I’m looking for some advice on how to optimize the flex getter node. Currently, the implementation works quite well - until I cycle power on some of the devices. After cycling power, sometimes - not everytime, the inject seems to ‘stop’. Is there something that I can change to prevent this from happening. I was reading about this on another forum and someone wrote about packet collisions when cycling power, but I thought that the flex-getter was supposed to automatically queue the inject. I’m relattively new to this so I could be misunderstanding.
I modified my flow to a sequential style with some 0.1 s delays after each write to the PAC Controller. When I did this the flow was functional until a MODBUS device in the sequence was offline - then the inject stops at that device. Once back online, everything works ok again. Similarly, when the first device in the sequence is offline, the inject stops all together. This is the same problem I was having with my mass function inject.
Is there a way to automatically redeploy the flow to get the connection re-established? Redeploying the flow seems to be the only sure fire way to get the flow to start working again.
Sorry for the brief replies yesterday, I was cleaning out my garage… well, trying to…
Glad you picked up the key point. Having more than 2-3 of anything parallel in Node-RED is usually not a good thing. Having as many as you had really was not getting the flow off to a good start.
Converting it to sequential style was the first step to debugging.
Thanks for the slightly different description of the issue just now, sounds like the Modbus node is just hanging on forever vs timing-out and moving on.
Looking at that nodes GitHub issues: GitHub - BiancoRoyal/node-red-contrib-modbus-flex-server: maintained by PLUS for Node-RED - https://plus4nodered.com I don’t see anything like this, so it might be worth an ask if there is a way to get it to timeout and move on.
You could include a screenshot of the new flow layout and describe it just as you have here, I think that should be clear what the issue is.
I’d rather see if there is a fix for that vs trying to have another flow look at this flow and doing the Node-RED API call to re-kick that flow to get it running again.
Here is the updated flow - so for example if the Infeed Rotary Feeder device goes off line I loose all the reads following. I don’t see anything about passing through on timeout in the flex-getter options.
I did not see anything either and yet it seems so obvious… hence I think its worth an ask on their GitHub.
Do you have an account?
If not I guess I could ask.
Although passing the information though was good for catching offline devices. How I had node red set up was too slow for our process. I’ll have to go back to the drawing board and see if I can make communications more efficient at our site.