Node-RED vs LabVIEW (DAQ solutions)


I just want to hear your guys opinion on Node-RED increasing precence in the DAQ community and its ability to challenge traditional softwares as LabVIEW.

I believe that when the new features as testing and breakpoint debugging are added it really can start eating up the DAQ market.

What are your opinions?

Also what is the challenges Node-RED face regarding performance? Although not C/C++ I believe the NodeJS runtime is quite powerful & capable but I wonder what one can do to increase performance in for example DAQ solutions where one need to process and write to local storage from multiple sensors at sample rates as low as 10 ms. Does anyone have experience with for example using Node-RED with real time operating systems as RTOS? Does it increase performance/reliability?

Many thanks for your inputs!:slight_smile:

There is a debugger plugin (with break points)

1 Like

Oh really, have not been using that only heard about it on a podcast recently. Still using the common/core debug node.. Thanks!

We have been using Node-RED with high-speed DAQ.

The application includes wireless gateway for ultra-low power wireless vibration & temperature sensors. The sample rate of the sensors go up to 26kHz.

The other application is multichannel ultrasonic system for SHM and PHM such as BroadScan D200. The sample rate goes up to 80MHz.

At these high sample rates, it is mandatory to have external ICs to process the high speed data, since Node-RED is based on Node.js. Node.js is not real-time processing, and the OS is not real time either.

As long as the interface with Node-RED buffering is handled correctly, then high speed DAQ is not a problem. Node-RED is great for IOT applications, which has significant advantage over LabView.

As to LabView, it is used extensively for DAQ and signal processing, so users have much easier time handling high-speed DAQ and quick data analysis.


Apart from the obvious cost difference between Node-RED and LabView, I think the other potential issue would be whether you can find the right experienced people to work on projects. I'm not an expert in this area but commonly, the prevailing industry standard attracts the most talent. Node-RED is currently at least, somewhat off the beaten track in this area I suspect?

Thanks for answers!

Yeah I have used Node-RED and LabVIEW but both because of cost as well as complexity/rigidity of LabVIEW I have stopped using it.

Node-RED just seems much more capable with endless choices and configurations. My only worry is the performance and ability to absorb huge amount of data alongside some processing and writing to csv file.

Does anyone know limits/benchmarks of for example Raspberry Pi 4B for this kind of setup?

I don't think it is very predictable since there are so many variables. Certainly there are things you can do to optimise the performance of the device and OS and get rid of unnecessary services. But then you are still highly dependent on how data is being received and what flows you are running.

I know that people on the forum have reported very high throughputs but without testing for your specific scenarios, it would just be guesswork.

Certainly, most of us would recommend using dedicated, real-time capable hardware such as ESP32's for collating high-speed data inputs and then feeding that data through to a central server. That's because a Pi can never be a real-time platform and was designed primarily as a learning platform not an industrial one (not a criticism, it has done amazingly all things considered).

Although there are several RTOS versions available for it. I have no experience, and I don't know if node-red would even run on a RTOS system, but it may be worth looking at.

Well, you can run Node-RED on some ESP's :slight_smile: But realistically, Node.js isn't a real time system either.

But, as said, thanks to the V8 engine running under Node.JS, Node-RED is surprisingly performant in many cases. But it does carry a LOT of baggage. That isn't a criticism, merely an observation. It does a lot of work in the background so you don't have to program it.

And, of course, the Pi itself has a lot of compromises in certain areas. Again, not really a criticism, they had to be made in order to hit the right price-point.

1 Like

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