QUEUED_MESSAGE - ? - E1.20 RDM (Remote Device Management) Protocol Forums

prwatE120 · November 24th, 2009

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

November 24th, 2009	#10
prwatE120 Task Group Member Join Date: Jun 2006 Posts: 181	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