Sub-device response to SET/GET DMX512 start address

[p_richart]

Hello all!

I'm working on a device with sub-devices and wonder if anyone can tell me how I should respond to a 'SET DMX512 start address' PID that is sent to a particular device with the sub-device field set to 0xFFFF (SUB_DEVICE_ALL_CALL)? After I set all subdevices to the same address do I respond with 0xFFFF in the sub-device field? Or do I not respond at all since it is an all call?

Also, slightly more confusing for me, how do I respond to a GET 'DMX512 Start Address' PID where one device is identified (not a broadcast command) but the sub-device field is loaded with SUB_DEVICE_ALL_CALL? Only one address will fit in the PD for this response but each of my subdevice's addresses could be different.

Thanks!
Patrick Richart

[sblair]

Patrick,

For Question #1:
It is expected that messages sent to a SUB_DEVICE_ALL_CALL for a specific UID respond back to the controller. Since you are communicating to a specific UID, there aren't any collision issues that you would have using an ALL_CALL with other root devices.

You'll see in the message templates for the Controller and Response messages that 0xFFFF is included in the Sub-Device field as valid for response messages.

For Question #2:
For a GET sent to all the SUB_DEVICE_ALL_CALL the answer is a little less clear. There is no defined behavior I can think of that specifies a useful response here. It's kind of a non-sensical request to get from a controller for some devices.

Some options you have:


If you have determined that all your devices in fact have the same value for all sub-devices you could respond with the actual data value with the SUB_DEVICE_ALL_CALL.

You could Queue up messages for ALL the Sub-devices and return them one at a time with the QUEUED_MESSAGE request. Could be a bit messy though.

Probably the safest thing I can think of would be to NACK it with NR_SUB_DEVICE_OUT_OF_RANGE, that way there is no confusion about what you're going to do with that GET request for all the sub-devices.

[prwatE120]

Patrick

For Question #2

I favour Scotts third option - use of the NACK with NR_SUB_DEVICE_OUT_OF_RANGE