E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Timing out IDENTIFY_DEVICE (http://www.rdmprotocol.org/forums/showthread.php?t=1058)

Gerry January 15th, 2010 04:20 AM

Timing out IDENTIFY_DEVICE
 
Is it advisable for a responder to time out IDENTIFY_DEVICE?
It seems a good idea to me, as it prevents the situation where a lamp could appear to be stuck on if the controller failed to clear it for some reason.

sblair January 15th, 2010 10:36 AM

There has been discussion on this in the past. In some respects it is application dependant. The standard does not currently mandate this either way.

The preference by most of us is to leave it enabled until the responder is reset or an identify off has been sent. Depending on the product, the type of install and venue there are reasons why you don't want it to automatically stop. If you are in a large architectural install or the device is not physically viewable for the location where the RDM controller is you want IDENTIFY to remain enabled until you have had a chance to physically track the device down.

ericthegeek January 15th, 2010 02:49 PM

I strongly feel that IDENTIFY_DEVICE should remain in place until explicitly turned off.

I can think of nothing more frustrating than setting a fixture that needs repair to identify, walking 5 or 10 minutes across a large venue to get to it, only to have identify time out seconds before you get there.

If the controller wishes to implement a way to automatically disable identify, it is free to do so. The advantage of doing it at the controller is that it's easier for the user to setup a timeout that makes sense for their venue, rather than building it into the fixture's firmware.

You could adjust a built-in timeout via a manufacturer specific PID in the fixture, but this will not be widely supported and will result in different behavior from different manufacturers.

I understand the concern about a fixture seeming to be stuck on. In general, I think it's best if the identify behavior is somewhat dynamic, with a strobe, ongoing color change, or fast fade. This way it's clear that nothing is stuck and that the behavior is deliberate.

Gerry January 18th, 2010 10:04 AM

Hi Scott & Eric,

Thanks for the advice guys.
I shall abandon the timeout in favour of a strobe on one channel.

dangeross January 18th, 2010 10:40 PM

I agree I would want the IDENTIFY_DEVICE to On until turned Off or the device is reset via RDM/Local Panel/Power Cycle. I would want the controller to keep track of which devices it has set IDENTIFY_DEVICE to On and also allow the transmission of a broadcast IDENTIFY_DEVICE Off.

prwatE120 March 3rd, 2012 02:49 AM

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 March 3rd, 2012 09:46 AM

Quote:

Originally Posted by prwatE120 (Post 2332)
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 April 25th, 2012 09:21 AM

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 November 12th, 2014 11:26 AM

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 (Post 2357)
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).

sblair November 12th, 2014 12:32 PM

Daniel,

It's a fair suggestion. In the past we have gone away from having Identify expire on it's own as it creates a whole host of user issues, especially for someone that has to go hunting for the piece of gear with the blinky light on it compared to the moving light that is in a very obvious strobe and having the identify expire while in the middle of walking around searching for it.

The route I expect we would probably take in adding something like this would be to create an additional PID that defines the timeout duration so that devices that support a variable duration can be easily identified by the controller up front rather than through trial and error.

There is a new document about to go out for Public Review that adds a whole suite of additional PIDs (BSR E1.37-5) it should be in Public Review by the end of the year. I would suggest putting in a Public Review comment for a new PID for this and anything else you might like to see during the Public Review and it then gets discussed by the entire Task Group and addressed.

este_ November 19th, 2014 07:12 AM

Our responders use a automatic identify timeout: they do not termi ate identify mode but change from LOUD mode to QUIET mode after three minutes or so to prevent "visible hanging" . Next IDENTIFY ON command will then invoke LOUD mode again (when enabled). Maybe this could be a solution to your problem.

majid December 12th, 2018 02:29 AM

I am struggling similar situation, I need to define suitable requirement for behaviour for my responder (LED fixture).
Implementing timeout using PERSONLITY seems possible, so that "WITH TIMEOUT" and "WITHOUT TIMEOUT" will be selectable via PERSONALITY.

In fact my question is something else, but I think related to this dıscussion so I decide write here.
I defined requirements as below:

1) with only RDM signal and IDENTIFY_DEVICE = 1, then LEDs will show R-G-B etc.

2) with only DMX signal and IDENTFY_DEVICE = 0, then LEDs will be turned on according to DMX data

3) with both DMX and RDM alternately mixed signal (such as 40 fps = 39 DMX + 1 RDM ) and IDENTIFY_DEVICE = 0 then LEDs will be turned on according to DMX, no change at RDM signal

4) with both DMX and RDM alternately mixed signal and IDENTIFY_DEVICE = 1 then ... my question rise up here!

Maybe IDENTIFY show would be canceled after receiving DMX signal ...
Maybe DMX signal would be ignored while IDENTIFY_DEVICE is set ...

I am not sure since I have no real field experience about RDM.

I appreciate sharing experiences.

ericthegeek December 12th, 2018 09:02 AM

Quote:

Originally Posted by majid (Post 3261)
4) with both DMX and RDM alternately mixed signal and IDENTIFY_DEVICE = 1 then ... my question rise up here!

Maybe IDENTIFY show would be canceled after receiving DMX signal ...
Maybe DMX signal would be ignored while IDENTIFY_DEVICE is set ...


Most real-world controllers will always send DMX, with RDM interleaved as needed. This means you need to use the second option you listed.


The DMX signal should be ignored when IDENTIFY_DEVICE is enabled.

sblair December 12th, 2018 11:00 PM

Hey Majid,

You're fine up until step 4. You're going to have problems in that case because the vast majority of the time you will have RDM commands interleaved between the DMX packets. This means that if packets are being interleaved and you try and revert to DMX having control then Identify will instantly be turned back off.

My view and I'm pretty sure Eric's view too has not changed in the last 8 years since our original posts on this, then when Identify is enabled it should take precedence until it has been explicitly turned off (or the fixture rebooted).

We are adding a new PID for IDENTIFY_TIMEOUT that allows the timeout to be user settable if desired and supported. This is in E1.37-5 which is currently in Public Review. http://tsp.esta.org/tsp/documents/do...2018-09-20.pdf

I would generally strongly discourage using Personalities for setting options like this. It is not technically against the standard to do it, but personalities are so often over used for setting obscure options that it really makes a mess of things, especially for lighting consoles that have to have a fixture library for each Personality in order to know how to control it.

peternewman December 13th, 2018 04:51 AM

Quote:

Originally Posted by majid (Post 3261)
Maybe DMX signal would be ignored while IDENTIFY_DEVICE is set ...

I'll just echo what others have said majid, and also point out IDENTIFY_MODE in E1.37-1 which would be a better way to control whether the DMX signal is ignored (in loud mode) or not.

Quote:

A value of 0x00 represents a “Quiet Identify” mode. This would typically be used for flashing a front panel indicator or display to visually identify the device discretely in a show situation with an audience present.

A value of 0xFF represents a “Loud Identify” mode. This would typically be used for a highly visual indication such as strobing a lighting fixture or outputting fog in a non-show situation without an audience present.

majid December 13th, 2018 11:17 PM

Thank you Eric and Scott.

Now It's clear to determine how responder supposed to behave on RDM signal timeout. I will follow official solution, IDENTIFY_TIMEOUT is the definite solution if needed.

There is similar requirement for us for DMX signal.
Some of our customers also expect DMX LED fixtures to show simple color change at loss of DMX signal. with approximately 1 minute timeout.

We have designed a simple DEMO-REPEATER device.
so that DMX signal go through it and in absense of DMX signal input, after 1 minute timout, it streams out DEMO dmx data ,
when DMX signal present again, it repeats exactly the input signal

I am planning to embed this requirment inside our new RDM LED fixtures.
I think it no harms while while IDENTIFY_DEVICE = 1, since device will ignore DMX signal.
but It seems would be confusing while IDENTIFY_DEVICE = 0,

Is there recommended/official solution to satisfy this last requirement (DMX timeout)?
otherwise I will reject the requirement and offer our old solution DEMO-REPEATER if requested.

sblair December 13th, 2018 11:32 PM

Majid, it really all depends on your market and customer requirements as well as type of product.

DMX signal loss behavior is different in almost every product. Most moving lights would typically close the douser after a couple seconds and then after several minutes might turn off the discharge lamp. In some moving lights this was configurable.

Lots of dimming systems would hold the last look for a variable amount of time. It was common to be able to program a default look in the dimmer rack for it to switch to on loss of DMX.

Lots of DJ type fixtures will switch to sound to light or demo mode as you mention.

For an architectural application, you would probably want it to hold the last look forever.

Point is there really is no one right answer as to what to do on loss of DMX as it is different for everything.

sblair December 17th, 2018 06:51 PM

It's also worth noting that the current public review document for the E1.20 revision has the following language added to IDENTIFY_DEVICE

"Once Identify is enabled it should remain active until explicitly disabled."

majid December 18th, 2018 10:39 PM

Quote:

Originally Posted by peternewman (Post 3264)
I'll just echo what others have said majid, and also point out IDENTIFY_MODE in E1.37-1 which would be a better way to control whether the DMX signal is ignored (in loud mode) or not.

Thanks for comments Peter.

Quote:

Originally Posted by sblair (Post 3266)
Majid, it really all depends on your market and customer requirements as well as type of product.

DMX signal loss behavior is different in almost every product...

I think even with IDENTIFY_DEVICE=0 , DMX signal timeout behaviour of LED fixtures maybe confusing.
I imagine during an RDM setup session, controller sets only one of responders IDENTIFY_DEVICE=1 and clears other responders.
after desired timeout , the one with IDENTIFY_DEVICE=1 remains in identify mode and all other fixtures with IDENTIFY_DEVICE=0 start glowing demo/default mode and bother user sight.

to avoid this situation, maybe the responder somehow ought to detect the RDM setup is runnig and never start demo/default mode even with IDENTIFY_DEVICE=0
for example after receiving DISC_MUTE command, the responder would cancel demo mode until next restart. etc.

ericthegeek December 19th, 2018 01:36 PM

Quote:

Originally Posted by majid (Post 3275)
for example after receiving DISC_MUTE command, the responder would cancel demo mode until next restart. etc.

Many systems will have discovery disabled during showtime, so you can't use DISC_MUTE to determine whether there's a RDM controller present.

If you want to do something like this, you might want to consider monitoring for *any* RDM traffic.


All times are GMT -6. The time now is 05:07 PM.

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