E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old November 8th, 2009   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default QUEUED_MESSAGE - ?

Hello,

I am not sure how to tread this pid. Currenlty I am not supporting it as it isn;t mandatory but I noticed earlier today that the 2 controllers (theya re not related) I have available here issue this pid almost constantly.
I NACK this with NR_UNSUPPORTED_PID.

What should I do instead to keep these controllers happy?

I am also wondering why none of the controllers I test with - except Enttech - acutally asks for SUPPORTED_PARAMTETERS.

The one controller asks for SENSOR_VALUE (for sensor 0) but never ask for SENSOR_DEFINITION. It then NEVER shows the value either

They all shoot of and just seem to do their own thing based on a set of assumptions that is not known to me.


Kind regards
Bernt
berntd is offline   Reply With Quote
Old November 9th, 2009   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 180
Default

Berntd

Can you please contact me off-list with details of the controllers you are using.

I am working with a number of companies to ensure consistency of implementations, and I also co-ordinate the various RDM demonstration areas at LDI and PLASA.

If I can invite these controller manufacturers to take a presence there, they are more likely to behave consistently.

Peter Willis
prwatE120 is offline   Reply With Quote
Old November 9th, 2009   #3
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 180
Default

Berntd

A reply to a GET:QUEUED_MESSAGES should normally be a STATUS_MESSAGE response, unless you actually have events (such as manual local change of DMX address) that you might be QUEUEING.

You are correct in thinking that if you have not declared support for QUEUED_MESSAGES, the controller has no needto be asking, although even your NACK can be used by a controller to keep track of the fact that you are indeed still on-line. So provided you did not have the QM PID in your list of supported PIDs, your use of NACK - NR_UNSUPPORTED_PID is correct.

In my mind, asking for SENSOR_VALUE (for sensor 0), without having asked for the definition is a symptom of an untested controller implementation.

regards

Peter Willis
prwatE120 is offline   Reply With Quote
Old November 10th, 2009   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Agree with Peter here. I believe the controller that Bernt is having issues with here follows the "IFE Standard".
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 10th, 2009   #5
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

Would be interesting to know what controller it is... In the current version of our controller we use the GET:QUEUED_MESSAGE even if the device doesn't support it and use the NACK only to keep track of the device still being online. We are currently discussing a good way to poll other devices instead of the QUEUED_MESSAGE PID for devices that not supports it to get some usefull data out.
__________________
Michael Karlsson
LumenRadio AB
mike_k is offline   Reply With Quote
Old November 11th, 2009   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I retract my earlier statement on agreeing with Peter on QUEUED_MESSAGES.

Section 11.1 gives guidance on this as we steer everyone towards using QUEUED_MESSAGES for the main polling message for a number of reasons. The issue is that not everyone supports QUEUED_MESSAGES.

We also allowed for the use of STATUS_MESSAGE with a Status Type of STATUS_NONE to effectively ping the device without retrieving any info.

We did allow for this though somewhat by stating in Section 11.1:

Quote:

Any response, including a NACK, to any message indicates the device is still present on the network.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 11th, 2009   #7
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 180
Default

Scott

I'm not sure how you are disagreeing with me?

If you have not declared support for QM in your list of supported PIDs, then surely it is correct to NACK them?

I was not advocating responding with the Status Response in the situation whereby you had not declared support for QMsgs.

Peter
prwatE120 is offline   Reply With Quote
Old November 12th, 2009   #8
Paul-Zero88
Task Group Member
 
Join Date: Dec 2008
Posts: 17
Default

In our RDM controller, we chose to use the SET:IDENTIFY_DEVICE (OFF) PID to 'ping' known responders to see if they were present on the network. This is a mandatory PID so there is no ambiguity about the response from the device. It also has the happy side-effect of clearing any stuck identify states in the responders. Of course this method might not be suitable for all controllers, but it worked for us.
Paul-Zero88 is offline   Reply With Quote
Old November 12th, 2009   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Another harmless way should be muting the device. You already know about the device sending it a Mute doesn't functionally affect anything.

The only potential loss of information is that you mask any intermittent reset issues. i.e. if a device is frequently reseting itself for some reason you would see that as you would continually find it un-muted during incremental discovery.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 24th, 2009   #10
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 180
Default

Following discussions at LDI amongst attendees of the ESTA Control Protocols Interoperability Pavillion (the RDM demo area), the following approach was discussed and has merit.

If the controller discovers a device that supported QUEUED_MESSAGES, then use that. For devices that DO NOT support QM, use a combination of GET:IDENTIFY_DEVICE and GET_DEVICE_INFO.

The use of IDENTIFY_DEVICE has low overhead, as the response message is short, and allows the controller to remain in sync with the true state of a responders IDENT status.

The use of DEVICE_INFO, whilst having a slightly higher response overhead (the message is slightly longer), it has the advantage of allowing the controller to keep track of the responders DMX Address and Personality.

Peter Willis
prwatE120 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 02:56 PM.


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