Chart Performance - Covid-19 Project

General
1

In order to enhance the line chart performance, is there a way to avoid the rendering of the whole chart when a new value comes in? What I mean is that just the new point is graphed and the points before it remain on the graph and after the desired number of ponits have been graphed, the chart is cleared and the process repeats.

Many thanks!

2

Welcome to the forum @xpercad. Assuming you are talking about the standard dashboard chart node then I do not believe that is possible. The best way of enhancing performance is to make sure that the rate that you provide data matches the size of the chart. So for example, if the chart were 240 pixels wide and the time range across the full chart is four hours (choosing two numbers entirely at random) then make sure that each line on the chart is not given new data more often that once a minute, so there is one sample for each pixel. Sending it data more rapidly than that does little to improve the chart and the more points you have the more data the browser has to move each time there is a new point added.
Note that the overheads of a chart are mostly in the browser rather than in node-red itself. The worst case situation is, of course, running both the browser and node-red in something like a Pi. In practice only a Pi 4 is capable of running a browser, particularly with charts unless you can tolerate a slow GUI.
I run all my Pis headless and run browsers on PCs and mobile devices. Of course you may not be using a Pi at all, I don't know.

3

Hi Colin, thank you so much for the welcome message and for your answer.

I am working on the GUI for a ventilator for COVID-19. I am using a Pi 4 for running the control software, the browser, node-red and I am using the standard dashboard chart node. As far as the GUI is concerned, I have more or less everything sorted out except one chart that I need to display in real time. The chart needs to receive and display samples every 50ms and it needs to display 12 sesconds of samples, that is, 240 samples and then reset and begin with a new chart.

I understand that the bottleneck is the browser trying to keep up with the code being generated by node-red and executing it. So my first question is if it could be possible to code a new chart node that would generate more efficient code for the browser, just suited for my particular need so it could run in the Pi 4. My second question and favor to ask is if you can point me to some other way of solving the problem.

Cheers!

4

Is there a reason why the chart needs to reset? wouldn't it be advantageous to have a continuous chart, with data older than 12 seconds falling off the end.
If the chart resets, there would be no context from the preceding 11 seconds.

  • Please note @xpercad that I've moved these posts to their own thread for prominence.
6

You are right, resetting the chart is not necessary. What is really important is displaying the chart in a timely manner.

7

Yes certainly that (the chart) could be done. The dashboard is designed for ease of use without having to have a detailed knowledge of html, javascript and css. The result is that it is fairly heavy on resources. A programmer with appropriate skills could design a much more efficient chart designed for your particular requirements. Probably you should start by looking at uibuilder as the base on which to build your UI.

However I am not sure that even a Pi4 (running Raspbian) will guarantee that you get 50ms samples fully reliably. Linux is not a real time OS and nodejs is single threaded so if anything in your flows or in the system locks out your sampling code for more than 50ms (which is entirely possible) then you will miss or delay samples. This may or may not matter to you.

As a matter of interest, if you reduce the sample rate, what rate will it run at before it clogs up?

Have you confirmed that it is definitely the browser that locks up by running the browser in a PC connected to the node-red running in the Pi?

8

This is a Pi3 running at 50mS - showing the last 12 seconds of random data

[{"id":"2eebdc26.ca1cc4","type":"inject","z":"c0dd6248.e3849","name":"","topic":"","payload":"","payloadType":"date","repeat":"0.05","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":120,"wires":[["77e55934.2f3b38"]]},{"id":"77e55934.2f3b38","type":"random","z":"c0dd6248.e3849","name":"","low":"1","high":"10","inte":"false","property":"payload","x":340,"y":120,"wires":[["9de9b58a.304e48"]]},{"id":"9de9b58a.304e48","type":"ui_chart","z":"c0dd6248.e3849","name":"","group":"1e960ad2.679125","order":0,"width":0,"height":0,"label":"chart","chartType":"line","legend":"false","xformat":"HH:mm:ss","interpolate":"cubic","nodata":"","dot":false,"ymin":"","ymax":"","removeOlder":"12","removeOlderPoints":"","removeOlderUnit":"1","cutout":0,"useOneColor":false,"useUTC":false,"colors":["#1f77b4","#aec7e8","#ff7f0e","#2ca02c","#98df8a","#d62728","#ff9896","#9467bd","#c5b0d5"],"useOldStyle":false,"outputs":1,"x":510,"y":120,"wires":[[]]},{"id":"1e960ad2.679125","type":"ui_group","name":"Group 1","tab":"e1c65761.441108","order":1,"disp":true,"width":6},{"id":"e1c65761.441108","type":"ui_tab","name":"Tab 3","icon":"dashboard","order":3}]

but as Colin noted it is not a realtime operating system so you may get other interruptions (not least memory garbage collection on the nodejs process).
Likewise - Node-RED is in no way certified for any life critical medical application, so while I applaud your efforts, and while extraordinary times call for extraordinary actions, please ensure that this is not on the critical path of any solution, and that it will fail safe every time.

2 Likes
9

@dceejay Is that running the browser in the Pi?

10

Ah. Course not :slight_smile:

11

I thought maybe you had found a way of super charging the Pi or had rapidly developed a new browser that requires an order of magnitude less resources.

12

Yes, that's definitely the case. Running the browser on a PC is a different story, even running the browser on a PC accessing node-red from the internet is more responsive than the browser in the RPi 4.

I will give it a go with uibuilder and my last resource could be to use a tablet or something similar connected to the Pi via ethernet or USB, WiFi can be problematic in hospitals.

Many Thanks!

13

Yes, I am aware of the risks. As much as we can, we are trying to "guarantee" fail safe operation on the hardware side, and mostly on the pneumatic side of things. That is one aspect over which I am loosing a lot of sleep :anguished:

1 Like
14

I would lend a hand myself, but I don't have that skill set in sufficient depth either.
Now if you had a PID loop that needed tuning then I'm your man.

On the chart, looking a the example @dceejay posted, it appears that it moves the chart back about a second and fills up the gap at the end and moves it again. I wonder whether it would help if it did, for example, 5 seconds each time so that it doesn't move it as often. I haven't looked at the code but I imagine it would likely be a simple hack to change that, at least as an experiment to see if it helped.

15

Just trying the chart on a Pi3b+ ...
I get a few blips at 50mS, but at 100mS it performs reasonably well, although you can still see a small amount of distortion in the sine, due to delays in the system causing the datapoint to arrive a little late.

sine

16

Again, is that running the browser on the Pi, which is the main problem that the OP has, I believe.

17

No a network PC, I missed that important point! :eyeglasses:

18

I tried the example @dceejay posted and it ran like the wind running the browser on the Pi 4. Thanks to that, I noticed I was completely wrong with the settings of the chart node I was using. To make sure it was working, I pinged the random node using a UDP input node and running an external UDP client, not within NODE-RED, sending packets every 50ms and the chart displays smoothly.

Again, many thanks!

19

Thanks for the offer, I'll ping you shortly.

20

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.