NI Modbus Library

[LV_Pro]

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"?

[RTSLVU]

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.

[rolfk]

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

[LV_Pro]

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

[rolfk]

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.

[Jacobson]

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.

[LV_Pro]

Any suggestions on tools to "sniff the packets"?  This is making me crazy, have had a number of divergent systems working using this code, the only thing to have changed is the "A-B" PLC family. And much of A-B documentation is behind registration walls. When the first of these were built my customer's shop was 40 minutes away, so I could go there and work with him to sort it out. Now he is about 5 hours away, sending me the hardware, trying to figure it out over the phone (he hasn't "email" per se, probably because as his last office, it is in a remote area). 

[Jacobson]

---

@LV_Pro wrote:

Any suggestions on tools to "sniff the packets"?  

---

Depends on the type of Modbus but if it's serial I think you can use NI IO Trace. Over TCP  you can just use Wireshark.

[tst]

---

@LV_Pro wrote:

---

I don't have any real experience with this library, but I do have a couple of comments:

1. First, as Rolf mentioned, usually in Modbus addresses are zero-based while coil and register numbers are one-based. However, this isn't implemented consistently, so it's possible you just have an off-by-one error. 
2. The second thing is that your screenshot shows the VI returning an array of integers which goes into a variant. I expect in practice the VI returns an array of U16, where each element is a register. The conversion between that array of U16s and the actual value you want depends on how the device encodes it, which could be very different from your previous device.

I didn't see that you specified what the actual incorrect behavior is, so I suggest you do that, so that people might have a better idea of what to suggest, but my guess would be that finding the documentation is the best option, even if it's behind various walls.

The second thing I would suggest is using some kind of generic Modbus program to simply see the register values directly. I believe there are some available, and if not, I expect the library has examples you can build into an EXE.