dmx4all/Faderverhalten

DMX4all Interface (v4) über RS232 an DMXControl 2.8 und aktuelle Alpha

Test mit 4-Kanal Dimmerpack (Eurolite DX-4) und gedownloadeter DDF, aber auch mit eigener DDF

Bewegt man in der Gerätesteuerung die Fader, so gibt es merkwürdige Sprünge. Insbesondere wenn der Fader schnell ganz nach links geschoben wird (theoretisch 0) bleibt das Licht "hängen".

In der Kanalübersicht wird aber korrekterweise 0 angezeigt, der DMX-Ausgabewert ist aber nicht 0 (das was am Dimmerpack ankommt)

hier die Frage: ist das ein Problem von DMX4all oder der entsprechenden Konfiguration (COM-Einstellungen etc.), ein Problem der COM-Schnittstelle des Computers oder sonst irgendwas?

Hat irgendjemand eine Idee?????

Die Baudrate ist auf Maximum (38400).

Bei Bedienung der Fader kommt es zu "komischen" Sprüngen. Ich habe nach setzen der Werte mal das Interface extern abgefragt (also welche DMX-Werte das Interface glaubt ausgeben zu müssen). Diese stimmen definitiv nicht mit den in der DMX Kanalübesicht angzeigten überein. Beispiel: DMXC Kanal 1: 0, im Interface 84; Kanal 2: 156, im Interface 82. Dementsprechend kann es die DMX-Seite (Dimmerpack usw.) nicht sein.

Wird der Effektsequencer verwendet, kann ich keine Mängel entdecken; egal ob langsam oder sehr schnell ausgeführt, das Interface folgt den Kommandos problemlos.

Kann es sein, daß die GUI zu viel Zeit klaut und dadurch Befehle an das Interface ausgelassen werden? [Windows XP, SP2, 700MHZ Intel Laptop]

????

Ich habe das Ganze heute man auf einem anderen, sehr sauber konfigurierten und schnelleren Rechner (1GHz) probiert. Hier tritt das Problem nicht generell auf, es sei denn, es ist gleichzeitig die Kanalübersicht geöffnet. Dann werden wieder Steuerbefehle an das Interface "verschluckt", die Kanalübersicht zeigt alles korrekt an. [sowohl mit der DLL aus der Release-Version als auch der aktuellen auf der Homepage (mit DMX-IN)).

Test wurde mit der aktuellen .127 Version durchgeführt.

Wo könnte der Fehler lliegen?

Wie erfolgt eigentlich generell die Datenübertragung zum DMX4all-Interface? Wird kontinuierlich alles neu übertragen oder wird nur bei einer Kanaländerung etwas übertragen [wäre ja ausreichend]? Und falls ja, was (alle Kanäle oder nur der geänderte Kanal)?

Gibt es irgendwie eine Möglichkeit DMXC auf Wunsch dazu zu veranlassen, alle DMX-Kanaleinstellungen erneut an das Interface zu senden (eine Art "refresh")?

Hallo zusammen,

ich habe das gleiche Problem mit meinem DMX4All Interface.

Habe mir zur Kontrolle mal den Datenstrom angeschaut, der über den COM-Port zum Interface gesendet wird.
Dabei fiel mir auf, dass beim langsamen faden von beispielsweise 2 Kanälen die Werte erst normal steigen, dann aber plötzlich bei einem Kanal extreme Sprünge auftreten und beim anderen der Wert sogar wieder abnimmt!

Hat jemand eine Idee?

Hallo DanielC und semmelkuh,

ich habe das Problem schon ausführlich im Bugtracker unter dem Titel "FS#51 - DMX4ALL Mini-USB Treiber spinnt bei Grandmasterfades" beschrieben:

http://www.dmxcontrol.de/flyspray/index…ails&task_id=51

Das Problem tritt mit dem Grandmaster auch teilweise mit ganz langsamen Fades besonders in den Extrempositionen auf.

Nachdem DanielC ja nun auch die Ausgabewerte am ComPort analysiert hat, ist eindeutig ein zu langsames Interface bzw. ein Fehler in dessen Firmware ausgeschlossen.

Meiner Meinung nach muss ein Speicherüberschreibungsbug im DMX-4ALL Treiber liegen (ohne ihn geht ja alles). Anders kann ich mir solche Effekte nicht erklären...

Leider scheint Stefan gerade zu beschäftigt zu sein. Er hat sich diesbezüglich bei mir noch nicht gemeldet. Ich hatte ihm ja eigentlich auch meine fachliche Hilfe beim Debuggen angeboten...

Gruß

Michael

Hallo Michael, wie ich aus deinem Beitrag im Bugtracker gelesen habe, kennst du dich mit C++ aus.

Auf diesem Gebiet bin ich leider nicht sehr bewandert, allerdings habe ich mich sehr intensiv mit dem DMX4All Protokoll auseinander gesetzt und bin in Sachen Elektronik recht fit.

Wenn ich also noch irgendwie zur Lösung des Problems beitragen kann, sagt bescheid.

Grüße
Daniel

Hallo Daniel,

vielen Dank für Dein Angebot. Ja es würde mir (und vielleicht auch Stefan - hallo ) ziemlich helfen, wenn Du mal nachvollziehen könntest, ob dieses Verhalten tatsächlich nur mit dem DMX4ALL Treiber (also nicht mit z.B. ArtNet) auftritt und sich genau so auswirkt wie ich beschrieben habe (auch mit der Weiterleitung der Fehler an die EasyView-Darstellung).

Dann kann ich wenigstens sicher sein, dass es nicht an meinem Rechner oder meiner speziellen Konfiguration liegt.

Vielleicht kann auch mal noch jemand anderes mit zwei Interfaces (Arne?) überprüfen, ob das wirklich nur beim DMX4ALL passiert...

Hast Du noch eine alte Version von DMXControl? Vielleicht sogar mit einer älteren Version des DMX4ALL-Treibers? Verhält es sich da genauso?

Merkwürdig ist nämlich, dass das Verhalten bisher niemandem aufgefallen ist. So selten tritt das ja nicht auf (oder fadet sonst niemand von Hand?)...

Welches Interface hast Du denn genau? Ich habe das Mini.

Gruß

Michael

hi,
habe das Problem auch.
gibt es jetzt eine Lösung?

???

hey hab genau das gleiche prob...

is echt mies wenn die fader zucken!

Lieber Markus,

das sehe ich so langsam auch so. So wie Du Dich anhörst kannst Du mir vielleicht auch eines besorgen. Hab nämlich keine Zeit zum Selberlöten...

Andererseits finde ich es ein wenig merkwürdig, dass Stefan seit meinem Bugreport nicht ein Wort zu dem Thema gesagt hat.

Ich bin immer noch der Ansicht, dass es an der DLL in DMXControl liegt und nicht am Treiber des Interfaces. Mit anderen Programmen hatte ich keine Fehler.

Stefan: könntest Du wenigstens mal so grob über die Parameterübergabe an Subroutinen (insbesondere DLL-Aufrufe), die Felderdimensionierungen sowie eventuelle dynamische Speicherreservierungen in der DMX4All.out.dll schauen, um simple Fehler Deinerseits auszuschließen und uns dann eine Rückmeldung geben? Nochmals: ich wäre selber dazu auch gerne bereit, wenn ich den Sourcecode bekomme - unterschreibe auch sämtliche NDAs .

Kommentier doch einfach mal alle Aufrufe des eigentlichen Treibers (COM-Interface-Kommunikation) aus und teste es dann ohne Interface. Möglicherweise kannst Du den Fehler so schon ohne Interface reproduzieren (ist ja dann in EasyView sichtbar).

Nochmals: Der Fehler fällt einem im Betrieb nicht unbedingt auf. Wenn man alles automatisch (automatische "Submaster A<>B"-Fades oder Szenenwechsel mit FadeIn-Zeit) faden lässt, konnte ich das bisher nicht
beobachten. Nur bei manueller Bewegug der Fader mit der Maus oder per Midi (DMXIn konnte ich nicht testen) egal ob langsam oder schnell gibt es Probleme, die laut DanielC eindeutig auch über die serielle Schnitstelle so versandt werden, also schon vor dem USB-Treiber und der Interface Firmware falsch sind. Auch in EasyView sind die sichtbar nur erstaunlicherweise in der Kanalübersicht nicht...

Das Problem lässt sich schon im normalen 2.9 Demoprojekt durch Aufziehen der ersten 4 Submaster und anschließendes Faden des Grandmasters reproduzieren...

Ich habe heute Nacht nochmals lange herumprobiert und hab die DMX4All.out.dll von der 2.8 in die 2.9 eingebaut, alles deinstalliert und die reine 2.8 installiert, eine komplette Neuinstallation der 2.9 gemacht und auch an den Parametern der DLL (DMXIn ein/aus, Anzahl der Kanäle maximal/minimal, Zeit verändert) geschraubt -> hat alles nichts gebracht...

Hat jemand noch ältere Versionen? Hat jemand ältere Treiber für das DMX4All?

Kann jemand bestätigen, dass es früher dieses Fehlverhalten auf jeden Fall nicht gab? Oder hatte sich schon jeder damit abgefunden, dass es am "billigen" Interface und dessen "schlechten" Treiber liegt?

Der Einsatz an Weihnachten kommt immer näher und ich kann immer noch nicht vernünftig faden...

Bitte, bitte....

Gruß

Michael

Hallo Stefan,

Quote

Soo, mal sehen ob ich die ganze DMX4All-Geschichte etwas entwirren kann...

vielen Dank, dass Du dich unseres Problems angenommen hast. Leider hatte ich am Wochenende keine Zeit zu antworten...

Quote

Das DMX4All-Ausgabeplugin gibt es andererseits auch schon seit Anbeginn von DMXC, und diese Probleme sind erst in letzter Zeit aufgetaucht.

Die Frage ist halt auch, ob das Problem mit einer alten DMXControl-Version auftreten würde und es nur bisher keiner bemerkt hat, weil die, die das Interface verwendet haben, nie den Grandmaster zum Faden genommen haben oder sonst halt einfach ohne sich zu melden, das Programm als nicht gut funktionierend beiseite gelegt haben...

Vielleicht kannst Du mir mal eine Version vor einer eventuell kritischen Umstellung der Ansteuerung zuschicken?

Quote

Darauf hin haben wir uns auch ein MiniDMX von DMX4All schicken lassen, womit sich das Problem des "nicht sauber fadens" nachstellen lies. Der Mailkontakt mit Markus Siwek von DMX4All hat ergeben, dass es in der neuesten Firmwareversion dieses Interfaces einen Bug gab/gibt, der zu diesem Fehlverhalten führt. Er bot uns an, das Interface zurückzuschicken und neu flashen zu lassen. In wie weit er das Problem öffentlich gemacht hat weiß ich nicht.

Kannst Du da genaueres über den Bug sagen? Ich verstehe da noch nicht so ganz, wie ein Bug in der Firmware des Interfaces sich rückwärts auf das Programm auswirken kann...

Quote

Das Ausgabeplugin ist eigentlich ganz primitiv - dynamische Speicheranforderungen und DLL-Aufrufe gibt es gar nicht. Das Ausgabeplugin benutzt nur das MS CommControl, um die nötigen Daten an den (evtl. virtuellen) Comport auszugeben. Daran hat sich in letzter Zeit auch nichts geändert, so dass es schon komisch wäre wenn da plötzlich ein Fehler auftritt.
Noch als Beispiel für die Primitivität:
Die SetChannel-Methode des Plugins sieht (ohne Kommentare) so aus:

Code

If OutputEnable Then
  LastRecv = ""
  frmMain.comMain.Output = Chr(255) & Chr((channel - 1 And &HFF)) & Chr(((channel - 1 And &H7F00) \ &H100)) & Chr(1) & Chr(value) & Chr(0)
  SetChannel = True
 End If

That's it!

OK. Das sehe ich ein, dass da nicht viel passieren kann . Ich dachte halt, Du übergibst da alle Werte des Universums an das Plugin, vergleichst mit vorigen Werten und schickst dann nur die Änderungen über die serielle Schnittstelle. Das hätte einiges an möglichen Fehlerquellen beinhaltet...

Quote

Um die einzelnen Tools/Fenster voneinander zu entkoppeln, nutzt DMXC Windows-Messages, die an die jeweiligen Message-Queues gepostet werden. Wenn jetzt aus irgendwelchen Gründen Nachrichten verloren gehen, dann meist nur in dem entsprechenden Tool - so sind z.B. Kanalübersicht und Ausgabeplugins getrennt. Da aber alle Ausgabeplugins von einem Fenster verwaltet werden und bei Updates sequentiell aufgerufen werden, erklärt das warum das Problem auch im Visualizer zu beobachten ist.

OK, das verstehe ich. Nur ist mir nicht ganz klar, wie Nachrichten verloren gehen sollten. Soweit mir bekannt ist die Windows-Messagequeue doch einfach ein FIFO-Puffer in den die Nachrichten reingeschrieben werden und dann in der selben Reihenfolge auch wieder ausgelesen werden...

Quote

Also eines der allerersten DMX4All-Interfaces (das, wegen dem DMXC entstanden ist ;)) funktioniert heute noch einwandfrei, und auch Arnes V3-Interface zeigt wohl keine Probleme.

Wurde das auch genau wie von mir beschrieben getestet? Also Demo Projekt laden mindestens 4 Submaster aufdrehen und Grandmaster langsam oder schnell auf und ab bewegen...

Quote

Du schreibst ja, dass die Kanäle nicht mehr synchron gefaded werden, oder? Am Ende des Fades bzw. kurz danach werden dann aber alle Werte korrekt gesetzt, oder? So äußert sich nämlich der V4-Bug, den unser Test-Interface hat.

Ne, leider eben nicht. In vielen Fällen wird's richtig, wenn ich die Maustaste nach dem Verschieben loslasse. Aber manchmal bleiben die Werte auch stehen, d.h. der Grandmaster ist definitiv auf 0 und trotzdem sind noch einzelne Kanäle an...

Insbesondere bei der Midisteuerung gibt es dieses Problem häufig.

Nachdem es bei der Automatiksteuerung (Submaster A-B-Fades, Szenenwechsel) wohl nie passiert (noch nicht 100%ig getestet) ist die Frage: Was ist anders bei der manuellen Erzeugung der Werte (Maus, Midi) im Vergleich zur automatischen?

Und tritt das nur mit dem DMX4All-Interface (z.B. weil das doch zu langsam die Daten entgegennimmt) auf, oder kann das auch mit anderen Interfaces bei mehr offenen Kanälen und "Handsteuerung" auftreten?

Wer steuert denn überhaupt manuell (bzw. über Midi) und macht nicht alles über Szenen und Effekte?

Gruß

Michael

Quote

Sorry, aber das älteste Setup das ich noch habe ist die ursprüngliche 2.8 (Download)...

Die 2.8 habe ich ja schon ausprobiert. Da passiert das auch...

Quote

So richtig wird DMXC davon ja scheinbar nicht beeinflusst, sondern nur die nach dem DMX4All-Aufgerufenen Ausgabeplugins. Die anderen Werte in DMXC stimmen ja, oder nicht?

Ja, in der Kanalübersicht ist alles OK...

Ich habe mit Herrn Siwek kommuniziert und er meinte der Bug sei nur in den DMX4ALL Mini-USB-DMX-Interfaces MK2 mit den Softwarestand V1.00 vorhanden. Soweit ich mich erinnern kann, hab ich aber eine andere Firmware drauf (muss heute abend noch mal nachschauen).

Quote

Vll. gehen sie auch nicht verloren, sondern werden halt erst abgearbeitet, wenn das DMX4All-Interface irgendwann mal mit dem gesendeten Datenstrom durch ist. Das würde erklären, warum die Werte zum Schluss oft richtig sind.

Ne, dass die am Schluss oft richtig sind liegt wohl nur daran, dass irgendwie schnelle Faderbewegungen mit der Maus von Windows nicht alle registriert werden und wohl erst beim Loslassen der Maustaste die letzte Position korrekt übertragen wird.

Außerdem fadet der Kanal oft zunächst schon runter macht dann aber plötzliche Sprünge auf scheinbar völlig zufällige Werte.

Und wie schon gesagt, das Problem tritt auch beim ganz langsamen Faden per Midifernbedienung auf. Daher kann es meiner Meinung nach kein Timingprobem vom Interface sein. Es sei denn die Midievents kommen irgendwie mit den Kanalwertevents in Konflikt.

Meine Frage ist wirklich, ob das Problem nur mit dem DMX4All-Interface auftritt. Was soll denn an dem so anders sein?

Ah - dabei fällt mir gerade noch ein, dass ich den neuesten USB-Treiber für das Interface nicht verwenden konnte, damit blieb mein Rechner immer stehen. Also hab ich den zuvor schon auf einem anderen Rechner installierten Treiber wieder verwendet. Damit läuft das Interface ja grundsätzlich auch...

Um zu testen, ob bei zu langsamer Ausgabe die Fehler auftreten, könntest Du ja mal ein Ausgabeplugin schreiben, dass nur ein paar Millisekunden wartet (am besten aktiv, also per Rechenschleife und nicht über "Sleep") und dann sehen, ob mit dem dieselben Probleme auftreten. Aber andere Interfaces basieren doch auch auf langsamer Übertragung über einen seriellen Port...

Oder Du gibst mal vor und nach den eigentlichen Übertragungen (Aufrufe des MS CommControl in der DMX4All.out.dll) die exakte Systemzeit (millisekundengenau) in eine Datei (dann könnte ich's auch testen) oder den Debugger aus.

Ich würde ja auch versuchen ein eigenes Ausgabeplugin zu schreiben, das die DMX4All.dll nutzt, müsste mich da aber erst in COM einarbeiten, da die Ausgabeplugins ja keine normalen DLLs sondern COM-Objekte sind...

Welche Methoden muss ein COM-Objekt in einem Ausgabeplugin denn alle bereitstellen? Sind das nur (in C-Notation):
bool Configure()
bool Disable()
bool Enable()
bool Term()
char *PluginName()
bool Init(char *CallingAppTitle, char *MyFileName, was_auch_immer_fuer_ein_objekttyp *PluginHelper)
bool SetChannel(long Channel, long Value)
?
Was mach ich mit dem PluginHelper, wenn ich kein DMXIn habe?

Sind meine Rechner vielleicht zu langsam? Ich hab einen P4 2,66 GHz (533Mhz Frontside) in meinem Tower und einen Centrino Pentium M 770 in meinem Notebook...

Und warum funktioniert alles mit anderen DMX-Programmen nur mit DMXControl nicht?

Gruß

Michael