Issue with multiple modbus rtu slaves

I’m submitting a … (check one with “x”)

Support/Advice

• support/advice request => Please do not submit support requests here, instead use the link to our support page, please!

Feature

• ( ) feature request

What is the motivation / use case for changing the behavior?

Simple question to get some hint

• ( ) simple question => please visit the Wiki, the YouTube tutorials and the Info tab by clicking on the node inside Node-RED before
• ( ) help wanted => you read all information and watched relevant YouTube tutorials, but you need more help

Problem

• (X) bug report => please search github for a similar issue or PR and test Modbus problems with the modbus-serial package before submitting
• ( ) unexpected behavior => please visit the Wiki before

Current behavior

Setting up multiple modbus rtu/rtu buffered slaves that utilise the same serial port cause issues. Setting up one at a time and testing works fine, which confirms there isn’t an issue with main codebase or hardware setup. More info here, https://discourse.nodered.org/t/multiple-modbus-rtu-slaves-causes-error/18783/8

Expected behavior

Multiple slaves should be accessible via the same serial port. Commands send concurrently should be queued per server, as not to choke up the comms bus. The same is true for initialisation, because as far as my tests show, these all try and happen at the same time, causing none of the servers to initialise.

Minimal reproduction of the problem with instructions

Hard to reproduce if you don’t have the same hardware setup. However there are two modbus slaves on each of the two node red tabs copied below. Disabling one tab and deploying allows the other connection to work fine. Enabling both causes the error condition above, proving that it’s an issue only with multiple modbus slaves on the same serial port.

Flow 2A:

[ { "id": "ae505081.3307", "type": "modbus-read", "z": "5484bbf1.3f12e4", "name": "digi", "topic": "", "showStatusActivities": false, "logIOActivities": false, "showErrors": false, "unitid": "", "dataType": "HoldingRegister", "adr": "14", "quantity": "1", "rate": "5", "rateUnit": "s", "delayOnStart": true, "startDelayTime": "1", "server": "7a2d3f7d.23a34", "useIOFile": false, "ioFile": "", "useIOForPayload": false, "x": 170, "y": 100, "wires": [ [ "d6f6caad.6f5908" ], [] ] }, { "id": "d6f6caad.6f5908", "type": "debug", "z": "5484bbf1.3f12e4", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "x": 400, "y": 100, "wires": [] }, { "id": "7a2d3f7d.23a34", "type": "modbus-client", "z": "", "name": "Novus DigiRail 2A", "clienttype": "serial", "bufferCommands": true, "stateLogEnabled": false, "tcpHost": "127.0.0.1", "tcpPort": "502", "tcpType": "DEFAULT", "serialPort": "/dev/tty.usbserial-14130", "serialType": "RTU", "serialBaudrate": "9600", "serialDatabits": "8", "serialStopbits": "1", "serialParity": "even", "serialConnectionDelay": "1000", "unit_id": "246", "commandDelay": "1000", "clientTimeout": "1000", "reconnectTimeout": "2000" } ]

Flow 4C:

[ { "id": "6265f722.682958", "type": "modbus-read", "z": "9e57cfa0.6fc53", "name": "rail", "topic": "", "showStatusActivities": false, "logIOActivities": false, "showErrors": false, "unitid": "", "dataType": "HoldingRegister", "adr": "512", "quantity": "1", "rate": "7", "rateUnit": "s", "delayOnStart": false, "startDelayTime": "", "server": "1ee5d4d5.ce5dab", "useIOFile": false, "ioFile": "", "useIOForPayload": false, "x": 230, "y": 100, "wires": [ [ "3bc7006b.b025f" ], [] ] }, { "id": "3bc7006b.b025f", "type": "debug", "z": "9e57cfa0.6fc53", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "x": 470, "y": 100, "wires": [] }, { "id": "1ee5d4d5.ce5dab", "type": "modbus-client", "z": "", "name": "DigiRail 4C", "clienttype": "serial", "bufferCommands": true, "stateLogEnabled": false, "tcpHost": "127.0.0.1", "tcpPort": "502", "tcpType": "DEFAULT", "serialPort": "/dev/tty.usbserial-14130", "serialType": "RTU", "serialBaudrate": "9600", "serialDatabits": "8", "serialStopbits": "1", "serialParity": "even", "serialConnectionDelay": "100", "unit_id": "247", "commandDelay": "1", "clientTimeout": "1000", "reconnectTimeout": "2000" } ]

Your Environment

Please tell us about your environment:

• ( ) I am using just the Node-RED package and got modbus-serial package installed with it
• (X) I have installed modbus-serial package global from source (using git clone)
• ( ) I have installed modbus-serial as a global package (using npm i -g)

Yes, modbus-serial is the name but it does all, TCP and Serial. The node-modbus package is just for the Modbus Server node.

• Device :

  • (X) macOS: 10.14.6
  • ( ) Linux: v
  • ( ) Windows: v
  • ( ) Raspbian: v
  • (X) Other: Balena
    • Name:
    • Version:

Tested on both macos and Balena (formerly Resin), so it’s not a vendor-specific issue.

• Description of the connecting Modbus system:

  • Name : Novus
  • Version: USB-i485
  • Vendor :
  • Link : https://

• node-red-contrib-modbus version: 5.1.0

• Node: (min. 6.x) node --version = v10.14.1

[biancode]

@biancode, being able to switch off reconnect on timeout is extremely useful… thanks.

What does “UnitId’s in parallel” do?

“UnitId’ in parallel” works with a queue on each UnitId and sends them in parallel per cycle if possible.

The order of UnitIds depends on msgs.

Option off sending: 1 2 3 2 1 3

Option on sending:

1,2,3 2,1,3

Modbus Gatways can handle that for example or TCP can do that - serial can normally not work in parallel.

[biancode]

@jcampino1 I tested with v5.13.1 and it works well to communicate with multiple Units over the same BUS (1 Port serial) - check that you do not have “parallel unitid” to on in the Modbus config node. If you need more help please open and fill out a new issue! 😉