ni.com is currently undergoing scheduled maintenance.
Some services may be unavailable at this time. Please contact us for help or try again later.
06-17-2026 10:09 AM
Does anyone know whether the NI Modbus Library "read Discrete" and "read Register" sub-vi's create the modbus mapped addresses i.e. 300001 vs sending what is wired to their address inputs, in this case "1". My program, talking to MicroLogix 800 PLCs (a number of projects, a number of years), has worked with just the "simple" addresses of 1, 2, 3 for the various reads. In my "tagname" parser it does select the appropriate read "type", i.e. Discrete, or Register. They, in the MicroLogix memory mapping, are at difference addresses, ie. discrete from 10001-11024, input registers 30001-31024.
So the question is do the "read" sub-vis append the "appropriate" addresses, i.e. "30000" to "1" to make "30001"?

06-17-2026 10:33 AM - edited 06-17-2026 10:33 AM
It's been awhile since I worked with Modbus, I had to look at my old code. But to answer your question you have to use the full register address or starting address if you are reading multiple registers.
Here's an example of my Vi for reading measurements from a power analyzer.
06-17-2026 02:15 PM - edited 06-17-2026 02:18 PM
Modbus is a generic interface but different manufacturers had their own idea how to name those addresses.
Basically you have a number of function codes to address different kind of IO items.
There are 4 basic IO items:
coils (digital outputs) usually address range 00001...09999 1-bit
discrete inputs usually address range 10001...19999 1-bit
analog inputs usually address range 30001...39999 16-bit
holding registers usually address range 40001...49999 16-bit
So the first number of that address is actually encoded in the so called function code to read or write a specific IO item type.
The remaining 4 digits are the 1 based address.
But the address is actually transferred as a 16-bit 0-based integer and can really address 65536 registers not just the 9999 that the traditional Modbus address scheme provides for.
Some manufacturers extended the traditional address to 6 digits to allow addressing registers beyond 9999 to 65535 (eg, 362000).
Other manufacturers use the actual register address in the Modbus protocol together with the according function code. The address is then usually written in Hex format (eg, 0x0002)
The LabVIEW Modbus library uses this more modern addressing scheme.
So your address 30001 translates for the LabVIEW Modbus library to:
read analog register (function code 04): address 0
An address 40003 would translate to:
read holding register (function code 03): address 2
write holding register (function code 06): address 2
06-18-2026 03:29 PM
Well, I'm still battling this. This has been a program that has worked, in varying evolution stages, for 20 years. This latest version has worked since 2020, but what now has changed is the target PLC, now an "A-B" Micro820, which doesn't follow the A-B MicroLogix 800 addressing scheme.
My question is whether the NI Modbus appends the "type" of read to the "address" supplied to the ModBus Vi. My program has supplies an address from the "taglist" that has been just the address of the register, like "1" rather than a 30001. But I am getting a "538182" error Mode 4

06-18-2026 04:43 PM
I have no experience with the AB hardware. But the NI Modbus library doesn't "add" the type of the register to the address. That is not how Modbus works.
Basically you need to select the correct type of read or write access. And if you really just got an address without the old prefix it may actually be 0 based.
So is it a holding register or an input register? Or is it rather a coil or a discrete input? Depending on that you need to use the according polymorphic version of the Read VI.
06-19-2026 09:19 AM
If you can find some AB software that talks to it's hardware over Modbus, it might be easiest to sniff the packet that's being sent and use that as a reference point.
Modbus address documentation never felt very consistent but I found that once you're able to map a valid packet to a specific documented register it's pretty easy to figure things out from there.