QUEUED_MESSAGE - must controllers support this? - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · October 31st, 2013

There's nothing in the standard that requires controllers to support queued messages. Thus, a manufacturer is free to decide whether they wish to support them or not.

But, a controller that doesn't support queued messages will have some major limitations. It won't work with equipment that acts as an RDM proxy (such as most of the wireless DMX systems), or anything else that uses ACK_TIMER.

Thus, it's my strong recommendation that any controller with more than an absolute minimum features set should implement queued messages.

Even something extremely simple (think DFD RAD) should support fetching queued messages in response to an ACK_TIMER.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
QUEUED_MESSAGE & Status Types	pkleissler	RDM Interpretation Questions	13	August 1st, 2019 03:23 AM
QUEUED_MESSAGE - ?	berntd	RDM General Implementation Discussion	9	November 24th, 2009 08:48 AM
Must a device support 32 charecters in DEVICE_LABEL?	p_richart	RDM Interpretation Questions	5	November 7th, 2008 01:02 PM
DMX/RDM support in new SBC	tracyu	RDM Marketplace Discussion	0	June 2nd, 2008 05:57 PM

October 31st, 2013	#2
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	There's nothing in the standard that requires controllers to support queued messages. Thus, a manufacturer is free to decide whether they wish to support them or not. But, a controller that doesn't support queued messages will have some major limitations. It won't work with equipment that acts as an RDM proxy (such as most of the wireless DMX systems), or anything else that uses ACK_TIMER. Thus, it's my strong recommendation that any controller with more than an absolute minimum features set should implement queued messages. Even something extremely simple (think DFD RAD) should support fetching queued messages in response to an ACK_TIMER.