Modbus TCP inconsistencies / issues

General
1

I've been having very inconsistent results trying to use the modbus getter nodes to poll data from a Universal Robot. Some of it may be the robot as Simply Modbus also fails to connect, however, modscan64 has no issues.

Generally the node shows active/connected until I try to poll it and then it says "Port not open". I then used Steve's guide which gave me a hint to use a raw TCP node. I copied the "working" packet from modscan64 and piped it into a tcp request node using an function node and it worked!

It may be that the UR is expecting the packet to be in a specific format? I would think it should be standard but I noticed some differences on the "front" part of the packet between Simply Modbus and modscan64. I've been unable to figure out how to get the actual packet sent from the Modbus getter node.

Here's an example of it working:

XMT: [36][00][00][00][00][06][01][03][00][00][00][0a]
RCV: [36][00][00][00][00][17][01][03][14][00][00][00][00][00][00][00][00][00][00][00][01][00][00][00][01][00][34][00][01]
2

Per the package recommendation I tried running modbus-serial directly on my RHEL VM and it worked fine:

$ cat modbus-test.js
// create an empty modbus client
var ModbusRTU = require("modbus-serial");
var client = new ModbusRTU();

// open connection to a tcp line
client.connectTCP("10.130.51.79", { port: 502 });
client.setID(1);

// read the values of 10 registers starting at address 0
// on device number 1. and log the values to the console.
setInterval(function() {
    client.readHoldingRegisters(0, 10, function(err, data) {
        console.log(data.data);
    });
}, 1000);

]$ node modbus-test.js
[
  0, 0, 0,   0, 0,
  1, 0, 1, 202, 1
]
[
  0, 0, 0,   0, 0,
  1, 0, 1, 180, 1
]
[
  0, 0, 0,   0, 0,
  1, 0, 1, 180, 1
]
[
  0, 0, 0,   0, 0,
  1, 0, 1, 225, 1
]
3

Are you doing parallel reads in node-red? Show us your flow.

4

Right now just trying a simple flow :slight_smile:

image
image711×242 12.6 KB

I can provide the flows but they don't get much simpler. No special settings or config tweaks. The second flow is a direct tcp injection of a working binary payload from modscan64 which works.

When I click the inject node I get this:

image
image299×528 4.52 KB

5

Modbus configuration:

image

image
image496×774 8.43 KB

6

I ran the flow in debug mode but I don't see anything useful in it... Interestingly I had to setup NodeRed on my local computer because I can't shutdown my VM as it's used in production and saw the same behavior.

It works ONCE (or a few times) and then starts giving me the "Port Not Open" error. VERY strange.

20 Jun 14:31:29 - [info] Starting flows
  contribModbus:queue:core queue serial lock command node UR-5e +0ms
  contribModbus:core:client Client -> initialized +0ms
20 Jun 14:31:29 - [warn] [modbus-client:UR-5e] Client -> fsm init state after new
20 Jun 14:31:29 - [warn] [modbus-client:UR-5e] Client -> first fsm init in 500 ms TCP@10.130.51.79:502 default Unit-Id: 1
20 Jun 14:31:29 - [info] Started flows
  contribModbus:core:client Client -> TCP port TCP@10.130.51.79:502 default Unit-Id: 1 +509ms
20 Jun 14:31:30 - [warn] [modbus-client:UR-5e] Client -> fsm connected after state init Get More About It By Logging TCP@10.130.51.79:502 default Unit-Id: 1
  contribModbus:queue:core queue serial unlock command node UR-5e +562ms
  contribModbus:queue:core sequential de-queue command +21s
  contribModbus:queue:core queue serial unlock command node UR-5e +3ms
  contribModbus:queue:core queue serial unlock command node UR-5e +1ms
20 Jun 14:31:50 - [warn] [modbus-client:UR-5e] Client -> fsm failed state after sending Get More About It By Logging TCP@10.130.51.79:502 default Unit-Id: 1
20 Jun 14:31:50 - [warn] [modbus-getter:Get Registers] Modbus Failure On State sending Get More About It By Logging
20 Jun 14:31:50 - [warn] [modbus-getter:Get Coils] Modbus Failure On State sending Get More About It By Logging
20 Jun 14:31:50 - [warn] [modbus-client:UR-5e] Client -> fsm broken state after failed Get More About It By Logging TCP@10.130.51.79:502 default Unit-Id: 1
20 Jun 14:31:50 - [warn] [modbus-client:UR-5e] Client -> fsm reconnect state after broken Get More About It By Logging TCP@10.130.51.79:502 default Unit-Id: 1
  contribModbus:queue:core queue serial lock command node UR-5e +6ms
  contribModbus:getter Port Not Open +0ms
20 Jun 14:31:50 - [error] [modbus-getter:Get Registers] Error: Port Not Open
    at C:\Users\aa674\.node-red\node_modules\node-red-contrib-modbus\modbus\maps\core\core\modbus-client-core.js:79:21
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
20 Jun 14:31:52 - [warn] [modbus-client:UR-5e] Client -> fsm init state after reconnecting TCP@10.130.51.79:502 default Unit-Id: 1
20 Jun 14:31:52 - [warn] [modbus-client:UR-5e] Client -> fsm init in 2000 ms TCP@10.130.51.79:502 default Unit-Id: 1
  contribModbus:core:client Client -> connection close sent TCP@10.130.51.79:502 default Unit-Id: 1 +25s
  contribModbus:core:client Client -> TCP port TCP@10.130.51.79:502 default Unit-Id: 1 +2ms
20 Jun 14:31:55 - [warn] [modbus-client:UR-5e] Client -> fsm connected after state init Get More About It By Logging TCP@10.130.51.79:502 default Unit-Id: 1
  contribModbus:queue:core queue serial unlock command node UR-5e +4s
7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.