Dashboard 2 line chart data format

Dashboard
,
1

Hello,
For reasons unrelated to this question I need to migrate a flow from Dashboard 1 to Dashboard 2. In Dashboard 1, I was feeding instrument data to a chart node, repetitively to make a waveform viewer that looked like an oscilloscope. The instrument data came from some C code that talked to the hardware. The Dashboard 1 chart node required a very specific json format so my C code printed the data to that format and I used a json node to convert that string to a json object that I connected to the DB1 chart, creating an xy line plot. It worked great.

The DB2 chart looks much more flexible and I can make my C code generate output in any format. What would be an efficient and simple format to generate my data? How should I configure the DB2 chart for that data?

Any advice is appreciated.

2

You can simply create an array of objects, where each contains properties "x" and "y", though you can name them whatever you like. Look at the config dialog for the chart node and it should be fairly obvious how to configure it.

3

Yes, I downloaded the scatter plot example for the DB2 chart node and observed what was going to the chart. My data is generated by a C language program run by an exec node. Below is what the json text looks like. I feed it through a json node to make a json object and then send that to the DB2 chart node. It works, but it is much much slower than the old DB1 chart node. That's a question for another thread though.

I checked it all in at node-red_experiments/db2_chart at main · hdlguy/node-red_experiments · GitHub

$ ./json_gen 10
[
    {"x": 0, "y": 138 },
    {"x": 1, "y": 6333 },
    {"x": 2, "y": 10638 },
    {"x": 3, "y": 10985 },
    {"x": 4, "y": 7462 },
    {"x": 5, "y": 172 },
    {"x": 6, "y": -5316 },
    {"x": 7, "y": -8328 },
    {"x": 8, "y": -9482 },
    {"x": 9, "y": -3933 }
]
4

To be pedantic, what comes out of the JSON node is a javascript object, not a JSON object. JSON is always a string.

The DB2 chart node should not be slow, plotting 10 points should be effectively instantaneous. What is it that is slow? Are you hitting the exec node 5 times/second as your flow suggests? If so, are you sure the code you are running from the exec node can run at that speed? To check, disconnect the chart and replace it with a debug node. Run it for a few seconds then look back and make sure you are getting 5 debug outputs/second.

Edit, I presume you are running the most recent version of the dashboard.

5

I'm not sure this is the place to discuss the speed of the DB2 chart node versus the DB1 chart node but I will describe the experiments I have done.

First I constructed an FPGA based prototype instrument that generated data resembling a digital oscilloscope with a pulse generator attached as the signal source. I built the Web UI for it using Node-Red and Dashboard 1.0. The FPGA was connected to a Raspberry Pi 5 by a PCI Express link. I wrote a collection of C programs that would let me control the instrument from the command line. Then I used Node-Red and DB1 to call the programs with exec nodes. One program would set the parameters of the instrument, things like pulse width, repetition rate and record length. Then I had another program that triggered a waveform capture. Finally, a program reads the waveform data from the FPGA over PCIe and sends it to stdout as properly formed json text.

In DB1 all those operations could runs so fast that the waveforms updated at a rate faster than 10 waveforms per second. This worked with record lengths up to 4096 sample points. The overall effect felt very real-time, like an oscilloscope.

I constructed the same type of thing with the DB2 chart node and it could not handle waveform updates any faster than once per second. The full 4K records could only run once every several seconds. To study the performance problem I constructed a simpler flow that could run directly on a my Linux desktop computer without the Raspberry Pi or FPGA. The C code just sends out a record of data as json text whenever the exec node is triggered. With the exec node driving only a debug node it can run faster than a 10Hz, However, when I connect it to the DB2 chart node it cannot complete the graphing of the waveform at that rate. It can only run at about 1Hz with 1k length records. This analysis tells me that the chart node is the piece that is slowing things way down.

It is possible I have a setting in the DB2 chart node that makes it slow but I have experimented a lot with this setup and it is always slow. My guess is that the underlying rendering code in the DB2 chart node is slower than the DB1 chart node. I think I have the latest version.

$ node-red --version
Node-RED v4.0.9
Node.js v22.14.0
Linux 6.8.0-85-generic x64 LE

At this time, I think I will need to look for other ways to plot waveforms with Dashboard 2.0. There are optimized javascript libraries for the purpose.

I should run this simplified experiment in DB1 and verifiy that it is very fast.

6

Check in Manage Palette that you have the latest version of @flowfuse/node-red-dashboard. It should be 1.29.0

7

This surprised me so I checked. In some very simple testing, it does indeed appear to be that way.

There may be a bug in DB2 chart code as I witnessed the below in my trials:

image
image1396×598 77.4 KB

8

There is a bug that means that old data are removed from the chart when the 'older than' option is selected. The fix appears to be simple, but in fact is not as simple as it looks. I am on the road at the moment but will post about it later today.

9

Hello Guys,
Thanks for all the help. It wasn't my purpose to make work for anyone but if I helped you find a subtle issue in the DB2 chart node, that's good thing.

Nothing I'm doing is urgent, but I do want to use DB2 for plotting waveforms. The other page of my flow updates the configuration flash of the FPGA. It needs the DB2 file upload node and progress bar node from DB2.

10

TBF, this is likely the cause of dashboard slowdowns and crashes - it was important enough to deal with.

There is an open PR here. I have asked @Colin to kindly review it (he has a keen eye for these things).

11

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