• State Not Answered
  • Date
    rautasami
  • Date
  • Replies 18 replies
  • Subscribers 5 subscribers
  • Views 991 views
  • Users 0 members are here

FX problem after updating a cue

I have an pan FX with low speed and small size (like 2bpm, 3 degrees)
After updating something (like a desk channel intensity) to the cue the effect does not run smoothly anymore.

The cue I'm updating has the FX as tracked information.
If I run the cue what is the source of FX and then the cues with tracked information, it runs smoothly again.
Also if I suck the FX to the programmer from the cue, it runs smoothly.

I haven't tried what happens if the FX is recorded as hard values.

But it seems the console has problems asserting the cue with tracked FX after updating.
  • 0
    Sami

    What version are you running 3.2.0 or 3.2.1?
    Is this only when running an FX as slow speeds and small sizes?
    I have been unable to recreate this in the lab so any extra info you can give would be helpful in finding what you as seeing.
  • 0
    I'm running 3.2.1
    That jumpy FX seems to happen also when recorded just the normal way.
    I have Sin in P and T speed 3 size 3 in 4 VL3500 spots.
    Offset 25, 225, 104, 306
    The FX runs smooth from programmer, but gets jumpy when played from cue.
    The strange FX behaviour can be seen also in output window.
    Maybe I should send you the showfile.
  • 0
    dl.dropbox.com/u/18000606/Anna%20Liisa170811_bck.hog3.shw
  • 0
    Sami

    I got the show file, I will look into this and report back what I find.
  • 0
    Sami,

    If you turn off art-net for all the universes does the problem go away? That's just a quick way to help us deduce if this is an engine problem or a desk problem.
  • 0
    Hmm...
    Everything here is run through Art-net... So, I think it kind of goes away :)
    But seriously... The jumpy FX can be seen in Output window. For example in cue 34, when update something there. If I suck those VLs to the Programmer the problem goes away. But I continue troubleshooting this...
  • 0
    We're not really seeing anything problematic in the output window. My point on disabling the art-net is that if you can see the jumpiness in the output window I was curious if the jumpiness went away after disabling art-net.
  • 0
    I will try that tomorrow if I have enough time.
    I think I'll take a short video also about what is going on in the output window.
    I will also check the DMX window.
  • 0
    db.tt/VCkP2qx

    A short video of what is happening in Output window.
  • 0
    I kind of found the reason for this problem. I powered off the DP number 3 and everything seems to run fine. Could this be a somekind of sync issue when DPs are outputting the same?
  • 0
    [QUOTE=srautane;56615]I kind of found the reason for this problem. I powered off the DP number 3 and everything seems to run fine. Could this be a somekind of sync issue when DPs are outputting the same?

    Do you have two DPs outputting the same ArtNet data on the same system?

    This could certainly bring down a system in a hurry since your ArtNet recievers wouldn't know which source to pay attention to first.

    If you need ArtNet redundacy @ the DP level you need a network A/B switch.

    Hope this helps. :)
  • 0
    Do you have two DPs outputting the same ArtNet data on the same system?

    Yes, I have. Art-Net can have multiple servers.
    My DPs have different Fixture link (Art-Net server) IP addresses.
    My nodes are set so that one of the DPs is the primary source and when it fails the nodes start to listen the other one.
    In Luminex nodes it's called IP backup mode.


    This could certainly bring down a system in a hurry since your ArtNet recievers wouldn't know which source to pay attention to first.

    That could be the case if my DPs have the same fixture link address. But, they don't.

    How do you explain that the jumpy FX can be seen in output window and goes away when data is sucked to programmer? (Check the video)
  • 0
    Hi Sami,

    Yes, the mix of two DP8000s with the same patch data explains the jumpiness in the output window as the output window is feedback driven and the timing between the two DP8000s will always have a little bit of drift in the feedback they provide back to the console.

    However, the two DPs should not be causing problems onstage in terms of DMX output. Of course, since you working with Art-Net that changes things a bit since you do have two streaming sources going at once.

    I unfortunately don't have any experience with or access to a Luminex switch. Are you using the Ethernet-DMX8 MkII?
  • 0
    an easy way to rule out the artnet side is to keep both dp's running(thats when you see the problem) and disconnect the artnet output from one of the dp's.
    -In this setup both dp's will be online on the hognetwork, and if they are causing this problem themselves, you would still see the problem on the output from one dp(or the other if you change to the other).




    -If the problem disapears, you have a problem on the artnet side. -If so, my guess is that your Luminex node gets confused in some way, and tries to swap source back and forth between the two dp's.
    (I don't know how the DP ensures "sync". and if they are not 100% in sync a artnet node that is setup to do LTP merging in some way can then be confused. i guess that it might be possible that we can see a little drift between two dp's?! -Why the problem goes away when you stomp, or suck. i dont know, and can only speculate, but it can be that the dp keeps better sync when sucked or stomped as opposed to when the dp gets info about that it needs to calculate the changes in efx when you edit it..based on priority or something. )

    However I don't know if this is true, and in any case this will probably be a more theoretical problem than something that you will see in real life since the sync is hopefully better than this, but I guess that in some cases depending on the speed and size on the changes on each value in the dmx packet you could see something like this.
    And also the way the luminex node has merging implemented in software can make this "worse".. In some way they need to deside how to switch between sources.. if one source stops.. how long should you wait before you change to Backup source? one packet?(approx 40 ms if streamed at 25HZ) one second? 10 seconds?..
    -If one packet.. what happens if you loose a packet due to network traffic? that will make the box switch over, and i guess the switch can look like a "jump" if dmx values are right(or wrong)
    -Anyways, there are tons of reasons this could get wrong, but if implemented in a wise way, this should work. And my impression is that Luminex makes reaaaly good products!
Related

www.etcconnect.com