E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Thread Tools Search this Thread Display Modes
Old October 31st, 2013   #1
Senior Member
Join Date: Jan 2008
Posts: 102
Default 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?

berntd is offline   Reply With Quote
Old October 31st, 2013   #2
Task Group Member
Join Date: Aug 2008
Posts: 376

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.
ericthegeek is offline   Reply With Quote
Old October 31st, 2013   #3
Join Date: Feb 2006
Posts: 436
Send a message via AIM to sblair Send a message via MSN to sblair

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.
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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

All times are GMT -6. The time now is 03:40 AM.

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