Test: RS485-Standard PC-Adapter

[jkret]

Hallo,

ich möchte den zB. denTrainprogrammer zum Programmieren meiner Loks testen ohne vorab in Hardware zu investieren zu müssen.
Warum ist es speziell beim ROCO-Verstärker 70641 nicht möglich über die Slave-Buchse direkt auf den Bus zuzugreifen? Die Hardware des X-Bus ist doch RS485, oder?
Ich habe Schnittstellenumsetzer RS232 bzw USB auf RS485 (NUDAM ND6520 bzw ND6530) ausprobiert, aber der Trainprogrammer bleibt beim INIT stehen und nichts passiert weiter.
Erst wenn man die PC-Verbindung trennt, kommt die Meldung ...Digitalsystem antwortet nicht..., dh bis dahin haben PC und Roco sich unterhalten, aber anscheinend nicht verstanden.
Mit einem Oszi kann man sehen, das der Bus arbeitet und die Software versucht Daten zu schicken.
Hat jemand Tips und Tricks, wie man damit eine Kommunikation herstellen kann, oder ist das garnicht möglich?

 

[topla]

Ist nicht möglich, weil

1. das Protokoll des XBus ein anderes ist als das zwischen PC und Interface
2. der XBus mit 9 Bit Datentelegrammen arbeitet und das der PC (und die Programme) nicht können
und
3. auf dem XBus ein ziemlich scharfes Timing einzuhalten ist, was ein PC bestenfalls mit DOS aber niemals mit Windows beherrschen kann.

Thomas

 

[jkret]

d.h leihenhaft ausgedrückt also das die Original-Umsetzer von zB ROCO oder Lenz eine Art Übersetzungsmodul für die verschiedenen Protokolle sind, das Datenformat des PC in 9Bit für DCC konvertieren und das schnelle Timing übernehmen?

Gruss Jens

 

[topla]

Ja.

Gruß
Thomas

 

[Arcon]

Das serielle Interface von Lenz macht eine Verbindung zwischen Rockverstärker und PC bei angestöpselter Maus als Zentrale möglich. Das USB-Interface von Lenz funktionert nach Aussagen aus dem Inter-Netz nicht.

P.S. Bitte frage andere nach dem Warum. Ich bin reiner User und habe von Innenleben mit den vielen vielbeinigen Käfern in den Baxes keine Ahnung! (Is mir auch wurscht, solange es funktioniert, oder?)

 

[xemax]

@jkret

Das Problem bleibt aber immernoch die Software, weil, wie topla schon geschrieben hat, die Protokolle verschieden sind.
Vom Rechner zum Interface werden 2 Byte mehr gesendet als vom Interface zur Zentrale.

Wenn du dir ein Interface selber bauen möchtest, schaue mal in diesem Thread rein:
Bauanleitungen für XPress-Geräte

Gruß
Ronny

 

[E-Fan]

Die Zwei Byte mehr sind kein Problem solange nicht synchron (Bearbeitung der Daten ohne Zwischenspeicherung, also in Echtzeit) gesendet werden muss was hier wegen der unterschiedlichen Längen der Datenpakete nicht so einfach geht. Könnte mir vorstellen das nicht das Interface sondern Windoof die Ursache des Problems ist weil irgendein Treiber fehlt bzw. unvollständig ist, was aber nicht heißen soll das Bill Gates mit seinem Produkt die Hauptschuld trägt.
Der PC weiß mit den ankommenden Daten einfach nix anzufangen (denke ich) da RS232 und RS485 nur für eine genormte elektrische Charakteristik stehen und bis auf einige Kleinigkeiten nichts über den Inhalt der Daten aussagen müssen die es zu übertragen gilt. Im einfachsten Fall könnten die Bit's nur invertiert an den Rechner geschickt werden der dann zum Beispiel plötzlich anstatt einer dezimalen 0 eine 255 ausließt und deshalb dicke Backen macht.

 

[topla]

Die Zwei Byte mehr sind kein Problem solange nicht synchron (Bearbeitung der Daten ohne Zwischenspeicherung, also in Echtzeit) gesendet werden muss was hier wegen der unterschiedlichen Längen der Datenpakete nicht so einfach geht.

Natürlich sind die zwei Byte mehr ein Problem, wo sollen die denn herkommen? Die PC-Software ist auf die Kommunikation mit einem Interface ausgelegt und sendet diese beiden Bytes eben nicht mit, da sie für diese Kommunikation nicht benötigt werden. Der vom TE genannte Pegelwandler von RS232 auf RS485 ist dumm, hat also keine eigene "Intelligenz" und kann die Softwareprotokollumsetzung nicht vornehmen. Außerdem ist der genannte Pegelwandler nur bis 38,4 kbd spezifiziert, also scheitert der Anschluß schon an der maximal möglichen Datenübertragungsrate. Außerdem erfolgt die Kommunikation auf dem XBus mit 62,5 kbd, versuche das mal an deinem PC einzustellen....

Könnte mir vorstellen das nicht das Interface sondern Windoof die Ursache des Problems ist weil irgendein Treiber fehlt bzw. unvollständig ist, was aber nicht heißen soll das Bill Gates mit seinem Produkt die Hauptschuld trägt.

Windows ist immer ein Problem...
und hier genau wegen der Unmöglichkeit, die benötigte Bitrate einzustellen, wegen der Unmöglichkeit, das benötigte 9. Datenbit zu händeln (außer über Kunstgriffe mit der Parität) und wegen der Unmöglichkeit, das benötigte exakte Timing (Antwort auf Token) auch nur ansatzweise garantieren zu können. Nutzt man die USB-Schnittstelle, kommen gleich noch ein paar Probleme dazu, da dort im Allgemeinen blockorientiert gearbeitet wird.

Der PC weiß mit den ankommenden Daten einfach nix anzufangen (denke ich) da RS232 und RS485 nur für eine genormte elektrische Charakteristik stehen und bis auf einige Kleinigkeiten nichts über den Inhalt der Daten aussagen müssen die es zu übertragen gilt.

Siehe oben, die empfangende Software kann mit dem Datentelegramm nix anfangen, da sie das Protokoll nicht kennt und gleich gar nicht beherrscht.

Gruß
Thomas

 

[E-Fan]

Die zwei Byte mehr sind kein Problem - such mal nach STM1 und schau Dir an was darin enthalten sein kann. Nämlich nen schnöder 64kB-Kanal einer ISDN-Leitung der in die 144Mbit des STM1 synchron gemutiplext wird. Das geht auch in Echtzeit.
Meinste ernsthaft das der XBus nicht mit dem Paritätsbit rumspielt? Die Bitreihenfolge ist bei RS485 strikt vorgegeben - aber nicht was wo drin steht.
Windoof ist nicht immer ein Problem weil man sich auch mit nem Mac oder Linux tief in die Materie reinknien muss damit es läuft. Warum wird bei Windows dann erwartet das man alles auf dem goldenen Teller präsentiert bekommt? Es könnte nämlich auch genauso gut sein das die Hardware des Motherboardes bei der nötigen Datenrate die Segel streicht weil die entsprechenden Taktteiler oder PLL-Einstellmöglichkeiten fehlen.
Wie Du schon sagst spielt da auch die Hardware ne Rolle. Dann kann man wohl nix machen bzw. ist gewzungen sich nach was passendem umzuschauen.

 

[Per]

das Datenformat des PC in 9Bit für DCC konvertieren

Unter DOS konnte ich doch das Datenformat der seriellen Schnittstelle definieren (Port-Befehl). Unter Windows sollte das entsprechende Programm das selbst können.

 

[topla]

Die zwei Byte mehr sind kein Problem - such mal nach STM1 und schau Dir an was darin enthalten sein kann. Nämlich nen schnöder 64kB-Kanal einer ISDN-Leitung der in die 144Mbit des STM1 synchron gemutiplext wird. Das geht auch in Echtzeit.

Ist ja richtig, aber auch etwas anderes. Einmal werden zwei Streams gemultiplext übertragen, hier müsste der zweite Stream ja erst mal erzeugt werden - und das geht nicht ohne Intelligenz in Form eines Prozessors.

Meinste ernsthaft das der XBus nicht mit dem Paritätsbit rumspielt? Die Bitreihenfolge ist bei RS485 strikt vorgegeben - aber nicht was wo drin steht.

Ich mache mit dem XBus seit zwei Jahren rum und glaube schon sehr sicher zu wissen, dass die Parität der Datentelegramme durch ein Prüfbyte am Ende (XOR) ermittelt wird und nicht durch ein byteweises Paritätsbit. Der XBus hat 9 Datenbits (das hat auch nichts mit RS485 als technischer Norm zu tun, da gehen auch 5-8) und nutzt das neunte Bit wie unter Master-Slave-Betrieb bei µCs beschrieben.

Windoof ist nicht immer ein Problem weil man sich auch mit nem Mac oder Linux tief in die Materie reinknien muss damit es läuft.

Sicherlich, das ist unbenommen. Ich habe da gerade eine Odyssee hinter mir, weil ich mit etwas anderen Vorbedingungen genau das versucht habe, was der TE vorhatte. Und leider fehlt es mir an Wissen, aber bei Linux vermute ich zumindest eine Chance, durch eine Anpassung im Treiber (selbst oder durch Dritte) das von mir gewünschte Resultat erreichen zu können.

Warum wird bei Windows dann erwartet das man alles auf dem goldenen Teller präsentiert bekommt? Es könnte nämlich auch genauso gut sein das die Hardware des Motherboardes bei der nötigen Datenrate die Segel streicht weil die entsprechenden Taktteiler oder PLL-Einstellmöglichkeiten fehlen.

Natürlich ist die Hardware ein Problem bei der Baudrate und der Bitanzahl. Es gibt aber Chipsätze (OX16C950), die durchaus die Baudrate und das neunte Bit beherrschen und sogar einen Treiber mitliefern. Und schon ist Windows wieder das Problem, weil eben kein Zugang dazu in Form einer API geliefert wird und mit dem nicht dokumentierten Wissen über die Schnittstellen auch ein Eigenbau nicht möglich sein wird. Und die Zeit, wo man problemlos auf die Hardware zugreifen konnte (DOS), ist eben leider vorbei. Versucht man es trotzdem, kannst Du garnicht so schnell gucken, wie Dir die bluescreens um die Ohren fliegen.

Wie Du schon sagst spielt da auch die Hardware ne Rolle. Dann kann man wohl nix machen bzw. ist gewzungen sich nach was passendem umzuschauen.

Gibt leider nix, was passt - oder ich habe es noch nicht gefunden.

Gruß
Thomas

 

[topla]

Unter DOS konnte ich doch das Datenformat der seriellen Schnittstelle definieren (Port-Befehl). Unter Windows sollte das entsprechende Programm das selbst können.

Port-Befehl kenne ich nicht, das ging mit mode, aber niemals auf 9 Bit, weil das die Hardware einer 16C450-UART nicht kann. Dafür gingen 5 Bit, interessant für Anbindung von Fernschreibern. Und unter Windows hat sich diese Unfähigkeit gehalten, auch wenn es inzwischen entsprechende Hardware gibt, wird diese erfolgreich ignoriert.

Gruß
Thomas

 

[E-Fan]

...Gibt leider nix, was passt - oder ich habe es noch nicht gefunden...

In der letzten Elektorausgabe meine ich einen Artikel zu einem universellen USB<->SPI Adapter gelesen zu haben und das für den USB-Controller nötige Hex-File kann man sich auf der HP der Zeitschrift ziehen.
An sich bräuchte man dann "nur" noch einen Puffer mit weniger als einem KByte und einen zweiten µC um den Umsetzer zu vervollständigen.

 

[uller]

HallO!
Hmm, mir verschliesst sich hier der Sinn das Fahrad noch einmal zu erfinden. Einfach nur ne RS485 Karte reicht ja definitv nicht und auch diese hat was gekostet, wahrscheinlich ist ein Selbstbauprojekt auch nicht teurer z.B. http://www.tinet.org/~fmco/home_en.htm
Mfg Uller

 

[topla]

HallO!
Hmm, mir verschliesst sich hier der Sinn das Fahrad noch einmal zu erfinden.

Jau, stimmt, der Fred ist hier etwas abgedriftet. Für die Belange des TE ist das zweifellos richtig. Ich hatte die Hoffnung, mit einer OX16C950-Karte ohne dazwischengeschaltete weitere Technik direkt am XBus sniffen zu können, um (vermutete) Probleme im Timing meiner Eigenbaulösung erkennen zu können. Mit dem LA war das nicht möglich, da die Aufzeichnungsdauer zu gering ist.

Gruß
Thomas

 

[E-Fan]

Da ist es günstig wenn man ein Speicheroszi sein Eigen nennen kann - mir sind allerdings nur zwei Foriker bekannt auf die das zutrifft.

 

[topla]

Speicheroszi bringt eigentlich an dieser Stelle nichts, da die Aufzeichnungsdauer viel geringer als beim LA ist und gegen die 32 Kanäle des LA und die eingebauten Interpreter hat man damit eh keine Chance.

Gruß
Thomas

 

[Per]

Port-Befehl kenne ich nicht, das ging mit mode

Genau, Mode wars!