GET_STATUS_MESSAGES for fault reporting

[dj41354]

from ANSI E1.20-2010 Section 6 Message Structure:
sub-section 6.2.8 Message Count:
"The message count field is used by a responder to indicate that additional data is now available for collection by a controller. This data (which might be unrelated to the current message transaction) should be collected by the controller using the GET:QUEUED_MESSAGE command."

This paragraph certainly makes it sound like the Message Count field is used by QUEUED_MESSAGE, not STATUS_MESSAGES... so I guess I'm still unclear on this..

Questions:
1) Is it ok to implement STATUS_MESSAGES and not implement QUEUED_MESSAGE?
(you said in your 4th response to me above: "You have to include Queued Messages, whether you include status messages in the count is up to you."
2) If Message Count is not used with my implementation of STATUS_MESSAGES, how does the controller know to ask for device status?.. does the controller just do this occasionally on it's own?

Thanks for you help with this..

[ericthegeek]

Originally Posted by dj41354

from ANSI E1.20-2010 Section 6 Message Structure:
sub-section 6.2.8 Message Count:
...
This paragraph certainly makes it sound like the Message Count field is used by QUEUED_MESSAGE, not STATUS_MESSAGES... so I guess I'm still unclear on this..

It's a good question, and your interpretation is perfectly valid. The ambiguity arises because of Section 10.3.1 paragraph 3:
"A responder with no messages queued shall respond to a QUEUED_MESSAGE message with a STATUS_MESSAGES response."

This means that a status message can also be collected by a GET QUEUED_MESSAGE request, thereby fulfilling the requirements of the paragraph that you quote.

I think your interpretation (that only Queued Messages should be included in the message count) is the better interpretation, but there are others who disagree.

Originally Posted by dj41354

1) Is it ok to implement STATUS_MESSAGES and not implement QUEUED_MESSAGE?
(you said in your 4th response to me above: "You have to include Queued Messages, whether you include status messages in the count is up to you."

I'll re-state it like this: "You have to include any outstanding Queued Messages in the Message Count field. Whether you include status messages in the Message Count is up to you."

By way of example: If you have 2 queued messages and 3 status messages waiting, then the message count could be 2 (queued messages only), or 5 (Queued plus Status messages). It's your choice, just as long as you're consistent.

Support for the STATUS_MESSAGES and QUEUED_MESSAGE PIDs is optional. You can support either one of them individually, both, or neither. It's entirely up to you.

Originally Posted by dj41354

2) If Message Count is not used with my implementation of STATUS_MESSAGES, how does the controller know to ask for device status?.. does the controller just do this occasionally on it's own?

Many controllers will poll for status and/or queued messages on an ongoing basis. Common (but not universal) behavior is to poll each responder every few seconds.

Originally Posted by dj41354

Thanks for you help with this..

Happy to help. That's why these forums exist. Hopefully you'll stick around, and maybe in a year or so you'll be the one answering questions!