CEM3 inputs

Hello,

Each port can have it's own priority level, it would be worth checking what each inputs level is.

This can be discovered using NET3 Concert (http://www.etcconnect.com/Products/Networking/Net3-Concert/Features.aspx

All the inputs should have the same priority and be HTP, but for whatever reason, when the sACN port looses signal, the other inputs are ignored. Kind of wondering if the 'signal loss behavior' could be modified to not ignore the other inputs

Hello,

I just re-read your original post (helps when I read stuff) and I missed a vital detail.

Your RPU is Master and you turn this off first!

What is happening is your Ti is taking over at a higher priority (normally 101) this is then in turn overriding the paradigm.

Two simple options:

1) Turn the Backup (Ti) off first

2) Disable "Backup takes over at higher priority" on both consoles. (This is in Shell>Settings>Network)

I would recommend option 1.

Regards,

Marcus

marcus, just curious: why option 1 rather than 2? if there is a failure during show, option 1 would still mean that paradigm can't control. or am i missing something?

The feature is designed for a situation like this:

Master Console dies and is stuck in the wrong cue, but continues to output sACN.

The backup takes over at a higher priority and overrides the Masters output.

If the the backup didn't take over at a higher priority then the Master and Backup's output would merge HTP and cause a mess on stage!

A well designed [paradigm] system would allow for priority changes; be this in a button on a touch screen that promotes the paradigm to a over all higher priority, implementing per channel priority, keeping architecturally controlled dimmers on a separate universe, or some other method.

Regards,

Marcus

i get why the higher priority feature is there in the first place. so you suggest that there was a button in paradigm to make it go to (at least) priority 101. but that would still mean that e.g. stage blues that are controlled by paradigm (on a universe Eos uses as well) would go temporarily dark unless i patch and park them on the console as well, right?

I would always tend to put stage whites and blues on a different universe to production dimmers when ever possible and optionally remove this universe from the allowed output range of the console.

Maybe the solution to your situation above, would be to have a "Show" button on paradigm that increases the per channel priority of the blues. 

Since there is a gateway providing DMX in addition to the sACN signal directly, could I raise the priority of Ports A and B, to 101, leave the sACN input at 100, and still take advantage of the 'take over at higher priority' feature?

You could, but it may not behave as you hope. The presence of any data at all on a DMX port at higher priority means it owns the output. The console would never control the dimmer. Control would only fall back to sACN if the DMX signal is not present at all.

The best way round this problem is to route the sACN to the dimmer through the Paradigm Processor and into the DMX ports for the CEM3. You will need to get a Authorized Service Centre or someone from ETC to reprogram you paradigm processor to make this work but this should be the basics of how to set this up.

In Paradigm there is a option on the Channels patched via DMX to be HTP without Priority which would avoid the problems with the Priority jump in EOS.

Depending on what channels are in Paradigm and what are in EOS will depend on what you need to do but here is a example of how i have done it before.

HouseLights are Patched in both EOS and Paradigm. In Paradigm sACN Universe 1 is set as a input to the DMX output going to your CEM3. These channels are set to HTP without Priority.

In the CEM3 you set all your channels that are not controlled via Paradigm (E.g. Production Dimming) to 0 in the patch for the DMX B Input. and Set your DMX Input Priority to 200. Any channel that is set to 0 wont be controlled via the DMX input and therefor wont be forced to 0.

Leave the houselights patched to sACN1. This is because should your Paradigm processor fail and the DMX B goes away the sACN will take over.

If you have work lights in your dimmer racks that are controlled via paradigm but you dont want them to be controlled via the desk there is also settings for making paradigm not allow those DMX address through from the desk so it only uses its internal control.

If you discuss this with your local ASC or ETC Technical Services they should be able to advise further.