• Date
    Casey
  • Date
  • Replies 7 replies
  • Subscribers 186 subscribers
  • Views 5234 views
  • Users 0 members are here

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

  • Thanks for the report!

    As a rule, with any console and any V*L, I only default the  P/T Timing channel to 255.  Color, Beam, and Gobo I default to 0.  I usually want to get between colors and gobos as fast as possible, and pan & tilt are where you really see the benefits of the smoothing.

    If I want anything other than the fastest possible response, I can always set the timing to something else.  It also means I don't have to remember to set Color Timing to 0 before running a color wheel effect.

    -Jason

  • in reply to Jason1032

    Jason1032 said:

    As a rule, with any console and any V*L, I only default the  P/T Timing channel to 255.  Color, Beam, and Gobo I default to 0.  I usually want to get between colors and gobos as fast as possible, and pan & tilt are where you really see the benefits of the smoothing.

    This makes sense to me.   However, for my style, the 16 bit pan and tilt is more than adequate for smoothing.  I haven't ever seen stepping nor been unable to get the light where I wanted it due to the 65,000 steps (roughly one step per .01° of movement, or .2 inches over a throw distance of 100') that the 16 bit nature of the pan and tilt parameters.

     

    Essentially what I'm saying is, for my style, I never need mspeed values.  As long as the board will always do exact what the console tells it to, I'm golden.  So I'd rather have it default to all of the mspeeds to 0, and then let me raise them above that if needed.

    I'm not asking for a change of the profile.  The VL manual clearly states that home should be 255.  I'm just saying that the way I work I will be changing those values to 0 before I get started.

  • in reply to Casey

    Casey,

    Would you be willing to send my your show file where this issue was seen?  We've had other reports of issues with VLs that I would like to into this from the console side a further.  I just want to be sure there isn't something hidden that the console it doing wrong.  If you can, please put attention Steven Peterson and email to eos (at) etcconnect (dot) com.

    Thanks,
    Steven

     

Reply
  • in reply to Casey

    Casey,

    Would you be willing to send my your show file where this issue was seen?  We've had other reports of issues with VLs that I would like to into this from the console side a further.  I just want to be sure there isn't something hidden that the console it doing wrong.  If you can, please put attention Steven Peterson and email to eos (at) etcconnect (dot) com.

    Thanks,
    Steven

     

Children
  • in reply to speterson

    speterson said:

    Casey,

    Would you be willing to send my your show file where this issue was seen?  We've had other reports of issues with VLs that I would like to into this from the console side a further.  I just want to be sure there isn't something hidden that the console it doing wrong.  If you can, please put attention Steven Peterson and email to eos (at) etcconnect (dot) com.

    Thanks,
    Steven

     

     

    Sure, I'll send over the show file and the logs that I dumped after I reproduced the issue but before I started troubleshooting.

     

    And for what its worth, I took a dmxter with me to the job site and looked at raw dmx values coming out of the console and they corresponded to what I was expecting to see, so I don't expect it was a console problem.  But who knows.....

     

Related

www.etcconnect.com