EOS Family Consoles and VL440 / 770 / 880 - Gobo stuck in or between frames

Hey All,

After much troubleshooting and testing, we have discovered an oddity with the interaction between the EOS family consoles and the VL 440 / 770 / 880 software.

The Problem:

This issue has to do with the mspeed parameters on these lighting fixtures.  The profile in the EOS family consoles defaults to 255 for all of the mspeed parameters.  This is what the manual specifies for these fixtures.  However, in certain situations, this value causes the gobos or other parameters to get stuck either with a gobo in or between gobos and will not move out of that position until the value is changed in a bump (0 seconds).  So in a show setting if you fade the gobo in, and then fade it back out.  In certain situations, the gobo will either stick in and not go back out with the fade.  Or the gobo will go half way in, and then will get stuck there.

This bug is reproducible. And while it can be fixed from the console, it appears to actually be a bug with the VL software.

From the VL manual (http://asoft11230.accrisoft.com/varilite/clientuploads/directory/downloads/SVL_User_RevC.pdf): 

Timing Channel Notes:

  • It is recommended that all timing channels are channels are defaulted to a DMX value of 255 (100%).  Applying this value will initiate a smoothing algorithm while using a console fade time.
  • To achieve best (smoothest) timing possible, utilize the luminare timing channels.  A luminare timing of DMX 0 (0%) will give the fastest response to the affected attribute. For example, this may be desired in fast color and/or gobo changes.
  • A timing value of zero is full speed. A time value of 100% (or 255 in DMX) causes the associated parameter(s) to follow cue fade time (console time) rather than the timing channel.

So, as best as I can tell, it is possible to ...confuse that smoothing algorithm.

We have a VL certified tech on staff, and he is reporting this bug back up to Vari-Lite.  However, ETC tech support asked that I post here as well to help any others that are having this same error.

First I want to say that this will not be an issue for everyone.  I've used this console (GIO) with these lights (VL440) before and never had this issue.  However, something about how this particular show was cued caused this issue to pop up.  It was not cued 'incorrectly', just in a way that confused the lights.

The Workaround:

  • Go into the profile library
  • Make a copy of the default fixture profile for the fixtures that are having the problem
  • In your new fixture profile that you just created, change the home position of the mspeed parameters from "255" to "0".
  • Apply this new custom fixture profile to the lights of that type in your rig.
  • Go back through your cue stack and on each cue with hard values or blocks, and home all of the mspeed values, and then update those cues.  If there are many cues, a macro may prove useful.

tadaa!!!!

 

I hope this helps others in the future.



[edited by: Casey at 11:01 AM (GMT -6) on Wed, Nov 13 2013]
Parents
  • I've been noticing this with my VL770's.  Haven't had the time or enough of an issue to trace it down.  Thanks for posting this.

     

    Does 0 "full speed" still take the console timing? Or is it a 0 count-esque look? Wondering for live moves if this is still an option, or if I need to live with the potential for it to get stuck in.

Reply
  • I've been noticing this with my VL770's.  Haven't had the time or enough of an issue to trace it down.  Thanks for posting this.

     

    Does 0 "full speed" still take the console timing? Or is it a 0 count-esque look? Wondering for live moves if this is still an option, or if I need to live with the potential for it to get stuck in.

Children
  • hydrogen said:

    Does 0 "full speed" still take the console timing? Or is it a 0 count-esque look? Wondering for live moves if this is still an option, or if I need to live with the potential for it to get stuck in.

    The way I read it, the VL manual is very confusing.  Because the lights will go wherever the DMX tells them to.  So regardless of if the mspeed value is 0 or 255, it is still 'following the cue timing' the light won't know the final location it is moving to until the board completes the fade.  The light won't know the final location it is moving to until the board completes the fade.    If you fade from point A to point B, the DMX values fade, and the light will follow accordingly.  You will get some stepping, because those parameters are 8 bit, so you may see the individual steps (from 123 to 124 to 125, since each 'step' is 1.5° of rotation on the wheels).

     

    As far as live moves go, it will follow the fade of the board with mspeeds at 0, but you may see steps in the fade, or do it at 255 and you may have issues with things getting stuck.  As with anything in lighting, your mileage may vary.  I'd recommend trying it both ways and seeing which way works best for your programming / design style.



    [edited by: Casey at 10:04 AM (GMT -6) on Thu, Nov 14 2013]
Related