E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 15th, 2010   #1
Gerry
Junior Member
 
Join Date: Jan 2010
Location: UK
Posts: 8
Default 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.
Gerry is offline   Reply With Quote
Old January 15th, 2010   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 15th, 2010   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old January 18th, 2010   #4
Gerry
Junior Member
 
Join Date: Jan 2010
Location: UK
Posts: 8
Default

Hi Scott & Eric,

Thanks for the advice guys.
I shall abandon the timeout in favour of a strobe on one channel.
Gerry is offline   Reply With Quote
Old January 18th, 2010   #5
dangeross
Junior Member
 
Join Date: Feb 2009
Posts: 13
Default

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.
dangeross is offline   Reply With Quote
Old March 3rd, 2012   #6
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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.
prwatE120 is offline   Reply With Quote
Old March 3rd, 2012   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by prwatE120 View Post
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.
ericthegeek is offline   Reply With Quote
Old April 25th, 2012   #8
owaits
Member
 
Join Date: Aug 2011
Posts: 32
Default

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.
owaits is offline   Reply With Quote
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
Old November 12th, 2014   #10
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 19th, 2014   #11
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

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.
este_ is offline   Reply With Quote
Old December 12th, 2018   #12
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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.

Last edited by majid; December 12th, 2018 at 06:53 AM.
majid is offline   Reply With Quote
Old December 12th, 2018   #13
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by majid View Post
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.
ericthegeek is offline   Reply With Quote
Old December 13th, 2018   #14
peternewman
Junior Member
 
Join Date: Oct 2018
Location: London
Posts: 11
Default

Quote:
Originally Posted by majid View Post
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.
peternewman is offline   Reply With Quote
Old December 18th, 2018   #15
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

Quote:
Originally Posted by peternewman View Post
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 View Post
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.
majid is offline   Reply With Quote
Old December 19th, 2018   #16
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by majid View Post
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.
ericthegeek is offline   Reply With Quote
Old December 12th, 2018   #17
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old December 13th, 2018   #18
majid
Member
 
Join Date: Oct 2017
Location: Turkiye
Posts: 38
Default

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.
majid is offline   Reply With Quote
Old December 13th, 2018   #19
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old December 17th, 2018   #20
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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."
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 05:26 AM.


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