Hallo miteinander :o) Kurz vorweg, ich habe mir vorgenommen eine eigene Lichtdekoration zu entwickeln, die via DMX gesteuert werden soll. Dafür habe ich einen Arduino und eine Hand voll LEDs, die via I2C angesteuert werden können. Der Arduino soll vom DMX-Shield die Signale entgegennehmen und die LEDs entsprechend steuern. Da ich kein Lichtmischpult habe und auch nicht anschaffen wollte, habe ich mir testweise ein USB to DMX Breakout Board von SK Pang bestellt, welches nun vor wenigen Tagen eingetroffen ist. Produktbeschrieb: http://www.skpang.co.uk/catalog/usb-to-dmx-breakout-board-p-977.html Ich habe mir erhofft, dass SK Pang ein Kommunikationsprotokoll dafür bereitstellt bzw. Support liefern kann, wurde aber an die Dokumentation von FTDI verwiesen: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf Ich bin zwar gelernter Applikationsentwickler (vornehmlich mit dem .NET-Framework arbeitend), vermag allerdings der Dokumentation nicht zu entnehmen wie ich nun via USB die gewünschten DMX-Signale erzeugen kann! Das hört sich für mich schon alles sehr Low-Level an... Kann mir bitte jemand ein paar heisse Tipps oder gar ein einfaches Beispiel geben? :o) Grüsse von der dunklen Seite der Sonne
Da scheint einfach nur ein USB<->RS232 Wandler (ft232) mit einem RS485-Treiberchip verbunden worden zu sein. D.h. deine Software muss das DMX-Protokoll selbst implementieren und für korrektes Timing sorgen. Enttec's Open DMX USB ist glaube ich ähnlich/genauso aufgebaut, Software dafür könnte mit dem Ding funktionieren. Mir persönlich gefällt diese Variante nicht, da das Timing vom Rechner+Treiber abhängt* und man sich damit möglicherweise Probleme einhandeln könnte. Zunächst einen der Treiber für ftdi-Chip installieren. a) Beim VCP-Treiber erscheint ein "Virtual Com Port", den du mittels .NETs "SerialPort"-Klasse ansteuern kannst. b) Beim D2XX-Treiber kann der ft232 über eine DLL gesteuert werden (da gibt es im Netz auch .net-Wrapper für) Das Protokoll ist eigentlich sehr simpel: http://en.wikipedia.org/wiki/DMX512#Protocol *problematisch ist nur der lange Break
Hallo bluppdidupp Danke für Deine Antwort. Ja, immerhin habe ich schon mal einen .NET-Wrapper gefunden: http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/CSharp/FTD2XX_NET_v1.0.14.zip Hm, nach einigem Studium des DMX-Protokolls und des .NET-Wrappers versuche ich es nun eigenhändig, Bit für Bit, zu implementieren. 250'000 Bits pro Sekunde ergibt eine Taktzeit von 4 Mikrosekunden. Muss ich "eigentlich nur noch" die Bits richtig zu Bytes zusammensetzen. Mal schauen, ob ich damit Erfolg habe. Ich melde mich wieder. Grüsse von der dunklen Seite der Sonne
In diversen DMX-Projekten wird häufig die serielle Schnittstelle auf 250 KBaud, 1 Start-Bit, 8 Datenbits, 2 Stop-Bits, No Parity eingestellt und für den Break/MAB einfach die Baudrate kurz abgesenkt und eine 0 gesendet - Könnte am PC vllt. auch klappen.
Danke für den Tipp, das ist eine kreative Idee, allerdings möchte ich möglichst mit dem von FTDI zur Verfügung gestellten Wrapper arbeiten. Mir ist unter anderem unklar, ob sich die Baudrate-, Stopbit-, Parity- und Databits-Eigenschaften, die ich auf dem .NET-FTDI-Objekt setze, für die USB- oder für die RS485-Schnittstelle gelten.. Ich finde dazu keine Anhaltspunkte, und aus dem Sourcecode (http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/CSharp/FTD2XX_NETclass.zip) werde ich auch nicht klug. Schaue mich sonst noch weiter bei FTDI um, evtl. können die mir ja etwas Support zum .NET-Wrapper geben. Mein bisheriger Versuch, das Protokoll in .NET zu implementieren sieht wie folgt aus: Reset-Sequenz (22x4µs LOW = 88µs LOW): 00000000 00000000 000000 MarkAfterBreak-Sequenz (2x4µs HIGH = 8µs HIGH): 11 Diese beiden Sequenzen finden praktischerweise in 3 Bytes platz. Praktisch deshalb, weil ich in .NET nur ganze Bytes senden kann. Nun folgen die 1 Byte Channel-Values, welche von 1 LOW-Start- und 2 HIGH-Stopbits eingerahmt werden. Ein solches Frame resultiert also in 11 Bits. Um das Protokoll einzuhalten, schicke ich gleich 8 Channels, damit ich die resultierenden 88 Bits sauber in 11 Byte verpacken kann. Frame 1: 0 11111111 11 Frame 2: 0 11111111 11 Frame 3: 0 11111111 11 Frame 4: 0 11111111 11 Frame 5: 0 11111111 11 Frame 6: 0 11111111 11 Frame 7: 0 11111111 11 Frame 8: 0 11111111 11 Nun hänge ich alle Bits (Reset, Mark + 8 Channel-Frames) aneinander und teile sie in Bytes auf: 00000000 00000000 00000011 01111111 11101111 11111101 11111111 10111111 11110111 11111110 11111111 11011111 11111011 11111111 Diese Bytes sende ich dann an das USB-to-DMX-Breakout, allerdings reagiert der DMX-Empfänger nicht, egal ob ich das FTDI-Objekt mit 2 oder 0 Stopbits konfiguriere. Ich bin mir auch bewusst, dass das Problem auf der Empfängerseite liegen könnte... Ich melde mich wieder, wenn mir eine Lösung gelungen ist. Danke soweit & Grüsse von der dunklen Seite der Sonne
Blöde frage Warum DMX? Nur weil es dafür ein Shield gibt, das man für Lichtinstallationen benutzt? Du setzt also eine für dich neue Technologie als Schnittstelle zwischen zwei Komponenten ein, die teuer durch zusätzliche Komponenten ist um bereits existierende bekannte Schnittstellen abzulösen, die günstiger und schneller zu implementieren wären? Da der Arduino eh wieder auf i2c überbesetzen muss nimm doch ethernet. Vorteile liegen auf der Hand. Wenn es just for fun ist, einfach ignorieren und noch viel Spaß beim basteln
Nein, ich will es unbedingt in die bestehende DMX-Topologie integrieren - Ethernet würde es wieder verkomplizieren ;o) Aber danke für den Input - manchmal merkt man ja selber gar nicht, dass man es komplizierter macht, als nötig wäre. :o) Bin daran, mir ein funktionierendes Lichtmischpult zu organisieren, um dem Problem auf die Schliche zu kommen. Grüsse von der dunklen Seite der Sonne
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.