RS485/DMX-Wandler mit FTDI spinnt ab mehr als ein Gerät

[axeljaeger]

Hallo,
um DMX-Scheinwerfer anzusteuern, wollte ich mir ein zweites DMX-Interface bauen.

Dazu wollte ich den FT232RL verwenden. Im Datenblatt ist eine Beispielschaltung gegeben:
http://www.ftdichip.com/Documents/DataSheets/DS_FT232R.pdf

Nach einigen Fehltritten habe ich es dann gestern soweit gebracht, dass ich einen Scheinwerfer ansteuern kann. Frohen Mutes habe ich die Platine mit Heißkleber ins Gehäuse geklebt und dann heute meine Lampen drann gehängt. Sowie ich mehr als eine Lampe drann hänge, verschieben sich die DMX-Kanäle um grob 2 Nummern. Das macht sich dadurch bemerkbar, dass ein Scheinwerfer, der auf Rot gestellt ist, sofort blau wird.

Mit einem "baugleichen" Adapter, den ich vor einem Jahr gebaut habe, geht es problemlos. Bisher hatte ich auf die Terminierung des Busses verzichtet, in der Annahme, der neue Adapter könnte etwas pingelig sein, habe ich mir einen Terminatorstecker gelötet, der aber auch nicht zur Lösung beiträgt.

Wie kann denn sowas überhaupt sein? Ich hatte letzte Woche das Problem, dass das Teil nur an einem bestimmten PC überhaupt als USB-Gerät erkannt wurde. Neues Layout gemacht, näher am Datenblatt, nun wird das Gerät an beiden bisher getesteten Rechnern erkannt. Ich gehe davon aus, dass das Problem ja nur irgendwo zwischen Ausgang RS485-Bustreiber und Scheinwerfer liegen kann.

Hat irgendwer eine Idee? Vielen Dank.

[Winne]

Die RS/232 ist für multislave ungeeignet da no tristate!!!
--> kollision == Kurzschluss, wenn 2 Treiberausgänge mit unterschiedlichem Pegel auf einander treffen.

Du benötigst RS485_Treiber !

[axeljaeger]

In der Schaltung laut Datenblatt wird noch ein RS485-Treiber dahinter gehängt. Die schlagen einen Maxim sonstwas vor, ich hab einen 75176B genommen, da der deutlich billiger ist und in wenigstens zwei dieser Adaptern funktioniert. (Mein alter und das Flagschiff eines kumpels).

[Winne]

tja,

wenn du keine el. kollisionen hast, dann ev. Datenkollisionen?

Adressierung ?

Ein wenig mehr Infos wären nützlich. Insbesondere ein elektrischer Übersichtsplan des Busses incl. Treiber. Und Protokol sowie Adressierung.

Der Fehler kann hier auf verschiedenen Ebenen liegen, zumindest wie du es beschreibst.

Und du weißt ja, Kristallkugeln sind rar und anfällig. Meine letzte ist seit 2 Jahren zurReparatur. Ob ich sie jemals wiedersehen werde? :eek:

[axeljaeger]

Ich habe den USB => RS485-Wandler wie im Datenblatt auf Seite 27 auf Streifenraster aufgebaut. Foto folgt nachher, wenn ich wieder zuhause bin.

Da dran hängt ein solcher Scheinwerfer als Empfänger:

http://www.mediazero-shop.de/catalog/product_info.php/n/hq_power_par36_led_rgb_spot_dmx_led_scheinwerfer/cPath/60_508_563/products_id/201637

Dieser hat die Adresse 1.

Hänge ich einen zweiten Scheinwerfer an den ersten, ich hatte dieses Baumuster:
http://www.mediazero-shop.de/catalog/product_info.php/n/mz_vision_led_par36_pinspot_rgb_dmx_black_led_sche inwerfer/cPath/60_508_563/products_id/4873
, kommt es zu der Adressverschiebung, also der erste macht nicht mehr, was er soll.

Alternativ kann ich 4 Stk. in Reihe von den ersten drann hängen, dann tritt das Phänomen auch auf. (Die 4 Stk. sind meine Festinstallation).

Die Scheinwerfer sind nur Empfänger, es gibt also mit dem PC nur einen einen Sender auf dem gesammten Bus.

Der Bus ist auf der einen Seite in dem Empfänger terminiert, in dem Schaltplan ist ja ein 120-Ohm Widerstand. Die andere Seite kann ich wahlweise terminieren oder auch nicht, das macht keinen Unterschied.

Die Gesammtkabellänge beträgt bis zu 20 Meter, größtenteils mit richtigen DMX-Kabel, Cat5, nur kurze Verbinder sind Mikrofonkabel.

Wie gesagt hatte ich schonmal so einen Empfänger gebaut, hatte seinerzeit aber ein etwas anderes Layout, in etwa dieses hier:

http://www.hoelscher-hi.de/hendrik/light/openrdm/open_rdm.gif

Diesmal hab ich das Layout aus dem Datenblatt verwendet. Die Unterschiede liegen aber auf der USB-Seite, die Seite Richtung Bus ist gleich, da wo ich den Fehler vermute.

Angesteuert wird das ganze dann über ein Programm mit libusb, wahlweise Mac oder Linux.

Ich kann mir überhaupt nicht vorstellen, wie es zu so einem Fehler kommen kann, da ich ja einen digitalen Bus habe und ich IMHO nur sehr unwahrscheinlich Störungen reinholen kann, die zu anderen, aber immerhin noch einigermaßen gültigen Steuerbefehlen führen.

Gerne will ich alles an Informationen liefern, was helfen könnte.

[Winne]

- DMX-512 Steuerung über jeden handelsüblichen DMX-Controller möglich (belegt 4 Kanäle)

ich fürchte das Problem beginnt hier

Bedienanleitung?

[axeljaeger]

Von was?

[Winne]

Von der Adressverschiebung. Ich fürchte das eine (automatische) Verschiebung erfolgt wenn nicht auf einer durch 4 teilbaren adresse gestartet wird und/oder nicht 4 zusammenhängende Adressen verfügbar sind?

Oszillogramm vom Bussignal(symmetrisch gemessen)am letzten Busteilnehmer wäre aufschlussreich.

[Rudo]

Das ist genau der Punkt, ab dem man ein DSO benoetigt! Es muss ja nicht gleich GHz-faehig sein. Uns hier im Forum rumraten zu lassen bringt fuer dich auch nicht soo viel;)

[axeljaeger]

Alles, was ich bisher an DMX-Doku gesehen hab, geht davon aus, dass man von 1 - 512 die Adressen zur Verfügung hat. Nun weis ich aber nicht, ob diese "Adressen" die gleichen sind, wie bei RS485, da man ja bei bei meinen Scheinwerfen bis zu 6 Adressen belegt, für jeden Farbkanal eine und zusätzlich Steuerkanäle. Ich kann es mir also nur so erklären, dass da im Prinzip ein Broadcast auf dem Bus passiert.

Ein Oszillogramm vom Bus hätte ich auch gerne, habe aber leider kein DSO zur Verfügung. Wenn sich das Problem nicht bis mitte nächster Woche lösen lässt, werde ich mal schauen, ob sich sowas in der Uni benutzen lässt.

Hier erstmal Bilder von meinem Versuchsaufbau: An den verpolungssicheren 3er kommt das der DMX-Bus, die anderen beiden 2x2 Stiftleisten sind für Status-LEDs.

[Rudo]

.... Nun weis ich aber nicht, ob diese "Adressen" die gleichen sind, wie bei RS485, ...
RS485 beschreibt nur eine Hardware, hat also nix mit Adressen oder Protokollen zu tun.
http://de.wikipedia.org/wiki/EIA-485

[axeljaeger]

Es gibt Fortschritte zu vermelden:

Ich habe das gleiche Layout nochmal auf Breadboard aufgebaut mit einem anderen FTDI und RS485-Treiber und beobachte exakt das gleiche. Ich gehe nun von einem Fehler in meinem Layout aus und nicht mehr von mysteriösen HF-Fehlern. (Ja, die beiden langen parallelen Leitungen in meinem Layout sind die beiden USB-Datenleitungen.)

[Michael Eggert]

Dazu wollte ich den FT232RL verwenden.
Mit einem "baugleichen" Adapter, den ich vor einem Jahr gebaut habe, geht es problemlos.


Moin!

War der "baugleiche" auch schon mit dem RL oder noch mit dem B?
Der RL braucht einen aktuellen Treiber! Steckt man den RL an einen Rechner mit altem Treiber, installiert er den ohne zu meckern, produziert dann aber seltsame Fehler z.B. bei der Baudrateneinstellung (da sind die beiden nicht kompatibel).

Gruß,
Michael.

[axeljaeger]

Der alte war auch schon mit dem RL.

Ich hab jetzt nochmal auf Breadboard aufgebaut und dabei heraus gefunden, dass es geht, wenn ich die beiden Leitungen zur Senderichtungsumstellung raus nehme.

(die beiden langen Leitungen an die 13 und 14).

Anschließend hab ich die beiden Leitungen auf meiner Platine entfernt, damit ging es mal. Ich wollte dann forschen, warum es damit geht und habs dann komplett kaputt gekriegt.

Ich hab jetzt nochmal eine weitere Platine gemacht, mit Leitungen zur Richtungsumkehr, da gabs wieder Zicken. Dann die Leitungen rausgenommen, es ging und schnell ins Gehäuse geschafft.

Edit: Zu den Treibern: Ich fahre das Ding mit einem Custom-Userspace-Treiber auf Mac an. Ich programmiere extra eine andere PID rein, damit sich der Standardtreiber das Gerät nicht holt.