# Modbus Holding Register Address **URL:** \ **Category:** Ignition\ **Tags:** opcua, modbus, scripting, ignition81\ **Created:** [June 4, 2024, 7:37pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367 "2024-06-04T19:37:51Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Emmanuel\_Akinwale](https://avatars.discourse-cdn.com/v4/letter/e/ccd318/32.png) [@Emmanuel\_Akinwale](https://forum.inductiveautomation.com/u/Emmanuel_Akinwale)\ **Post date:** [June 4, 2024, 7:37pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/1 "2024-06-04T19:37:51Z")
Hello, I'm currently facing some challenges with addressing holding registers in Modbus communication within the Ignition SCADA software. I've been working with the official Modbus specification, but I'm running into issues that I hope someone can help clarify. Here's the context: 1. **Address Ranges** : According to the Modbus spec, The addresses are 20480-20735 (0x5000-0x51FF) are not holding registers. However, I understand that holding registers are typically in the 40xxx range (e.g., 40108-40110). 2. **Error in Ignition** : When I attempt to use the 20xxx addresses in Ignition, I receive an error, indicating these addresses may not be valid or recognized. 3. **Clarification Needed** : I need to understand how to correctly reference holding registers in Ignition. For example, in the Modbus documentation, addresses 108-110 are reference points and correspond to actual addresses 107-109 (in hex as 6B-6D). Has anyone else encountered this issue or can guide how to properly configure and use holding register addresses in Ignition? Any examples or detailed explanations would be greatly appreciated. ![modbus_moxa_data_stream](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/6/f6aeab9713122a565597c6797ca1fc7c830c4abe.jpeg) ---
**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 4, 2024, 7:52pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/2 "2024-06-04T19:52:49Z")
> [@Emmanuel\_Akinwale](#): > > According to the Modbus spec Whose Modbus Spec? The _ **official** _ [Modbus Specification](https://modbus.org/tech.php) disagrees with whatever you are looking at. And **device** makers don't have to implement everything, so device-specific address ranges abound. It seems to me you are stumbling on the "area prefix" the Modbus Spec calls out for various types of data. To summarize: - Area zero: Output coils and other writable booleans. Classic address range `00001` through `09999`, expanded to `000001` through `065536`, on the wire with function codes 0x01 and 0x05 and 0x0f as 0x0000 through 0xffff. In Ignition as `Cn`, where `n` is 1-65536 or 0-65535 depending on your zero-based-addressing setting. - Area one: Discrete inputs or other readonly booleans. Classic address range `10001` through `19999`, expanded to `100001` through `165536`, on the wire with function code 0x02 as 0x0000 through 0xffff. In Ignition as `DIn`, where `n` is 1-65536 or 0-65535 depending on your zero-based-addressing setting. - Area three: Analog input registers and other readonly short integers. Classic address range `30001` through `39999`, expanded to `300001` through `365536`, on the wire with function code 0x04 as 0x0000 through 0xffff. In Ignition as `IRn`, where `n` is 1-65536 or 0-65535 depending on your zero-based-addressing setting. - Area four: Holding registers and other writable short integers. Classic address range `40001` through `49999`, expanded to `400001` through `465536`, on the wire with function code 0x03 and 0x06 and 0x10 and 0x16 as 0x0000 through 0xffff. In Ignition as `HRn`, where `n` is 1-65536 or 0-65535 depending on your zero-based-addressing setting. Any of the "classic" or "expanded" formats need to have their prefix digit stripped off before using with Ignition's character-based prefixes. You kind of have to read the device maker's programmers' minds sometimes, but when hexadecimal is shown for an address, it almost always means the zero-based offset intended for use "on the wire". And most commonly means it is a holding register. Your device should have more information, possibly scattered or in examples, to help you decipher what they've done. There's also an area **six** , "File Records", that isn't supported by Ignition's native driver. See my alternate driver if you need that: > [@Automation Professionals' Advanced Modbus Driver](https://forum.inductiveautomation.com/t/automation-professionals-advanced-modbus-driver/41312): > > Automation Professionals is pleased to announce the first beta for its Advanced Modbus Driver, for Ignition version 7.9. Key features: Server mode, emulating one or more slave [devices](https://www.automation-pros.com/modbus/UserManual.pdf), using any of the three typical connection types, including simultaneous connections of multiple types. Client mode, incorporating all three connection modes in one driver. Support for Modbus Function Codes 20 and 21, File Records. Configure protocol tweaks for troublesome devices per slave unit, enabling suppor… ---
**Author:** ![Thomas\_Salisbury](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/thomas_salisbury/32/62046_2.png) [@Thomas\_Salisbury](https://forum.inductiveautomation.com/u/Thomas_Salisbury)\ **Post date:** [June 5, 2024, 10:55am UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/3 "2024-06-05T10:55:21Z")
Our engineer claims we ARE following that specification, and sent us this 🙂 [Modbus\_Application\_Protocol\_V1\_1b3.pdf](https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf) What we can't get out of them. (being engineers and all) is what Modbus address to actually pull data from. ---
**Author:** ![Thomas\_Salisbury](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/thomas_salisbury/32/62046_2.png) [@Thomas\_Salisbury](https://forum.inductiveautomation.com/u/Thomas_Salisbury)\ **Post date:** [June 5, 2024, 11:04am UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/4 "2024-06-05T11:04:58Z")
If y'all could explain how 0x5017 is a holding register address... We sure can't figure it out. ---
**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 5, 2024, 12:05pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/5 "2024-06-05T12:05:21Z")
It isn't, for sure, a holding register address. Offsets of addresses within the modbus protocol are 16-bit unsigned integer, where the first element is offset zero. `0x5017` could be an offset within any of the areas. Your engineers need to be explicit about what function code(s) go with that offset. Then you will know for sure what kind of address it is. Have your engineers looked at Ignition's addressing documentation? > **[Modbus Addressing | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/opc-ua/opc-ua-drivers/modbus/modbus-addressing#manually-addressing-a-modbus-device)** > > Manually Addressing a Modbus Device Consider also pointing your engineers at the documentation for my alternate driver, and the sections on "supported function codes" and "supported address formats". [https://www.automation-pros.com/modbus/UserManual.pdf](https://www.automation-pros.com/modbus/UserManual.pdf) {There are some minor differences between the IA driver and mine.} ---
**Author:** ![Cody\_Morgan](https://avatars.discourse-cdn.com/v4/letter/c/db5fbb/32.png) [@Cody\_Morgan](https://forum.inductiveautomation.com/u/Cody_Morgan)\ **Post date:** [June 5, 2024, 3:31pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/6 "2024-06-05T15:31:18Z")
As @pturmel points out, 0x5017 is an allowable offset for any of the primary tables in the Modbus data model. As described in the Modbus Application protocol (the document linked by @Thomas_Salisbury ) sections 4.3 and 4.4 describe how the data may be arranged and addressed. You will notice there is no mention of the numerical prefixes (e.g. 40xxx) in these sections. > [@Thomas\_Salisbury](#): > > What we can't get out of them. (being engineers and all) is what Modbus address to actually pull data from. Figuring out how to pull data from a Modbus device can be more difficult than it has to be at times, I sympathize with you. From the screenshot that @Emmanuel_Akinwale provided, we can see a write message for a holding register with offset 0x5017 from slave addresses 64, 65, & 66 on rows 11-13. The value in the write was 0. > [@Emmanuel\_Akinwale](#): > > **Error in Ignition** : When I attempt to use the 20xxx addresses in Ignition, I receive an error, indicating these addresses may not be valid or recognized. It's hard for me to say what the cause of this is without more information. Could you provide the exact error you are seeing? 20XXX could be a valid offset for a holding register as far as Ignition is concerned, so it is likely the error you are seeing is related to the response we get from the device. I have no experience with Moxa MGate devices, but I would recommend checking to see if you have specified the correct unit id, if required. If you can provide more information about your use case, I would be happy to help you figure this out. ---
**Author:** ![Thomas\_Salisbury](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/thomas_salisbury/32/62046_2.png) [@Thomas\_Salisbury](https://forum.inductiveautomation.com/u/Thomas_Salisbury)\ **Post date:** [June 5, 2024, 4:43pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/7 "2024-06-05T16:43:56Z")
we just get a BAD when trying to create a tag with any read register ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [June 5, 2024, 4:48pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/8 "2024-06-05T16:48:20Z")
You're going to have to provide more information for anyone to help you out. Do you have the manual to the device you're trying to work with? ---
**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 5, 2024, 4:54pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/9 "2024-06-05T16:54:46Z")
> [@michael.flagler](#): > > provide more information And show both your device configuration and your sample Ignition tag's OPC properties. Consider using Wireshark to capture packets from Ignition and from Modscan and compare the traffic. We can't immediately tell if you've screwed up inside Ignition, or if you have firewall/network issues. ---
**Author:** ![Thomas\_Salisbury](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/thomas_salisbury/32/62046_2.png) [@Thomas\_Salisbury](https://forum.inductiveautomation.com/u/Thomas_Salisbury)\ **Post date:** [June 6, 2024, 2:40pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/10 "2024-06-06T14:40:55Z")
I wish we could. It's proprietary and we are unable to really share much. We will attempt to get more data from Modscan. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [June 6, 2024, 3:02pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/11 "2024-06-06T15:02:45Z")
You might try some tools that can try to discover or scrape a device for valid registers like one of these: > **[Releases · JoshuaVlantis/Modbus-Scraper](https://github.com/JoshuaVlantis/Modbus-Scraper/releases)** > > Contribute to JoshuaVlantis/Modbus-Scraper development by creating an account on GitHub. > **[Modbus Scanner: Perfect to Discover and Test Modbus](https://store.chipkin.com/products/tools/cas-modbus-scanner)** > > CAS Modbus Scanner is a utility to retrieve coils, inputs, holding registers, and input registers from a Modbus-enabled device.... > **[Releases · sanny32/OpenModScan](https://github.com/sanny32/OpenModScan/releases)** > > Open ModScan is a Free Modbus Master (Client) Utility - sanny32/OpenModScan ---
**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 6, 2024, 3:28pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/12 "2024-06-06T15:28:59Z")
> [@Thomas\_Salisbury](#): > > unable to really share much You should take this to IA support. They can help you under an NDA. Or pay an integrator to work under an NDA. ---
**Author:** ![BRYAN\_MOBLEY](https://avatars.discourse-cdn.com/v4/letter/b/db5fbb/32.png) [@BRYAN\_MOBLEY](https://forum.inductiveautomation.com/u/BRYAN_MOBLEY)\ **Post date:** [June 6, 2024, 3:35pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/13 "2024-06-06T15:35:07Z")
I just went through reading some PAC3220 devices from SIEMENS via MODBUS TCP. I got BADs all day long until I used Chipkin Modbus Scanner that michael.flagler referenced and found out device 0 doesn't allow for any functions. Added a 1. in front of my path, for example, [Modbus Device]1.HRF7, and that got me going. Also had to set the config to start at 0 for offsets. ---
**Author:** ![Cody\_Morgan](https://avatars.discourse-cdn.com/v4/letter/c/db5fbb/32.png) [@Cody\_Morgan](https://forum.inductiveautomation.com/u/Cody_Morgan)\ **Post date:** [June 6, 2024, 5:16pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/14 "2024-06-06T17:16:18Z")
> [@BRYAN\_MOBLEY](#): > > Added a 1. in front of my path, for example, [Modbus Device]1.HRF7, and that got me going. Yes, it is very common for the Modbus TCP server to require a unit id when it is serving as a gateway for multiple Modbus serial devices. I suggested checking this in an earlier reply. From the screenshot above, the use case would lead me to think a unit id is necessary. ---
**Author:** ![BRYAN\_MOBLEY](https://avatars.discourse-cdn.com/v4/letter/b/db5fbb/32.png) [@BRYAN\_MOBLEY](https://forum.inductiveautomation.com/u/BRYAN_MOBLEY)\ **Post date:** [June 6, 2024, 5:36pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/15 "2024-06-06T17:36:44Z")
I was confused when I was implementing it as I only have two devices. They each have their own IP. So in my mind there was just one device per connection. ---
**Author:** ![Cody\_Morgan](https://avatars.discourse-cdn.com/v4/letter/c/db5fbb/32.png) [@Cody\_Morgan](https://forum.inductiveautomation.com/u/Cody_Morgan)\ **Post date:** [June 6, 2024, 6:29pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/16 "2024-06-06T18:29:19Z")
In your case, it's possible the PAC3220 devices don't necessarily need a unit id, but reject 0 as the broadcast unit id. I believe the specification recommends using 255 when a unit id is not necessary, but the Modbus driver in Ignition defaults to 0. This isn't recommended, but is often accepted. ---
**Author:** ![BRYAN\_MOBLEY](https://avatars.discourse-cdn.com/v4/letter/b/db5fbb/32.png) [@BRYAN\_MOBLEY](https://forum.inductiveautomation.com/u/BRYAN_MOBLEY)\ **Post date:** [June 6, 2024, 6:41pm UTC](https://forum.inductiveautomation.com/t/modbus-holding-register-address/91367/17 "2024-06-06T18:41:38Z")
Thanks for the heads up. I was quite ignorant to Modbus TCP when getting them to talk.