Read Device Identification: Number of Objects

I

Thread Starter

Ivo Bauer

I am studying the implementation of "Read Device Identification" function (0x2B / 0x0E). Response data frame for this function contains a field named "Number of Objects", but I do not seem to understand what it means. The Modbus Application Protocol document is not of much help to me in this particular case.

AFAIK, the Number of Objects could have one of these meanings:

1) Number of objects in the list transmitted within a single Modbus response. If multiple transactions are required to retrieve all objects using given access type, this field might have a different value in each transaction.

2) Total number of objects that can be retrieved from a Modbus server device using given access type. If multiple transactions are required to retrieve all objects, this field will retain the same value in all those transactions.

Can you please tell me which of the options above describe the meaning of "Number of Objects" field the best?

Thank you in advance
Ivo
 
Hello,

The specification reads:

Number Of Objects
Number of identification Object returned in the response (for an individual access, Number Of Objects = 1)

Reads like the "s" not needed.

So, when you read object X the response contains the object ID for verification.

SWAG.

Good luck,

Mark
http://www.peakhmi.com/
 
Dear Mark,

Thank you for your reply.

> Number Of Objects
> Number of identification Object returned in the response (for an individual access, Number Of Objects = 1)

> Reads like the "s" not needed.

> So, when you read object X the response contains the object ID for verification.

I think this is a typo and the "s" definitely should be there as Number of Objects could have values greater than 1 (see the examples in the specification).

ID for each object transmitted within the same response is already available in the List of (Object ID, Object Length, Object Value).

For an individual access, Number of Objects in the response is 1. But what about stream access when multiple Modbus transactions are required?

Does it denote a total number of objects to be retrieved in multiple transactions or just the number of object to be retrieved in a single transaction?

Best regards
Ivo
 
F

Frank O'Gorman

The sensible, and probably correct, interpretation is (1). It is possible to determine the number of objects in the response by stepping through them, adding up their lengths, until you reach the end of the message - but no other Modbus response requires you to use the length of the message to determine the number of data bytes/objects in the message.

However, an example in the specification shows a request that requires two responses, with 2 objects in the first response and 1 object in the second, and with the "number of objects" set to 3 in both responses. This is consistent with your meaning (2).

I believe that the example is simply wrong, as a result of careless adaptation of the single transaction example (the two transaction example was not in the original draft IETF specification http://tools.ietf.org/html/draft-dube-modbus-applproto-00). But official clarification would be helpful!

Frank O'Gorman
Wingpath Software Developemnt
 
Hello Ivo,

your first option is correct:

> 1) Number of objects in the list transmitted within a single Modbus response. If multiple transactions are
> required to retrieve all objects using given access type, this field might have a different value in each transaction.

The 'Number of Objects' gives you the number of Object entries in the list that follows.

Regards
Ulrich
 
Dear Frank,

Thank you for the reply.

> The sensible, and probably correct, interpretation is (1). It is possible to determine the number of objects in the
> response by stepping through them, adding up their lengths, until you reach the end of the message - but no other
> Modbus response requires you to use the length of the message to determine the number of data bytes/objects in the message.

You make a very good point here. Since Read Device Identification is also a public Modbus function, it should conform to the Modbus standard and do not enforce you to walk through the response stream in order to determine the number of objects transmitted in that PDU frame.

> However, an example in the specification shows a request that requires two responses, with 2 objects
> in the first response and 1 object in the second, and with the "number of objects" set to 3 in both responses.
> This is consistent with your meaning (2).

Yes, I noticed that too during my reading of the Modbus Application Protocol specification.

> I believe that the example is simply wrong, as a result of careless adaptation of the single transaction
> example (the two transaction example was not in the original draft IETF specification
> http://tools.ietf.org/html/draft-dube-modbus-applproto-00).
> But official clarification would be helpful!

I could not agree more - official response would be very helpful. I have already contacted Modbus Organization via their website form a couple days ago, but did not get any response yet.

Do you know someone appropriate who to ask?

Best regards
Ivo
 
Dear Ulrich,

Thank you for the reply.

> The 'Number of Objects' gives you the number of Object entries in the list that follows.

While I highly appreciate your confirmation of my hypothesis, do you happen to have any "evidence" that backs it up? I would be very interested to have a reference to one or more real Modbus server devices that implement Read Device Identification function.

Best regards
Ivo
 
J

Julian Krämer

Hi,

please have a look at the "MODBUS Application Protocol Specification V1.1b"! There's a detailed description of everything you need to know (p.44ff).

Request:
ReadDevId code is used to select the category you want to receive data from and the way to do this.
Basic category (stream access) Obj. ID 0x00 .. 0x02
Regular category (stream access) Obj. ID 0x03 .. 0x7F
Extended category (stream access) Obj. ID 0x80 .. FF
Specific Ident. Obj. (individual access)

Stream access means, that if you select a category (e.g. Regular) and request Object (e.g. 0x4) you get a response containing all implemented Objects starting from 0x4 to the end of the category. The Object ID in the request specifies the offset from which the reading starts.

The Number of Objects is used to indicate the amount of objects read, because they may vary regarding the Regular and Extended category.

Please have a look at the examples in the document named above. They are very useful!
 
L

Lynn August Linse

> While I highly appreciate your confirmation of my hypothesis, do you happen to have any "evidence" that backs
> it up? I would be very interested to have a reference to one or more real Modbus server devices that implement
> Read Device Identification function.

I think you are expecting too much 'perfection' here. Very few device support this command so even if you do right (or wrong), you may never really know. However, I assume most polling masters will expect & perhaps demand that the object count be 1, so if you add a second object they might either ignore the 2nd, or even refuse to read any objects at all.

Buy a Modicon or Telemecanique PLC and see what they do, as they are some of the few I trust to actually support.
 
F

Frank O'Gorman

Dear Ivo

> Do you know someone appropriate who to ask?

The only name I have is the one listed on the modbus.org contact page (Lenore Tracey). The email address lenore [at] modbus-ida [dot] org worked several years ago, but I don't know whether it is still correct.

Regards
Frank
 
F

Frank O'Gorman

Hi Julian

> please have a look at the "MODBUS Application Protocol Specification V1.1b"! There's a detailed description
> of everything you need to know (p.44ff).

It was this description that prompted Ivo's request for clarification!

> Please have a look at the examples in the document named above. They are very useful!

The second of these examples is the one I referred to in my earlier post, which is consistent with Ivo's meaning (2).

Frank
 
Dear Frank,

> The only name I have is the one listed on the modbus.org contact page (Lenore Tracey). The email address lenore [at]
> modbus-ida [dot] org worked several years ago, but I don't know whether it is still correct.

Thank you. I have just emailed Mrs. Tracey my request for clarification. I will keep you and others updated about the response I get from her or someone who is in charge of the Modbus specification.

Best regards
Ivo
 
Dear Julian,

Thank you for your reply.

> please have a look at the "MODBUS Application Protocol Specification V1.1b"! There's a detailed description
> of everything you need to know (p.44ff).

[snipped]

> Please have a look at the examples in the document named above. They are very useful!

I have already read that description along with accompanying examples in the document you refer to, but found some discrepancy between the description and the examples which requires some clarification. That is why I posted here.

Best regards
Ivo
 
Dear Lynn,

Thank you for your reply.

> I think you are expecting too much 'perfection' here. Very few device support this command so even if you do
> right (or wrong), you may never really know. However, I assume most polling masters will expect & perhaps demand
> that the object count be 1, so if you add a second object they might either ignore the 2nd, or even refuse to read
> any objects at all.

Acknowledged. I will take this into account when implementing the support for Read Device Identification function.

> Buy a Modicon or Telemecanique PLC and see what they do, as they are some of the few I trust to actually support.

Good suggestion, but unfortunately this is not an option for me at the moment. That is why I try to gather some information from other people who are experienced with devices that support this Modbus function.

Best regards
Ivo
 
Dear Ivo,

I cannot offer written evidence, however I am working with Schneider PLCs and have practical experience how these behave.

Best regards
Ulrich
 
Dear Ulrich,

> I cannot offer written evidence, however I am working with Schneider PLCs
> and have practical experience how these behave.

Thank you very much. By evidence I meant just a make/model of devices that you have some experience with, but your word is enough.

Best regards
Ivo
 
Dear Frank,

I just wanted to let you know that Mrs. Tracey received my email and promised to pass on my questions directly to the people working on Modbus specification. I cannot wait to get a response from her! I will keep you and others here updated.

Best regards
Ivo
 
Top