• Date
    HarryC
  • Date
  • Replies 4 replies
  • Subscribers 186 subscribers
  • Views 4005 views
  • Users 0 members are here

Macro problems on RPU

 

Hi All,

Got a bit of a strange one; I'm currently running a show using an EOS linked with an RPU - the EOS is the backup whilst the RPU is the primary as recommended in the EOS manual.

Before each show I've got a couple of cuelists programmed that run a channel check; one cuelist fades all conventionals up to 30% then down again, then runs a macro to release the channels. A second cue list does the same with each attribute for the moving lights.

As the desk and RPU are way up the back in the control room I'm using the iRFR to run these cuelists - I use a simple macro to start each cuelists which is just a press on the appropriate fader.

This macro is simply "Go 1" for a cuelist loaded on the first playback fader, and "Go 2" for the 2nd cuelist. The show stays on the Main playback pair. All this triggering works fine.

At the end of each cuelist there's a macro that sends the cuelist back to cue 0 and sneaks all NPs back to their default positions, it looks like this:

Cue 11/*

Go_To_Cue 0*

Macro_Wait 5*

Sneak 5*

---------------------

This macro works as intended however I have had some intermittent issues with the macro not completing on the RPU. It will get stuck on "Macro 5 waiting 2 seconds" and cannot be stopped with the escape key. The first time this happened I didn't pick it up as the RPU screen was partly hidden behind the screens for the main console (lesson learned there!). Everything ran fine for the first hour (40 cues or so) then the RPU lost sync and the backup (being the EOS console itself) took over. The RPU was still fully responsive, it had not crashed. Both the console and the RPU are running 1.9.6. The macros are set to run in background mode. I am not able to repeat this problem when running the macro from the console, but when running from the iRFR I've had this happen 2 out of 4 times.

Just wondering if someone can point me in the right direction here as to what may be causing this, naturally I have cut the two release macros and will just manually sneak the cuelists etc but I'd still like to know the cause of this one :)

 

Many thanks!

Harrison.

  • Harrison, is it possible for you to email us the logs from the RPU, along with the date/time you see this issue?  Please send to eos@etcconnect.com

    Thanks much!

    a

     

  • in reply to Anne Valentino

    Hey Annie,

    Many thanks for your quick response!

    Logs sent; let me know if you need any more info.

    Just out of curiosity is there a better way I could achieve the desired result of running some channel-check cuelists remotely, with a release? Anyone got some techniques they could share?

    Thanks,

    Harrison.

  • in reply to HarryC

    HI all

    Why not try using execute to run the separate cue stacks? 

    We have the rig check residing at the end of the main cue list as a series of cues. A different cue for each element of the rig.

    Each cue executes a separate list, inside each list the cues are 'hung' together and runs until it get to the end. 

    We run the check cues from the remote on stage, as we are only playing inside one list there should be no issues with ownership of channels etc. Back it up with the preset containing all the right channels for the main list (even @ 0) and a end cue for all NIPS in at home etc. 

    Tip... We leave the intensity in the main list and the NIPS in the separate lists so if they are run by accident the lamps only move about and not display to the audience. (this lesson may have been learnt the hard way) 

    You can tuck the other cue lists away on a fader page out the way and not worry about operators accidentally hitting them. 

    See not a Macro harmed in the making of this sequence. 

    Hope this is of some help,

    Olly B

    Chichester Festival Theatre

  • I have somewhat a related issue with the iRFR. I have had on a few occasions tried to execute a macro that simply parks a few addresses that will not work. It looks like it starts, (by that I mean it turns on at least one of the addresses, then turns it off) but doesnt complete.

    Of course, I tried to replicate the issue to send in the logs for it, and now its working fine. 

    I'm on 1.9.8 build 57, but I know I've seen this problem before this.

Related

www.etcconnect.com