Hi,
also bei dir passieren da mehrere Dinge parallel. Erst einmal zum Interface:
Gemäß diesem Post ist das Lixada Interface ein Nachbau des Anyama Interfaces.
Souko Spanned ist tatsächlich, dass DMXControl 3 meckert beim Hinzufügen des Interfaces. Da müssten wir mal schauen, ob das nicht noch ein Bug in dem DMX-Plugin für dieses Interface ist. Da melden wir uns nochmal. Denn so wie es aussieht, versucht das Plugin das Interface zwei mal hinzuzufügen und das geht natürlich nicht. Kann das Interface bzw. die Geräte daran sauber angesteuert werden? Wenn ja, dann sind die Warnungen ala WARN org.dmxc.lumos.Kernel.DMX.AnymaUDMXInterface - Failed to write 32 bytes, wrote 0 ein Resultat des Versuchs, das Interface zwei mal hinzuzufügen. Wenn nein, dann müssen wir da nochmal genauer schauen.
Was ich aber spannender finde ist folgendes:
ERROR org.dmxc.lumos.Kernel.Run.KernelRunManager - Exception when stopping Manager AffinityManager: Exception of type 'System.OutOfMemoryException' was thrown.
System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.IO.MemoryStream.set_Capacity(Int32 value)
at System.IO.MemoryStream.EnsureCapacity(Int32 value)
at System.IO.MemoryStream.Write(ReadOnlySpan`1 buffer)
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at System.IO.StreamWriter.WriteLine(String value)
at org.dmxc.lumos.Kernel.HAL.Affinity.CorrelationRepository.saveCorrelations() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\HAL\Affinity\xCorrelation\CorrelationRepository.cs:line 134
at org.dmxc.lumos.Kernel.HAL.Affinity.GoboAffinityClass.shutdown() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\HAL\Affinity\GoboAffinityClass.cs:line 133
at org.dmxc.lumos.Kernel.HAL.Affinity.AffinityManager.org.dmxc.lumos.Kernel.Run.IManager.shutdown() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\HAL\Affinity\AffinityManager.cs:line 107
at org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ManagerShutdownAction(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:line 653Hier meckert DMXControl 3, dass der Arbeitsspeicher ausgegangen ist. Wie viel Arbeitsspeicher hast du auf der Maschine? Wie alt ist denn dein Projekt bzw. welche Datei-Größe hat es?
Viele Grüße
JP
Vielleicht kommt DMXC ja da irgendwie durcheinander, dass das Interface "zweimal" passen würde
Ja, genau das ist mein Gedankengang. Da müssen wir aber erst noch genauer in den Code schauen. Aber schon einmal danke für deine weiteren Tests 
Dann können wir hoffentlich weiter eingrenzen.
Das mit der OutOfMemory-Exception ist dann tatsächlich spannend. Könntest du mir das Projekt mal zukommen lassen, dass wir da mal reinschauen können?
Könntest du mir das Projekt mal zukommen lassen, dass wir da mal reinschauen können?
aber gerne doch....ist aber echt nicht berauschend...eher so "einfach rumprobieren" 
Hallo mcbeth1307 ,
Mal ganz ehrlich, ich würde das aktive DE- Interface immer dem passiven Lixada USB DMX512 vorziehen bzw verwenden.
Gruß Steff
Mal ganz ehrlich, ich würde das aktive DE- Interface immer dem passiven Lixada USB DMX512 vorziehen bzw verwenden.
Vll. ist das Lixada nicht ganz so super, allerdings ist es trotzdem ein "aktives" Interface, erzeugt also die DMX-Ausgabe mit einem eigenen Mikrocontroller. "Passiv" sind nur das Enttec OpenDMX und dessen viele Klone.
Stefan
Hallo,
Vll. ist das Lixada nicht ganz so super, allerdings ist es trotzdem ein "aktives" Interface,
OK das sah für mich erst mal wie ein einfaches passives Interface-Kabel aus.
Man lernt ja nie aus.
Ich wollte das bei mir mal kurz einrichten um zu schauen was für Eistellungen man hier vornehmen kann.
Geht aber nicht weil ich das Interface bei mir nicht vorhanden ist.
Meine Fragen zu dem Interface:
Kann man hier die Timings ändern ?
Gibt es wie beim DE Interface eine galvanische Trennung ?
Gtruß Steff
ich habe da folgende Einstellungsmöglichkeiten....die mir ehrlich gesagt nichts sagen:
Habt Ihr da nen Vorschlag der mir vielleicht weiterhelfen könnte ?
gibt es da schon neue Erkenntnisse.
Da gibt es leider noch nichts neues.
Habt Ihr da nen Vorschlag der mir vielleicht weiterhelfen könnte ?
Wenn ich die Einstellungsmöglichkeiten aber mal so sehe: Das Interface unterstützt offenbar auch das Anpassen des DMX-Signals auf der Leitung (also wie das Signal genau geformt ist). Das bedeutet, man kann wichtige Parameter des DMX-Signals verändern. Zur Erklärung: Die Break-Time ist die Zeit in Mikrosekunden zwischen zwei DMX-Paketen (also ein Set aus allen DMX-Werten). In dieser Pause ist das Signal auf dem Bus konstant 0. "Mark after Break" ist ein Marker für die Empfänger, dass jetzt das nächste DMX-Paket startet. Hier ist das Signal konstant 1 auf dem Bus. Danach werden dann die ganzen Kanäle der Reihe nach geschickt. "Pause zwischen Bytes" ist eine Wartezeit zwischen zwei Kanalwerten. Das hier sind also Zeiten, die so in der Spezifikation von DMX vorgegeben sind (dort finden sich also die 88 µs, die 8 µs und die 0 µs für die drei Werte). Die drei hier eingestellten Werte sind die Mindest-Zeiten und sollten eigentlich verwendet werden, da sie die beste Updaterate von ~44Hz bieten. Wie das genau aussieht, kann man auch auf folgender Webseite sehen: https://wiki.production-partner.de/licht/lichtsteuerung-mit-dmx-512/
Die Spezifikation erlaubt aber auch längere Zeiten (was dann aber eben auf die Update-Rate geht). Manche DMX-Geräte (vor allem günstigerer Natur) kommen mit diesen Mindestzeiten jedoch leider nicht zurecht, weil eben auch am DMX-Controller gespart wurde. Dann kann es vor kommen, dass diese von dem Signal "überfordert werden". Dabei interpretieren diese dann z.B. DMX-Werte falsch (verrutschen in den Kanälen, interpretieren die Bits falsch, etc.). Das äußert sich unter anderem in einem Flackern / Aufblitzen. Dann kann es helfen, diesen Geräten ein bisschen mehr Zeit zu geben, indem man das DMX-Signal "langsamer" macht (sprich die Zeiten etwas hoch setzt). Um wie viel, das muss man leider ausprobieren, denn das hängt vollkommen von den eingesetzten DMX-Geräten und deren interner Performance ab.
Du kannst also mal folgendes probieren: Setz mal die Break-Time etwas hoch (erst einmal auf vielleicht 100 oder so). Und erhöhe auch minimal die Mark after Break Zeit (auf 16 oder so). Wenn das schon hilft, gut. Wenn nicht, dann würde ich die Breaktime schrittweise noch etwas weiter auf 250 oder so setzen. Hier noch einmal wichtig zu betonen: Je höher diese Werte, desto langsamer ist das DMX-Signal. Ergo geht damit auch deine Update-Rate in den Keller. Das ist bei der Break- und Marktime noch nicht soooo tragisch, weil diese nur einmal pro DMX-Frame gesendet werden und damit keinen soo großen Einfluss auf die Updaterate haben. Die Pause zwischen den Bytes schon mehr, weil diese ja nach jedem DMX-Kanal gehalten wird.
Mal so zur Einordnung: Mit den Original-Werten ist die Updaterate bei ~44,2Hz. Mit Marktime=250, Breaktime=16 und Pausetime=0 ist die Updaterate bei ~43,87Hz. Mit Marktime=250, Breaktime=16 und Pausetime=8 sinkt sie schon auf ~37,2Hz. Das also bei der Pausetime bitte beachten.
Ich hoffe, das hilft soweit mal zur Einordnung und das du das mal ausprobieren kannst, ob du dadurch das Flackern beheben kannst.
Viele Grüße
JP
P.S.: Hatte nicht auf dem Schirm, dass man bei dem Lixada-Interface auch diese Werte einstellen kann. Da hat dieser Hersteller doch auch mal etwas sinnvolles übernommen (bisher war vor allem das DE/fx5-Interface und unser Nodle-Interface in der Lage, das DMX-Signal anzupassen).
