E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   LAMP ON MODE (http://www.rdmprotocol.org/forums/showthread.php?t=1013)

-dalc- June 22nd, 2009 07:16 AM

LAMP ON MODE
 
Rdm standard provides the "LAMP ON MODE OFF" mode (Lamp stays off until directly instructed to strike).
I was requested (from one of the biggest italian service) to provide a mode in witch Lamp stays off independently from any other condition (Lamp stays off despite instructed to strike).
This could be very useful during device testings.
I could implement this mode as a "manufacturer specific mode", but I think that it would be interesting to insert it among standard modes.

sblair June 23rd, 2009 09:55 AM

My concern would be in adding a mode to a defined message that isn't widely supported. Having a mode that explicitly ignores all commands to strike would often make the product appear broken. Hence, why I don't think there would be very wide support for it.

I'd be curious in understanding their needs with this a bit more. Obviously as you mentioned this could be handled with a manufacturer-specific message and that may be the best option.

-dalc- June 23rd, 2009 02:10 PM

Once i thought it wasn't a useful thing but then I spoke with a service technician and he told me about the control tests of a fixture coming back from a show.
The usual way is to plug the fixture to the controller and testing the fixture changing DMX values manually, without configuring the device in the controller. So it could be very easy to accidentaly strike the lamp and, If someone is working around the fixture, or fixture is opened, this action could be harmful for eyes.
A "LAMP FORCED OFF MODE" could be considered as a safety precaution.
I think it is unlike this mode makes the product appear broken, since it would be well signalled in the fixture display and/or in the controller display.

-dalc- June 23rd, 2009 02:18 PM

Once i thought it wasn't a useful thing but then I spoke with a service technician and he told me about the control tests of a fixture coming back from a show.
The usual way is to plug the fixture to the controller and testing the fixture changing DMX values manually, without configuring the device in the controller. So it could be very easy to accidentaly strike the lamp and, If someone is working around the fixture, or fixture is opened, this action could be harmful for eyes.
A "LAMP FORCED OFF MODE" could be considered as a safety precaution.
I think it is unlike this mode makes the product appear broken, since it would be well signalled in the fixture display and/or in the controller display.

sblair June 23rd, 2009 03:07 PM

If a fixture is left in this mode a controller (especially one without RDM fully integrated) would never be able to turn the lamp on. That would typically appear broken.

Most fixtures typically have a two step process for striking the lamps that involves more than wiggling just a single channel.

-dalc- June 24th, 2009 06:11 AM

As an engineer, I agree with you. But LJs and service technicians don't reason in the same manner (Also I've noticed that professional users have opposite ideas from low end users...).
I was explicitally requested to implement a single step process for striking the lamp, so I'll implement "LAMP FORCED OFF" mode as a "manufacturer specific mode".
Howewer I think It could be a good thing for controllers to set "lamp on mode" to "LAMP ON MODE ON" or "LAMP ON MODE OFF" before sending a set "lamp state" comand (so lamp handling returns totally under the control of the controller).

dangeross June 25th, 2009 04:57 PM

LAMP FORCED OFF
 
We've implemented a similar function but not for lamp control. One thing we did was make the command non-persistent so that a reset or power cycle would return our device to normal operation.


All times are GMT -6. The time now is 03:10 AM.

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