Modbus RTU write and read
Closed this issue · 15 comments
Hello
I'm carrying out a project where I intend to carry out the control through the Node-Red where I will be reading in sensor data and then with that data writing it to another device. Right now I am using a jetson nano directly connected to another jetson nano for writing testing but I enconter this problem:
Writing node red/jetson nano:
msg : string[60]
"Modbus Failure On State sending Get More About It By Logging"
msg : TransactionTimedOutError
"TransactionTimedOutError: Timed out"
msg : error
"Error: Client Not Ready To Write At State init"
Reading node red/jetson nano:
msg : string[60]
"Modbus Failure On State sending Get More About It By Logging"
msg : error
"Error: Timed out"
msg : error
"Error: Client Not Ready To Read At State init"
The flow for my write is
[{"id":"acefe3edeaaea469","type":"inject","z":"57325149c5ebdbcc","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[0,0,0,1,1,1]","payloadType":"json","x":90,"y":1080,"wires":[["5d070261787e3b4f"]]},{"id":"5d070261787e3b4f","type":"function","z":"57325149c5ebdbcc","name":"","func":"\n\n\nmsg.payload ={ value: msg.payload,\n 'fc': 5,\n 'unitid': 1,\n 'address': 0 ,\n 'quantity': 6 }\n\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":300,"y":1120,"wires":[["c77cda57d306495e"]]},{"id":"1b16fc2c2c07f65b","type":"inject","z":"57325149c5ebdbcc","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[1,1,1,0,0,0]","payloadType":"json","x":90,"y":1160,"wires":[["5d070261787e3b4f"]]},{"id":"c77cda57d306495e","type":"modbus-flex-write","z":"57325149c5ebdbcc","name":"","showStatusActivities":true,"showErrors":true,"server":"64e234ec8ad4b896","emptyMsgOnFail":false,"keepMsgProperties":false,"x":490,"y":1120,"wires":[["89369c2bcbeb76ca"],["0792493db10c2906"]]},{"id":"89369c2bcbeb76ca","type":"debug","z":"57325149c5ebdbcc","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":690,"y":1100,"wires":[]},{"id":"0792493db10c2906","type":"modbus-response","z":"57325149c5ebdbcc","name":"","registerShowMax":20,"x":710,"y":1180,"wires":[]},{"id":"64e234ec8ad4b896","type":"modbus-client","name":"RS485-1","clienttype":"simpleser","bufferCommands":true,"stateLogEnabled":false,"queueLogEnabled":false,"tcpHost":"127.0.0.1","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB0","serialType":"RTU","serialBaudrate":"4800","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","serialAsciiResponseStartDelimiter":"0x3A","unit_id":"1","commandDelay":"200","clientTimeout":"1000","reconnectOnTimeout":true,"reconnectTimeout":"2000","parallelUnitIdsAllowed":true}]
The flow for my read is
[{"id":"040f3f841721c8e4","type":"inject","z":"f9741d2194372498","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"5","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":210,"y":440,"wires":[["bc141855739a4d1a"]]},{"id":"bc141855739a4d1a","type":"function","z":"f9741d2194372498","name":"","func":"msg.payload = { \n'fc': 3, 'unitid': 1, 'address': 0 , \n'quantity': 6 } ;\nreturn msg\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":300,"y":560,"wires":[["ca1fd0284d866462"]]},{"id":"ca1fd0284d866462","type":"modbus-flex-getter","z":"f9741d2194372498","name":"","showStatusActivities":true,"showErrors":true,"logIOActivities":false,"server":"64e234ec8ad4b896","useIOFile":false,"ioFile":"","useIOForPayload":false,"emptyMsgOnFail":false,"keepMsgProperties":false,"x":410,"y":440,"wires":[["e64761381089d6d6"],["8f251f22d86c7791"]]},{"id":"e64761381089d6d6","type":"debug","z":"f9741d2194372498","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":510,"y":360,"wires":[]},{"id":"8f251f22d86c7791","type":"modbus-response","z":"f9741d2194372498","name":"","registerShowMax":20,"x":530,"y":560,"wires":[]},{"id":"64e234ec8ad4b896","type":"modbus-client","name":"RS485-1","clienttype":"simpleser","bufferCommands":true,"stateLogEnabled":true,"queueLogEnabled":false,"tcpHost":"127.0.0.1","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB0","serialType":"RTU","serialBaudrate":"4800","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","serialAsciiResponseStartDelimiter":"0x3A","unit_id":"1","commandDelay":"200","clientTimeout":"1000","reconnectOnTimeout":true,"reconnectTimeout":"2000","parallelUnitIdsAllowed":true}]
Please, try "RTU Buffered" and set a start time delay of 10 sec - messages showed that you try to send maybe to fast while init states and the connection was not established while sending read or write. You can use context variables inside the flow to set the state of your serial Modbus connection and then you could just read or write if the connection is available by checking this in a function node before.
I have tried changing to RTU Buffered and set a start time delay of 10 sec and it still has the same errors
what do you mean by " You can use context variables inside the flow to set the state of your serial Modbus connection and then you could just read or write if the connection is available by checking this in a function node before. "
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.
FYQ: see Node-RED Context
Other point - did you try to write the ttyUSB0 with the user where node-red works with? Maybe it is just a access right problem. Some Linux systems need to allow the user to read/write tty options or to grant access right to the tty file.
Have similar issue:
The connection seems to work just fine though, but seems a bit "risky" to base production on a node continuously reporting errors.
The Flex Write node flashes and does things even not getting any input:
flex.write.flutter.mov
The "Show Activity" checkbox in the settings, does not affect that - also unsure what this does (undocumented as per design, I guess)
Hi @hoegge, I think the node has the "Show Activities" active on true and then it is very fast to reconnect or changing its states on sending Modbus commands. As the message explains, you can see more if you activate all logging as to find here DEBUG - The "Get" is start reading. Maybe you have to be sure, that you do not read and write at the same time or to have other sharing of the port commands if it is serial Modbus.
Hi @biancode . The strange thing is that if I set "Show Activity" to false and even disconnect the input (both the case in the attached video above) it still behaves the same. Blinking activity and showing activity. The output errors in the debug pane stops though.
Is it at all possible to read and write at the same time in Node-red? NodeJS is single threaded, but of course if the reads/writes are done async it is possible. I run TCP/IP only, so then it should not be a problem, should it?
And all these appear at the same instance (within less than a second) without anything being sent to the node, i.e., it is not sending data to the Modbus device either. So errors and activity occurs spontaneously without any input to the node (v 5.21.2):
TCP can work in parallel. Then 11 or like this count nodes try to work with the same client at the same time and get all informed from this client about the problem to send the command. Is the parallel queue option active? Otherwise, there is a Modbus failure from the device maybe?
Do you have one connector (client) in Node-RED for the nodes or multiple? One should work better. One for reading and one for writing on TCP flows.
For writing I have only a single node, but multiple for reading (4 flex getters and 1 flex sequencer). So does this mean thet getters interfere also with the single setter node?
Why it it better with just one getter and one setter? Do they share any state? I thought they shared a "modbus server instance", where things / interaction with the modbus server was queued
It also seems like, there is something a bit weird with the activity lights. The activity on the write node flashes, when the queue processes reads, and the flex get nodes' activity are always just passive. Is that how it should be?
activity.modbus.mov
TCP can work in parallel. Then 11 or like this count nodes try to work with the same client at the same time and get all informed from this client about the problem to send the command. Is the parallel queue option active? Otherwise, there is a Modbus failure from the device maybe?
Well, are they really working at the same time? Node.js is single threaded, right, so each node would never fire simultaneously? And is it really ok that the write node flashes when the flex-sequence-getter is firing? Is there some kind of cross-talk or wrong mix-up between getters and setter?
Right, they are not really working at the same time, but it is in the Promises to schedule for a parallel like operation with the separated queues and TCP requests asap.
Yes, it is really ok that the write node flashes when the flex-sequence-getter is firing, because the write has to queue from an input. It is in the hands of the program/flow to handle the sending to inputs. If there is some and write is not possible and the queue is active, then it gives the msg to the queue for the next step to send it to the client later.
In my projects I use a read and a write client on TCP to have a clean read - write parallelism.
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.