TCP-Datenausgabe für Zusi
Wer für den Zugsimulator Zusi externe Geräte wie Fahrpulte, EBuLa- oder MMI-Displays entwickeln möchte, benötigt die TCP-Datenausgabe. Aktuelle Version des TCP-Servers ist die Version 1.3, der Testclient wurde ebenfalls überarbeitet.
Die TCP-Datenausgabe ermöglicht es, die aktuellen physikalischen Daten des Führerstands (also alles, was im Führerstandseditor an Daten verfügbar ist) während einer Fahrt nahezu ich Echtzeit auszulesen. Zusi sendet hierfür alle 100 Millisekunden Datenpakete an den TCP-Server, der diese an die angeschlossenen Clients weiterleitet.
Benutz’ es einfach!
Um als Anwender mit der TCP-Datenausgabe arbeiten zu können, benötigen Sie den TCP-Server und einen oder mehrere Clients.
TCP-Server 1.3 (Setup, 499 KB)
Verfügbare Clients
ZusiDisplay (MMI-Displays, EBuLa, Triebwagendisplays…)
ZusiSoundthesizer (Neues Soundmodell mit vielen Funktionen für sehr realistischen Klang)
Selbst Anwendungen entwickeln
Sie können auch selbst Anwendungen für die TCP-Datenausgabe entwickeln. Hier helfen ihnen neben der Dokumentation diverse kleine Hilfsprogramme und Code-Vorlagen, die Sie anpassen können.
Das TCP-Datenausgabe-Protokoll erklärt, wie ein Client aufgebaut sein muss und welche Befehle gesendet werden müssen. Eine Liste zeigt die möglichen physikalischen Daten. Für häufig benötigte Aufgaben finden sich Code-Beispiele in der Dokumentation.
Die Sourcecode-Vorlage ist ein komplettes Programmbeispiel eines fertigen Clients (Programm und Delphi-Source-Code). In der Version 2 wurde dieser Code so überarbeitet, dass ein Aufteilen der Daten besser erkennbar ist. Zudem ist die Benutzung des speziellen Datentyps TDateTime besser erklärt.
Sourcecode-Vorlage für einen Testclient in Delphi (Für Delphi 4 und darunter benötigen Sie diese Unit)
Der Zusi-Simulator verhält sich wie Zusi und gibt die Daten VIst und die Zugkraft aus. Dies ist nützlich, um sich schnell einen Überblick über die Funktion zu verschaffen, ohne erst Zusi starten und eine Strecke laden zu müssen.
Zusi-Simulator (VIst, Zugkraft) zum Testen von Clients
Die TCP-Testtools dienen zum Debuggen von TCP-Anwendungen. Es gibt einen Client- und eine Serverapplikation. In beide Programme können die zu übertragenden Daten von Hand eingeben werden, damit kann überprüft werden, wie ein Programm Befehl für Befehl auf die Daten reagiert.
Für das Mitloggen der Daten ist der Debug-Modus des TCP-Servers vorgesehen. Zudem können auch Programme wie Ethereal bei der Diagnose möglicher Probleme helfen.
TCP-Testtools zum Debuggen von TCP-Anwendungen
8 Kommentare »
RSS feed for comments on this post · TrackBack URI
Paul A. sagt:
26. Mai 2006 @ 14:31
Hallo,
ich habe vor ein Freeware (GPL/Closed Source) Programm zur Steuerung eines Fahrpultes zu schreiben.
Ich würde dabei gerne auf ihren TCP Server verweisen. Bzw. ihn benutzen, allerdings nicht auf meiner Homepage anbieten sondern einen Link zu ihnen setzen.
Ist das in Ordnung ?!
mfg
Paul A.
Daniel Schuhmann sagt:
26. Mai 2006 @ 14:35
Selbstverständlich ist dies in Ordnung.
Christopher sagt:
23. Januar 2008 @ 20:25
Hallo,
das Programm hat einen Fehler: Zeichenketten werden vom TCP-Server zwar offenbar korrekt empfangen (und korrekt im Debug-Fenster angezeigt), aber nicht korrekt an die Clients weitergeleitet. Die Längenangabe und die ersten drei Zeichen (also die ersten 4 Bytes) werden korrekt übermittelt, danach folgt entweder Datenschrott (möglicherweise bestehend aus Daten, die im gleichen Paket eigentlich erst später folgen?) oder das Paketende, selbst wenn die Zeichenkette laut Längenangabe mehr als 3 Zeichen enthält.
Im Zusi-Forum habe ich einen entsprechenden Diskussionsfaden angelegt.
Gruß,
- Christopher
Bernhard sagt:
24. Januar 2008 @ 4:55
Hallo Christopher!
Aufgrund eines Fehlers in der mitgelieferten commandset.ini wird der von Dir im Forum angesprochene ID 77 (LM Block, bis zu dem die Strecke frei ist) nicht als string behandelt. Alle nachfolgenden Daten sind somit ebenfalls unbrauchbar. Ergänze in der section “Commands” die Zeile “2637=0″.
Abgesehen davon ist die Benutzung der jeweils aktuellen Fahrsimulator-Version dringend anzuraten, denn im Hinblick auf die Datenausgabe und insbesondere die Behandlung von strings ist Zusis Versionsgeschichte recht durchwachsen:
- 2.4.3.0 - 2.4.3.3: Die Länge von strings ist entgegen der Dokumentation nicht in einem sondern in vier Bytes (little endian) kodiert.
- 2.4.3.4: Absturz der Datenausgabe
- 2.4.3.5 - 2.4.4.2: Die Datenausgabe arbeitet wieder korrekt, Zusi unterschlägt jedoch alle angeforderten strings. Außerdem sendet Zusi nach dem ersten Verbindungsaufbau einen leeren DATA-Befehl.
- ab 2.4.5.0: Strings werden wieder korrekt gesendet, ihre Länge ist erstmals der Dokumentation entsprechend in einem Byte kodiert. Zusi sendet nach dem ersten Verbindungsaufbau nun allerdings einen fehlerhaft formatierten DATA-Befehl, der im wesentlichen aus einer Liste der angeforderten IDs besteht und dadurch bei clients für Verwirrungen bis hin zu Abstürzen sorgen kann.
Trotz dieser Fehler und anderer struktureller Schwächen des Protokolls halte ich die Datenausgabe für ein hervorragendes Spielzeug, das einer Simulation wie Zusi sehr gut zu Gesicht steht.
Beste Grüße,
Bernhard
Daniel Schuhmann sagt:
24. Januar 2008 @ 16:35
Weitere Antworten zum Thema am besten in den entsprechenden Thread im Zusi-Forum.
Jörg Petri sagt:
1. April 2008 @ 23:51
Zusi ist in der Version 2.4.6.3 erschienen und soll weitere TCP-Daten übermitteln.
Frage1: Kommt ein neuer/erweiterter TCP-Server?
Frage2: Gibt es schon eine genaue Auflistung der von Zusi jetzt übermittelten Daten/Parameter?
Gruß
Jörg
Bernhard sagt:
5. April 2008 @ 21:05
Hallo Jörg!
ad 2)
97: Längsbeschleunigung
98: Querbeschleunigung
99: Querneigung
100: Aktuelle Höchstgeschwindigkeit
101: Aktuelle Zielgeschwindigkeit
102: Zielweg
103: Abstand nächster Reisezughalt
104: Name nächster Reisezughalt (String)
105: Planzeit nächster Reisezughalt (DateTime)
106: PZB restriktiv (Boolean)
107: PZB-Zwansgbremsung (Boolean)
Achtung: Einige IDs, insbesondere 102 und 103, liefern nur sinnvolle Werte, wenn die entsprechenden Daten auch im Schummelfenster angezeigt werden.
ad 1) Der TCPServer 1.3 kann durch folgende Änderungen an der commandset.ini auf den neuesten Stand gebracht werden:
[FriendlyNames]
…
2657=Längsbeschleunigung
2658=Querbeschleunigung
2659=Querneigung
2660=Aktuelle Höchstgeschwindigkeit
2661=Aktuelle Zielgeschwindigkeit
2662=Zielweg
2663=Abstand nächster Reisezughalt
2664=Name nächster Reisezughalt
2665=Planzeit nächster Reisezughalt
2666=PZB restriktiv
2667=PZB-Zwansgbremsung
[Commands]
…
2664=0
2665=8
Beste Grüße,
Bernhard
Jörg Petri sagt:
6. April 2008 @ 13:38
Danke Bernhard, ich habe mir schon die Liste geupdatet.