Hallo zusammen!
Als stolzer Besitzer eines Nodle R4S bin ich grade dabei, eine Steuersoftware zu bauen und stoße leider auf Timing-Probleme. Mein Ziel ist unter anderem ein softwaregesteuerter Stroboskop-Effekt, um nicht von den Hardware-Strobe-Modi abhängig zu sein, die man auf unterschiedlichen Gerätetypen nicht vernünftig synchron bekommt. Der Effekt soll unterbrechungsfrei rhythmisch flackern, ohne Unregelmäßigkeiten. Leider bekomme ich das nicht hin: Es tritt regelmäßig "Tearing" auf, d.h. der Nodle verarbeitet ein Frame während es geschrieben wird, oder ich schreibe ein Frame zu schnell (bevor das alte abgearbeitet ist) oder zu langsam (so dass es nicht abgearbeitet wird).
Rahmenbedingungen:
- Nodle R4S, angeschlossen direkt an USB ohne Hub
- Nodle_USB.dll / Nodle USB Interface Library 2.0.0.32 aus dem Nodle Config Tool 1.0.3
- NodleWrapper (ähnlich wie im Nodle Config Tool oder DMXControlProjectsEVNodleU)
- USBDMXEnergyFixer ausgeführt
- InterfaceMode: 6 - PC Out -> DMX Out & DMX In -> PC In
- Timing: Control = 2 (nur InterFrame-Time), Break = 22, Mark = 7, InterByte = 0, InterFrame = 81, ChannelCount = 512, StartByte = 0
Proof of Concept:
- Nodle Out => ETEC LED PARTYBAR 2 => Nodle In
- OnBlockChange:
- Wenn outBytes[0] == 0 dann outBytes[0] = 255 sonst outBytes[0] = 0
- Schreibe durchschnittliche Dauer seit letztem Aufruf: Pendelt sich bei ziemlich genau 24,00 ms ein
Sobald OnBlockChange aufgerufen wird, invertiere ich also den Rot-Kanal und fertig. Das führt durch den Loopback zurück per Input wiederum zu einem OnBlockChange, wo dann wieder invertiert wird und immer so weiter. Das Ergebnis: Ein perfektes Stroboskop, auch nach mehreren Minuten gibt es keinen einzigen Aussetzer. Die Frequenz ist mit 24 ms sehr nah am DMX-Optimum, die Prozessorlast bei 0% (ob der Prozess als "normal" oder "Echtzeit" läuft macht keinen Unterschied auf meinem System). Es ist also grundsätzlich möglich, mit dem Nodle eine einwandfreie, framegenaue Ausgabe zu erzeugen. Beobachtung bzgl. "neuem Ausgabemodus": Wenn man ein komplettes Universum alternierend schreibt (nur 0en, dann nur 1en usw.) ist der alte OutBytes-Modus zuverlässiger an den 24 ms im Vergleich zum neuen SendDmxUniverse-Modus.
Problem dabei: Ich kann den Eingang nicht vernünftig nutzen, sondern blockiere ihn nur zum Zweck, das Timing des Ausgangs in der Software mitzubekommen. Ich hab das Teil ja allerdings genau deshalb gekauft, weil ich den Eingang anderweitig benötige.
Reproduktionsanleitung:
- Nodle Out => ETEC LED PARTYBAR 2 => Terminator
- Multimedia-Timer (High Precision, winmm.dll TimeSetEvent) mit exakt 24 ms, Jitter bei 1 ms, Drift gemessen per System.Diagnostics.Stopwatch nach mehreren Minuten immer < 2ms
- Wenn outBytes[0] == 0 dann outBytes[0] = 255 sonst outBytes[0] = 0
Hier läuft alles super für ca. eine Minute, dann "driftet" das Zeitfenster, während dem geschrieben wird, in das Zeitfenster der DMX-Verarbeitung und es gibt Müll, der sich durch Tearing äußert (manche Bytes sind schon übertragen, andere noch nicht => Ungleichmäßiges Blinken, falsche Farben usw.). Das hält dann eine Weile an, bis das timergesteuerte Schreiben-Fenster wieder aus dem Lesen-Fenster rausgewandert ist, dann ist alles wieder super. Das Verhalten ist sowohl beim direkten Schreiben per OutBytes als auch mit SendDmxUniverse zu beobachten.
Ich wünsche mir also:
- Einen Callback "RequestAnimationFrame", der unmittelbar nach der Verarbeitung getriggert wird (z.B. während der Interframe-Time?), um sauber schreiben zu können
- oder einen blockierenden Aufruf "SendDmxUniverseBlocking", der so lange blockiert, bis der aktuelle Aufruf abgearbeitet und ausgegeben wurde - um das dann einfach entspannt auf einem eigenen Thread in einer Endlosschleife aufzurufen
- oder (bis es sowas gibt) einen praktikablen Workaround, um meinen Timer regelmäßig mit dem Nodle zu synchronisieren (z.B. durch Parameteränderungen oder CloseLink/OpenLink innerhalb des Timers?)
Ich freue mich über jegliche Form der Unterstützung 
Danke und liebe Grüße
Frank
LightningBrothers
