search

BiancoRoyal / node-red-contrib-modbus

maintained by PLUS for Node-RED - https://plus4nodered.com
https://www.npmjs.com/package/node-red-contrib-modbus
BSD 3-Clause "New" or "Revised" License
278 stars 107 forks source link

Modbus TCP Communications Stops After Days of Operation #451

Open aquiot-inc opened 3 months ago

aquiot-inc commented 3 months ago

Which node-red-contrib-modbus version are you using?

5.26.0

What happened?

I have had a problem with node-red-contrib-modbus Modbus TCP Client being "hung" (not firing attached nodes properly) after a number of days of running continuously (doing Modbus TCP only, no serial RTU). It's difficult to reproduce/debug because it's running in NodeRed and it takes days to show up. So I'm wondering if I may be be seeing something related to this: https://github.com/Cloud-Automation/node-modbus/issues/329

Also, this possibly similar issue that was never resolved:

Server

Other/External server

How can this be reproduced?

I will try to devise a simple flow to show this error as it is currently part of a complex set of flows. At this point, trying to determine if anyone has seen this issue.

My flow has 3 Flex-Getter nodes being triggered every second with 500ms timeout and no Reconnect on timeout. So, responses are expected quickly, otherwise timeout and start again on the next 1s trigger.

System is able to recover from un-plugging re-plugging Ethernet cables. When the "crash" occurs, it is after multiple days of otherwise normal operation. When this happens, NodeRed is able to process other flows but all 3 of the Flex-Getter nodes don't seem to be outputting anything even though the Modbus devices (servers) are available on the network and work fine after NodeRed is restarted.

What did you expect to happen?

The flow should keep working. If there is any network problem (if that is part of what happened), timeout should occur and the nodes should be idle until the next trigger.

Might be helpful to have a way to restart the Modbus clients, full deallocation of all resources and reinitialize. This could then be triggered by a watchdog type of flow/subflow.

Are people normally expecting NodeRed + node-red-contrib-modbus flows to work continuously without such interruptions. I.E. is this a reliable thing for real-world mission critical applications?

Other Information

Running NodeRed v3.0.2 on Weidmüller GW30 PLC running u-OS

kommando828 commented 3 months ago

I have a Pi running a bluetooth sensor, randomly it stops detecting bluetooth signals after a few days. Cured the issue by setting a timer to reboot the Pi overnight at 3am. You will lose the Modbus connection for 2 to 3 mins every 24 hours but at least it will run at all times between the reboots.

aquiot-inc commented 3 months ago

I have a Pi running a bluetooth sensor, randomly it stops detecting bluetooth signals after a few days. Cured the issue by setting a timer to reboot the Pi overnight at 3am. ...

I though about something like that. However, it avoids the problem instead of fixing it. For me, It would be better done using a watchdog instead of fixed timer. Also, the restart would need to be done outside of Node Red in case NR gets into a state where it cannot process the timer flow.

kommando828 commented 3 months ago

Try this

https://forums.raspberrypi.com/viewtopic.php?t=126106

Waiting for a fix when

https://github.com/BiancoRoyal/node-red-contrib-modbus/issues/410

it is time to build a "VERY NEW VERSION Q4-2023" until that time we do not fix issues here

means that any bugs on the current version are only going to be fixed after the new release means a short term fix is DIY.

biancode commented 3 months ago

The Modbus Flex-Connector can help in that case to switch to a simulated Modbus Server inside Node-RED and switch back every night from my perspective. The whole re-init and other new features are in the very new package and we hope to release it end of Q2 or in Q3 latest. We hope to get some more support for it see https://p4nr.com/