Write signed(-) values over modbus TCP to holding registers

[Archie]

What do you have the PollRateOverride set to on the driver?

[elirofu]

here you have!

Thanks

[elirofu]

What do you have the PollRateOverride set to on the driver?

from 100 ms to 1000 ms.. I had been testing with diferent poll rates but it still showing 0s

Thanks

[Archie]

Here is something that doesn't look quite right. In your WireShark capture look at packet 17 and 18. The request says to read 76 consecutive 16 bit registers starting at 29 (which would be address 40030)(function code 3 is the holding register read)

Then look at packet 18, the response shows registers 0-44 are all zero. Since the request started at 29, that would mean registers 29-72 are all 0's,

Now look at packet 19 and 20. This says to read 12 registers starting at 57. The result shows register 57 is 650.

So how can the first read say register 57 is 0, but the next read says it is 650? Something doesn't add up with the values coming from your device. Is your device treating each register as a 32 bit where 40001 starts at 0, but 40002 starts at 4, instead of the normal 2?

[elirofu]

Hello,


I have another device which is is master device and it works. I don't know why with the Modbus driver does not.
maybe duplicated registers??

attached is the mapping of the holding register in my slave device.

thanks

[Archie]

Is that a RedLion data station or G3?

Part of the problem is caused by the Modbus driver optimizing the reads by grouping them together. You can eliminate this by opening ModbusBase in the AdvancedHMIDrivers\Modbus project. Go to line 470, which is this:

        ((SubscriptionList(index + ItemCountToGroup + 1).Address.Element + SubscriptionList(index + ItemCountToGroup + 1).Address.NumberOfElements) - SubscriptionList(index).Address.Element) < 20


Change the 20 at the end of the line to a 1

That will probably make it work, but will drastically reduce the update rate.

[elirofu]

It is a PTV from red lion.. so much identical to the G3.


let me test and ASAP I will post the results.


Thanks.

[elirofu]

Is that a RedLion data station or G3?

Part of the problem is caused by the Modbus driver optimizing the reads by grouping them together. You can eliminate this by opening ModbusBase in the AdvancedHMIDrivers\Modbus project. Go to line 470, which is this:

        ((SubscriptionList(index + ItemCountToGroup + 1).Address.Element + SubscriptionList(index + ItemCountToGroup + 1).Address.NumberOfElements) - SubscriptionList(index).Address.Element) < 20


Change the 20 at the end of the line to a 1

That will probably make it work, but will drastically reduce the update rate.

It worked! I set up the PollRateOverride to 1 sec.

let's make me clear the things.. my device which is a PTV from red lion is sending correct values but after a very short period of time sends 0's?

thanks.

[Archie]

let's make me clear the things.. my device which is a PTV from red lion is sending correct values but after a very short period of time sends 0's?

The AdvancedHMI drivers attempt to optimize communications by grouping together values into a single read. For example if you have 2 BasicLabels for addresses 40001 and 40004, it is faster to read all values from 40001 to 40004 in a single read than to read the 2 values with separate reads.

The Modbus driver doesn't exactly optimize 32 bit values correctly, so it can read the same value twice, but starting from a different offset. For example it may read 40001-40021, then read 40011-40032. Although the 2 reads start at a different offset, the values in the overlapping range (40011-40021) should come back the same, but your device will return different values based on the where the offset starts.

If you don't mind I am going to send the Wireshark capture to a Red Lion expert to see what they say about it.

[elirofu]

It makes a lot of sense what you said.

right now it is in working condition.


Also thank you for your support.. really good support!!


thanks again!