QUEUED_MESSAGE - must controllers support this?

[berntd]

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]

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]

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.

[zano_villa]

Hello everyone,


I have a ROOT DEVICE with SUBDEVICES both need and support QUEUED MESSAGES.
Do I have to specify QUEUED MESSAGE support on SUPPORTED PARAMETER PID of SUBDEVICES or is it enough to specify for ROOT DEVICE ?


Thank you

[ericthegeek]

Get QUEUED_MESSAGES should only be sent to the root device, so only the root devices should include the PID in its list of SUPPORTED_PARAMETERS.

If the responder responds to the request with a queued message it can set the sub-device field in the response to match the relevant sub-device. To reiterate: The Request is sent to the responders root, but the response can come from any sub-device.

If the responder responds to the request with one or mote status messages, the the response sub-device is always zero (root), but each status message within the response includes the sub-device