Unison stopped taking priority over Ion

In the settings page in the shell (when you exit out of the Ion application) there are parameters to set the priority of your console.

You can also configure the priority of a port on your nodes in the same place you configure it to be DMX In or Out.  I suspect either your Ion or your node is taking priority from the Unison system.

Hope that helps,

~P

Thanks for the help.  I was hoping to change the priority of the Unison, though.  I want to keep everything else the same and just make Unison a higher priority than everything else.  Is there a way to change the priority of Unison?

Thanks.

You'll probably need to get your local ETC Authorised Tech in if you want to make any changes to your Unison system, changing priorities can have unwanted consequences depending on how the system was programmed.

If you were happy with how the system was working before it sounds like we just need to work out what got changed and put it back.

The first place I would look as Paul suggests is in the Network section of the Ion shell. Chances are that the priorities have been changed by accident here, it's easy to do if you click in the field by accident and move the mouse wheel. Your ACN priority probably wants to be at it's default which is 100, and your Net2 priority default is 10.

Do you want to have control of the houselights from the board at all? If you were to give Unison a higher priority you would probably end up stomping on the Ion anyway, so if that's what you really want to do you are probably better off just un-patching the Houselights from the Ion completely.

Is your Unison a Paradigm system or a Unison Legacy system out of interest?

Graham

I finally got a chance to look at this some more and confirmed that the priority on the console never changed.  The Net2 and the ACN are both at their defaults.

When the house lights are not patched into the board, the Unison controls them with no problem.  As soon as the house lights are patched into the board and the board is on, the Unison has no control of the house lights.  I changed the board to a much lower priority.  When I did, the Unison worked, but the board would not control the house lights, and I also lost control of our sensor racks.  We also have a couple of touring Sensor racks that get data from a gateway.  I could still control the touring racks, even at the lower priority.  I reset the console's priority back to the defaults, and everything worked fine, except that the board still took priority over the Unison.

It's a legacy Unison system.

If anybody has any other thoughts on why this would be happening I would appreciate it.  

Thanks.

Michael

Michael,

In addition to each source type (Net2, sACN...) having it's own priority, the Sensor rack can also set priority for which protocol has priority over another for the incoming data. Each port can have its own priority so there are 4 possible winners, Net2, sACN, DMX A and DMX B. It sounds like you might have an issue with the priorities going into the Sensor rack itself, these are set at the Sensor rack. You could check there to be sure that they are all being treated as equals.

Since you have a Legacy Unison it is outputting either Net2 or DMX to the Sensor rack. With both Net2 and sACN enabled form the Ion it is sending levels to the Sensor rack using both protocols. If the Sensor rack is treating sACN as a Higher Priority then the lights would only be controlled from the Ion when it is on, with the channels patched and the Unison system would have no control. I'd guess your Net3 nodes are in Net3 mode, so they are probably sending sACN to the Sensor racks as well. Since you had an outside company come in and send DMX into a Gateway, then onto the rack, it is entirely possible they set the rack to have sACN as the highest priority source to make sure your Unison system didn't have control when their Console was connected.

I don't recall the exact method of checking the priority structure in the Sensor Rack, but t is in the Manual, and viewable form the web interface. A quick phone call to Phone Support would also get you the exact information you need to double check this. A quick check would be to disable sACN form you console and see if the issue is resolved. If it is, than you indeed have a priority conflict at the Sensor rack.

Michael,

In addition to each source type (Net2, sACN...) having it's own priority, the Sensor rack can also set priority for which protocol has priority over another for the incoming data. Each port can have its own priority so there are 4 possible winners, Net2, sACN, DMX A and DMX B. It sounds like you might have an issue with the priorities going into the Sensor rack itself, these are set at the Sensor rack. You could check there to be sure that they are all being treated as equals.

Since you have a Legacy Unison it is outputting either Net2 or DMX to the Sensor rack. With both Net2 and sACN enabled form the Ion it is sending levels to the Sensor rack using both protocols. If the Sensor rack is treating sACN as a Higher Priority then the lights would only be controlled from the Ion when it is on, with the channels patched and the Unison system would have no control. I'd guess your Net3 nodes are in Net3 mode, so they are probably sending sACN to the Sensor racks as well. Since you had an outside company come in and send DMX into a Gateway, then onto the rack, it is entirely possible they set the rack to have sACN as the highest priority source to make sure your Unison system didn't have control when their Console was connected.

I don't recall the exact method of checking the priority structure in the Sensor Rack, but t is in the Manual, and viewable form the web interface. A quick phone call to Phone Support would also get you the exact information you need to double check this. A quick check would be to disable sACN form you console and see if the issue is resolved. If it is, than you indeed have a priority conflict at the Sensor rack.