Hello everyone, I have reviewed the forum looking for the solution to the "node-red-contrib-modbus" nodes, more specifically to the problem with serial modbus. The fact is that you can only read 13 consecutive holding or input registers, if you read more (120 according to the protocol specification) the slave device responds but node-red is not able to read it. Does anyone know the solution?
I have read in some forum topic that they have solved it by installing 64-bit Linux, but what happens if I use a board that can only install 32-bit Linux?
This doesnt sound right. I know some devices dont like to respond if they have gaps in their registers - that can trip you up.
Have you captured the serial data response and verified it is a valid modbus response (there are online tools like this one that can verify the response data)
Curious. Can you provide a link?
Dear Stive, I thank you in advance for your interest. When I tried to read Modbus RTU devices through the serial port, I sniffed the RS485 bus to see the messages and confirmed that after testing with several devices it is clearly a problem with the "node-red-contrib-modbus" collection of nodes. It can be reproduced perfectly with Raspberry Pi, NanoPI Neo and NanoPI DUO 2. To find out that the Modbus RTU device responds I have used a Saleae logic analyzer and my own software made with Qt which I have been using for years in my work and with both methods I have was able to confirm that the reading nodes are not capable of reading responses from more than 13 records.
The topic bothers me a lot because I am especially very scrupulous when programming PLCs with Modbus registers, I try to make all the registers correlative to reduce the number of messages needed per device (I always try to package all the functionality in a single message Modbus with up to 120 holding registers to be able to read multiple devices in the shortest possible time) and node red is today a very useful tool for me in my work, except for this inconvenience.
Can you provide the request and response bytes for 2 identical requests to the exact same device, same address and register count, from:
- Node-RED (the failed transaction)
- Some other application (one that succeeds)
Although I did not write the modbus nodes, I am keen to see if this is a real issue and would push to get it resolved sonce modbus is important to the community.
Are you inside my head 
This is something so many people get wrong. And the reason I wrote this article: Modernize your legacy industrial data. Part 2. • FlowFuse
1 Like
Well until Monday I can't do tests, on Monday I will collect evidence and pass it here
Hello again Steve, I am attaching a video in which you can clearly see how after 14 holding registers the serial port reading node fails. The hardware that node red has installed is a NanoPi Neo from "friendlyElec" with Ubuntu 20.04 LTS 4.14.111
Hey @T3NCHU4N I'll watch it shortly but in the meantime please include the requested data bytes as text.
From my humble opinion I think that the problem is in the way of managing the serial port, it seems to me that since it is not handled correctly based on a message length it loses control of what it should do. The bytes sent to you are:
Messages asking for 13 holding register:
01 03 12 00 00 13 135 95
Response from 13 holding register:
01 03 26 03 232 05 59 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 184
So far everything works, now we go with messages greater than or equal to 14 holding registers long:
Messages asking for 14 holding register:
01 03 12 00 00 14 199 94
Response from 14 holding register:
01 03 28 03 232 05 59 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 187 182
On the rs485 bus everything is correct as seen in the video but node-red is not able to read what it receives through the serial port. Another piece of information that may help is that the same thing happens with raspberry pi 3 but with node red running on a Windows PC this problem does not happen as you can see in this image:
So that data in hexadecimal bytes is
REQ
01 03 0C 00 00 0D 87 5F
RES
01 03 1A 03 E8 05 3B 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 B8
and they are valid RTU
REQ
RES
however,
that data in hexadecimal bytes is
REQ
01 03 0C 00 00 14 C7 5E
RES
01 03 1C 03 E8 05 3B 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BB B6
which is not valid RTU as far as I can see!
REQ
RES
Now in my defence, the tools I am using AND the node-red modbus node could be too strict or flawed - OR - the unit/software you are using could be overly permissive with the modbus specification *1, *2
*1 the invalid CRC on the request might be simply ignored by your slave. The modbus spec may even permit this
*2 it may or may not be permitted to provide a single byte for the last WORD in a RESPONSE by the official ModBus specification, however I have not gone down that rabbit hole.
PS, if you add the missing byte to your 14 WORD RESPONSE, it is valid:
01 03 1C 03 E8 05 3B 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BB B6
PS, you did NOT state whether this data was generated for NODE-RED or the other software
My info above assumed these were from the other software!
If not, try testing the bytes in other software in the online RTU checker
Steve hello again, the data that I have sent you and the video have been made as follows:
1.- A Modbus RTU slave device connects to an RS485 output from the NanoPi NEO development board.
2.- Node-Red is installed on the NanoPI NEO and, acting as master with the Modbus reading nodes, sends queries to read the registers of the slave device.
3.- In addition, a laptop PC is connected to the RS485 BUS using a USB to RS485 converter in listening mode to read the messages that circulate on the RS485 BUS. This is how I obtained the bytes of the messages, which I copied and pasted exactly as they come.
In the response plot to the 14-register question:
01 03 28 03 232 05 59 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 187 182
I see the 28 bytes of the byte number of bytes, sorry if I have not understood you correctly but you comment that a byte is missing in the slave's response:
01 03 28 03 232 05 59 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 187 182
01 03 1C 03 E8 05 3B 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BB B6
I repeat that I think the problem is in the management of the serial port
It seems that this topic is getting cold, it's a shame because many people are having the same problem.
It is cold because you have not cleanly provided the sample data I asked for and went on to say " I think the problem is in the management of the serial port" which is nothing to do with Node-RED!
If you can provide EXACTLY the things I ask for, I should be able to see the difference and understand what and why things are not working.
Let me ask one more time, with a bit more clarity from me too:
**Please respond with ALL data
- there should be 4 byte strings:**
- A request packet from the working setup (non node-red)
- A response packet from the working setup (non node-red)
- A request packet from the NON working setup (node-red)
- A response packet from the NON working setup (node-red)
- The SAME register address should be used for non-node-red and node-red operations
- The SAME slave device should be used for non-node-red and node-red operations
- Please paste the data as bytes (hexadecimal values) and please paste them in a code block.
Request & Response Data Packets for 14 Modbus registers:
NOT using Node-RED
Request Packet
01 03 0E etc etc
Response Packet
01 03 0E etc etc
Using Node-RED + node-red-contrib-modbus
Request Packet
01 03 0E etc etc
Response Packet
01 03 0E etc etc
Dear Steve, first of all I apologize if my comment may have bothered you, in my defense I can say that I am Spanish and I am using Google translator.
Continuing with the topic of Modbus nodes, I will tell you what you ask for, but I can tell you that I am using a PLC category device from among the more than 500 installed at my work and that work with all the software I have tested:
Requests from software other than Node-Red:
Master:
01 03 0c 00 00 0e c7 5e
Slave:
01 03 1c 03 e8 05 3b 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb b6
Requests using Node-Red + node-red-contrib-modbus:
Master(Node-Network):
01 03 0c 00 00 0e c7 5e
Slave(PLC):
01 03 1c 03 e8 05 3b 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb b6
This message is not able to be read by the "Read Modbus" node when more than 13 consecutive records are requested.
Sorry again for my insistence but the error is not here, I understand that the ideal would be for the developers to do the test with Raspberry PI for example.
I am doing another test with two USB to RS485 converters from Node-Red, the "Serial in" node uses converter 1 and reads everything that passes through the RS 485 bus and the "Read Modbus" node uses converter 2 to launch requests to the slave by the bus. You can check that it asks the questions and the device responds but the "Read Modbus" node does not know.
Video link: 2023-12-04 18-08-46.mkv - Google Drive
de nada 
But thats what I NEED to understand the issue. I NEED the request and response for 14!
The fact you have posted 2 working packets is not going to help anyone. I NEED the a GOOD 14 register request/response AND the broken 14 register request/response i'm afraid.
The request packets WILL be transmitting (and probably some kinda response will be occurring too) but you will need to capture the data using an intermediate tool - something that listens either on the wire or by using a software Null-modem / loop back.
I thought that you already had something to capture the packets Node-RED was sending and the device was replying with?
If not, then you need to either use a physical wire tap device or a software - something like com0com or Virtual Serial Port or portmon or even wireshark if your 485 convertor is Ethernet based.
I do hope you can successfully grab these and show me the GOOD and the FAILED request AND response packets - I would really like to get this resolved for the community.
PS, I appreciate you taking the time to follow up on this.
Sorry, perhaps I misunderstand.
That does look like a 14 register request. Both the REQUEST and RESPONSE are valid.
- Did you capture these packets between Node-RED and a real device?
- Did it fail to produce data in Node-RED?
I will check out the video when I get a chance
Steve hello again, to your questions:
Did you capture these packets between Node-RED and a real device?
Yes, and I have tried it with several Raspberry-type devices, and the truth is that I don't understand what happens, I imagine that the developers could use the debugging tools and see what happens. I understand that if it is tested and it works, you could tell us what hardware you have specifically used or version of Linux. Could it be the libraries for ARM?
Couldn't produce data in Node-RED?
No, it is true that among thousands of messages, someone has read it but with a maximum length of 14 records and I have seen it once or twice in months of attempts (hence my idea that it is due to the bit time).
Steve, you are my last hope, if it cannot be solved, it would be necessary to make software that runs on localhost and works through TCP and that the software handles RS485
@Steve-Mcl I don't know anything about the modbus nodes.... but is there anywhere in there that they may be doing a .toString on the incoming binary data? By default that would try to use utf-8 decoding rather than binary so could change the length of the output. But then again I would have expected to see more errors reported by users if that was the case here.
Hello @T3NCHU4N
i see from your screenshots and video that you are using the Modbus Read node ..
as an additional test can you check if the Modbus-Flex-Getter node experiences the same problem ?
The only difference between the two nodes is that the Flex-Getter can accept an external msg with the settings for the Modbus read.
Test Flow (check the configuration for your device) :
[{"id":"c271b2e90284c677","type":"inject","z":"54efb553244c241f","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":320,"y":2500,"wires":[["4819d151c4601f3b"]]},{"id":"4819d151c4601f3b","type":"function","z":"54efb553244c241f","name":"Modbus msg","func":"msg.payload = {\n 'value': msg.payload,\n 'fc': 3,\n 'unitid': 1,\n 'address': 3072,\n 'quantity': 14\n}\n\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":490,"y":2500,"wires":[["8aa3796a635e873c"]]},{"id":"8aa3796a635e873c","type":"modbus-flex-getter","z":"54efb553244c241f","name":"","showStatusActivities":false,"showErrors":false,"showWarnings":true,"logIOActivities":false,"server":"571417056c8dd220","useIOFile":false,"ioFile":"","useIOForPayload":false,"emptyMsgOnFail":false,"keepMsgProperties":false,"delayOnStart":false,"startDelayTime":"","x":720,"y":2500,"wires":[["4ee1b336b2b08fc1"],[]]},{"id":"4ee1b336b2b08fc1","type":"debug","z":"54efb553244c241f","name":"debug 39","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":930,"y":2480,"wires":[]},{"id":"571417056c8dd220","type":"modbus-client","name":"","clienttype":"simpleser","bufferCommands":true,"stateLogEnabled":false,"queueLogEnabled":false,"failureLogEnabled":true,"tcpHost":"127.0.0.1","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyS1","serialType":"RTU-BUFFERD","serialBaudrate":"19200","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","serialAsciiResponseStartDelimiter":"0x3A","unit_id":"1","commandDelay":"1","clientTimeout":"1000","reconnectOnTimeout":true,"reconnectTimeout":"2000","parallelUnitIdsAllowed":true,"showWarnings":true,"showLogs":true}]
Dear Unborn, I just tested the flow you sent:
1.- With 13 registers it works perfectly
2.- With 14 or more it does not work
Video link: 2023-12-05 07-10-29.mkv - Google Drive
