![]() |
|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
![]() |
#1 |
Junior Member
Join Date: Jan 2010
Location: UK
Posts: 8
|
![]()
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. |
![]() |
![]() |
![]() |
#2 |
Administrator
|
![]()
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 |
![]() |
![]() |
![]() |
#3 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]()
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. |
![]() |
![]() |
![]() |
#4 |
Junior Member
Join Date: Jan 2010
Location: UK
Posts: 8
|
![]()
Hi Scott & Eric,
Thanks for the advice guys. I shall abandon the timeout in favour of a strobe on one channel. |
![]() |
![]() |
![]() |
#5 |
Junior Member
Join Date: Feb 2009
Posts: 13
|
![]()
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.
|
![]() |
![]() |
![]() |
#6 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
![]()
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. |
![]() |
![]() |
![]() |
#7 | |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]() Quote:
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. |
|
![]() |
![]() |
![]() |
#8 |
Member
Join Date: Aug 2011
Posts: 32
|
![]()
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. |
![]() |
![]() |
![]() |
#9 | |
Junior Member
Join Date: Nov 2014
Posts: 2
|
![]()
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:
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). |
|
![]() |
![]() |
![]() |
#10 |
Administrator
|
![]()
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 |
![]() |
![]() |
![]() |
#11 |
Junior Member
Join Date: Jan 2010
Location: Germany
Posts: 24
|
![]()
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.
|
![]() |
![]() |
![]() |
#12 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
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. |
![]() |
![]() |
![]() |
#13 | |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]() Quote:
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. |
|
![]() |
![]() |
![]() |
#14 |
Administrator
|
![]()
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 |
![]() |
![]() |
![]() |
#15 | ||
Junior Member
Join Date: Oct 2018
Location: London
Posts: 11
|
![]() Quote:
Quote:
|
||
![]() |
![]() |
![]() |
#16 |
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]()
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. |
![]() |
![]() |
![]() |
#17 |
Administrator
|
![]()
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 |
![]() |
![]() |
![]() |
#18 |
Administrator
|
![]()
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 |
![]() |
![]() |
![]() |
#19 | ||
Member
Join Date: Oct 2017
Location: Turkiye
Posts: 38
|
![]() Quote:
Quote:
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. |
||
![]() |
![]() |
![]() |
#20 | |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
![]() Quote:
If you want to do something like this, you might want to consider monitoring for *any* RDM traffic. |
|
![]() |
![]() |
![]() |
Bookmarks |
|
|