Backup lighting desks

[Tomo]

For all Primary/Backup systems, Ethernet is the way to get the data out of the desk.

 

If you do that, then all the major console systems (can be configured to) automatically flip over to the backup controller(s) - usually so fast the console op is the only one to notice!

 

Otherwise you need complex (and expensive!) multi-universe DMX changeover units which are likely to be less reliable than a network switch and DMX gateway.

 

Nope MA consoles automatically switch over to which ever console you specify when the "Main" console falls over for outputting network protocols instantaneously.

Only for the universes that particular piece of hardware was outputting. (Pet peeve of mine, sorry)

An MA/MA2 "console" above 4/8 universes is not inside the facepanel, it's spread over the facepanel and the NSPs/NPUs. Unless those also have backups, the "console" doesn't have a backup - merely a spare facepanel.

 

I've yet to see a single MA/MA2 install where there were any backup NSPs or NPUs at all, let alone a full set.

- I'm sure some people do, but it's vanishingly rare.

 

Partial backup can be a useful cost saving, as long as you know!

 

Personally I think it's worse to think you have a full backup when you only have a partial one, than not to have a backup at all.

[Tom Young]

Nope MA consoles automatically switch over to which ever console you specify when the "Main" console falls over for outputting network protocols instantaneously.

Only for the universes that particular piece of hardware was outputting. (Pet peeve of mine, sorry)

An MA/MA2 "console" above 4/8 universes is not inside the facepanel, it's spread over the facepanel and the NSPs/NPUs. Unless those also have backups, the "console" doesn't have a backup - merely a spare facepanel.

Hey Tomo,

 

Not sure I'm following you here or perhaps I'm misunderstanding you...

 

As you know MA consoles work on a "Parameter" level rather than a strict universe level. So whilst on an MA2 Light you have 4096 parameters, so 8 universes worth of dimmers, that doesn't necessarily mean that 8 universes will be processed by the desk and the rest by external hardware. As soon as you start plugging in NPU's and other consoles, the system starts sharing the workload around the network. There's no control over what goes where, it's all done by clever algorithms. It doesn't matter which universes are on what NPU's or anything. Obviously this was slightly different on MA1, whereby once you plugged in 3 NSP's they did all the processing and the console was just a face panel).

 

The main reason people have NPU's is to help share the workload and increase parameter count. Wherever possible, data should be taken from sACN/ArtNet etc. nodes. Obviously these will boot up faster than an NPU and are also technically less likely to fail and fall over.

 

So if you have a main console and a backup console connected together in the same session, then of course you have a full backup. The way the MA system works is that even if you lose NPU's etc. you still retain the parameter license for the life of the session. So as long as you're not taking data out of NPU's, you could have all NPU's fall over and everything would carry on working. Again when everything is in a session together, all consoles in the session share the same network protocol output settings, because they have to because they're working in the same session.

 

So I think it's incorrect to say that unless you have a backup of every single piece of hardware you only have a partial backup. Also for what it's worth, I've never been on a job where there hasn't been a spare of all the key components. Spare console, at least 1 spare NPU, spare switch at both ends for each type of network/network ring. So actually, it's really common to have backup NPU's and NSP's and if I will always spec at least one.

[Jivemaster]

It's essential to plan some form of backup, proportional to the value of the gig. BUT it's also important to recognise what may fail and in what order of probability. Western European mains may be good but not perfect, generator sets less so by a little. UPS's cover for short breaks but would a genset come online in time.

 

Then there is the problem that NASA once had with a shuttle launch aborted because three supposedly synchronous computers on board lost synchronisation.

[Barney]

On the other hand ...

 

I've been busking shows with a tracking backup lighting console before, when a certain manipulation of keys/faders/actions caused the software to crash and restart. As the actions on the master were being tracked and replicated by the slave, it also crashed :(

 

Luckily it was an 'unplug the DMX lines, get the console back into the same state, and re-plug the DMX lines' solution in this case, only missing a minor LX cue. Longest 20 seconds of my life waiting for the reboot, though!

 

In the case of a software glitch, which would presumably affect all tracking units, is there a way to have a backup solution for such eventuality?

[alistermorton]

The only way to avoid that particular scenario is diversity - don't use two identical setups and don't have them exactly mirroring.

[Judge]

Thats a weird one alright. I would have though that if there is a certain combination of actions/keystrokes etc that cause a crash then it would more likely be specific to that board and unlikely to propagate over to the backup. But it did, so who knows.

 

I crashed a Tiger Touch 2 a few times programming a show for Edinburgh Festival recently. As nobody else had experienced issues with it (it had been on site for a couple of weeks) I can only assume it was my actions/keystrokes. Some fast and furious editing but thats business as usual really. It was fine during the shows though which are less demanding I guess. This rig wasnt running dual desks though so I wasnt able to see it crash its backup too. Of course it might just have been a sticky button that didnt release properly or something, we never found out.

[the kid]

Thats a weird one alright. I would have though that if there is a certain combination of actions/keystrokes etc that cause a crash then it would more likely be specific to that board and unlikely to propagate over to the backup. But it did, so who knows.

 

I crashed a Tiger Touch 2 a few times programming a show for Edinburgh Festival recently. As nobody else had experienced issues with it (it had been on site for a couple of weeks) I can only assume it was my actions/keystrokes. Some fast and furious editing but thats business as usual really. It was fine during the shows though which are less demanding I guess. This rig wasnt running dual desks though so I wasnt able to see it crash its backup too. Of course it might just have been a sticky button that didnt release properly or something, we never found out.

 

 

We used to have that with a Congo, when you know what your doing you can go fast, but the desk got angry and crashed.

[Just Some Bloke]

I have a couple of friends who run the LX dept of a major touring musical (I better not say which as I haven't asked them for permission) who gave me a tour of their kit recently. They have a main lx desk FOH and a backup in the wings. I asked if they'd ever needed the backup and they explained that at the venue they were currently at they had needed to do so at the first performance. They had temporarily lost power to the FOH position shortly after the show started, so while the No1 op sorted that out, the No2 had run the cues from the wings. When power was restored they swapped back and the only people who knew what had happened was themselves and the DSM (different voice saying "standing by"!).

[johnhuson]

There is only so much you can do to mitigate problems thought, a touring LD friend of mine had both his main and backup MA2's and all the NPU's on the network all crash at the beginning of the first song a couple of weeks ago.

[richardash1981]

There is only so much you can do to mitigate problems thought, a touring LD friend of mine had both his main and backup MA2's and all the NPU's on the network all crash at the beginning of the first song a couple of weeks ago.

I think that emphasises the discussion about diversity a few posts back: identical backup systems in sync provides superb protection from hardware failure, but very little from software defects. To protect against software defects you need a different set of hardware and software, but this more or less precludes full sync and generally doubles setup (programming) as well as hardware costs.

 

At what point does it become a good idea for critical equipment to have it's own internal UPS using lithium batteries integrated into the power supply design? This would offer both a simpler design (no inverter to mains needed) and diversity of backup rather than relying on a small number of large UPS units.

[Judge]

I think that if you are paying north of £10k for a lighting board it is inexcusable NOT to have a proper built in UPS

[andy_s]

So on my current middle scale tour, theatres up to 1000 seats, I've seen a few ions used as backup to gio or eos. To be honest, I just thought ETC were running some sort of BOGOF deal...

And really, for me, ion is better, as one of my cues is 'wiggle the grand master' With ion, it's just there, ready.

[Caerdydd]

I've had some bad experiences with networking desks and the fault on the primary desk inducing on the second, not an Avo but another well known manufacturer...

A colleague of mine who works on some of ITV's largest prime time shows told me that he never networks the desks during a live show, but will have a second running and it's a quick swap out of an ethercon and being in the right cue.....

[alexforey]

With EOS, almost everyone I know has their smaller console as a primary, and their large one as a tracking backup (RPU as primary, Gio as backup; Ion as Primary, EOS Ti backup; Gio Primary, EOS Ti Backup), and they operate from the backup. That way, if the main console fails/crashes, the operator has to change literally nothing -- they just keep pressing the Go on the backup, which is an ideal solution.