PAN TILT FINE Probleme ?

  • Guten Tag ,



    Ich habe folgendes Problem :


    Wenn ich für meine Showtec Indigo 4600 MH s eine Bewegungsscene erstelle und als anzusteuernde Kanäle Pan und Tilt an wähle, werden die PAN TILT Kanäle mit der eingestellten geschwindigkeit angesteuert. Jedoch werden die PAN Tilt Fine Kanäle auch angesteuert (die werte springen mehrmals pro Sekunde von 0 -255 ) ohne dass sie angewählt wurden.



    Kann das vieleicht am DDF liegen (DDF im Anhang ) ?



    Lg



    Lightmaxxx

  • Hallo Lightmaxx


    Das ist so gewollt. DMXControl steuert die fine Kanäle automatisch an (wenn sie als solche im DDF definiert sind).


    Durch diese Steuerung soll, gerade bei den großen Verfahrwegen von MovingHeads, eine feinere Bewegung erreicht werden.


    Ist jetzt dem MH aber nicht anzusehen oder?


    Gruß Philipp

  • Hallo,
    das ist vollkommen normal. Panfine und Tiltfine unterteilen die Werteänderung um eins bei den Pan- und Tilt-Werten in 255 zusätzliche Werte. Wenn du also den Pan-/Tilt-Wert um eins erhöht, fährt DMXC automatisch den passenden Panfine bzw. Tiltfinekanal durch, weil Pan und Panfine bzw. Tilt und Tiltfine immer zusammen gehören. Wenn du also den Pan- oder Tilt-Kanal schnell änderst, werden die Panfine- bzw. Tiltfine-kanäle entsprechend oft durchgefadet, was dann letztendlich so aussieht, wie du das beschrieben hast. Dem Scanner / MH macht das aber nichts.
    Viele Grüße
    JP
    Edit: Mist, Philipp war schneller ^^

  • Nabend,


    mal zwei Versuche der Erklärung aus dem Bauch heraus: Man kann das sehr computertechnisch sehen. Dann entspricht (nur) der PAN-Wert einem Byte, also einer Zahl zw 0 und 255. Hat man auch einen PANfine-Kanal, so setzt sich der PAN-Wert aus insgesamt zwei Byte zusammenen (auch 16bit-Steuerung genannt). Der PAN-Wert ist das höherwertige Byte (Werte zwischen 256 und 65280) und der PANfine-Wert das niederwertige Byte (Werte zwischen 0 und 255). Zusammen ergibt das dann einen Wertebereich von 0 bis 65535, also deutlich mehr (und damit genauer) als bei nur einem verwendeten DMX-Kanal. Die Sprünge kommen einfach vom binären Zahlensystem. (schnelles Beispiel-GIF: Die hinteren Zahlen "springen" während der Wert stetig größer wird)


    Zweite Idee ist eher praktisch-mathematisch. Movinglights haben einen bestimmten Bewegungsradius. Legen wir für das Beispiel fest: PAN-Bereich ist 0° bis 512° (etwa 1,5 Umdrehungen). Haben wir einen DMX-Kanal für PAN, können wir der Lampe 256 verschiedene Werte senden. Das Movinglight wird das einigermaßen ordentlich in Signale für den Motor umrechnen und macht bei jeder Wertänderung um 1 einen Motorschritt von 2° (weil 512° PAN-Bereich durch 256 mögliche Werte = 2°). Das ist relativ viel und bei wenigen Metern Entfernung an der Wand deutlich sichtbar als ruckeln.
    Nehmen wir den PANfine-Kanal hinzu können wir diese groben 2°-Schritte verbessern und weicher machen. Während der PAN-Kanal von 132 auf 133 springt, lassen wir den PANfine-Wert langsam* von 0 bis 255 anwachsen und dann wieder auf 0 zurück. Jede Wertänderung des PANfine-Kanal entspricht jetzt einem Motorschritt von (2° / 256) ≈ 0,008°. Schon viel besser. Kein ruckeln mehr zu sehen. Wenn der PAN-Kanal jetzt weiter geht von 133 auf 134 wollen wir ja wieder die Zwischenschritte nutzen können, deshalb rutscht der PANfine-Wert wieder zurück auf null und das Spiel geht wieder von vorne los. Natürlich kann man das Movinglight auch auf diese Zwischenschritte sehr genau positionieren, dann hat der PANfine-Kanal natürlich den gewünschten Wert und nicht zwingend immer null.


    MfG, der lichtheini


    *langsam ist relativ... es sieht eher aus wie Sprünge

  • Mein problem ist nur eben dass die pan tilt fine werte mehrmals pro sekunde von 0 -255 springen.

    was soll daran ein Problem sein? Das ist bei schnellen Fahrten immer so. Bei schnellen Fahrten fallen die Fine-Kanäle aber so gut wie garnicht mehr ins Gewicht. Die Begründung dafür ist ganz einfach. Ein Scanner / MH benötigt eine gewisse Zeit, um von Punkt A nach Punkt B zu fahren. Wenn wir jetzt langsam den DMX-Wert z.B. von Pan erhöhen, also jede Sekunde um einen Schritt, dann fährt der MH innerhalb sagen wir mal 0,6sec (bsp. geringst mögliche Verfahrgeschwindigkeit) an die neue Position und wartet dann dort => es ruckelt. Daher hier die Unterteilung mit den Fine-Kanälen, weil der Scanner nun sehr viel kleinere Schritte machen kann, wodurch es nicht mehr so aussieht, als ob es ruckelt. Nun überlegen wir uns das selbe, für eine schnelle Werteänderung, also z.B. alle 0,2 Sekunden eine Werteerhöhung auf dem Pankanal. Nun ist die Änderungsgeschwindigkeit der Werte größer, als die minimale Verfahrgeschwindigkeit des MH. Was macht wer? Er beschleunigt, weil er sonst immer weiter hinter der eigentlich vorgegebenen Position zurück liegt. Dadurch versucht er immer in die Richtung zu fahren, an der er eigentlich sein sollte. Das kann man sich in etwa wie ein Katz und Maus-Spiel vorstellen. Die aktuelle Position ist die Katze, die immer versucht, auf dem kürzesten Weg zur Maus, der durch den DMX-Wert vorgegebenen Position zu kommen. Da der MH das bei schnell genuger Werteänderung aber nie schafft, ist hier die Bewegung auch mit einem reinen Pan oder Tilt-Kanal flüssig. Nun wirkt sich ein flackernder Finekanal praktisch nicht mehr auf die Bewegung aus, denn dieser hat wieder nur Einfluss auf die Maus und nicht direkt auf die Katze. Das wäre in etwa so, wie wenn die Maus Haken schlägt. Macht die Maus sehr schnelle Haken, dann läuft die Katze trotzdem fast gerade aus. Ich hoffe, damit ist das verständlich erklärt, warum es nichts aus macht, wenn Finekanäle schnelle Änderungen machen.
    Viele Grüße
    JP

  • Der Fine Kanal stellt die 256 Zwischenstufen zwischen zwei Werten des nicht Fine Kanal dar. Würde der nicht springen, wäre die Implementierung falsch.


    Fade ich von Pan 0 -> 2, habe ich folgende Zwischenschritte
    Pan 0, Pan Fine 0,
    ...
    Pan 0, Pan Fine 127
    ...
    Pan 0, Pan Fine 255,
    Pan 1, Pan Fine 0,
    ...
    Pan 1, Pan Fine 127,
    ...
    Pan 1, Pan Fine 255,
    Pan 2, Pan Fine 0.



    Dennis

  • Aber ist das nicht schädlich für die MH s ??


    Nein, überhaupt nicht. Denn es sprint immer nur der Zielpunkt. Das ist einfach ein Punkt im Koordinatensystem, egal wie sehr dieser springt. Dieser hüpft irgendwo hin und der MH versucht zu folgen.


    Lustiger wird es, wenn wir diese Position so schnell ändern, dass der MH nicht mehr hinter her kommt. Denn MHs und Scanner haben auch eine maximale Verfahrgeschwindigkeit. Schneller geht nicht. Wenn also die vorgegebene Position zu schnell ist, dann kommt der MH nicht hinterher oder in Katze und Maus gedacht: Wenn die Maus soo schnell im Kreis um die Katze rennt, dass diese nicht mehr mit kommt, dann bleibt die Katze halt in der Mitte sitzen, wärend die Maus rennt. Bei manchen MHs kann man diese maximale Verfahrgeschwindigkeit auch reduzieren (z.B. damit die Traverse nicht durch zu schnelle Bewegungen anfängt zu wackeln). Wenn man dann sehr schnell den MH einen goßen Kreis fahren lässt, dann bleibt dieser auch in der Mitte und bewegt sich nur ganz wenig, weil er der vorgegebenen Position einfach nicht folgen kann. Aber auch das macht dem MH überhaupt nichts.
    Viele Grüße
    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

    Edited once, last by JPK ().

  • Newly created posts will remain inaccessible for others until approved by a moderator.

    The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.