Moving Head Pan Fine changing on fade out

[kenact]

Windows 10 x64 QLC+ 4.12.7 GIT

I recently added 3 Tomshine Mini Gobo Moving Heads to my plot. There seems to be an issue with the Fine Pan and Fine Tilt. By default Intensity is set to HTP and all the other channels are set to LTP. I'm seeing something weird.

I created 2 scenes and set the Mini Gobo to
Pan 17
Fine Pan 141
Tilt 50
Fine Tilt 141
Intensity 255
Color Wheel 24
All other channels are 0

I add the scenes to a chase, with a 1 second fade in and fade out and a hold of 1 second.

When I run the chase, the head moves as if the Fine Pan and Fine Tilt went to 0.

If I change the Fine Pan and Fine Tilt to 0, the head doesn't move when stepping through the chase.
No other channels seem to be affected, for instance Color Wheel at 24 is blue, and 23 is green, but the color isn't changing. I haven't tried change the Fine settings to HTP, because it doesn't make sense to me that those 2 channels would be the only ones affected by this.

[GGGss]

Did you check with the DMX monitor?
It is generally accepted that all channels are LTP with movers except for the intensity.
What do you want to achieve with the fade times? Going from one position to another slowly?
In my workflows, I always separate positions, intensity and other gimmicks using movers. I never put them inside the same scene unless it's a 'reset' sequence.

Regarding your color change: check with the DMX monitor what you are outputting. This might shed light on what is going on.

[MichelSliepenbeek]

I add the scenes to a chase, with a 1 second fade in and fade out and a hold of 1 second.

What happens if you change the run time to 5 seconds (or set Fade In and Fade Out to 0)?

When I run the chase, the head moves as if the Fine Pan and Fine Tilt went to 0.

This makes sense: if you tell your chaser to Fade In, it will start with zero.
On the Fixtures Tab go to the Channel Fade Configuration (where you also set LTP/HTP) and make sure that Can Fade is unboxed for your Pan and Tilt channels.
(And do the same for your color wheel, mode channels and ...... Only Intensity should remain "boxed" in this situation).

If you want to avoid sudden moves of your moving heads use the Pan Tilt Speed Channel (channel 5 on your Fixture) for that.

Another reason could be that you also have a XY pad active, which is causing conflicts.

[kenact]

Did you check with the DMX monitor?

Not yet.

What do you want to achieve with the fade times? Going from one position to another slowly?

I'm using the fade to change the intensity of 2 lekos at a time, creating a sort of candle effect. which is working just fine, but I want the moving head to remain constant while this is going on. I can't use a fade to change color smoothly on these. They have a color wheel, not RGB LEDs, Maybe I'll have more money next time.

[kenact]

What happens if you change the run time to 5 seconds (or set Fade In and Fade Out to 0)?

The heads don't move, but I don't achieve the effect I'm going for.

if you tell your chaser to Fade In, it will start with zero.

None of the other moving head faders act that, and my lekos don''t either. If I have a leko at 128 in the first scene, and 128 in the second, that light doesn't change. If I have a leko at 32 in the first scene and fade it up to 64, it doesn't go down first.

If you want to avoid sudden moves of your moving heads use the Pan Tilt Speed Channel (channel 5 on your Fixture) for that.

Another reason could be that you also have a XY pad active, which is causing conflicts.

I'm not concerned about the speed of the movement. I'm in a theatrical situation, and I don't usually move my heads while there lit.

I've never used an XY Pad.

[kenact]

I finally got a chance to view the DMX monitor. This is very strange. I have set up 1 scene

Pan - 62
Pan Fine - 63
Tilt - 65
Tilt Fine - 59
Speed - 0
Intensity - 255
All others - 0

I set up a 2nd scene

Pan - 62
Pan Fine - 99
Tilt - 65
Tilt Fine - 105
Speed - 0
Intensity - 255
All others - 0


I set up a chase with 3 steps, Step 1

Scene 1
Fade In - 10s
Hold - Infinity
Fade Out - 0

Step 2

Scene 1
Fade In - 10s
Hold - Infinity
Fade Out - 0

Step 3

Scene 2
Fade in - 3s
Hold - Infinity
Fade Out - 0

When I start the Chase Pan Fine and Tilt Fine scroll from 0 - 255 repeatedly until the fade in ends after 10 seconds

Going to Step 2, Pan Fine and Tilt Fine go to 0 until the fade in completes.

Going to Step 3, Pan Fine and Tilt Fine scroll from 0 - 255 repeatedly until the fade in ends.

I determined that Fade Out has no effect on this problem.

No other values change. I've included a workspace that shows the problem. Just use the DMX monitor while stepping through the Chase.

[kenact]

I just tried the Chauvet MiN Spot RGBW and it responds the same way. All faders act as expected, except for Pan Fine and Tilt Fine.

[GGGss]

Now wait a minute ... there was a time where fine channels were not treated right and then Massimo decided to mimic their behaviour. He did copy the course value to the fine one. (Or was this only for intensity channels?)
Anyway, fine channels and the logic behind is off - The QLC+ engine needs a 16 bit counter mechanism...

[kenact]

Maybe I'm missing something. I can understand the creation of fixtures, to group all the functions of a single fixture into one group, and to easily identify what each channel does, but these are still all just DMX channels. Aside from being able to set LTP & HTP, shouldn't all the channels work the same?

[MichelSliepenbeek]

No of course not.

Once you know that two channels are defined as Pan and Tilt, QLC can make use of that by creating specific EFX functions and an XY Pad widget that make use of that.
Once you know that three channels are defined as Red, Green and Blue, QLC can make use of that by creating a Color Selector (RGB Click & Go).
Once you know that a channel is defined as Color Wheel or Gobo Wheel, QLC can make use of that by creating a pop up window to select the Color/Gobo.
Once .......

The problem with Pan Fine and Tilt Fine is that they add precision to static positions, but while a moving head is still traveling to its intended position those Fine Channels have no meaning.
If you want a moving Head to travel from Pan (coarse) = 40 to Pan (coarse) = 60 and you use a algorithm that just produces all possible Pan Coarse values that are on the way (with your engine running at 50 ms) it will take 1 second to (produce the DMX information to) make the move (considering your Moving Heads are fast enough to follow).
If you use the same algorithm in 16 bit mode, it will take 255 seconds (which is unacceptable).

So in this case it is important to find a compromise between Fast (but smooth) travelling and precise positioning.


What triggers me in the given example is that the Pan (course) has the same value in both scenes.
Does the problem also occur when you go from Pan (coarse) = 61 and pan Fine = 250 to Pan (coarse) = 62 and pan Fine = 31?

(I still have to make the upgrade to 4.12.7, so i cannot test it myself).

[kenact]

The problem with Pan Fine and Tilt Fine is that they add precision to static positions, but while a moving head is still traveling to its intended position those Fine Channels have no meaning.
If you want a moving Head to travel from Pan (coarse) = 40 to Pan (coarse) = 60 and you use a algorithm that just produces all possible Pan Coarse values that are on the way (with your engine running at 50 ms) it will take 1 second to (produce the DMX information to) make the move (considering your Moving Heads are fast enough to follow).
If you use the same algorithm in 16 bit mode, it will take 255 seconds (which is unacceptable).

So in this case it is important to find a compromise between Fast (but smooth) travelling and precise positioning.

I'm failing to see the logic here. If I set this fixture to DMX channel 1, and connect it to a 12 channel 2 scene preset, I can set scene 1 to Pan = 40, Pan Fine = 50, Tilt = 45 and Tilt Fine = 55. I can set scene 2 to Pan = 70, Pan Fine = 30, Tilt = 75 and Tilt Fine = 40. I can crossfade between scene 1 & 2 and it's up to the fixture to position itself based on the DMX data sent to it. The 2 scene preset board has no idea what functions it's sending data to. It only knows the DMX channel.

What I have experienced is jerky movements when I have a value in Pan Fine or Tilt Fine, and I'm changing the Pan and/or Tilt during a fade in process, but smooth movements when both are zero.

What triggers me in the given example is that the Pan (course) has the same value in both scenes.
Does the problem also occur when you go from Pan (coarse) = 61 and pan Fine = 250 to Pan (coarse) = 62 and pan Fine = 31?

As I said, in a case like that, the Pan Fine scrolls through 0-255, multiple times, until the fade in completes.

[kenact]

I have finally figured out the logic for Pan and Pan Fine. They have to work in coordination with each other. The existing channel definitions are not currently working properly.

To achieve completely smooth operation, going from Pan 1/Pan Fine 2 to Pan 4/Pan Fine 4, Pan Fine has to scroll to 255, then Pan moves to 2 as Pan Fine moves to 0, then scrolls again to 255, then Pan moves to 3 as Pan Fine moves to 0, then Pan Fine moves up to 4.

Conversely, if Pan is supposed to decrease in value, Pan Fine has to scroll DOWN to 0 and move to 255 when Pan moves down by 1. This has to repeat until Pan reaches it's assigned value, and then Pan Fine scrolls down to it's assigned value.

It should work this way, regardless of the value of Pan Fine.


edit by @janosvitok: fixed "moves to 3"

[janosvitok]

I have finally figured out the logic for Pan and Pan Fine. They have to work in coordination with each other.

I'm not sure if you describe the current QLC+ behavior or the "normal" 16 bit behavior. If the latter, I guess it is simple as this:

- Pan and Pan Fine together behave as 16-bit integer (0..65535; value = (256*pan) + pan fine)
- Pan is the MSB (Most significant byte, i.e. the upper 8 bits, 0..255)
- Pan Fine is the LSB (Least significant byte, i.e. the lower 8 bits, 0..255)

The way you described is obviously correct.

The problem in QLC+ is that it processes the channels in isolation, and in this case sometimes overflow/underflow is needed. When summing the lower channels ("fine"),
it may happen that the sum is > 255 and the upper sum must be incremented (+1). When subtracting, the upper difference may need -1 (if the lower result is <0).
So the problem is how to handle these overflows/underflows that may happen later in the processing chain...

Jano

[GGGss]

The problem in QLC+ is that it processes the channels in isolation, and in this case sometimes overflow/underflow is needed. When summing the lower channels ("fine"),
it may happen that the sum is > 255 and the upper sum must be incremented (+1). When subtracting, the upper difference may need -1 (if the lower result is <0).
So the problem is how to handle these overflows/underflows that may happen later in the processing chain...

This is the thing I'm talking about all the time ... and is the correct definition.

[janosvitok]

This is the thing I'm talking about all the time ... and is the correct definition.

I think the best thing to do would be to advance the 16-bit idea even further: QLC+ should think (alternatively) in terms of degrees and angles and recompute to DMX values according to actual head capabilities. This would make scenes independent on actual hardware used (nice thing for touring groups). On the other hand, proper 3D coordinates would be required.

Similarly for color - if a HSV value is stored in a scene, it can be decomposed to actual light's color model.

This is a lot of work though, it's not going to happen any time soon...


Jano

[MichelSliepenbeek]

Why not also implement:
- "dim while travelling".
- RDM (Remote Device Management), then you will know where the fixtures really are (to UnDim if they have reached their positions or even better to controll the travelling speed).

I do agree:

it's not going to happen any time soon...

[GGGss]

Why not also implement:
- "dim while travelling".
- RDM (Remote Device Management), then you will know where the fixtures really are (to UnDim if they have reached their positions or even better to controll the travelling speed).

I do agree:

it's not going to happen any time soon...

MIB Move in Black ... gives other troubles that you need tracking built inside QLC+ ... It will have to decide when to move and when to shut the light off for the move. This is a well-discussed theme with the big guys...

Did you confuse something? WIth RDM you don't get to know where the mover is pointing at right now ... this is a false statement. RDM is only used to set parameters remotely or check the measurements and lamp hours f.i. With RDM you can address the light you are looking for so it highlights itself. My warning to you: never enable RDM during production. RDM communication introduces quite some lag on the DMX signals.

[kenact]

I move my heads while black all the time. That isn't a problem for me. I discovered this problem when I had two scenes, where the Pan and Pan Fine values remained the same. I was dimming other lights. But even though Pan and Pan Fine did not change between scenes, the head moved, unless Pan Fine was set to 0.

Fade out does not seem to affect DMX values of Pan & Pan Fine
Fade in does not seem to affect DMX values of Pan & Pan Fine, if both are set to 0

I've gone through most of the possible scenarios.