Hallo,
das ist ja spannend, dass es so etwas auch gibt. Tatsächlich unterstützt DMXControl 3 nur eine PTSpeed-Eigenschaft pro Gerät. Da es sich hier aber "nur" um den PTSpeed handelt und um keine Geräteeigenschaft, für die es eine intelligentere Ansteuerung in DMXControl 3 gibt (wie für Gobos oder die Farbe), würde ich in diesem Fall tatsächlich auf zwei Raw Kanäle gehen: https://wiki-de.dmxcontrol-pro…on_(DDF-Syntax)_DMXC3#raw Damit solltest du dann beide Kanäle entsprechend benennen und ansprechen können. Einziger Wermutstropfen ist, dass du eben nicht mehrere unterschiedliche MH / Scannertypen gleichzeitig auswählen und deren PTSpeed gemeinsam steuern kannst. Aber das dürfte wie gesagt (anders als bei der Farbe oder den Gobos) hier verkraftbar sein.
Viele Grüße
JP
das ist ja spannend, dass es so etwas auch gibt.
das gibt es bei GLP und Ehrgeiz Geräten sogar recht häufig. Hab es bisher immer mit raw-Elementen gelöst; war mir eh wurscht weil ich die Geschwindigkeit von Bewegungen sowieso ausschließlich über die Cuelist Speeds steuere (bei Geräten mit 16Bit merkt man da sowieso keinen Unterschied mehr), PT-Speed ist für mich also unnötig :o)
weil ich die Geschwindigkeit von Bewegungen sowieso ausschließlich über die Cuelist Speeds steuere
Von daher wäre es auch in Ordnung, wenn du mittels des const-Elements dauerhaft einen bestimmten DMX-Wert vorgibst. Die "richtige" Funktion kann im DDF auch jederzeit noch nachgereicht, also nachträglich hinzugefügt werden.
Also es ist so etwa 15 Jahre her, da hatte ich mal 10 Stück von den Teilen. Waren große Klasse, da man die Wackelköpfe unendlich drehen lassen konnte. Mit den DIP Schaltern wird schon die DMX Adresse eingestellt, allerdings mußte man eine Stelle vor oder zurück eingeben, warum auch immer. Bei mir haben die damals unter DMXC2 sofort reagiert.
An dem DIP-Schaltern stellt an offensichtlich die "Scannernummer" ein und nicht die tatsächliche DMX-Adresse, hat mich eine Stunde gekostet, bis ich es herausgefunden habe (Scanner 1 = Adresse 1-8, 2= 9-16, usw).
Was aber viel mehr nervt ist, dass die Geräte stark zeitverzögert reagieren. Ich stelle eine PAN/ Tilt Position ein und es dauert zwischen 5-10 Sekunden, bis das Gerät diese Position fährt.
Beide Phänomene zusammen bringen mich auf die Idee, dass die Heads dein DMX-Signal vll. nicht verstehen (z.B. weil normgerecht schnell).
Welches DMX-Interface verwendest du?
Stefan
Oder denke ich da zu einfach?
Tatsächlich ja 
Ich gehe jetzt nicht auf den gesamten Aufbau des DMX-Signals ein (also welche Spannungen wie lange auf dem Bus sein müssen). Dafür mal hier schauen: https://wiki.production-partne…chtsteuerung-mit-dmx-512/). Aber ich greife da ein paar wichtige heraus und die schauen wir uns genauer an. Da es sich bei DMX um ein digitales Signal handelt, werden die Bits (0 und 1) auf dem Bus zum einen durch gewisse Spannungswerte repräsentiert, die zum anderen für eine gewisse Zeit anliegen müssen, damit sie als solche erkannt werden. Außerdem arbeitet der DMX-Bus zyklisch. Das bedeutet, es muss eine Info geben, wann eine neue Übertragung anfängt. Das wird durch eine Wartezeit (die Breaktime) gefolgt von einem "Hi"-Signal für eine gewisse Zeit (Mark after Break oder kürzer "Marktime") symbolisiert. Anhand dieser Kombination können die Empfänger wissen "Aaaaahh, jetzt beginnt die Übertragung aller DMX-Kanäle". Für DMX ist spezifiziert, dass die Breaktime mindestens 88µs lang ist. Die Breaktime soll zwischen 8µs und 1s lang sein.
Was hat das jetzt mit dem Interface zu tun? Beim Nodle U1 haben wir darauf geachtet, dass es die kürzesten erlaubten Zeiten unterstützt und sich auch exakt daran hält. So hat man die größtmögliche Übertragungsrate. Nur haben eben manche Geräte Probleme damit, weil da eben z.B. langsamere Prozessoren verbaut sind (um Kosten zu sparen). Die kommen mit diesen Timings nicht zurecht und legen dann ganz interessante Verhaltensweisen an den Tag. Das Nodle U1 ist aber auch eines der ganz wenigen DMX Interfaces am Markt, bei dem man diese Timings auch bewusst verstellen kann, sprich die Timings größer machen kann. So gibt man den Scheinwerfern mehr Zeit, das DMX-Signal zu analysieren. Daher die Frage von Stefan.
Wenn der Kanal den Wert bekommt, hält er diesen doch, bis er wieder verändert wird, oder?
Nein, so funktioniert DMX nicht. DMX schickt ganz stumpf in jedem Buszyklus einmal den gesamten Block an DMX-Werten. Ich sage hier bewusst Block und nicht "ganzes Universum", denn laut DMX-Spezifikation ist es auch erlaubt, nur die ersten x Kanäle zu senden, wobei x auch kleiner als die maximalen 512 Kanäle sein darf.
Ich hoffe, das war soweit verständlich. Wenn nein, dann gerne noch einmal nachfragen 
Viele Grüße
JP
Und um hier nochmal eine eigene Erfahrung zu ergänzen: bei mir haben die schnellstmöglichen Timings im DE-Interface (welches neben dem Nodle U1 bzw. Nodle R4S eines der weiteren wenigen USB-DMX-Interfaces ein Anpassen der Timings ermöglicht) dafür gesorgt, dass die Kanalbelegung von angeschlossenen Geräten nicht mehr passte. Die verschiedenen DMX-Kanäle waren zunehmend verschoben.
Erst nach dem Ändern der Timings - sprich "verlangsamen" - verhielten sie sich so, wie in der Bedienungsanleitung angegeben.
Sorry für die späte Rückmeldung. Ich hatte leider nicht so viel Zeit wie erhofft. Du kannst die Änderungen auch direkt aus DMXControl 3 heraus machen. Das geht in den Advanced Interface-Settings des Nodle-Interfaces (siehe Bild im Anhang). Außerdem habe ich in folgendem Post mal eine kleine Anleitung geschrieben, wie man bei der Break- und Marktime vorgehen kann, um eine gute Einstellung zu finden. Zumindest gehe ich so immer vor.
Der Hintergrund ist nämlich, dass es "DIE" Werte in einem solchen Fall nicht gibt. Es hilft nur, etwas auszuprobieren und schrittweise die Werte zu erhöhen, bis man eine Einstellung gefunden hat, die mit den eigenen Geräten funktioniert.
Viele Grüße
JP
Newly created posts will remain inaccessible for others until approved by a moderator.
JPK