PC -> DMX Interface für Ansteuerung unter Linux gesucht

Also ich kenne eigentlich kein Interface, dass Daten wirklich puffert. Selbst das von Digital Enlightenment macht es trotz des vorhandenen Speichers nicht. Ich sehe da eigentlich auch keine Performanceprobleme. Wenn ich an meiner Windowskiste vier nachbauten der Enttec Open DMX Interfaces dranhänge, liegt die Prozessorlast nicht über 20% und das mit anderen Programmen im Hintergrund. Mein Vorschlag daher, zum testen einfach ein paar FTDI Chips mit nem RS485 Treiber versehen und das testen. Kostet vielleicht 10€, lässt sich einfach in C Programmieren und sollte tun.

Ja der FTDI gibt sich als Seriellen Port aus, was der FTDI macht, musst du dann über die Software einstellen. Für DMX musst du ihn also mit 250 kBaud laufen lassen und das gewünschte Bitmuster durchschieben. Irgendwo habe ich noch einen Eagle Schaltplan, wie man das Enttec DMX Interface am simpelsten Nachbaut. Ist wirklich nur der FTDI Chip, der SN76175 Bustreiber und ein paar Widerstände. Der Rest ist wie gesagt Software, aber das war ja auch dein Wunsch. Kannst dich ja mal in die FTDI DLL einlesen. Alles was man wissen muss, gibt es bei FTDI auf der HP.

Zitat von Deadeye5589

Also ich kenne eigentlich kein Interface, dass Daten wirklich puffert. Selbst das von Digital Enlightenment macht es trotz des vorhandenen Speichers nicht.

Also ich kenne eigentlich fast nur Interfaces (E:Cue, uDMX, DMX4all, ...), die die Daten im µC puffern - ausser dem Enttec eben, weil das ja gar keinen hat...

Das Digital Enlightenment kenne ich nicht "persönlich" (heisst, hatte ich noch nicht in Benutzung), aber da steht auf der Homepage

Zitat

Hier noch einmal alle Features des Interfaces:
(...)
* Pufferung der DMX-Daten im Interface

Für das Enttec-Dings gibt's übrigens auch direkt auf der HP einen Schaltplan - falls Neugier...

Puffern die Interfaces wirklich? Sprich lädst du erst nen Stream rein, bevor die Ausgabe gestartet wird? Bricht die DMX Ausgabe zusammen, wenn du das Interface vom Computer trennst? Falls ja, würde ich da wirklich nicht von Pufferung sprechen. Höchstens mal ein einzelnes Datenwort, ja ok aber für die Performance bringt das nix.

Den Schaltplan zum Open DMX gibt es zum Download bei Enttec, allerdings kann man das Teil noch weiter vereinfachen. Ich habe den Stromlaufplan mal angehangen, für alle die Interesse haben.

Die Puffern quasi einen "Snapshot", also den momentanen Zustand der 512 Kanäle - zieht man den USB ab, bleibt alles "stehen", so wie wenn man in der Lichtsteuer-SW "Freeze" drückt... also die DMX-Ausgabe bricht nicht zusammen, es kann sich halt nur nix mehr ändern...

die geben einfach immer das komplette Universe aus ihrem Speicher aus, der PC "schreibt" über ein eigenes Protokoll in diesen Speicher die Werte, die sich ändern - das geht z.T. auch gar nicht anders (z.B. bei dem kleinsten DMX4all Interface), weil die serielle Verbindung zum PC (auch wenn's über USB geht, ist dann ein emulierter Com-Port) gar nicht schnell genug wäre, um direkt DMX auszugeben - oder beim Butler z.B., der geht über Ethernet, da kann man das ja nicht einfach nur über eine HW-Pegelkonversion erledigen...

ebensowenig wie bei uDMX, das ja USB per SW macht, die Daten kommen ja per USB nicht genau in dem Timing rein, wie sie per DMX ausgegeben werden, die müssen gepuffert werden

also generell, alle Interfaces die ich kenne, die einen µC haben, empfangen praktisch auf der einen Seite Daten vom PC und schreiben die in den Speicher, auf der anderen Seite geben sie aus diesem Speicher dann DMX-Daten aus - beides quasi völlig unabhängig voneiander...

das ist ja irgendwie schade, dass die "normale" serielle Schnittstelle keine 250 kb/s kann, sonst könnte man mit nem einfachen Pegelkonverter (Bauteile für 1 Euro) direkt darüber DMX ausgeben - reine SW-Sache...

meine uralten Golden Scan z.B. werden über PMX (Pulsar Multiplex, elektrisch gesehen RS232) angesteuert, die kann man *direkt* an den PC hängen (wenn man denn ne SW dafür hat... ich hab's mal zum Spaß gemacht, einfach Kommandos im Terminal "eingetippt", funktioniert)

Aha,

ok gut zu wissen, das Interface von Digital Enlightenment puffert jedenfalls nicht, ziehst den USB Stecker ist schicht im Schacht. Allerdings kann man ja am Enttec sehen, dass es auch ohne Speicher geht. Wird halt alles von der Software erledigt und da klappt es mit den Timing ja schließlich auch. Von daher ist die USB Verbindung schon schnell genug um die 250kb/s zu transferieren, selbst wenn sich das Gerät als virtueller Com-Port ausgibt.

Natürlich ist USB schnell genug, sogar USB 1 hat ja schon deutlich mehr als nötig (12 Mbit/s) - k.A., nachdem der COM-Port "nur virtuell" ist, kann ja (muss ja wohl) sein, dass man den dann auch auf 250 kbit/s stellen kann... bzw. die DMX-SW das "überschreibt", im Handbuch zum Enttec-Interface ist z.B. zu sehen, dass da der COM-Port auf 9600 Baud konfiguriert wird, das würde ja damit unmöglich funktionieren...

Und natürlich ist es für einen PC kein Problem, die Daten schnell genug zur Verfügung zu stellen (DMX senden ist ja nicht mal für nen µC ne große Sache), das meinte ich ja damit, schade dass der COM-Port keine 250 kBit/s kann, dann könnte man sich ein extra DMX-Interface sparen...

Nur eben, dass halt die Interfaces, die ich so kenne, eben "richtige Interfaces" sind, also auch ein Protokoll in ein anderes übersetzen (inkl. nötiger Zwischenspeicherung der Daten), nicht nur "mehr oder weniger ne elektrische Anpassung vornehmen"...

Zitat von Deadeye5589

ok gut zu wissen, das Interface von Digital Enlightenment puffert jedenfalls nicht, ziehst den USB Stecker ist schicht im Schacht.

Das heisst aber nicht zwangsläufig, dass es nicht puffert - gut möglich, dass da "aus Sicherheitsgründen" (wie auch immer) dann die DMX-Ausgabe abgeschaltet wird, wenn nix mehr vom PC kommt* - da das aber auch mergen kann (empfangene Daten mit denen vom PC mischen), muss das wohl im Interface gepuffert werden, ich kann mir jetzt nicht vorstellen, dass die empfangenen Daten zum PC geschickt, dort gemerged werden und das dann komplett wieder "direkt" vom PC ausgegeben wird, das würde irgendwie nicht wirklich Sinn machen...

*PS: natürlich stellen beim abziehen des *USB-Steckers* sämtliche DMX-Interfaces den Versand ein, die über USB auch mit Strom versorgt werden - das ist ja klar, ohne Saft können die auch nicht weiter senden...

Zitat von Pesi

Natürlich ist USB schnell genug, sogar USB 1 hat ja schon deutlich mehr als nötig (12 Mbit/s) - k.A., nachdem der COM-Port "nur virtuell" ist, kann ja (muss ja wohl) sein, dass man den dann auch auf 250 kbit/s stellen kann...

Wenn da der FT232RL verbaut ist, geht das ohne Probleme. Dieser kann im VCP-Mode (Virtual Com-Port) bis zu 3MBaud (3.000.000 Baud). Allerdings muss man Windows da ein bissl hinters Licht führen, indem man Aliase in der INF-Datei des Treibers definiert. Man setzt zB. einen Alias für 300 Baud und wählt in den Schnittstelleneingenschaften dann 300 Baud aus. Wenn man direkt mit eigener Software auf den Chip zugreift, geht das natürlich auch an Windows vorbei und man kann da die Schnittstelle frei parametrieren (siehe http://www.mikrocontroller.net/topic/85472#721438).

Zitat von dgoersch

Wenn man direkt mit eigener Software auf den Chip zugreift, geht das natürlich auch an Windows vorbei

So muss das wohl auch hier laufen - weil das Teil ja auch den 88µs-Break erzeugen muss, und das geht ja nicht, wenn da ne feste Baudrate eingestellt ist und einfach Bytes rausgeschickt werden...

Einigen wir uns doch einfach darauf, dass es funktioniert und gut ist. Das Enttec ist jedenfalls eine sehr billige Version zum selber bauen, die sowohl von DMX Controll und Freestyler, als auch von Madrix sofort erkannt wird.

Klar, ich hab' ja auch nix gegen das Teil gesagt! - ist doch trotzdem interessant, darüber zu reden, wie das alles da so funktioniert/funktionieren könnte...?

btw.: das uDMX ist vom Schaltungsaufwand her "das selbe", nur dass da halt der Mega8 die Funktion des FT232RL übernimmt - und der ist billiger und einfacher zu beschaffen....

P.S.: noch mal btw.: ich dachte immer, bei Madrix wäre das so wie bei E:Cue, die SW ist gratis, aber sie hilft nix ohne das (zu kaufende) Interface (z.B. Neo)...? - geht denn das Madrix zum runterladen dann problemlos mit dem Enttec, da würde man das ja quasi umsonst bekommen....

Madrix hat seit der Version 2.7 einen "Vorschaumodus" eingebaut. Der ermöglicht die Ausgabe der DMX Informationen auch ohne Dongel, jedoch wird die Ausgabe jede Minute für ein paar Sekunden auf Blank geschaltet. Dabei beschränkt sich Madrix in diesem Modus nicht auf die Anzahl der Universen. Man kann also die Ultimate Version testen, muss aber halt mit der Unterbrechung der Ausgabe leben. Will man Madrix dauerhaft nutzen, kommt man halt nicht um den Kauf des passenden Dongels herum. Beim Neo haben sie den Dongen einfach mit eingebaut, so spart man sich einen USB Port am Rechner.

Hmm also der uDMX ist schon noch etwas aufwendiger von der Schaltung her, alleine weil der Ausgang galvanisch getrennt ist und den FTDI kriegst du auch bei Reichelt. Aber ansonsten könnte man es auch mit dem Teil probieren. Jedoch scheinen wir den Themenstartet ja schon wieder Mundtot gemacht zu haben.

Naja, der André ist öfter mal für ein paar Tage nicht verfügbar, ich weiß das, weil ich auch ab&zu e-Mail-Kontakt mit ihm habe - wir haben ihn also sicher nicht vergrault...

das mit der galvanischen Trennung beim uDMX ist ja nicht nötig, die kann man auch weglassen - im Original ist sie auch nicht drin, die wurde dann ja nur in der Waechter-Version dazugefügt - und das kann man praktisch als "extra Modul" betrachten, also man kann auch das Enttec bei Bedarf um diesen Schaltungsteil erweitern zur galvanischen Trennung...

Danke für den Tipp mit Reichelt, letztes Mal habe ich den nicht gefunden... - evtl. neu im Programm...?

Ahja, so geht das bei Madrix, es gibt auch nen extra Dongle - im Prinzip nicht blöd, aber eigentlich nur, wenn der Dongle dann billiger ist, als das Interface mit Dongle... - habe mich damit noch nicht beschäftigt, weil für mich reicht die Demo-Version mit den Aussetzern, bei dem ganzen Geblinker fällt das gar nicht wirklich auf, wenn ein paar Lampen mal ein paar Sekunden aus sind...

Zitat von Pesi

Danke für den Tipp mit Reichelt, letztes Mal habe ich den nicht gefunden... - evtl. neu im Programm...?

Kommt drauf an, wie lange "letztes Mal" her ist.
Ich habe meinen ersten FT232RL dort vor etwa einem Jahr gekauft.

Was spricht denn gegen einen einfachen Aufbau mit dem FTDI Chip? Dafür gibt es definitiv Linux Treiber und ich denke dann auch passende .so Dateien. Wenn nicht kann man meine ich auch aus ner dll eine so machen ohne großen Aufwand.