# Modbus driver fail to read HRUS register followed by HRF register (32bit float) **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [June 20, 2023, 4:19pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287 "2023-06-20T16:19:19Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [June 20, 2023, 4:19pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/1 "2023-06-20T16:19:19Z")
**Ignition 8.1.28** @Kevin.Herron, There is perhaps a bug in modbus TCP driver or a strange behavior. We have a device with the following table (see below) Read **HRUS** Register from 1 to 11 are **OK** Read **HRF** Register from 12 to 20 are **Bad** , but they can be read by another modbus master. If we disable the first tag ( **HRF12** ), the next HRF are read with success. It seems that Ignition driver group consecutive **HRUS** and **HRF** to make only one frame and this is not allowed by the device. We have tried to add Address Mapping to try to force to split request, but it seems that the driver group consecutive frames too ? The only horrible solution found is to make 2 ignition devices, one with **tags for HRUS** and another for **tags for HRF** ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/7/6765723e562cf9dc8e0ea60a2f97ca6473568cc3.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/4/e40ffcf0f5047a610423ec6fdeb1055dadfe6e47.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/b/bb2af07b7ead19ccc3a234292d37f8123a3a9d5a.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/9/799090a9925625824b9f101b8e3714e5ea67d01b.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/3/7369f656ebd4ec2206c3471f8f569391e3867f2e.png) But if we try to read the whole holding register table, it fail: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/3/2343b77dfbd725887f53130c61236202160b0a49.png) ---
**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:** [June 20, 2023, 4:22pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/2 "2023-06-20T16:22:08Z")
> [@mazeyrat](#): > > It seems that Ignition driver group consecutive **HRUS** and **HRF** to make only one frame and this is not allowed by the device. Devices don't know anything about how we're combining registers to derive values. The request is just for a certain range of registers, that's it. Get a Wireshark capture and see what's going on. If you can request 1 through 11 successfully, but a request for 1 through 20 fails, then either one of those registers has no data at it, or your device's Modbus implementation is broken. edit: I see your last screenshot where the device returns `Illegal data address` when reading the full range. I'm not sure there's much you can do here. ---
**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:** [June 20, 2023, 4:28pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/3 "2023-06-20T16:28:34Z")
> [@Kevin.Herron](#): > > I'm not sure there's much you can do here. My driver would be no help, either, fwiw. Thinking how to solve this.... ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [June 20, 2023, 4:29pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/4 "2023-06-20T16:29:57Z")
Yes it's very stange, if we read 1-11 and 12-22 separately it's ok, but if we read 1-22 it fail.. ---
**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:** [June 20, 2023, 4:30pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/5 "2023-06-20T16:30:08Z")
> [@pturmel](#): > > Thinking how to solve this.... 2 Ignition devices like he's already stumbled on, I think. Otherwise a driver would need some kind of setting where you defined arbitrary memory/register boundaries that the request optimization logic wouldn't combine across. ---
**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:** [June 20, 2023, 4:31pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/6 "2023-06-20T16:31:55Z")
> [@Kevin.Herron](#): > > arbitrary memory/register boundaries that the request optimization logic wouldn't combine across. My driver has close to that logic, where you define the available registers, and it automatically excludes gaps from spanning. But there's no actual gap here. Hmm, some more. ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [June 20, 2023, 4:32pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/7 "2023-06-20T16:32:23Z")
Perhaps a max size to 10 will help. It will be better than 2 devices I will test tomorrow. ---
**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:** [June 20, 2023, 4:44pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/8 "2023-06-20T16:44:04Z")
> [@pturmel](#): > > Hmm, some more. Doable, but ugly. Won't be quick. What brand of device is this? Or brands? ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [June 20, 2023, 4:57pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/9 "2023-06-20T16:57:10Z")
The device is a Schneider ASP, a building automation small PLC. ---
**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:** [June 20, 2023, 4:59pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/10 "2023-06-20T16:59:29Z")
It's f\*cking incredible to me that Schneider/Modicon devices are somehow among the worst Modbus implementations out there. ---
**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:** [June 20, 2023, 5:03pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/11 "2023-06-20T17:03:54Z")
> [@mazeyrat](#): > > Schneider 🤦‍♂️ Can you fire them? (Not even half-kidding.) ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [June 20, 2023, 5:07pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/12 "2023-06-20T17:07:22Z")
That is the customer stuff...😭 This was not our choice. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [June 20, 2023, 6:56pm UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/13 "2023-06-20T18:56:16Z")
> [@Kevin.Herron](#): > > Schneider/Modicon devices are somehow among the worst Modbus implementations Why, it's not like Modicon invented the protocol or anything. 🤣 ---
**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 10, 2025, 1:02am UTC](https://forum.inductiveautomation.com/t/modbus-driver-fail-to-read-hrus-register-followed-by-hrf-register-32bit-float/75287/14 "2025-03-10T01:02:02Z")
I finally got around to addressing this feature. My latest beta will split access requests to abutting configured address ranges, as noted here: > [@Automation Professionals' Advanced Modbus Driver](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312/82): > > Well, I didn't declare it production grade, as I found a couple minor items in the DriverAdapter to Device conversion. I also refactored my CSV versus binary serialization format in the internal database to make it easier to excise the latter in v8.3. Which enabled a feature I've been cogitating on for a while: mitigating the bad behavior of some devices when abutting register ranges cannot be spanned. My config will no longer merge configured ranges of addresses that abut without overlapping… Presumably too late for @mazeyrat, but if others run into it, they won't be stuck.