Some tag disconnects when connecting a different device with different modbus device ID

Ignition
1

Hello Everyone,

Need your help on how can I fix the problem of colliding data for tags from different devices. I have a single modbus network wherein I will be connecting PV inverters and Power meters, I connected the PV inverter first with a modbus device ID of 1 and all of the mapped tags are working great. However when I connected a Power meter with modbus device ID of 15, 2 tags from the inverter suddenly disconnected while all of the tags in the Power meter is working properly. I am confident the the mapping are right and its working when connected alone. Please Help

2

Here are the inverter tags when the power meter is not connected

PV inverter tags Online
PV inverter tags Online764×827 108 KB

you can see that the above tags for Power meter is not yet updating.

Power meter online
Power meter online523×565 60.6 KB

and then above are the tags for Power meter and then below happens

Tag in red2
Tag in red2538×539 64.3 KB

Inverter device ID is 1 the address for the Load Power=1.HR198, Utility Power=1.HR203, Data Type Integer, Function Code 3 Holding Registers

Power meter device ID is 15, Data Type Float, Function Code 4 Input Register

3

Logs and/or Wireshark capture would be useful.

4

Where can I go to logs? is this it?

IO Gateway logs
IO Gateway logs1289×864 99.2 KB

Logs
Logs1792×751 250 KB

5

New observation, I added more tags from the Power Meter, now all the individual tag connection problem from inverter got switched, all the previous working tags are now disconnected and the 2 disconnected tags are now working.

Problem switched
Problem switched754×539 66.1 KB

6

image
image1897×996 52.8 KB

Here is the wireshark diagnostic results

7

Your device is not responding fast enough, here it is showing at a quarter of a second for 3 requests. Use the fastest modbus baud rate you can on both devices and make sure that the devices are capable of reading that much data over modbus at that speed.

The “Overload” graph should be close to 0% at all times.

8

That wireshark image is not showing modbus traffic.

How is your gateway talking to the MB network? (Driver and settings.)

9

Thank you @davice_Stone for the advice, I will try this. Regards

10

Hello Phil, The PV inverter and Power meter is wired (daisy chain) to a RS485 to Modbus TCP converter.

image
image1559×301 20.2 KB

Its just disconnected right now as I am typing, I am not in the site right now.

11

Brand and Model?

12

I have attached link to the datasheet, see below:

13

It isn't entirely clear, but that document suggests the device is not intended to bridge Modbus RTU and Modbus TCP, but instead bridge either of those to LoRaWan.

Two points I noticed:

  • The default framing on the RS485 port is 9600 N-8-1. N-8-1 is explicitly not supported in Modbus RTU, though many devices tolerate it.

  • The device indicates its max packet size is 232. You will need to reduce the max coils/discretes/registers per read or write to accommodate that.

14

Hello Phil, so what is the framing configuration that is supported by Modbus RTU?

15

  1. You are using a very low cost device which will result in appropriate low cost performance. Any issues you have will most certainly be due to device issues. You have settings that are asking for performance that is simply not obtainable with this device. The trick is finding the settings that work.

  2. Page 12 of this document has the communication parameter recommendations that Phil is referring to. Note that No Parity requires two stop bits. It appears that the default configuration will only produce 10 bits instead of the required 11 (Good catch @pturmel , I would have never caught that). I would alter the communication settings to even parity if that is an option.

    image
    image955×651 32.8 KB

  3. My experience with low cost devices is that bad tag quality happens quite frequently. These devices tend to be powered by chipmunks on treadmills, which overheat and take frequent breaks. Bad quality tags are to be expected from time to time. This is the trade off for the low cost.

  4. As @ David_Stone stated, the Overload % should be zero. This is the measurement you should monitor and optimize, not bad tag count.

  5. Your tag sample rate is set to 1000ms in your tag configuration for all tags. This is the default value and is most likely way too fast for a low cost device such as this. Set it as high you can tolerate (30000ms) for now, then when you get things working you can tweak it for better performance.

  6. I have found that if a low cost device doesn't respond in 100ms it most likely will not respond at all (the chipmunks are on break). I normally set the communication timeout to 200ms, as there is no point in waiting for information that will never arrive:

    image
    image546×415 12.4 KB

  7. The max data length of 232 bytes is less than the Modbus specification of 253bytes (another good @pturmel catch!). It appears the Ignition defaults are set to expect 250bytes of data. I would adjust the following values to 80% of the defaults:

image
image543×372 10.3 KB

  1. I have found that the "Span Gaps" optimization can cause issues with low-cost devices. Uncheck it.
16

Nice write-up. I am going to take some of these ideas and give them a try at one of our clients who have a ton of modbus gateways that are finicky..

17

Greatly appreciate your support! Thank you

18

I also wonder how much the LoRaWAN bridge is causing issues since it's ultra low bandwidth (should be able to do 9600bps though, but aren't intended for high speed anything.

19

That’s why I chose the words “low cost.”

I didn’t want to explicitly call out a reason such as LoWaRAN, but just to set expectations in general about the performance of these devices.

It is unreasonable to expect a $10 device to perform as well as a $500 device.

20

I see you've never compared an AB unmanaged switch to the rest of the market...