Posts by av@dmx

Hallo Arne,

ich war beruflich unterwegs; jetzt noch meine Bitte, mir die Codebeispiele verfügbar zu machen. Die Alternative erscheint mir für dir Praxis und zum Sammeln von Erfahrungen sehr intressant.

Viele Grüße,

Lothar.

Hallo Arne,

ich programmiere in Delphi (Embarcadero Rad Studio, mittletweile Tokio 10.2)). Vor wenigen Jahren hatte ich zunächst mit Delphi 7.1 ein Testprogramm für DMX-Steuerung mit dem Nodle Interface version 1.00 und DE-Interface Version 1.1 erfolgreich durchgeführt. Bei der DE-Doku waren die damals implementierten Funktionen inklusive der notwendigen Objekt-Pascal Deklarationsvorschläge kurz dargestellt; allerdings auch dort nur dies und ohne Beschreibung der Funktionen. Die meisten sind selbsterklärend und einen Teil habe ich durch "Trial and Error" eingegrenzt. Bei den Funktionen "Un/Register xxxx ChangeNotification" Routinen bin ich nicht sehr weit gekommen; iinsbesonder, weil ich nur ein Interface hatte und dann machten alle mit xxxx= Interface... keinen Sinn und ich bekam keinen Sinn in die Varianten mit xxxx=InputBlock..., weil ich bei RegisterInputBlockNotification keine Reaktionen beobachten konnte. Möglicherweisae kommt das erst zum Tragen, falls man den Channelcount des Senders auf einen Wert kleiner 512 einstellt. Somit blieb bei mir von diesen Funktionen nur RegisterInputChangeNotification, die Sinn ergab, da sie mir mitteilte, wann Daten am Eingang empfangen wurden. Die Wirkung der Funktion UnregisterInpitChangeNatification blieb mir allerdings verborgen .

Beim Blick in die aktuelle Nodle_USB.dll war bei allen Un/Register... Funktionen aufgefallen, dass jeweils eine ...Serial-Version hinzugekommen ist; ich kann nur vermuten, dass dort Notifications Interface-bezogen (auf der Basis der Seriennummern) ausgetauscht werden. Desweiteren sind die Funktionen GetDeviceTyp und GetInterfaceConfig hinzugekommen; diese sind im Prinzip selbsterklärend, wenn die Syntax der jeweils ausgetauschten Variablen bekant ist, um die Funktionen richtig zu formulieren, und wie die Werte zu interpretieren sind, Bei den Funtionen Set/StoretInterfaceAdvTxConfig waren damals in der DE-Inteface-Doku dazu Angaben gemacht.

Ich baue gerade weitere Nodle_U1-Interfaces zusammen, werde alles aktuell flashen (V1.04), die aktuelle Nodle_USB.dll verwenden und möchte natürlich möglichst dann alle Funktionen korrekt nutzen. Inwieweit ich meine Sofware ausschließlich zum Testen nutze oder auch einmal eine etwas einfache "Lichtsteuerungssoftware" für mich programmiere, lass ich noch offen. Ich gehe einmal davon aus, dass ich im Normalfall mit DMXC 2/3. steuern werde. Meine eigene Programmierung dient zum Einen meinem Verständnis der Abläufe und es fällt dabei auf jeden Fall ein Service-Tool ab, um einzelnen versteckten Problemen auf die Spur kommen zu können.

Ein kleiner Wunsch zur Hardware: Ich fände es sehr wertvoll, das Interface mit einem Taster aufzurüsten, der über einen hoffentlich noch nutzbaren Eingang am Prozesseor bewirkt, dass das Interface, wenn der Taster beim Anlegen einer Betriebsspannung (über die USB-Buchse) gedrückt ist, das Interface in den Mode 1 DMC In -> DMX Out (Repeater-Mode) geht. Dann ist das Interface immer schnell auch als Repeater einsetzbar, ohne dass dies erst durch Anschliessen eines Rechners durchgeführt werden muss. Wenn ein solcher Eingang nach verfügbar ist, wäre diese Funktion mit einem Firmware-Update vermutlich ohne großen Aufwand realisierbar.

Gruß Lothar.

Ich habe gesehen, dass die entsprechenden DLL's bei den Programmen DMXC 2 und DMXC 3 auch zur Verfügung gestellt werden und die eine (ältere) Variante in der nodle-U1-zip-Datei noch unkommentiert enthalten ist. Es wäre vielleicht sinnvoll, diese dort zu entfernen.

Ich wäre glücklich, wenn es zu der Nodle_USB.dll eine Dokumentation der Schnittstelle zum aufrufenden Prgramm gäbe. In der Binärdatei findet man zwar verfügbare Funktionsaufrufe, nur reicht das nicht, um von einem eigenen Programm mit dem Interface sinnvoll zu kommunizieren. Ich bräuchte also dringend eine entsprechende Dokumentation oder einen Hinweis auf einen Standard, in dem ich dies nachlesen kann, falls es wirklich dazu einen Standard gibt und dieser in der DLL konform realisiert wurde. Auch für einen eigenen "Wrapper" für eine selbst definierte Schnittstelle wäre es nötig, da der Zugang zum Inteface praktisch nur über die Nodle_USB.dll möglich ist. Kann mir dazu jemand etwas mitteilen?

Beim Messen der Signale auf dem DE-Interface-Board fiel mir auf, dass die Signalqualität am Ausgang des Optokopplers für den DMX-Out-Kanal deutlich besser ausfällt als für den DMX-In-Kanal. Fügt man am Ausgang des Ausgang des Optokopplers für den DMX-In-Kanal einen Pull-Up-Widerstand von 10k gegen Vcc ein, wird die Qualität signifikant besser (höhere Flankensteilheit). In der Funktion hatte es sich zwar nicht ausgewirkt, aber besser ist eben besser.

Frohe Ostern, av@dmx.

Ich bin leider im Schreiben von Forenbeiträgen unerfahren und hatte meine neuen Erkenntnisse im ersten Beitrag durch "Bearbeiten" ergänzt. Leider wird im Forum nicht angeezeigt, dass der Beitrag aktualisiert wurde. Ich hoffe, durch diese Antwort den Hinweis zu geben.

av@dmx

Ich habe das DE-Interface auf mehreren Rechnern (XP, 7, 32 und 64 bit) gemeinsam mit der Software DMXControl in Betrieb genommen. Bei allen funktioniert es und wird nur auf einem Rechner in der DropDown-Liste der angeschlossenen Interfaces 3-fach mit derselben Seriennummer angezeigt; auf alllen anderen Rechner korrekterweise nur einfacch.

Ich vermute eine Hardware-Abhängigkeit, da ich auf dem besagten Desktop-Rechner das Betriebssystem (XP in der identischen Aktualität wie auf einem korrekt arbeitendem Laptop) zweifach auf unterschiedlichen Partitionen installiert habe: einmal die Arbeitsumgebung und eine zweite Variante in einer Minimalinstallation, um möglichst wenige Störeinflüsse durch Fremdsoftware zu bekommen. In beiden Fällen wird das Interface dreifach angezeigt. Parallel habe ich die Meldungen für das Nodle U1 Inteface geprüft; dort wird auf dem besagten Rechner korrekt einfach angezeigt. Obwohl beide Interfaces ähnlich konzipiert sind und behandelt werden, besteht hier offenkundig ein wesentlicher Unterschied.

Kann mir jemand einen Tip geben, wie das Fehlverhalten zu beseitigen ist? Liegt ggfs. auch noch ein Bug in der DLL vor?

Für Hinweise schon vorab herzlichen Dank,

av@dmx.

In der Object-Pascal-Umgebung "Delphi" habe ich unter Einbindung der Liblrary usbdmx.dll das DE-Interface erfolgreich in Betrieb genommen. Die Daten von "DMX-In" lese ich dabei in einem festen Zeitraster aus. Dieses "Polling" ist allerdings ineffizient, da meistens keine Änderungen stattfinden. Um ereignisgesteuert zu reagieren, wurden in der DLL beispielsweise die Funktionen RegisterInputChangeNotification und UnregisterInputChangeNotification vorgesehen. Die Funktion RegisterInputChangeNotification beinhaltet den Parameter vom Typ THOSTINPUTCHANGEPROC. Ich vermute, das Proc der Bezeichner einer Routine im eigenen Programm ist, das aufgerufen werden soll, sobald eine Änderung der Eingabedaten erfolgte.

Leider kenne ich mich auf dieser Ebene in Delphi nicht so gut aus, um die nötigen hierfür zu erzeugen. Es wäre für mich sehr hielfreich, wenn jemand einen kurzen Ausschnitt mit den Programmzeilen zur Verfügung stellen könnte, aus denen dies ersichtlich ist.

Vielen Dank im Voraus,

av@dmx.

Ich habe weiter gesucht und getestet. Für RegisterdeviceChangeNotification und RegisterInputChangeotification habe ich eine funktionierende Lösung gefunden; sie ist wie folgt (Beispiel: RegisterInputChangeNotification):

util main:
interfaces
type
PDMXArray = ^TDMXArray;
TDMXArray = array[0..511] of byte;
TSERIAL = array[0..15] of Char;
TSERIALLIST = array[0..31] of TSERIAL;
THOSTDEVICECHANGEPROC = procedure; stdcall;
THOSTINPUTCHANGEPROC = procedure; stdcall;
THOSTINPUTCHANGEPROCBLOCK = procedure(blocknumber: byte); stdcall;
...
function RegisterInputChangeNotification(Proc: THOSTDEVICECHANGEPROC): DWORD;
stdcall external 'usbdmx.dll';
...
implementation
{$R *.dfm}
procedure InputChangeNotification;
begin
... kurze Zuweisungen
end;

procedure Form1.ScanButtonClick(Sender: TObject);
begin
...
RegisterInputChangeNotification(@InputChangeNotification)
...
end;

Möglicherweise ist dies nicht der korrekte Weg, da die äquivalente Vorgehensweise für RegisterInputChangeBlockNotificatioen zum Absturz führt:

util main;
interfaces
type
PDMXArray = ^TDMXArray;
TDMXArray = array[0..511] of byte;
TSERIAL = array[0..15] of Char;
TSERIALLIST = array[0..31] of TSERIAL;
THOSTDEVICECHANGEPROC = procedure; stdcall;
THOSTINPUTCHANGEPROC = procedure; stdcall;
THOSTINPUTCHANGEPROCBLOCK = procedure(blocknumber: byte); stdcall;
...
function RegisterInputChangeBlockNotification(Proc: THOSTINPUTCHANGEPROCBLOCK):
DWORD; stdcall external 'usbdmx.dll';
...
implementation
{$R *.dfm}
procedure InputChangeBlockNotification(Block : Byte);
begin
Edit1.Caption := IntToStr(Block);
end;

procedure Form1.ScanBlockButtonClick(Sender: TObject);
begin
...
RegisterInputChangeBlockNotification(@InputChangeBlockNotification);
...
end;
...
end.

Das Programm läuft zunächst fehlerfrei. Sobald über DMX-In eine Veränderung eintrifft, wird offenbar die Procedur InputChangeBlockNotification(Block : Byte) aufgerufen (es erscheint in label1 die Nummer des 32bit-Blocks, in dem eine Änderung erfolgte; z.B. die "1", wenn Kanal 38 sich änderte, bzw. "0" bei Kanal 5) und nach zwei bis drei Sekunden erscheint die folgende Meldung in der Entwicklungsumgebung "Im Projekt ... sind zu viele aufeinander folgende Exceptions aufgetreten". Beim Aufruf der ausführbaren Datei erfolgt nach sehr viel kürzerer Zeit ein schlichter Absturz.

Was läuft hier falsch und wie kann ich es korrigieren?

Vielen Dank im Voraus für eine Lösung,

av@dmx.