Posts by Ponk
-
-
Hallo steff. Ich danke dir für deinen Hinweis.
Deinen Lösungsansatz habe ich auch schon entdeckt gehabt, und das funktioniert auch. Allerdings ist es ein unschöner WorkAround, da ich erst alle Effekte auf Buttons verknüpfen muss um damit dann über Midi das ganze sauber steuern zu können. Es funktioniert - Ja,... ist aber leicht unschön.
Eventuell hat noch jemand einen anderen Lösungsansatz oder Idee, oder kann mir erklären, dass es eben so ist, aber eigentlich ein Bug ist, der wohl nimmer gefixt wird :-(.
Und Ja, ich steuer mit Midi die Effekte an, was dann an WebInterfaces weitergereicht wird, damit ich das ganze über den Browser, Tablet etc. steuern kann. Das funzt alles supi ... aber das unangenehme dabei: Wenn ich die Rückmeldung von DMX-Control erhalte, dass der Effekt läuft, bekommt mein Button im Browser auch den 'gedrückten zustand'...aber muss ich teils 1mal / teils eben zweimal auf den Button im Browser klicken..., denn über Midi erhalte ich nur "Effekt läuft", aber eben nicht, "worüber wurde der Effekt gestartet" bzw. resp. "wie oft" ich auf den einzelnen EffektButton klicken muss, damit der Effekt stoppt. Da ist mir nämlich das ganze erst so richtig aufgefallen, und konnte es eben auf das in meinem ersten Post beschriebene Problem runterbrechen, damit's leichter verständlich wird.
-
Hallöchen,
beim Arbeiten mit DMX-Control 2.12.2 ist mir folgendes Problem aufgefallen, an dem ich mir die Zähne ausbeiße:1) Zuerst die Fakten:
- benutzte DMX-C Version: 2.12.2 ; Betriebssystem: WinXP / Win7
- ich habe einen einzigen Effekt im Effektsequenzer angelegt (mit ein paar Steps)
- Dieser Effekt wurde einem KommandoButton in der Kommandobox zugewiesen mit den Eigenschaften:- Modul: Effekte
- Gerät/Funktion: '<der eine Effekt s.o.>'
- Kanal: Start / Stop
- Flags: 'T'
2) Und nun mein Problem:- Starte ich den Effekt durch Drücken des KommandoButtons, so startet der Effekt, der KommandoButton erscheint als "gedrückt", im EffektSequenzer wird dieser Effekt 'fett' markiert und die einzelnen Steps laufen nacheinander durch -> wunderbar so ist das toll
- Drücke ich den Button erneut, dann hört der Effekt auf, der Button erscheint nicht mehr niedergedrückt und im Effektsequenzer ist der Effekt ebenfalls nicht mehr 'fett' mariert -> Super. Alles tippitoppi
- Starte ich den gleichen Effekt über den EffektSequenzer, dann erhalte ich das exakt gleiche Verhalten wie im ersten Schritt (KommandoButton erscheint als niedergedrückt...) -> Wunderbar. Klappt ausgezeichnet
---> ABER - JETZT WEIß ICH NICHT MEHR WEITER:
Der KommandoButton in der KommandoBox erscheint nach Schritt 3 als niedergedrückt, was den laufenden Effekt signalisiert. SEHR GUT: Wenn ich aber diesen nun drücke hätte ich erwartet, dass dieser den laufenden Effekt ausschaltet. Was er aber nicht macht! Warum? Ich muss ihn erst erneut drücken! Warum?
3) Zusammenfassung: Starte ich einen Effekt über den EffektSequenzer muss ich in der Kommandobox einen eventuell verknüpften Button zweimal drücken, um den Effekt zu stoppen. Starte ich hingegen den Effekt über den KommandoBox-Button brauch ich nur einmal zu Drücken, um den Effekt zu stoppen.
Kann mir da bitte einer erklären / helfen, wie dieses zweimal Drücken umgehe, falls der Effekt über den Effektsequenzer gestartet wird? Ich komme einfach nicht weiter.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -4) zum Hintergrund:
Ich habe ein größeres Programm und Setup, bei dem ich viele verschiedene EinzelEffekte programmiert habe: z.B. ein Programm, welches MovingHead 1 rotieren lässt (nennen wir es MH1), eins für Moving Head 2 MH2, eins für MH3 usw. Und dann habe ich im EffektSequenzer z.B. ein weiteres Programm (nennen wir es Y), welches diese EinzelProgramme gruppiert startet (dieses Programm besteht nur aus den 3 EinzelBefehlen 'Starte MH1, Starte MH2 und Starte MH3'). Das funktioniert auch alles an sich total super. In der Kommandobox habe ich nun insgesamt 4 Buttons, auf die ersten 3 habe ich jeweils den Einzeleffekt gelegt: Button1 startet und stoppt Effekt MH1, Button2 kümmert sich um Effekt MH2 und Button3 um MH3. Der 4. Button startet den Effekt Y wodurch MH1-MH3 indirekt gestartet wird (und die 3 ersten Buttons in der Kommandobox als 'niedergedrückt' erscheinen). Möchte ich nun z.B. mittels Button2 den Effekt MH2 stoppen, muss ich den Button2 zweimal klicken.... Starte ich die 3 Einzelprogramme über die Buttons 1-3 jeweils einzeln, muss ich z.B. Button2 nur einmal Drücken, um Effekt MH2 zu stoppen. Und das ist Mist.
Damit könnte man evtl. noch leben. Jetzt geht's aber weiter, wo das Ganze sehr unangenehm und somit nicht mehr beherrschbar wird: Das ganze steuere ich über's Midi Interface an. Funktioniert prinzipiell super. Ich habe 3 Midi Adressen konfiguriert, welche jeweils Effekt MH1, MH2 und MH3 starten. Wunderbar! Nun noch die 4. MidiAdresse, welchen Effekt Y startet. Funktioniert auch super. ABER: Hier das Gleiche: Starte ich über MidiAdresse 4 (indirekt) die Effekte MH1-MH3, MUSS ICH IMMER zwangsläufig z.B. Adresse 2 zweimal schicken, um Effekt MH2 zu stoppen (Starte ich hingegen MH2 über Midi-Adresse 2, brauch ich auch nur einmal den Midi-Befehl 'Adresse2' hinzuschicken, um Effekt MH2 zu stoppen).
Vielleicht kann mir da jemand Licht ins Dunkel bringen. Vielen Dank
-
Was erhälst du für eine Rückmeldung, wenn du versuchst die DLL zu registrieren (mit dem Tool, bzw. mit regasm)?? Hast du es schon im Admin-Modus versucht?
-
Wunderbar! Das freut mich zu hören!
Danke ebenso fürs Aktualisieren
-
Hi!
SO, nun habe ich glücklicherweise doch noch Zeit gefunden, um alle Wege der Bits und Bytes zu kontrollieren. Und was soll ich sagen? Irgendwo steckt(e) da ein Bug! Ich schätze ihn nicht als leicht oder schwer zu finden ein,... sondern mittlerweile als 'unverschämt', da er nicht offensichtlich war/ist!!!
Das ist aber auch nicht weiter schlimm, denn in einem solchen Fall hilft nur Eines: "Tabula Rasa" : Algorithmus wegschmeißen und neu schreiben.
Kurzum: Ich habe die SendeMethode neu arrangiert, sodass nun die Verzögerung beseitigt sein sollte. Ich habe die Bisherige und neue DLL direkt gegenübergestellt, und mit meinen DMX-Geräten getestet-> bei der Neuen DLL traten keinerlei Verzögerungen mehr auf (auch nicht bei sehr hohen DMX-Kanälen).
Im Anhang findest du die 'neue' DLL in der Version V1.1
Viel Spaß beim Testen. Ich bin und bleibe auf Deine Testergebnisse gespannt
-
Hi, ich habe mal ein "größeres Setup" aufgebaut, und siehe da - da kommen Pakete tatsächlich verzögert an! Iss'n Ding!
Das Positive dabei: Ich kann den Fehler reproduzieren und dadurch auch Debuggen. Ich hab zwar noch keinen Anhaltspunkt warum das Verhalten auftritt, aber dem kann ich zumindest langsam nach und nach auf die Schliche kommen.
Werde mich auch dransetzen.
Als kurzen WorkAround kann ich die Folgendes Anbieten: Stelle bitte im Konfig-Dialog des Interfaces die maximale Kanalanzahl auf manuell, und gebe dabei die letzte DMX-StartAdresse + KanalAnzahl deines letzten DMX-Gerätes ein. Dann werden nicht alle 512 Kanäle übertragen, sondern eben nur die eingestellte Anzahl (ich hoffe, du hast aktuell nicht alle 512 Adressen im Gebrauch, sonst geht das natürlich nicht.
Bei mir tritt das Verhalten so ab ca. 190 übertragenen Kanälen ein. Meine Geräte gehen aktuell nur bis 160 - daher ist mir das Verhalten nicht aufgefallen. Beim Testen habe ich zwar Kanal 512 ebenso "einzeln" getestet, aber eben keine parallelen Szenen in dieser KanalGrößenOrdnung übertragen, weil ich nicht alle DMX-Geräte bei mir umprogrammieren wollte. ;D
Aber gut. Ich danke dir für die Fehlermeldung, die nun greifbarer ist, und bitte noch um etwas Geduld, damit ich den offensichtlichen Bug beseitigen kann.
-
Guten Morgen
Vielen Dank schon mal für deine Zeit.
Ich muss gestehen, das mit dem einen Schritt bei Pan/tilt habe ich noch nicht getestet. Mache ich später natürlich noch.Ja, prüfe das nochmal bitte. Ich gehe aber davon aus, dass es prinzipiell auch verzögert ist. Falls es für dich möglich ist: Nimm mal einen Rechner / Laptop mit Win7 oder Win XP zum Test. Wie bereits erwähnt habe ich selbst keine Möglichkeit das ganze mit Win10 zu testen.
Das mit dem größeren Programm werde ich heute / morgen mal zum Test benutzen, da es bei mir mit "kleinen" Programmen fehlerfrei funktioniert.
-
Kurze Frage noch:
Muss ich der Szene eine Mindesteinblendzeit geben, damit das Gerät beim Abspielen sofort reagiert? Oder darf die Einblendzeit und Haltezeit = 0 sein? Spielt das eine Rolle?
Also für den Submixer spielt das keine Rolle.
So, nun zu dienen Testergebnissen: OK wunderbar, damit kann ich zumindest ne Menge anfangen. Ich weiss zwar nach wie vor nicht, woran das Verhalten liegen kann, aber ich werde da wohl nochmal ein paar Geräte von mir aufbauen müssen, und ein größeres Programm über das Interface starten.
Eines jedoch noch zum Verständnis: Du hast geschrieben "Nur bei der Pan/Tilt - Bewegung arbeitet der Moving Head sofort. Farben, Gobos usw. erst nach einer Verzögerung." verstehe ich das richtig, dass wenn du den Pan/Tilt Wert im SubMixer um "1" Schritt änderst (auch nach vorheriger 10s Pause) - das Gerät SOFORT reagiert?
-
OK, wunderbar. Hab mal reingeschaut - wichtige Infos dazu habe ich nciht entdecken können.
Also teste mal bitte wie gesagt mein beschriebenes Vorgehen, um in Erfahrung zu bringen, wie die Reaktion beim Ändern eines einzelnen Wertes um "1 Stufe" ist. Stelle dazu testweise mal den DMX-Startkanal des PAR - Scheinwerfers auf "1". Dann im SubMixer den Kanal 4 (Dimmer) auf 255. Dann 10s warten und anschliessend Kanal 5 von 0 auf 1.
-
Versuche es bitte ohne erstellte Szene nur im Submixer.
Für mich ist wichtig, was passiert, wenn sich nach längerer Zeit (in dem Fall nach den 10s) ein einziger DMX-Wert ändert.
Pack & go: Das Problem ist, das ich ohne "Hardware" nicht sehe, was am freeAP ankommt / ankommen soll. Das würde mich aktuell zu viel Zeit kosten, solch ein Setup aufzusetzen.
Du kannst mir aber gerne mal den Typ der betroffenen LED-PAR mitteilen, dann lad ich mir das Manual mal runter, und schlage da mal nach nutzbringenden Infos nach.
-
Oha!
Interessant ist, dass der SubMixer SOFORT reagiert, aber das Abspielen der Szenen nicht.
Um auszuschließen, dass ein Fehler in der DLL ist, versuche bitte noch Einmal Folgendes:
1. Starte den Submixer,
2. fahre alle Slider auf "0",
3. PAR1: Dimmer auf 255 stellen
4. 10s warten!
5. nun den RotKanal von PAR1 von 0 auf 1 stellen=> ist im PAR sofort die schwächste Rotstufe zu sehen, oder reagiert der PAR auf diese "EinWertÄnderung" auch schon verzögert?
P.S. Im Handbuch vom PAR kannst du genau entnehmen, ab welchem DMX-Wert der Rotkanal reagiert. Ich habe hier im Schritt 5 DMX-Wert "1" angenommen.
(Manche Geräte haben aber auch größere Intervalle, z.B. 0-9 = Aus, 10-19 = schwächste Rotstufe usw. - In einem solchem Fall muss im Schritt 5 dann eben von 9 auf 10 gewechselt werden).
Mir geht es hierbei darum, ob beim Verändern EINES EINZIGEN DMX-Wertes das Interface, bzw. das DMX Gerät verzögert reagiert oder nicht -
Hi,
das ist aber alles sehr merkwürdig.
Nochmal zum Verständnis: Über die Kanalsteuerung reagiert alles sofort, nur beim Abspielen von Szenen / Programmen nicht??
Wie schaut es mit dem SubMixer aus? Stoppe dazu mal alle Szenen / laufenden Programme, und bewege dann im Submixer einen Slider eines DMX-Kanals. Reagieren da die Geräte sofort, wenn du einen Slider bewegst... oder zeitverzögert??
-
Hi.
Ok, verstehe. Also explizit habe ich keine Puffer implementiert. Daher gehe ich davon aus, dass Win10 UDP-Pakete "anders" versendet, als Win 7 , bzw. Win XP.
Im Anhang habe ich eine DLL gepackt, bei der explizit die SendePufferGröße als extrem klein deklariert wurde. Bitte teste diese einmal aus (einfaches Kopieren in DMX-C2 Ordner + DMX-C Neutstart reicht aus).
Bin gespannt, ob sich ein anderes Verhalten ergibt.
P.S. Die angefügte DLL habe ich ebenso unter Win7 und Win XP getestet -> sie stellt im Verhalten keinen Unterschied zu der ersten DLL dar.
-
So, ich habe mal ein Setup aufgesetzt, und versucht dein beschriebenes Verhalten nachzustellen. Leider erfolglos. Das Interface reagiert bei mir SOFORT, ohne jegliche Verzögerung. Ich habe es mit einem Win7 Rechner und Win-XP Rechner getestet.
Das ist aber äußerst merkwürdig.
hmm.. Was kann man da tun?! Ich schreibe einfach mal ein paar Punkte auf, die mir spontan einfallen (davon wirst du mit Sicherheit schon einige versucht haben), die man versuchen kann:
- leeres DMX-Control Projekt anlegen, und nur 1 DMX-Geräte darin mit der Startadresse 1 definieren, dann im Submixer testweise ein paar Funktionen des angeschlossenen Devices den Slidern zuweisen, und die Slider bewegen -> reagiert es da schneller, oder genauso langsam? Wichtig: Bewege mal einen Slider nur um einen Schritt, und warte, bis das DMX-Gerät reagiert.... dann bewege den Slider mal sehr schnell hoch und runter.... Hat das schnellere Bewegen Einfluss auf die Reaktionsgeschwindigkeit?
- testweise Firewall und Virenscanner ausschalten
- Welches Betriebssystem benutzt du? Wie gesagt: ich habe das Plugin unter Win7 64bit und Win XP + SP3 erfolgreich getestet
- testweise Sicherstellen ,dass über die Netzwerkkarte keine schnellen Downloads / Uploads erfolgen, evtl. ALLE Netzwerkgeräte des Netzwerksegments bis auf das free AP und den ansteuernden Rechner mal trennen
- falls verfügbar: funktioniert dein Setup mit einem anderen / kabelgebundenen Interface problemlos?
- Hänge dich mit Netztwerktools an die sendende Netzwerkkarte und filtere die Datenpakete an die IP-Adresse des free AP (z.B. mit IP-Tools, EtherDetect, Smartsniff...) -> Sobald du in DMX-C einen Slider im SubMixer bewegst, MUSS darin SOFORT erkennbar sein, dass an die IP vom free AP Datenpakete geschickt werden...
Gruß Sven
-
Hallo Dennis,
ok, Problem hab ich verstanden. Du brauchst vorerst nichts weiter auszuprobieren.
ich kümmer mich darum. Allerdings komme ich erst Ende nächste Woche KW46 dazu, da ich aktuell unterwegs bin.Ich bitte um etwas Geduld
-
Hallo,
an dieser Stelle möchte ich eine alternative DLL für das Velleman Interface K8062, bzw. VM116 und DMX Control 2.12.2 vorstellen. Warum? Ich nutze das Velleman Interface schon seit Jahren mit all seinen Vor,-u. Nachteilen. Der größte Nachteil für mich war die "träge" und teils und abgehackte Kommunikation mit DMX-Control. Jedesmal ist genau beim Aufruf einer Funktion aus der notwendigen Ansteuer-DLL für das Interface DMX Control für einen kurzen Moment blockiert.
Als Folge dessen reagierte DMXC teils angehackt, bzw. wurde die komplette DMX Ausgabe immer wieder ganz kurzzeitig blockiert. Ich hatte DMX-Geräte, die genau das nicht vertragen. Bei steigenden Programm, und GeräteAnzahl in DMX-Control macht sich das nach meiner Erfahrung immer mehr bemerkbar. Das ist kein Fehler von DMXC, sondern vielmehr der Natur der gesamten Architektur geschuldet. Das ist unschön, stört und man kann es optimieren. Daher meine DLL, die diesen nervigen Makel beseitigt. Ich stelle sie hier gern der Community zur Verfügung.
Ich möchte noch einmal anmerken, dass ich hier eine alternative DLL für das Interface anbiete, die die DMX-Ausgabe und die Kommunikation mit DMX-Control optimiert. Die hier bei den "offiziellen" Ausgabeplugins verfügbare DLL funktioniert natürlich ebenso und kann ebenfalls verwendet werden.
Getestet habe ich die DLLs bereits stabil und erfolgreich in der DMX-Control Version 2.12.2 auf einem WinXP (inkl. SP3) und Win7 (64bit) System. Der Speicherbedarf blieb im Betrieb konstant. Abstürze gab es nicht.
Hier die Kurzanleitung zur Installation:
----------------------------------------1. DMXC2 "komplett" installieren (V2.12.2) - Nach Installation Programm NICHT öffnen
2. Microsoft .net Framework 4.0 installieren (falls noch nicht vorhanden)
3. K8062D und K8062e.exe aus den "offiziellen Ausgabeplugins" nach <Programme>\DMXControl kopieren
4. die 2 Dlls ('VellemanUsbDmxK8062_SR.out.dll', 'VellemanUSBDMX.dll') nach <Programme>\DMXControl kopieren
5. die 'VellemanUSBDMX.dll' in Windows mit Regasm.exe registrieren
6. DMXControl starten, und als AusgabePlugin 'VellemanUsbDmxK8062_SR' wählen
7. FertschUnd hier die ausführliche Anleitung:
------------------------------------
0. Kurz zum Hintergrund:
Die ansteuernde DLL 'VellemanUSBDMX.dll' habe ich in C# programmiert. In der DLL arbeite ich threadbasierend, d.h. es erfolgt eine Entkopplung vom Aufruf aus DMX-Control und der Ausgabe der DMX-Werte. Der wesentliche Vorteil dabei ist, wie oben erwähnt, das DMXControl für den Funktionsaufruf der DMX-Ausgabe vom Interface nicht blockiert wird. Kurz gesagt: "Die DMX-Ausgabe, und die Reaktion von DMXC 2.12 geht ab, wie eine V1 ;D"1. Am besten man installiert DMXControl V2.12.2 neu, und mit allen Komponenten. Damit ist ein einheitlicher Ausgangszustand hergestellt.
2. Microsoft.net Framework 4.0 installieren
Ich habe die 'VellemanUSBDMX.dll' in C# programmiert. Daher ist das Microsoft .net Framework notwendig.
Gerade bei Windows XP ist das Framework in dieser Version nicht vorinstalliert (bei Win7 bin ich mir grad auch nicht ganz sicher). Um herauszufinden, ob das Framework in dieser Version bereits installiert ist, nutzt man die Anleitung unter https://msdn.microsoft.com/de-…5568(v=vs.110).aspx#net_a ... ODER ... geht es am schnellsten, wenn man die beigefügte "DLL für Com registrieren.exe" startet. Startet das Programm, dann ist das Framework korrekt installiert, und man muss an dieser Stelle nix weiter machen. Erhält man eine rote Fehlermeldung, bzw. einen Ausnahmefehler beim Starten, dann ist das Framework 4.0 nicht verfügbar. In diesem Falle muss man es nachinstallieren, und lädt sich dazu das offizielle Microsoft Setup von https://www.microsoft.com/de-d…oad/details.aspx?id=17718 runter.3. K8062D.dll und K8062e.exe aus den "offiziellen Ausgabeplugins" nach <Programme>\DMXControl kopieren
Der eigentliche ansteuernde "Treiber" des Interfaces sind die 2 Dateien 'K8062D.dll' und 'K8062e.exe', welche auch hier bei den "offiziellen" Ausgabeplugins verfügbar sind, bzw. glaube ich sind die bei der DMXC Version 2.12.2 sogar schon mit installiert. Man sucht sie sich ggf. hier auf der Plattform und kopiert diese beiden Dateien ins Programm-Verzeichnis von DMX-Control2 (meist 'c:\Programme\DMXControl' oder 'c:\Program Files (x86)\DMXControl'). Meiner Erfahrung nach gibt es ein paar verschiedene Versionen dieser Dateien (leider ohne erkennbare DateiVersionsNummer). Ich nutze erfolgreich die K8062D.dll mit einer Dateigröße von 42496 Bytes und die K8062e.exe mit 343552 Bytes.4. Die 2 DLLs nach DMXControl kopieren
Die 2 hier angebotenen DLLS ('VellemanUsbDmxK8062_SR.out.dll', 'VellemanUSBDMX.dll') ins Programmverzeichnis von DMXC2 kopieren. Meist lautet dies 'c:\Programme\DMXControl' oder 'c:\Program Files (x86)\DMXControl'. Die 'VellemanUsbDmxK8062_SR.out.dll' wird von DMX Control benötigt, um überhaupt zu erkennen, das es mit dem Velleman K8062/VM116 Interface arbeiten soll. Die 'VellemanUSBDMX.dll' erledigt dann die tatsächliche Arbeit, bzw. die Kommunikation mit den Treiberdateien.5. die 'VellemanUSBDMX.dll' in Windows mit Regasm.exe registrieren
Einfach gesagt: Der Schritt ist notwendig, damit aus DMX-Control die Befehle aus der "arbeitenden 'VellemanUSBDMX.dll' erkennt" und auch aufrufen können. Dazu wird das Microsoft Tool Regasm.exe verwendet. Es wird zum .net Framework mit dazugeliefert und wird über die Kommandozeile ausgeführt. Wie das genau funktioniert kann man ergooglen. Schneller geht es, wenn man das von mir beigefügte Tool 'DLL für COM registrieren.exe' benutzt, denn es nimmt einem genau diese Tipparbeit ab. Dazu startet man es und wählt für die Registrierung die 'VellemanUSBDMX.dll' aus dem DMXC ProgrammOrdner aus. Das war's auch schon.6. DMXControl starten, und als AusgabePlugin 'VellemanUsbDmxK8062_SR' wählen
Ein einfacher selbsterklärender Schritt: Man startet DMX-Control, wählt das Plugin 'VellemanUsbDmxK8062_SR' aus und schon kann es losgehen.7. Fertsch
So, nach diesen ganzen Schritten steht der korrekten Funktion theoretisch nichts mehr im Wege.Wie das bei einer Version 1.0 so ist, kann es durchaus sein, dass man "betriebsblind" beim Endtest gewesen ist, etwas fundamental Wichtiges vergessen hat, oder hier und da noch kleine "ProgrammKäferchen" die PluginAusführung "suboptimal verzieren" ;). In diesem Falle nur keine Scheu - teilt es mir mit, und ich kümmer' mich drum.
Ich hoffe, für alle Interessenten einen nutzbringenden Beitrag zur alternativen Implementierung des Interfaces geleistet zu haben.
Noch irgendwelche Fragen, Wünsche, Kritiken oder Anmerkungen? Dann einfach antickern. -
Hallo,
wie bereits im ForumThread DMX Control 2 erkennt Eurolite USB-DMX512-PRO nicht (Treiber) gesucht beschrieben habe ich zu Beginn des Jahres eine Wrapper-DLL für DMX-Control 2.12.2 zur Verfügung gestellt, wodurch die dort aufgeführten Probleme nicht auftreten (zumindest bei mir nicht mehr). In Erweiterung dessen habe ich die DLL um einen Konfig-Dialog erweitert, das "Umbiegen" auf eine bestehende DLL beseitigt, eine ordentliche zugehörige *.out.dll erstellt und noch weitere Optimierungen im Plugin vorgenommen. Ich nutze sie schon seit Monaten erfolgreich. Sie läuft stabil - bislang hatte ich keine Probleme damit. Daher stell' ich sie auch gerne anderen Nutzern hier zur Verfügung, die mit dem Interface auch "komisches Verhalten", bzw. Probleme damit haben.
Vom technischen Hintergrund habe ich den Unterbau von C++ auf C# umgestellt (ich mag einfach C# mehr, als C++), wodurch nun nicht mehr die VC++ Runtime, sondern das .net Framework 4.0 benötigt wird.
Getestet habe ich die DLLs bereits stabil und erfolgreich in der DMX-Control Version 2.12.2 auf einem WinXP (inkl. SP3) und Win7 (64bit) System. Der Speicherbedarf blieb im Betrieb konstant. Abstürze gab es nicht.
Hier die Kurzanleitung zur Installation:
----------------------------------------
1. DMXC2 "komplett" installieren (V2.12.2) - Nach Installation Programm NICHT öffnen
2. Microsoft .net Framework 4.0 installieren (falls noch nicht vorhanden)
3. Installieren des richtigen Treibers für das Eurolite USB-DMX512 Pro MK2 Interface
4. die 2 Dlls ('EuroliteUsbDmxMk2_SR.out.dll', 'EuroLiteUSBDMX.dll') nach <Programme>\DMXControl kopieren
5. die 'EuroLiteUSBDMX.dll' in Windows mit Regasm.exe registrieren
6. DMXControl starten, und als AusgabePlugin 'EuroLiteUsbDmx512ProMk2_SR' wählen
7. den entsprechenden COM-Port des angeschlossenen Interfaces einstellen
8. FertschUnd hier die ausführliche Anleitung:
------------------------------------0. Kurz zum Hintergrund:
Ich programmiere lieber in C#, als in C++, daher habe ich den Unterbau entsprechend auf das Microsoft.net Framework 4.0 geändert. Für die Funktion hat dies im Vergleich zu C++ keinerlei Auswirkung. In der DLL arbeite ich threadbasierend, d.h. es erfolgt eine Entkopplung vom Aufruf aus DMX-Control und der Ausgabe der DMX-Werte. Der wesentliche Vorteil dabei ist, das DMXControl für den Funktionsaufruf der DMX-Ausgabe vom Interface nicht blockiert wird. Beim Arbeiten mit DMXC 2.12.2 ist mir das schon häufig aufgefallen, dass das Programm kurz "hängt", während DMXC 2.12.2 die Funktion für die Ausgabe der DMX-Werte vom Interface aufruft. Das ist kein Fehler von DMXC, sondern vielmehr der Natur der gesamten Architektur geschuldet. Jedenfalls habe ich das Problem auf diesem Wege erfolgreich beseitigen können. Kurz gesagt: "Die DMX-Ausgabe, und die Reaktion von DMXC 2.12 geht ab, wie ein Zäpfchen ;D"1. Am besten man installiert DMXControl V2.12.2 neu, und mit allen Komponenten. Damit ist ein einheitlicher Ausgangszustand hergestellt.
2. Microsoft.net Framework 4.0 installieren
Wie bereits erwähnt habe ich die 'EuroLiteUSBDMX.dll' in C# programmiert. Daher ist das Microsoft .net Framework notwendig. Gerade bei Windows XP ist das Framework in dieser Version nicht vorinstalliert (bei Win7 bin ich mir grad auch nicht ganz sicher). Um herauszufinden, ob das Framework in dieser Version bereits installiert ist, nutzt man die Anleitung unter https://msdn.microsoft.com/de-…5568(v=vs.110).aspx#net_a ... ODER ... geht es am schnellsten, wenn man die beigefügte "DLL für Com registrieren.exe" startet. Startet das Programm, dann ist das Framework korrekt installiert, und man muss an dieser Stelle nix weiter machen. Erhält man eine rote Fehlermeldung, bzw. einen Ausnahmefehler beim Starten, dann ist das Framework 4.0 nicht verfügbar. In diesem Falle muss man es nachinstallieren, und lädt sich dazu das offizielle Microsoft Setup von https://www.microsoft.com/de-d…oad/details.aspx?id=17718 runter und installiert es.3. Installieren des richtigen Treibers für das Eurolite USB-DMX512 Pro MK2
a. Auf der Originalseite http://www.steinigke.de/de/mpn…12-pro-interface-mk2.html wird aktuell nur noch der Treiber ab Win7 angeboten.
b. Ich empfehle die Treiber direkt vom Hersteller des verbauten FTDI-Chips vom Interface zu installieren:
Unter ftdichip.com/Drivers/VCP.htm findet man die richtigen Treiber für verschiedene BetriebssystemVersionen.
Kurz: für XP nutzt man: http://www.ftdichip.com/Driver…24%20WHQL%20Certified.zip für Windows7: http://www.ftdichip.com/Driver…24%20WHQL%20Certified.zip (dies ist der Gleiche, wie unter a.)
Bei der Installation ist es extrem wichtig, den VCP-Treiber mitzuinstallieren (VCP=Virtual Com-Port)! Warum? Der Treiber installiert eine virtuelle COM-Schnittstelle, über welche dann die Kommunikation mit dem Interface von DMXC2 aus erfolgt. Bleibt dies aus, dann geht absolut nüschd.4. Die 2 DLLs nach DMXControl kopieren
Die 2 hier angebotenen DLLS ('EuroliteUsbDmxMk2_SR.out.dll' und 'EuroLiteUSBDMX.dll') ins Programmverzeichnis von DMXC2 kopieren. Meist lautet dies 'c:\Programme\DMXControl' oder 'c:\Program Files (x86)\DMXControl'. Die 'EuroliteUsbDmxMk2_SR.out.dll' wird von DMX Control benötigt, um überhaupt zu erkennen, das es mit dem Eurolite USB DMX512 PRO MK2 Interface arbeiten soll. Die 'EuroLiteUSBDMX.dll' erledigt dann die tatsächliche Arbeit, bzw. die Kommunikation mit der Hardware.5. die EuroLiteUSBDMX.dll in Windows mit Regasm.exe registrieren
Einfach gesagt: Der Schritt ist notwendig, damit aus DMX-Control die Befehle aus der "arbeitenden 'EuroLiteUSBDMX.dll' erkennt" und auch aufrufen kann. Dazu wird das Microsoft Tool Regasm.exe verwendet. Es wird zum .net Framework mit dazugeliefert und wird über die Kommandozeile ausgeführt. Wie das genau funktioniert kann man ergooglen. Schneller geht es, wenn man das von mir beigefügte Tool 'DLL für COM registrieren.exe' benutzt, denn es nimmt einem genau diese Tipparbeit ab. Dazu startet man es und wählt für die Registrierung die 'EuroLiteUSBDMX.dll' aus dem DMXC ProgrammOrdner aus. Das war's auch schon.6. DMXControl starten, und als AusgabePlugin 'EuroLiteUsbDmx512ProMk2_SR' wählen
Ein einfacher selbsterklärender Schritt: Man startet DMX-Control, wählt das Plugin 'EuroLiteUsbDmx512ProMk2_SR' aus und schon kann es fast losgehen... man muss nur noch...7. den entsprechenden COM-Port des angeschlossenen Interfaces einstellen
Ist das Interface nicht angeschlossen, oder kann der zugehörige Port vom Interface nicht automatisch ermittelt werden, erhält man eine Fehlermeldung. In dem Fall muss der entsprechende Port manuell über die Combobox ausgewählt werden.
Man ermittelt die richtige Nummer im Gerätemenager. Wie geht das?
a. DMX Control schließen
b. Interface vom PC abziehen
c. Gerätemanager öffnen (Win XP: >Start>Einstellungen>Systemsteuerung>Verwaltung>Computerverwaltung >Geräte-Manager; Win7: >Start>Rechtsklick auf Computer>Verwalten >Geräte-Manager)
d. den Knoten "Anschlüsse (COM & LPT)" (falls vorhanden) öffnen
e. dort die Namen der aufgelisteten Anschlüsse merken (meist steht da "... (Com1)", "... (Com2)"...)
f. jetzt das MK2 an den PC anstecken
g. den Knoten aus c. erneut öffnen - dort taucht nun ein neuer Eintrag auf (z.B. "USB Serial Port (Com6)"), und genau "Com6" ist der gesuchte Anschlussname, den wir dann in DMX-Control in der ComboBox nach erneutem Programmstart einstellen.8. Fertsch
So, nach diesen ganzen Schritten steht der korrekten Funktion theoretisch nichts mehr im Wege.Wie das bei einer Version 1.0 so ist, kann es durchaus sein, dass man "betriebsblind" beim Endtest gewesen ist, etwas fundamental Wichtiges vergessen hat, oder hier und da noch kleine "ProgrammKäferchen" die PluginAusführung "suboptimal verzieren" ;). In diesem Falle nur keine Scheu - teilt es mir mit, und ich kümmer' mich drum.
Ich hoffe, für alle Interessenten einen nutzbringenden Beitrag zur alternativen Implementierung des Interfaces geleistet zu haben.
Noch irgendwelche Fragen, Wünsche, Kritiken oder Anmerkungen? Dann einfach antickern. -
Hallo,
ich habe mir vor geraumer Zeit das EuroLite freeDMX Wi-FI interface AP (zukünftig 'freeDMX' o. 'freeAP' genannt) zugelegt, und vergeblich eine DLL für die Ansteuerung über DMX Control Version 2 gesucht. OHA - Mist - Nix da! Also heisst es: "Selbst ist der Mann". Ich stelle hier für die DMX Control Verison 2.12.2 die entprechenden DLLs zur Verfügung, sodass man das Interface auch unter DMX Control 2 verwenden kann.
Ich selbst arbeite seit Jahren mit der 2er Version und möchte auch aufgrund von chronischem Zeitmangel mich noch nicht ins DMX Control 3er Universum stürzen, und meine ganzen Licht-Programme wieder ganz von vorn programmieren müssen (oder gibt's evtl. nen Programmkonverter oder sowas?). Ich sag nur: "Never change a running System" - und da ist auch was Wahres dranne, daher fahre ich aktuell mit der DMX Control Version 2.12.2 sehr gut, und leiste auf diesem Wege einen kleinen Beitrag für die Community, die das Interface auch in der 2er Version benutzen wollen.
Die ersten Erfahrungen mit dem freeDMX sind an sich ganz OK. Aber: Zuerst die schlechte Nachricht: Der größte Nachteil, der mir ein leichtes Knurren entlockt ist, dass der Transport der Datenpakete über UDP erfolgt. Bedeutet im Klartext, dass man KEINE Kontrolle darüber besitzt (und auch nicht zu 100% implementieren kann), ob ein abgeschickter DMX-Wert von DMX-Control auch tatsächlich am freeAP ankommt. Im schlimmsten Fall bedeutet das beispielsweise für einen MovingHead, dass er zwar wie wild wackelt und rumrotiert, aber dunkel ist, weil z.B. das "Datenpaket Lampe an" nicht ankam... Ouuuu man - wie grausam und schrecklich!
Das ist auch kein Fehler von DMX-Control, oder meiner DLL -> das ist einfach der Natur vom UDP-Protokoll geschuldet. ABER jetzt die gute Nachricht: Ganz so schwarz muss man das Ganze nicht sehen, denn ich habe einen Workaround in die DLL implementiert, welcher das beschriebene Szenario auf ein Minimum reduziert. Keine Angst - der MovingHead bleibt NICHT dunkel. Meine bisherigen Erfahrungen und Tests können dies bestätigen.
Das freeAP an sich läuft recht stabil. Es empfiehlt sich, zur WLAN-Anbindung auch "ordentliche" Router, oder AccessPoints zu verwenden, denn das vermindert ebenfalls das Verlorengehen von Datenpaketen. Weiterhin empfiehlt es sich auch, so wenig wie möglich Switche oder Router zwischen dem freeAP und dem sendenden Rechner zu installieren. Sollte einmal die Verbindung zum freeAP abreißen, startet das Plugin den Verbindungsaufbau automatisch.
Aktuell habe ich nur die DMX-Ausgabe umgesetzt. Das DMX-In ist aktuell nicht verfügbar.
Getestet habe ich die DLLs bereits stabil und erfolgreich in der DMX-Control Version 2.12.2 auf einem WinXP (inkl. SP3) und Win7 (64bit) System. Der Speicherbedarf blieb im Betrieb konstant. Abstürze gab es nicht.
So, nun zur Einrichtung
Hier die Kurzanleitung zur Installation:
----------------------------------------1. DMXC2 "komplett" installieren (V2.12.2) - Nach Installation Programm NICHT öffnen
2. freeAP per WLAN ins Netzwerk einbinden, wichtig: kein DHCP verwenden
3. Firewall konfigurieren (ausgehender Port: 10108, eingehender Port 10107)
4. Microsoft .net Framework 4.0 installieren (falls noch nicht vorhanden)
5. die 2 Dlls ('EuroliteFreeDmxAP_SR.out.dll', 'EuroliteFreeDMXAP.dll') nach <Programme>\DMXControl kopieren
6. die 'EuroliteFreeDMXAP.dll' in Windows mit Regasm.exe oder meinem beigefügten Programm registrieren
7. DMXControl starten, und als AusgabePlugin 'EuroliteFreeDmxAP_SR' wählen, IP und Port vergeben
8. FertschUnd hier die ausführliche Anleitung:
------------------------------------
0. Kurz zum Hintergrund:
Die ansteuernde DLL 'EuroliteFreeDMXAP.dll' habe ich in C# programmiert. In der DLL arbeite ich threadbasierend, d.h. es erfolgt eine Entkopplung vom Aufruf aus DMX-Control und der Ausgabe der DMX-Werte. Der wesentliche Vorteil dabei ist, das DMXControl für den Funktionsaufruf der DMX-Ausgabe vom Interface nicht blockiert wird. Kurz gesagt: "Die DMX-Ausgabe, und die Reaktion von DMXC 2.12 geht ab, wie Schmidt's Katze ;D"1. Am besten man installiert DMXControl V2.12.2 neu, und mit allen Komponenten. Damit ist ein einheitlicher Ausgangszustand hergestellt.
2. freeAP ins Netzwerk einbinden
Die Netzwerkanbindung ans sich ist nicht schwierig und kann mit der zum Gerät mitgelieferten Anleitung problemlos durchgeführt werden. Es empfiehlt sich bei der Konfiguration im Webinterface vom freeAP eine statische IP-Adresse zu vergeben, und KEIN DHCP zu verwenden. Dadurch ist sichergestellt, dass das Gerät auch immer über die selbe (oder gleiche!?) IP-Adresse erreichbar ist. Mein Plugin verwendet UDP-Port 10107 für eingehende Verbindungen vom freeAP zum Plugin und UDP-Port 10108 für Vebindungen vom Plugin zum freeAP. Im Konfig-Dialog des Plugins vergibt man die Portnummer vom freeAP (die, die man im WebInterface vom freeAP einstellt).3. Firewall konfigurieren
Da die Kommunikation über das Netzwerk erfolgt, müssen die Ports 10107 für eingehende Verbindungen und 10108 für ausgehende Verbindungen UDP- seitig in der Firewall konfiguriert werden, sodass diese zur Kommunikation zur Verfügung stehen.4. Microsoft.net Framework 4.0 installieren
Ich habe die 'EuroliteFreeDMXAP.dll' in C# programmiert. Daher ist das Microsoft .net Framework notwendig.
Gerade bei Windows XP ist das Framework in dieser Version nicht vorinstalliert (bei Win7 bin ich mir grad auch nicht ganz sicher). Um herauszufinden, ob das Framework in dieser Version bereits installiert ist, nutzt man die Anleitung unter https://msdn.microsoft.com/de-…5568(v=vs.110).aspx#net_a ... ODER ... geht es am schnellsten, wenn man die beigefügte "DLL für Com registrieren.exe" startet. Startet das Programm, dann ist das Framework korrekt installiert, und man muss an dieser Stelle nix weiter machen. Erhält man eine rote Fehlermeldung, bzw. einen Ausnahmefehler beim Starten, dann ist das Framework 4.0 nicht verfügbar. In diesem Falle muss man es nachinstallieren, und lädt sich dazu das offizielle Microsoft Setup von https://www.microsoft.com/de-d…oad/details.aspx?id=17718 runter und installiert es.5. Die 2 DLLs nach DMXControl kopieren
Die 2 hier angebotenen DLLS ('EuroliteFreeDmxAP_SR.out.dll', 'EuroliteFreeDMXAP.dll') ins Programmverzeichnis von DMXC2 kopieren. Meist lautet dies 'c:\Programme\DMXControl' oder 'c:\Program Files (x86)\DMXControl'. Die 'EuroliteFreeDmxAP_SR.out.dll' wird von DMX Control benötigt, um überhaupt zu erkennen, das es mit dem freeAP Interface arbeiten soll. Die 'EuroliteFreeDMXAP.dll' erledigt dann die tatsächliche Arbeit, bzw. die Kommunikation übers Netzwerk.6. die 'EuroliteFreeDMXAP.dll' in Windows mit Regasm.exe registrieren
Einfach gesagt: Der Schritt ist notwendig, damit aus DMX-Control die Befehle aus der "arbeitenden 'EuroliteFreeDMXAP.dll' erkennt" und auch aufrufen kann. Dazu wird das Microsoft Tool Regasm.exe verwendet. Es wird zum .net Framework mit dazugeliefert und wird über die Kommandozeile ausgeführt. Wie das genau funktioniert kann man ergooglen. Schneller geht es, wenn man das von mir beigefügte Tool 'DLL für COM registrieren.exe' benutzt, denn es nimmt einem genau diese Tipparbeit ab. Dazu startet man es und wählt für die Registrierung die 'EuroliteFreeDMXAP.dll' aus dem DMXC ProgrammOrdner aus. Das war's auch schon.7. DMXControl starten, und als AusgabePlugin 'EuroliteFreeDmxAP_SR' wählen
Ein einfacher selbsterklärender Schritt: Man startet DMX-Control, wählt das Plugin 'EuroliteFreeDmxAP_SR' aus. Im PluginDialog muss noch die vergebene IPAdresse und Portnummer vom freeAP konfiguriert werden, die man im Schritt 2 vergeben hat und schon kann es losgehen. Alle anderen Einstellungen sollten selbsterklärend sein. Nicht wundern, falls das "An,- und Abhaken" im Plugin-Dialog manchmal etwas klemmt. Das ist normal - und durchaus zulässig. Das liegt am Verbindungsaufbau über's Netzwerk. Kleine Anmerkung noch: Gleich nach der Initialisierung des Plugins beim Programmstart ist mir aufgefallen, dass unter WinXP die DMX-Ausgabe in der ersten halben Minute etwas "klemmt", warum auch immer... aber danach funktioniert alles "sauber".8. Fertsch
So, nach diesen ganzen Schritten steht der korrekten Funktion theoretisch nichts mehr im Wege.Ich hoffe, für alle Interessenten einen nutzbringenden Beitrag zur Implementierung des Interfaces in DMX Control 2 geleistet zu haben.
Noch irgendwelche Fragen, Wünsche, Kritiken oder Anmerkungen? Dann einfach antickern.Wie das bei einer Version 1.0 so ist, kann es durchaus sein, dass man "betriebsblind" beim Endtest gewesen ist, etwas fundamental Wichtiges vergessen hat, oder hier und da noch kleine "ProgrammKäferchen" die PluginAusführung "suboptimal verzieren" ;). In diesem Falle nur keine Scheu - teilt es mir mit, und ich kümmer' mich drum.
!!! WICHTIGER NACHTRAG: AUF DER ZWEITEN SEITE DIESES THREADS GIBT ES ZIEMLICH AM ENDE EINE AKTUALISIERTE DLL V1.1, DIE EINEN BUG BESEITIGT. ZUR INSTALLATION BITTE ERST DIESE SCHRITTE BIS ZUM ENDE AUSFÜHREN, UND ERST DANN DIE UPDATEHINWEISE DER AKTUALISIERTEN DLL BEFOLGEN !!!
-
Wunderbar - das wäre prima! Ich bleib gespannt