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
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 |
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 |
Agree with Peter here. I believe the controller that Bernt is having issues with here follows the "IFE Standard".
|
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.
|
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:
|
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 |
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.
|
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. |
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 09:11 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.