HogIII performance... shaking Movinglights.

Hello everyone

I just started a tour with 20 Elp60 Led-sticks, five MAC 700 and a few conventionals. That gives me about 1400 DMX channels...since I'm running the LED-sticks in 60channel mode. (Yes I want and I need it that way!).
And there is the problem: first I had everything on one DP, first universe 480xLED, sec. univ. 480xLED, 3rd univ. 240xLED plus ML and conv..... well when I swopped all LED, for example from red to blue, it took the console about a half a second to react, plus on fast programming the console crashed! Nework problems! To slow for rock n'roll!... well ok. I changed from one DP to two DP's, moved one of the LED universes to DP two and I changed the Software from build 1014 to 1053. That helped already a lot, the performance improved.
So far so good, but then: when I ran an effect on the LED's and I did a slow move on the ML they start to shake and do no more nice moves they shake from on position to the next... impossible to accept.
So I changed the universes again, now I run 960chans LED on DP one and the rest on DP two 240LED, plus ML etc. Well the ML are better now, not good but I can live with it, but I'm having the old delay on the LED's again and I have a delay between the two DP's!
Maybe this is all normal, but what can we do about it?

Anyone an Idea?

greetz

Michael
Parents
  • Todd,

    It isn't really important for you to balance fixtures between outputs on a single DP2000. The important factor is how many concurrent crossfades are running on a single DP2000 and balancing the number of crossfades between multiple DP2000s. Most people use a combination of dimmers, automated luminaires, LEDs, and media servers. In these situations, they generally aren't crossfading every parameter of every fixture at the same time and they don't have any problems with workload on their DP2000s.

    The current trend of large rigs with many universes of LED fixtures forces us as programmers and system designers to be more careful with how we patch our rigs. There are two main reasons for this:

    1) LED fixtures have a very small channel count and can be densely packed into universes and all of their channels are usually being crossfaded. Is it very common to run colour effects on large rigs of LED fixtures. It's possible to get into a situation where you have as many as 2048 crossfades running at once and this takes a lot of processing power.

    2) The Wholehog 3 network architecture distributes crossfades. Each DP2000 processes the crossfades and conversion from real-world values to DMX values. This is a *large* advantage of our system, because it means that when you add 4 universes of DMX by adding a DP2000, you're adding the processing power to handle those universes of DMX. Processing DMX and crossfades is a processor-intensive and time-critical job. By distributing these tasks, we offer better performance and response at the console and a far more scalable system. The important thing to think about as a user is that you are no longer working with a system where all DMX is generated on a single PC board with a single clock. There are now independent devices that each generate DMX for a portion of a lighting rig. These nodes communicate with each other in a number of ways to maintain synchronization, but if one DP2000 has a very heavy processing load and another has a very light load, you probably aren't getting the best performance available from your system and you may see the effects of this.

    In summary, balancing the load between outputs on a single DP2000 isn't going to make much of a difference, because all of the crossfades are still being handled by the same processor. Balancing the loads (of simultaneously running crossfades) between DP2000s may make a big difference, but it will depend on your individual rig.

    I hope this helps.
Reply
  • Todd,

    It isn't really important for you to balance fixtures between outputs on a single DP2000. The important factor is how many concurrent crossfades are running on a single DP2000 and balancing the number of crossfades between multiple DP2000s. Most people use a combination of dimmers, automated luminaires, LEDs, and media servers. In these situations, they generally aren't crossfading every parameter of every fixture at the same time and they don't have any problems with workload on their DP2000s.

    The current trend of large rigs with many universes of LED fixtures forces us as programmers and system designers to be more careful with how we patch our rigs. There are two main reasons for this:

    1) LED fixtures have a very small channel count and can be densely packed into universes and all of their channels are usually being crossfaded. Is it very common to run colour effects on large rigs of LED fixtures. It's possible to get into a situation where you have as many as 2048 crossfades running at once and this takes a lot of processing power.

    2) The Wholehog 3 network architecture distributes crossfades. Each DP2000 processes the crossfades and conversion from real-world values to DMX values. This is a *large* advantage of our system, because it means that when you add 4 universes of DMX by adding a DP2000, you're adding the processing power to handle those universes of DMX. Processing DMX and crossfades is a processor-intensive and time-critical job. By distributing these tasks, we offer better performance and response at the console and a far more scalable system. The important thing to think about as a user is that you are no longer working with a system where all DMX is generated on a single PC board with a single clock. There are now independent devices that each generate DMX for a portion of a lighting rig. These nodes communicate with each other in a number of ways to maintain synchronization, but if one DP2000 has a very heavy processing load and another has a very light load, you probably aren't getting the best performance available from your system and you may see the effects of this.

    In summary, balancing the load between outputs on a single DP2000 isn't going to make much of a difference, because all of the crossfades are still being handled by the same processor. Balancing the loads (of simultaneously running crossfades) between DP2000s may make a big difference, but it will depend on your individual rig.

    I hope this helps.
Children
No Data
Related