E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   QUEUED_MESSAGE - ? (http://www.rdmprotocol.org/forums/showthread.php?t=1046)

berntd November 8th, 2009 07:57 PM

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

prwatE120 November 9th, 2009 01:56 AM

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 November 9th, 2009 02:03 AM

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

sblair November 10th, 2009 04:08 PM

Agree with Peter here. I believe the controller that Bernt is having issues with here follows the "IFE Standard".

mike_k November 10th, 2009 04:42 PM

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.

sblair November 11th, 2009 12:39 PM

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.


prwatE120 November 11th, 2009 02:43 PM

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

Paul-Zero88 November 12th, 2009 01:22 AM

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.

sblair November 12th, 2009 03:53 PM

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.

prwatE120 November 24th, 2009 08:48 AM

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


All times are GMT -6. The time now is 05:39 AM.

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