E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

 
 
Thread Tools Search this Thread Display Modes
Prev Previous Post   Next Post Next
Old February 14th, 2012   #1
ggallant
Task Group Member
 
Join Date: Feb 2012
Posts: 5
Default ACK_TIMER corner cases

Hey guys, I have two unusual ACK_TIMER response cases I'd like to think are illegal, but the RDM spec doesn't expressly forbid:

1. ACK_TIMER following ACK_OVERFLOW for the same pid

For example:

GET LAMP_HOURS
GET_RESPONSE ACK_OVERFLOW LAMP_HOURS
GET LAMP_HOURS
GET_RESPONSE ACK_TIMER LAMP_HOURS
Is this legal? Has anyone seen or created a responder that does this?
Spec 6.3.2 says:
The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.

and Spec 6.3.3 says:
This mechanism allows the controller to [shall] retrieve deferred Get command data by issuing GET QUEUED_MESSAGE
The combination of both of these clauses indicates to me that it's illegal, because the correct controller followup to the ACK_TIMER (GET QUEUED_MESSAGE) would reset the overflow sequence; i.e. the responder would violate 6.3.3 by allowing the partial transfer to continue.

If I'm right, the Spec should expressly state that once a responder returns ACK_OVERFLOW for a given pid, it may not subsequently return ACK_TIMER for that pid until it has returned an ACK/NACK.

2. ACK_TIMER response to GET QUEUED_MESSAGE.


Is this legal? It seems slippery to me, e.g.:

GET QUEUED_MESSAGE
GET_RESPONSE ACK_TIMER LAMP_HOURS

To me, that response says, "responder's ACK_TIMER timeout on the original GET LAMP_HOURS was wrong; it needs more time to respond". Yah, it's hokey, but plausible.

There's also:

GET QUEUED_MESSAGE
GET_RESPONSE ACK_TIMER QUEUED_MESSAGE

This response to me says, "responder needs more time to prepare its queued messages".

Has anyone seen this?

Section 10.3.1 says:
Each QUEUED_MESSAGE response shall be composed of a single message response

I'm not sure what "single message" is supposed to mean.

Aside, and this is just me ranting... since the Spec allows lock-step sequencing, it should have stipulated which sequence patterns are valid. Also, RDM should not have dual-purposed QUEUED_MESSAGE for both change reporting and delayed response. Delayed response should have been handled with a "pending write, latest read" pair common to other SCADA systems. This would have made ACK_TIMER congruent to ACK_OVERFLOW, eliminated the above confusion as to which order and pids are valid for ACK_TIMER, and most importantly, saved controllers from having to flush a queue of (typically unrelated) messages to get to the data they originally asked for.
ggallant is offline   Reply With Quote
 

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
RDM Compatibility Corner at PLASA 2010 prwatE120 RDM General Implementation Discussion 0 September 4th, 2010 05:25 AM


All times are GMT -6. The time now is 11:38 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.