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 - must controllers support this? (http://www.rdmprotocol.org/forums/showthread.php?t=1182)

berntd October 31st, 2013 04:47 PM

QUEUED_MESSAGE - must controllers support this?
 
Hello group

Am just wondering about the queued messages again.
We have a controller here which does not fetch them from our device.
One needs to rediscover to update anything from the device.

The controller vendor mentioned that they have not implementet to get queued messages or send any RDM on the fly because RDM packets seem to interfere with DMX during shows and also cause problems with certain devices.

It is a valid point as we also had heaps of problems with DMX devices over the years behaving funny.

However, in not getting the messages, valuable information about errors and changes etc are never updated on the cotroller.

What's your take on that?


Regards
B

ericthegeek October 31st, 2013 09:59 PM

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.

sblair October 31st, 2013 10:06 PM

I would say that it is a pretty poor RDM implementation then.

I can understand if they feel the need to put a setting option in to disable RDM communication for devices that are non-compliant to the DMX standard that misbehave.

I know of at least one company that has philosophical disagreements with RDM polling in a show environment, but from the discussions I've had with them I'd say it is mostly out of ignorance and lack of experience.

My view is that devices need to support queued messages as it is a core part of RDM and that the decision of whether to disable all or part of RDM needs to be a choice for the user to make based on their needs.


All times are GMT -6. The time now is 07:04 AM.

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