View Single Post
Old November 12th, 2014   #9
daniel
Junior Member
 
Join Date: Nov 2014
Posts: 2
Default

This bit me while working on a new product. I was trying out DF's RAD and did my addressing, then immediately pulled the wire and plugged it into a non-RDM capable DMX source. My fixture was now permanently stuck on (until I re-plugged the RAD), and I think this is a problem. I do not want to force Identify to expire if that is going to be unexpected behavior though.

Quote:
Originally Posted by owaits View Post
My feeling is that if Identify is expected to timeout there should be a parameter in the packet to specify the timeout. Without this parameter it should wait till the Off command is sent.
I realize adjusting existing commands can be dicey, but here is a possibility:
The present 8-bit parameter of IDENTIFY_DEVICE is only valid for 0 (off) or 1 (on). It might be possible to assign higher values to a series of time settings, ie 3 = 10s, 4 = 30s, 5 = 1m... or something...

If an RDM terminal is set by the user to issue expiring IDENTIFY_DEVICE commands, it can attempt to send IDENTIFY_DEVICE with a parameter other than 0 or 1. A device that does not support this will (or should) respond with NR_DATA_OUT_OF_RANGE. This will inform the controller that the device does not support timeout values. The controller can fall back to issuing IDENTIFY_DEVICE[1] (on) and working as it does now.

But for a fixture that DOES respond to those, the controller will periodically send out renewal messages for IDENTIFY_DEVICE. ie IDENTIFY_DEVICE[4] every 30 seconds.

In any case, when the controller is finished with the fixture, it will issue IDENTIFY_DEVICE[0] (off).
daniel is offline   Reply With Quote