Colorsource Consoles & Colorsource Relays DO NOT Tristate DMX when "OFF"

It seems that as long as they receive power, Colorsource Consoles & Colorsource Relays DO NOT Tristate DMX when turned "OFF".  This means when they are off (standby or relay-off), but connected to power (powercon or DC from PSU), NOTHING ELSE CAN DRIVE THE DMX LINE (such as preset stations or...anything)!

 

Can this maybe be fixed....in firmware? 

 

Thank you.

Bruce

  • What's the scenario where you have multiple DMX sources on the same physical DMX line? This would generally be considered bad practice without the use of a merger or something equivalent (such as a Gateway configured to act as a merger).
  • It seems that there are some arch preset stations( by "others" ) that keep thinking they are receiving DMX (because the line is still being controlled) and they will not take control until they think DMX is gone...so they will not work. I've thought about having the Colorsource Relay also switch asmall relay breaking the DMX line...
  • The RDM standard requires controllers and proxies (like the CS Wireless Relay) to "bias" the DMX line to the "mark" state - this is necessary to prevent flicker when waiting for RDM replies (eg the "Is anybody there?" request).

    Therefore, you will always see approx. 3-5VDC between the data wires whenever an RDM controller is physically connected and powered - it's a physical electrical connection!

  • OK, I refreshed myself on RDM. The default mark makes sense......when the controller or relay are actually TURNED ON!

    I have not tried this, but will Legacy Unison see the ColorSource as No DMX when it is powered off...but plugged it? If I have an "Input Aquire" or "Input Loss" Macro (Ctl-F12) will it behave...or will I have to unplug the board?

    Bruce
  • No DMX or RDM data is sent when ColorSource Console is "Hibernating" (screen gone black, Stage button blue)

    All fully-compliant DMX receiving devices will perform their configured DMX-loss action.

  • But the DMX line is sitting at "Mark" when the board is "Hibernating" There should be NO difference between a "Hibernating" and a unplugged/no power controller.
  • The console is "Hibernating". It's still powered.
    The message says "... or remove power cable to power down completely."

    It is however irrelevant, because (as previously mentioned), the DMX and RDM standards are only defined for a single DMX/RDM controller connected at one end of the physical cable run.

    Connecting multiple controllers to the same DMX cable at the same time does not comply with DMX or RDM.
    - In most cases it will also breach the underlying EIA/TIA 485 electrical standard as it will be terminated at both ends and somewhere along the wire as well.

    As it is outside the standards, such a physical topology is unsupportable and may result in unwanted behaviour.

    If you need multiple DMX controllers for the same fixtures, then you need an appropriate DMX merger or switchover unit.

    There are many ETC (and third party) products that perform DMX merge and/or switchover functions.
    For example, all ETC Architectural controllers can combine their DMX input into their DMX output, and Net3 DMX Gateways can be used as standalone mergers/switchers.

    Your local ETC dealer or ETC technical support/project manager will be happy to put together some appropriate designs for the functionality you desire.

  • Since we're probably talking about Fleenor products...

    You may want to consider using the Preset 10 A2 instead of the original Preset 10. The original Preset 10 has a single DMX connection for input and output, so it has the potential for the problems you're seeing in RDM systems. The Preset 10 A2 has separate input and output connections with an internal merge. I don't think it will allow RDM data to pass properly, but it should still be capable of playing presets while the console is connected and hibernating.

    I'm not sure how it detects data loss, so it may need to be in "Combine" mode to work correctly.
  • Hello Bruce,

    I am very interested if you found a solution to this problem. I have a Colorsource 20 and a Leprecon APC wall panel system that will not function properly due to the Colorsource 20 not fully "powering down" and allowing the APC unit to take control of the DMX. I spoke with support and they did not have any solutions other than "put a power strip inline to power off the console" which would be unacceptable for the installations we do. Two thoughts, is there be some type of relay that would disconnect its DMX output connector when it detects loss of DMX data. or ETC is there a software patch that would allow the console to shut down rather than hibernate?

    I know this is a year old thread but looks like there isn't a solve yet.

    Thanks,

    Ben
  • Your receiving device does not fully comply with the DMX standard.
    It is expected that devices that do not comply with the standard will misbehave under some circumstances.

    The solution is for the receiving device (in your case the Leprecon APC) to properly detect DMX data loss as defined in the DMX/RDM standards.

    I would recommend that you ask Leprecon to correct their bug and detect DMX data loss as defined in the standard.

    They may well have already done so, especially as RDM-capable controllers are becoming common and so many of their users will be running into their data-loss detect bug.

  • The standard talks about a transmitter being idle and how to behave....but I do not believe it talks about how a device should behave when turned off. I think a device in its "OFF" state should behave like it is unplugged. I guess this gets tricky when "OFF" is really "Standby".

    RDM or not, a lot of legacy DMX products use a high line as an active line detect (after all, it makes the blinkey LED light up). It would be a very useful option to be able to put the receivers in "OFF" v/s "Idle" mode when off.
  • What was done in the end was to install a push-button switch to switch between local (Leprecon) vs wireless (it just floated the DMX In line to the Leprecon). In this case it wasnt really a big deal because the wireless was never used without accessing the rack where the switch was located first. Not as elegant as I would like...but everyone (else but me) was happy in the end.
Related