OPC tag resets at 16 bit max value

Ignition
1

I have a Keyence MP-FEN1 FD-R sensor that is connected to Ignition through the Modbus TCP driver.

I followed the sensor’s doc and created OPC tags based on the addresses given.

One address is for a totalizer value, that is supposedly 32 bit

image

However, my tag for this value always resets at the value of 65,535 (16 bit max).

I have my OPC item path as so: [meter name]HRUI7144

I used HRUI as the designator for this is what the Ignition doc recommends for a 32 bit unsigned integer:

image

With this all being the case, I am unsure why my tag value resets at the max of 16 bits. I checked throughout the sensor docs, and I could not find anything regarding setting a reset value or anything along those lines.

Any ideas? Perhaps I’m using the wrong register designator?

2

It looks like your off by either 1 or 2 on your address.

3

Possibly also need to change the swap word order setting.

In my experience, when documentation shows a register address in hexadecimal, it is zero-based.

4

Yeah as the others have said, you're not reading the correct bits and need to fix that.

A -- B -- C

The sensor is probably writing to B and C and reversed order while you have Ignition reading A and B and thus you're only seeing half of it. Something along those lines.

If you're reading another signed int from the device put a negative value in it and you'll also see issues.

1 Like
5

The sensor documentation states this:

image

based on this, I assume it fine to not do zero-based.

6

I will look into this, thanks.

7

It is not fine. Look very closely at the first image in your OP.

7144 == 0x1BE8 → 47145

Note that including the classic 4 prefix is shown one-based, making the first two columns obviously zero-based.

(My alternate driver is only zero-based, as the protocol itself is zero-based.)

8

Phil,

Could you please elaborate on this?:

including the classic 4 prefix is shown one-based, making the first two columns obviously zero-based.

I am not very familiar with the TCP protocol and don’t understand what you mean by “columns” and how the 4 prefix is shown one-based.

9

It isn't the TCP protocol, it is the Modbus protocol. The Modbus protocol has various flavors, but they all use the same function codes to perform read or write operations for specific address types. All of these function codes, on the wire, use 16-bit unsigned integer address offsets. These naturally start with zero. There are different function codes for each memory address type.

The original implementing PLCs, by Gould Modicon, used numeric prefixes for these address types in ladder logic and on physical displays, as follows: 0 boolean coils, 1 discrete inputs, 3 analog inputs, and 4 holding registers. Those PLCs started their addresses at 00001, 10001, 30001, and 40001. BUT, the communications protocols and all binary traffic started addressing at zero in each range. That is, to address a target memory location via the protocol, you drop the prefix, and substract one, and use the right function for the prefix. (My alternate driver's user manual has a "supported address formats" table that covers all of this.)

This gobbledygook at the start has made a mess of user interfaces ever since. Complicated by the fact that other brands sometimes used zero-based offsets with the numeric prefix, and some used one-based addresses with their binary implementations. Complete and utter cluster-[expletive].

That image is clearly cut from a table of memory addresses versus usage. That table's first three columns are the addresses: zero-based decimal offset, zero-based hex offset, and one-based prefixed address. Many device manufactures include all three to make it easy for users whose systems expect one of these forms. It happens to also make it abundantly clear to experienced users that the manufacturer has a clue.

4 Likes
10

Thank you for the clarification and detail.

1 Like