DLL's

Die Nodle_USB.dll ist eine allgemeine in C geschriebene DLL, welche die Windows USB API anspricht, also die gesamte USB Kommunikation übernimmt. Die DMXControlProjectsNodleUSB.out.dll ist eine "Wrapper" DLL, welche die Schnittstelle an die von DMXControl erwartete Schnittstelle für DMX Plugins angleicht. Für mehr Details wie eine Schnittstelle A an eine Schnittstelle B angepasst werden kann, siehe hier: https://de.wikipedia.org/wiki/Adapter_(Entwurfsmuster)

Das Ausgabeplugin in dem Archiv ist übrigens für DMXC 2 und nicht für DMXC 3.

Sowohl DMXC 2 als auch 3 bringen aber die Nodle_USB.dll und ein passendes Ausgabeplugin schon mit.

Stefan

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?

av@dmx

Kurze Gegenfrage: In welcher Programmiersprache möchtest du dein Programm schreiben? Wenn du es in C# oder einer anderen .Net Sprache schreibst würde ich dir empfehlen einfach das DMXControl 3 Plugin mit dem Wrapper zu verwenden. Wir haben absichtlich die ganze API der DMX Interfaces in eine gemeinsame DLL ("DMXLIB.dll") ausgelagert, sodass alle DMXC 3 Interface Plugins auch einfach durch andere Programme verwendet werden können.

Der zentrale Vorteil für dich liegt auf der Hand:

1. Du brauchst dich nicht mit Unmanaged Calls rumschlagen

2. Du kannst 1:1 alle DMXC 3 Interfaces unterstützen.

Falls das interessant ist, kann ich dir ein Code Beispiel schicken, wie du mit wenigen Zeilen Code DMX Werte aus dem Nodle raus bekommst.

Gruß Arne

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.

Quote from av@dmx

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.

Ein Repeater-Modus ist schon integriert. Er funktioniert allerdings nach einem leicht anderen Prinzip. Dazu musst du nur den entsprechenden Jumper stecken und sobald das Interface Strom aber keine Datenverbindung erhält, geht es nach 10 Sekunden in den Repeater-Modus. Wie das genau funktioniert, kannst du in unserer News dazu von Anfang März nachlesen: Vereinsnews - 18_KW09 - Pimp-my-Nodle / Nodle-Firmware 1.04

Viele Grüße

JP

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.

Das Beispiel ist mal Anhand des Nodle Treibers. Alle anderen Treiber funktionieren Identisch, es müssen evtl. andere Parameter gesetzt werden. Ich gehe davon aus, dass du in dein C# Projekt die DMXControlProjectsEVNodleU.dll als Referenz eingebunden hast. Das Beispiel funktioniert, aber in produktiven Code sollte man einige Dinge die hier Hard Gecoded sind dem User als Konfiguration anbieten.

var f = new NodleUsbInterfaceFactroy();
f.initialize();

//Interface suchen, erstes Interface anlegen
var nodle = f.CreateInterface(f.Interfaces.First());
nodle.initialize();

//Input Port und Output Port einschalten, Interface selber einschalten
nodle.SetInputState(0, true);
nodle.SetOutputState(0, true);
nodle.Enabled = true;

//Interface Mode auf 6 stellen
var para = nodle.Parameters.FirstOrDefault(c => c.Name == "Set Interface Mode");
nodle.SetParameter(para.Name, para.EnumValues.ElementAt(6)));

//Nun sind wir fertig und können Senden
byte[] dmxData = new byte[512];

//dmxData irgendwie mit Daten Füllen
nodle.SendDMX(0, 0, dmxData);

//Wenn Programm beendet werden soll:
nodle.Dispose();