I realize this thread is getting a little old but just wondered if the issues I am having are in any way related...
I had a port USB/RS485 module, a Waveshare, connecting 3 separate devices, a PLC running at 19200, a meter at 9600 and an IO module also at 9600.
Additionally there is an inverter which is Modbus TCP.
Initially I was just polling the lot every second, for basic data, and not worrying If I needed to send something to the PLC, assuming that the Flex Nodes would handle the queuing.
That wasn't stable, I assumed due to the USB device, so I dropped the pole frequency and sequenced them manually.
I still want worrying about occasionally sending stuff to thew PLC, because of the queues but it became obvious fairly quickly that all was not well, and still isn't...
When first deployed all looks OK, there would be the very occasional fail, but generally stuff works almost all the time. However, depending on the pole rate, and remembering that stuff is still sequenced with the flow, after an hour or two the fail rate on all devices would start creeping up and once it did it would o up exponentially until nothing was talking.
At which point the only way to restore coms was to restart Node-Red. Disabling all FlexNodes and re-enabling them didn't work disabling/enabling flows didn't work.
The rest of the flows looked just fine and looking at the OS, a Raspberry 5 running PI OS from an SSD, there didn't appear to be any issue with processor load or memory.
And yet the issue feels like a memory leek.
I swapped out the 4 port USB serial converter for 3 separate units, on separate USB ports.
That helped with the PLC error rate somewhat, the original worst offender, so perhaps port contention was a contributory factor but the time it takes to 'lock up' hasn't changed much, its just that the errors show up on the grid meter first now.
I am now polling all 4 getter nodes at the same time, all be it, only every 2 seconds, and stopping the pole to the PLC if UI need to write something, and it is still locking up.
I haven't posted code because it is a mess after so much mucking about. I think I have tried everything obvious, including only ever doing one thing at once to a single device on its own USB port and nothing stays stable.
Less traffic results in less errors so a longer time before it needs to be restarted but after fiddling with everything I can think of for well over 6 weeks I am unable to get it stable.
The really odd thing is that I have another system elsewhere, talking to several Modbus devices, 2 PLC's, 4 grid meters and 4 inverters, the latter 4 being RTU whilst the rest are TCP.
I only have one issue with that system, which is a single getter latching up at initialize, every few weeks, and that getter is reaching out over the web to a remote TCP/RTU converter to read a meter on the other side of the estate.
I don't see the same degradation over time and the one node that I haven't been able to get properly stable can be 'recovered' by disabling/enabling it.
Were it not for the problem node, with the TCP/RTU converter on the other system, I would be swapping out USB/RTU to TCP/RTU on the newer system that is locking up.
I am utterly at a loos as to know where to go with it and it is driving me daft now as well as making me look somewhat inept...
Anyone have any thoughts? Is there a simpler Modbus Node I can use, even I have to build a flow to handle queues and errors?
Lastly I use the basic getter, no inbuilt queuing, and have 3 of them utilizing separate USB ports, should I still avoid traffic on more than one of them at a time, or can I use them in parallel?
FYI.
I have asked about the 'Flex getter stuck initializing' thing before... Didn't find an answer!
Odd issue with Modbus Flex Getter - General - Node-RED Forum
Thanks for looking,
Al
