Optimizing MODBUS Flex Getter Nodes

Node-RED
1

Hello,

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.

Dan

forumpostnodered
forumpostnodered1704×902 173 KB

2

That’s a pretty terrifying screenshot depending on whats in the function block… Are you able to share the JavaScript?

3

msg.payload = (value: msg.payload, ‘fc’:3,‘unitid’:255,‘address’:500,‘quantity’:1)
return msg;

just reading the one register and then pushing it to PAC for error handling

4

So the function node fires off all those getter nodes at once.
I think that might be a big issue.

Take a look at this thread and this summary here:

5

Thanks for the info Beno.

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.

6

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.

7

optoforumnodered
optoforumnodered1080×875 175 KB

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.

8

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.

9

See this post:

image
image804×131 15 KB

2 Likes
10

Farout!! @grant1 that was both exciting and painful to read!
What a thread!

Thanks for the link @philip

1 Like
11

Once again the forums to the rescue! Thanks @philip my flow now reads regardless of device state and isn’t going to ‘sleep’.

Thanks also to @Beno - hope the garage is good and clean.

Dan

1 Like
12

Oh yeah, that thread was a beast. Glad it served some purpose here.

13

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.

14

You could take all the delay nodes out.
Would it be quick enough without them?
The key is to make it flow vs parallel.