# OPC tag resets at 16 bit max value **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [March 25, 2026, 8:43pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681 "2026-03-25T20:43:25Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\ **Post date:** [March 25, 2026, 8:43pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/1 "2026-03-25T20:43:25Z")
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](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/8/6821f987e655192554b99c799004b101cc353887.png) 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](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/b/3bffecd797334231a748244c169db3cf974c3260.png) 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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 25, 2026, 8:45pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/2 "2026-03-25T20:45:12Z")
It looks like your off by either 1 or 2 on your address. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 25, 2026, 8:55pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/3 "2026-03-25T20:55:07Z")
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. ---
**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\ **Post date:** [March 25, 2026, 9:02pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/4 "2026-03-25T21:02:17Z")
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. ---
**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\ **Post date:** [March 25, 2026, 9:22pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/5 "2026-03-25T21:22:09Z")
The sensor documentation states this: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/6/e6be11b7fd2274a672e323e727a1c86028caace0.png) based on this, I assume it fine to not do zero-based. ---
**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\ **Post date:** [March 25, 2026, 9:22pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/6 "2026-03-25T21:22:42Z")
I will look into this, thanks. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 25, 2026, 9:26pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/7 "2026-03-25T21:26:52Z")
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.) ---
**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\ **Post date:** [March 26, 2026, 3:12pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/8 "2026-03-26T15:12:14Z")
Phil, Could you please elaborate on this?: ```python 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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 26, 2026, 3:41pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/9 "2026-03-26T15:41:18Z")
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](https://www.automation-pros.com/modbus/UserManual.pdf) 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]. > [@Slick](#): > > understand what you mean by “columns” 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. ---
**Author:** ![Slick](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@Slick](https://forum.inductiveautomation.com/u/Slick)\ **Post date:** [March 26, 2026, 8:33pm UTC](https://forum.inductiveautomation.com/t/opc-tag-resets-at-16-bit-max-value/114681/10 "2026-03-26T20:33:56Z")
Thank you for the clarification and detail.