Yes, I agree with you. We are trying to make an effort to have more crucial information available for those who are developing.
Look at this message that the OEM manufacturer sent me a few days ago when we were discussing about my issue:
"Hello Gonçalo,
we are now finished our investigations and we now come to the conclusion that we can say that the behavior of Node-RED to stop from time to time for short moments
seems to be normal. Even with the newest version of Node-RED and plugins installed in combination with the allocation of more CPU power and RAM for the container.
For us, this is also plausible due to the fact that Node-RED is a non-real-time capable system. This is for instance recognisable just if you enter the Node-RED configuration WEB-UI.
But one thing we could recognize, that using Modbus-Flex-Getter reduced in any case the stability."
I run node-red on numerous low power devices, old Pi Zeros for example. As long as one is not doing anything massively intensive then I don't see pauses. At least not often enough to notice.
How often are you triggering the modbus comms?
Have you got multiple modbus nodes?
I'm triggering the Modbus comms each 2 seconds.
I used to have multiple Modbus nodes, but now I only have one communicating with several devices (7 devices).
The problem is that right now I've started a project from scratch and I only have 2 flows and only one is communicating via CAN. The other one is just processing variables. The issue still occurs.
Yes, this is a regular IoT/embedded system type problem. You also see it on medical devices as well.
Done properly, the manufacturer would surface the Node-RED logs to a web page, or make them accessible to an external syslog or even MQTT. Node-RED has the settings to allow this so it really isn't that hard. I even have a flow that lets me see trace-level logs for the uibuilder runtime on a web page (hosted by uibuilder of course! Very meta) - requires a custom log setting though so can't be done unless someone has access to settings.js.
Hmm, actually, thinking about it, you could probably alter settings.js from Node-RED then restart the device.
Hello Colin.
Hope you're doing fine.
I think I found a big clue regarding the freezing problem when I was testing with only 2 flows and CAN communication.
I noticed that it wasn't the Node-RED, but the socketcan nodes. I connected a Debug node to the socketcan read node and checked that from time to time I stopped receiving CAN frames, even though I was sending each 100ms.
In fact, the problem may lie with the physical communication interfaces (RS-485 and CAN). @TotallyInformation@Trying_to_learn
In general, another thing to watch out for is cloning of messages.
IF your messages could contain larger amounts of data, they are still really quick between nodes if there is no cloning. However, for example attaching a debug node to monitor a message COULD cause a clone, and a clone of large data can take a long time.
It does not sound like this is your issue, but it's something to be aware of.
It's also important to understand garbage collection if expecting 100ms response times. NodeJS can hang for 100-200ms when it hits a complex garbage collect; not a great deal you can do about it since NR and it's supporting libraries are complex beasts :(.
Thank you for your feedback!
When you talk about “Cloning”, do you mean passing the same message to multiple nodes?
In fact, I deleted all my Debug nodes but I still have many Function nodes in parallel.
yep. Any place where you have two wires out of a single output. But in modern NR, I believe you also have some control over cloning.
But it won't be a problem unless you have large data - it's just something to be aware of.
ONE way around it is to store the data in global or flow, and reference it using an id, then pass the id.
(I found this when doing a lot of image processing...)
Another (and arguably better way) is to keep the data in the msg and do things in series (it is very easy to hit concurrency issues with context). You dont have to stick with msg.payload. You can put stuff into msg.myProp1, msg.myOtherProp, msg.sommitElseEntierly and pass it to the next node and so on. It is only when you branch off to multiple wires that you start cloning.
