Timing out IDENTIFY_DEVICE

[prwatE120]

After quite a bit of field experince with this, I take the exact opposite view to Eric, and insist that IDENTIFY Timeout on all our products. With wireless links and remote controls, you dont need to be 5-10 minutes walk from the areas you are trying to ident, and there is nothing worse than having a director shout at you to "to turn off that .... flashing light" when, as a result of the problem you are possibly chasing in the first place, you have lost control of the fixture via RDM and cannot use the controller to turn it OFF.

In order to keep sync with controllers, we of course attempt to issue a queued message that indicates to the controller that the IDENTIFY has expired.

As the standard does not speak to thia at all, both approaches are acceptable, and it is down to the manufacturer to decide.

Certainly it is a good idea for a console to have the ability to send a broadcast IDENTIFY_DEVICE Off - I seen a few that don't.

[ericthegeek]

Originally Posted by prwatE120

there is nothing worse than having a director shout at you to "to turn off that .... flashing light" when, as a result of the problem you are possibly chasing in the first place, you have lost control of the fixture via RDM and cannot use the controller to turn it OFF.

This problem is not unique to RDM can happen with plain old DMX too. If you've put the fixture into a strobe or color cycle mode and then lose DMX control, many fixtures will hold their last state until signal returns.

Arguably, the right way to handle this when you have talent on stage is to use the IDENTIFY_MODE QUIET PID from E1.37-1.

[owaits]

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.

Otherwise we end up in a mess where some fixtures time out in 1 min, others in 5min and others will never time out. Specifying a timeout in the packet would remove ambiguity and give the controller control.

[daniel]

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.

Originally Posted by owaits

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).