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.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 2nd, 2014   #1
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default STATUS_NONE response

How should a responder answer a get status request when there are no status warnings or messages pending? The document is not clear on that. I'm currently using the STATUS_NONE type response with the data fields set to 0. That is nine zeros I believe. The test software I'm using shows this as an unknown status response so it must be expecting something else here. If I respond with a warning like "overtemp" , it shows it as expected. Using Enttec RDM controller BTW.
kenypp is offline   Reply With Quote
Old January 2nd, 2014   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 420
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Welcome to the forums!

STATUS_NONE is not allowed as a valid Status Type in a response message. This is indicated in Table 10-1 as the NONE type isn't listed as one of the valid return types.

The proper response is to do a standard format GET_COMMAND_RESPONSE for STATUS_MESSAGES with a PDL of 0 and nothing in the Parameter Data (PD) block.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 2nd, 2014   #3
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default

Thanks, that was going to be my second choice to try out although I didn't see it listed anywhere as a suggested response. This responder is a simple light with only a couple of status responses possible. Should I return this empty response for the status clear types and any other status types that the fixture doesn't support?
kenypp is offline   Reply With Quote
Old January 2nd, 2014   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 420
Send a message via AIM to sblair Send a message via MSN to sblair
Default

The _CLEARED types are not types that can be requested by the controller. If you look at Table 10-1 the column on the left shows all the possible Status Types that a controller can send to you as a request. The other columns going across are the Status Types allowed to be returned for a given Status Type request.

If you don't support the "_CLEARED" types then all you have to do is just not ever return one as part of a response.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 3rd, 2014   #5
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default

Thanks for explaining table 10-1, that was very helpful.
I had a few quick questions regarding my implementation that I'll add here rather than starting a new thread.
1. Is there a public status warning for "replace bulb"? I didn't see one in the appendix.
2. When responding to get device info, is this still RDM version 1.0? I saw it mentioned in the document even though the document is labeled 1.20.
3. When responding to an unsupported parameter request I am using nack reason unknown. When responding to a set when only get is supported I am using nack reason unsupported parameter. This is how I read it in table A-17. Is this correct?
kenypp is offline   Reply With Quote
Old January 3rd, 2014   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 420
Send a message via AIM to sblair Send a message via MSN to sblair
Default

1. There are additional messages posted at: http://tsp.plasa.org/tsp/working_gro...RDMextras.html STS_LOAD_FAILURE is the generally applicable one for a failed lamp. There are some other messages that might be relevant depening on the type of lamp and system involved as we have some that are used for indicating load (wattage) changes and some specific for discharge lamps.

2. Yes, the Protocol Version ID is still 1.0. The E1.20 you see is the ANSI designation for the RDM document. It's not a version number, but the number for the RDM standard as all ANSI standards are identified by a unique number.

3. For responding to an unsupported parameter request, i.e. you get a request for a message PID you don't support you should use NR_UNKNOWN_PID.

If you are responding to a SET request when you only support GET on that message then you should use NR_UNSUPPORTED_COMMAND_CLASS.

Also, I'm not sure where you are located but I would highly suggest attending the upcoming RDM Plugfest in Dallas in a few weeks if you can make it. Details are located here: http://tsp.plasa.org/tsp/news/newsde...php?newsID=459

The event is free and there is access to a lot of RDM testing gear and diagnostics that have been developed to help determine compliance to the standard and what corrections might be needed. Everyone involved with writing the standards are also there so it's a great opportunity to get a lot of free consulting and guidance and implementation testing done.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 3rd, 2014   #7
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default

I'm in the LA area. I don't think I can make it but hopefully there will be lots of stuff posted during and after that will be available. Thanks for the link to additional messages.
kenypp is offline   Reply With Quote
Old January 4th, 2014   #8
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

If you're at all serious about RDM Development, let me reiterate Scott's suggestion to attend the plugfest. The plugfests aren't boring technical presentations. Rather, it's a bunch of engineers sitting around a table with compilers and oscilloscopes to figure out what equipment works well together, and when things don't work why they broke. It's a great chance to play with a wide variety of controllers, responders, splitters, and test equipment, and you'll never find a more knowledgeable group of people about PLASA Control Protocols. We've had developers show up with a basically non-functional product on Friday afternoon, and leave with something that's mostly debugged on Monday.

It's not really something that gets posted on the web afterwards. It's more a case of finding out that your product doesn't work properly when connected to an AAA console through a BBB wireless link.
ericthegeek is offline   Reply With Quote
Old January 4th, 2014   #9
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default

Just to finally clarify the status response question, I'm interpreting table 10-1 as: Always respond to all status requests including status none with at least a standard ack response with no data. Only respond with data if there is a status advisory, warning or error requested and there is something to report. Am I correct? Thanks for all of your help.
kenypp is offline   Reply With Quote
Old January 4th, 2014   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

Quote:
Originally Posted by kenypp View Post
Always respond to all status requests including status none with at least a standard ack response with no data. Only respond with data if there is a status advisory, warning or error requested and there is something to report. Am I correct?
Yes, you are correct.

Also, make sure you handle STATUS_GET_LAST_MESSAGE properly. GET_LAST is used to re-transmit Status Messages (and Queued Messages) when the data gets lost or corrupted in-transit. It's crucial that responders support GET_LAST otherwise messages can be permanently lost.
ericthegeek is offline   Reply With Quote
Old January 5th, 2014   #11
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default

If the last response to a GET_STATUS request was an empty ACK is that what should be returned for a GET_LAST request or do you go back to the last status message that contained data?
kenypp is offline   Reply With Quote
Old January 5th, 2014   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

My interpretation is that you should send the Empty Status response.

Another corner case to watch out for if what happens if you receive a STATUS_GET_LAST_MESSAGE before you've received any GET Status Messages requests. Again, in this case you should send an ACK with an empty payload.
ericthegeek is offline   Reply With Quote
Old January 5th, 2014   #13
kenypp
Junior Member
 
Join Date: Jan 2014
Posts: 9
Default

Thanks Eric
kenypp is offline   Reply With Quote
Old February 7th, 2014   #14
Milton Davis
Task Group Member
 
Join Date: Aug 2006
Posts: 12
Default

Further to this, Scott said:

"If you don't support the "_CLEARED" types then all you have to do is just not ever return one as part of a response".

If I receive a request for status type that is one of the _CLEARED variety and I don't support that, what should the response be if I'm not echoing the _CLEARED status type?

Regards,
Milton Davis
Milton Davis is offline   Reply With Quote
Old February 7th, 2014   #15
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 360
Default

Quote:
Originally Posted by Milton Davis View Post
If I receive a request for status type that is one of the _CLEARED variety and I don't support that, what should the response be if I'm not echoing the _CLEARED status type?
The controller will never send a request for an _CLEARED Status Type.

The controller will send a GET STATUS_MESSAGES Status Type ERROR. The responder can then return status messages with Status Type ERROR and ERROR_CLEARED.

Request:
GET STATUS_MESSAGES ERROR

Response:
ERROR: Dimmer Room Flood
ERROR: Low Line Voltage
ERROR: Ground Fault Trip
ERROR_CLEARED: Dimmer on fire
ERROR_CLEARED: Dimmer Rack Overtemp

To put it colloquially, the controller asks: "Tell me about your error conditions". The responder then replies "The following 3 error conditions have occurred, and 2 error conditions I reported earlier are no longer present.

The controller will not send:
GET STATUS_MESSAGES ERROR_CLEARED


Edit:
If your responder receives a request for Status Type _CLEARED, you should respond with "NR_DATA_OUT_OF_RANGE".

Last edited by ericthegeek; February 7th, 2014 at 11:48 AM.
ericthegeek is offline   Reply With Quote
Old February 7th, 2014   #16
Milton Davis
Task Group Member
 
Join Date: Aug 2006
Posts: 12
Default

Many thanks, Eric. More of the careful interpretation of table 10-1...

Regards,
Milton
Milton Davis is offline   Reply With Quote
Reply

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


All times are GMT -6. The time now is 03:17 PM.


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