dmx4all/Faderverhalten

Also mein Interface hat definitiv eine andere Firmware:

USB DMX-Interface V3.36
(c) 2000-2004 Markus Siwek

Ich habe Herrn Siwek angeschrieben, ob ich damit wirklich nicht vom Firmwarebug betroffen bin und ob er das Problem selber nachvollziehen kann...

Kann mal bitte jeder, der ein DMX4ALL-Interface besitzt, die Firmwareversion melden (kann man glaub ich auch im Konfigurieren-Dialog des Ausgabeplugins über den Button "Interfaceinfo anzeigen" abrufen, ansonsten über das DMXConfigurator Programm von DMX4ALL) und dazu sagen, ob er den Bug nachvollziehen kann oder nicht (eventuell noch mehr Kanäle und Submaster aufziehen)?

Und wer noch ein zweites Interface hat (insbesondere eines das ebenfalls auf Kommunikation über die serielle Schnittstelle basiert), ob es damit kein Fehlverhalten gibt?

Meine DMX-Steuerung sollte für den Kinderchor-Auftritt an Heilig Abend (bzw. zur Generalprobe am 22.12.) zuverlässig funktionieren. Das ist nicht mehr lange hin...

Gruß

Michael

Hoc, vielen Dank und leider willkommen im Club ...

Ich habe Antwort von Herrn Siwek bekommen. Es sei kein Bug in dieser Interfaceversion bekannt. Daher wäre es noch interessanter von allen anderen zu hören, ob es mit einer anderen Firmwareversion oder einem anderen Interface von DMX4ALL (nicht dem Mini) besser läuft....

Er meinte auch, dass man die zu übertragende Datenmenge von der Software her möglichst gering halten sollte. Aber ich nehme an, das macht Stefan sowieso und überträgt nur geänderte Werte. Allerdings sind das natürlich bei einem Grandmasterfade gleich einige...

Die Frage wäre, ob das Ganze auch auftritt, wenn man an einen Submaster sehr viele Kanäle dranhängt und dann diesen fadet.

DanielC: könntest Du mal bitte überprüfen welche Kanäle im jeweiligen Fall über die serielle Schnitstelle gesendet werden?

In anderen Programmen (z.B. dem DMXConfigurator) ist mir das Verhalten bei Masterfades noch nicht aufgefallen (muss ich vielleicht auch noch mal detaillierter testen). Also denke ich, es müsste mit Software in den Griff zu bekommen sein.

Stefan: Wäre es ein großer Aufwand ein neues Ausgabe-Plugin zu programmieren, das in einem extra Thread alle Nachrichten einfach mal entgegen nimmt, intern in ein Array abspeichert und dann immer den (in einem anderen Array gespeicherten) alten Zustand des Universums mit dem neuen vergleicht und nur die Änderungen ausgibt?

So würde verhindert, dass Nachrichten verschluckt werden (wie auch immer das im Moment passieren soll..). Wenn dann zu schnelle Fades auftreten, werden halt ein paar Zwischenwerte übersprungen, aber das sollte bei einem schnellen Rechner nicht bemerkbar sein, und am Ende ist gesichert, dass die richtigen Endwerte eingestellt sind.

Mir fällt übrigens gerade noch ein, dass es eigentlich nicht daran liegen kann, dass Nachrichten verschluckt werden. Wie sollte denn dann bei langsamen Fades, die richtig beginnen (alle Lampen werden dunkler), am Schluss der Sprung auf einen völlig falschen Wert entstehen?

DanielC: kannst Du das auch das Verhalten nachvollziehen? Was geht da an der Schnittstelle raus? Wenn's immer 255 wäre, dann handelt es sich vielleicht um einen Rundungsfehler und einen Über- (bzw. Unter-) lauf auf eine negative Zahl (bei der -1 sind ja in der Computerdarstellung erst mal alle Bits gesetzt, wenn man das als vorzeichenloses Byte interpretiert ist das eine 255).

Stefan: gibt es einen Unterschied zwischen der Berechnung der Werte in der Kanalübersicht und der im Ausgabe-Plugin?

Ich hoffe wir kommen der Lösung des Problems so langsam näher...

Gruß

Michael

Also jetzt wird's Tag...

Ich hab mal den PortMon von Sysinternals (inzwischen bei Microsoft: http://www.microsoft.com/technet/sysint…es/portmon.mspx) dazwischen gehängt und die Kommunikation über die serielle Schnittstelle mitgeschnitten.

Dabei konnte ich zwei Dinge feststellen:

1. Durch die zusätzliche Verzögerung aufgrund der Protokollierung durch PortMon tritt der Effekt wesentlich deutlicher und meist extrem krass auf. Wenn ich auf 0 (bzw. 255) fade gehen die Werte zunächst wirklich auf 0 runter (bzw.255 rauf), dann aber nach einiger Zeit (erstaunlich viel später nach dem Fade) wieder auf recht hohe Werte (nicht unbedingt 255 bzw. tiefe Werte nicht unbedingt 0) und zwar über einige Zwischenwerte. Das ist äußerst merkwürdig. Wo kommen diese Werte her?

Dabei wird eindeutig nur ein schreibender Zugriff (bis auf die RÜckmeldung Hex 47) auf das Interface protokolliert (6-Byte Befehl beginnt mit Hex FF, 2 Byte Kanalnummer, 01, DMX-Wert, 00). Bei Inaktivität gibt's übrigens ein paar 4-Byte Befehle (FC 00 00 32). Hab leider keine Dokumentation des Protokolls...

2. Das Problem tritt tatsächlich auch mit den Subfadern beim Ansteuern mehrerer Kanäle auf (bei mir jetzt mal 8 am selben Submaster getestet).

In der Kanalanzeige ist auch dabei alles in Ordnung...

Stefan: kannst Du mal ne Debug-Version von dem DMX4ALL-Ausgabeplugin compilieren, die alle empfangenen (Windows- bzw. DMXControl-) Nachrichten in eine Datei protokolliert? Irgendwoher müssen diese Werte doch kommen...

Kann jemand, der ein anderes, auf (realer oder virtueller) serieller Übertragung beruhendes Interface (nicht von DMXX4ALL) verwendet, mal überprüfen, was bei ihm unter diesen Bedingungen (PortMon und Grandmasterfade mit mehreren offen Submastern) passiert?

Gruß

Michael

Hallo Stefan,

Das war's...

Und wenn Du mir jetzt noch sagst, was an der Version anders ist als an der aus dem 2.9 Installer (und auch der aus der 2.8er Release) , dann haben wir den Fehler gefunden...

Falls Du wirklich außer der Umstellung auf ein Debugprojekt nichts geändert haben solltest, dann verschick doch noch mal eine aktuelle Releaseversion der DLL.

Ich konnte bisher mit der Debug-Version - ob mit oder ohne Debug View und mit oder ohne PortMon - kein Fehlverhalten mehr feststellen...

Super. Vielen Dank. Das Weihnachts-Singspiel ist gerettet!!!

Das heißt... ich hoffe es gehen mit dieser Version auch immer noch alle Ausgabewerte tatsächlich ans Interface - hab nämlich gerade außer dem Interface und einem Scanner (aber dafür kein einziges XLR-Kabel oder den Abschlusswiderstand) keine Hardware mehr zuhause zum Testen ...

Gruß

Michael

Hallo Stefan,

scheinst auch ein Nachtmensch zu sein ...

Quote

WAAAAS?? ??? ??? ??? :o :o :o
Das gibt's nicht...

Doch. Und es kommt noch besser:

Quote

Ich hab jetzt mal die DLL mit auskommentierten Zeilen angehängt.

Und die funktioniert ebenfalls bestens! Alles in Ordnung...

Die Frage ist nur, was ist an meinen kaputt? Die waren direkt aus den Installationdateien der 2.8 und 2.9...

Hast Du inzwischen ein Compilerupdate oder Servicepack eingespielt?

Ich häng mal meine DLLs aus der 2.9 und der 2.8 an, damit den Bug nochmals alle nachvollziehen können ...

Die kannst Du ja mal selber mit der aus der Installation vergleichen ("DOS"-Befehl fc). Wie gesagt: ich hatte die Version 2.9 runtergeladen und installiert...

Gruß

Michael