Can a MicroLogic PLC read Modbus Holding Registers in the 5xxxx range?

I'm trying to read Modbus registers (like 50102), but it appears that the MSG configuration wants to configure it as a 4xxxx address.

I know others also find the addressing scheme confusing. I don't care if I understand it (although, that would be nice), I just want to get it working.

Has anyone done this?

 

Hi,

I cannot answer if a MicroLogic PLC can read 5xxxx registers. But if it cannot, I would advise you to use a gateway. The Anybus Communicator is a gateway that can read 5xxxx registers. The gateway is a Modbus Master on one side and depending on what model, be a DeviceNet, Modbus slave on the other.

Go to: http://www.hms.se/support/support-step.asp?ProdType=AnybusCommunicator

for available flavours of the gateway.
or drop me an email at:
support [at] hms.se

//Patrick L

 

Try reading Register = 50102-40001 = 10101 = 0x2775

 

The typical Modbus Address Scheme is :

0x = Digital Outputs (Bit)(Read / Write)
1x = Digital Inputs (Bit) (Read Only)
3x = Internal Registers (Read Only)
4x = Holding Registers (Read / Write)
6x = Extended Memory (Depends on Controller)

Through the years the Modbus Addressing scheme has be increased to accommodate the larger memory sizes.

Example based on the 4x Holding Registers

4xx = Three Digit Reference (x Address Range 00-99)

4xxx = Four Digit Reference (x Address Range 00-999)

4xxxx = Five Digit Reference (x Address Range 00-9999)

4xxxxx = Six Digit Reference (x Address Range 00-99999)

From your description it appears that the product is utilizing a six digit reference and the correct address would be 450105 and refers to the 50105 register in the 4x range.

Based on your information the MSG configurartion will only allow you to access a maximumn of 9999 4x references.

The Modbus protocol does not care about the various references utilized to represent the address. The MSG should translate this request into a 4x Read or Write request using the appropriate register offset. In the MSG example it appears that they have limited it to a maximum of 9999. If you want some additional technical details please refer to www.modbus.org for the Modbus Protocol specifications.

 

To make something clear about Modbus, this 0x, 1x, 3x, 4x, 4 digit, 5 digit stuff has *nothing* to do with Modbus. You can go through the entire official Modbus spec and you will see *nothing* like that mentioned anywhere.

Where it comes from is some manufacturers like to document their hardware by comparing it to Modicon (now Schneider) PLC data table addresses. That is, they are saying that if you had a Modicon PLC, this is what the equivalent data table address would be. The reason why the numbering is "inconsistent" is because they're not all comparing their devices to the same model of Modicon PLC.

Considering that most people using Modbus devices these days aren't using them with Modicon PLCs, I think the amount of confusion this sort of vendor documentation creates isn't compensated for by whatever help it gives the minority of Modicon PLC users. If the vendors simply wrote their documentation according to the names Modbus actually uses, I think the majority of Modbus questions here would go away.

Actual Modbus addressing is very simple. There are 4 types of memory: discrete inputs (read-only bits), coils (read/write bits), input registers (read-only 16 bit words), and holding registers (read/write 16 bit words). Each of those address ranges is simply numbered 0 to 65,535. The type of address you talk to is determined by what function (command) you use. It's as simple as that.

The number and type of addresses each vendor actually implements for their hardware will of course depend on what that device does. For example, an I/O block with 8 outputs only needs 8 coils, so that is all that might get implemented.

As for your question about "5xxxx", according to Modbus there is no such thing as ""5xxxx" (or "4xxxx" for that matter) addresses. Either you are reading the documentation incorrectly or this is just some name your hardware vendor pulled out of thin air.

It is possible that this is simply holding register 50102. As I mentioned above, valid Modbus addresses go up to 65535. Or it might be holding register 50103. Some vendors have decided that numbering their products from 0 is "too confusing" for their users, and so use their own numbering system starting at 1. So, Modbus address 0 might be vendor hardware address 1.

So, what you have to keep in mind is that some vendors will use the Modbus protocol for communications, but they don't document their hardware in their manuals according to Modbus addressing. Instead, they sometimes use data table addresses of a PLC that just happens to use Modbus. That might be handy if you were using that particular PLC, but it simply confuses the majority of actual users.

 

Hello,

What Mr. Griffin said is 99.99999% accurate.

The current specification: MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1a, does not mention anything about 0X, 1X, etc. (That I could find.)

An earlier version of the specification: Modicon Modbus Protocol Reference Guide PI-MBUS-300 Rev. J, June 1996 does mention it, many times, it even starts in the table of contents: 22 (16Hex) Mask Write 4X Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

The earliest copy of the specification I have, when Gould had it, June 1969, only associates the 0X, 1X, etc with the function codes when referring to the 384 at paragraph 2.2.1. After that I do not see any XXXX.

One bit of data I have not seen stated, some manufactures create one block of 16 bit words and all reads and writes map to the same block, using the function code to define the memory access. I mention this because if it is the case, input register 1 maps to holding register 1, maps to discrete inputs 1-16, etc.

Good luck,
Mark
http://www.peakhmi.com/

 

Thanks to Mark for the correction. It appears that old versions of the Modbus spec did make some reference to Modicon products. I suppose that shouldn't be too surprising, as the original specs were documenting what was then a Modicon protocol. It appears that the Modbus committee has since purged these vendor specific references from the specs.

However, as for where you said you haven't seen anything stated about mapping blocks of memory over each other, this is explained in the "MODBUS Application Protocol Specification V1.1b" (it might also be in older versions, but I haven't checked that). Section "4.3 MODBUS Data model" states:

"The distinctions between inputs and outputs, and between bit-addressable and word-addressable data items, do not imply any application behavior. It is perfectly acceptable, and very common, to regard all four tables as overlaying one another, if this is the most natural interpretation on the target machine in question."

I have actually used this feature in some of my own software. You may wish to have something which is purely a server in order to allow two masters to talk to each other. However, there would normally be no way for either master to write to discrete inputs or input registers using the Modbus protocol (devices with servers built in can do so because they can go through the "back door" in their own software). If you map coils over discrete inputs and input registers over holding registers, then one master can write to a coil while another master can read it as a discrete input.

I would also like to correct something that I wrote in my previous response. I said that the Modbus *protocol* numbers addresses from 0. That appears to be true.

However, I see in the specification that I cited above that the document distinguishes between the Modbus *protocol* and the Modbus *data model*. The Modbus *data model* numbers addresses starting from 1.

This appears to be an attempt to reconcile the 0 versus 1 numbering scheme in vendor documentation. The *protocol* defines the messages that actually get sent. The *data model* would define how those addresses should get documented. So, the vendors who use "1" based addressing in their documentation (which doesn't affect what gets sent out over the wire) are the ones who are doing it correctly.