TCP-Server: Strings

Soundthesizer, Zusitool und andere Zusatzsoftware

Moderatoren: Andreas Damm, Jens Haupert

Nachricht
Autor
Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

TCP-Server: Strings

#1 Beitrag von Schorsch »

Hallo,
ich habe einen eigenen TCP-Server in C geschrieben. Einlesen der Float-Werte (= Single-Werte) und TDateTime funktioniert soweit auch. Nun wollte ich die von Zusi gelieferten String-Werte einlesen, habe da aber so meine Probleme. In den meisten fällen werden sie "scheinbar" korrekt übertragen und ich kann sie richtig interpretieren, doch manchmal schaut es so aus, dass die Länge des Strings nicht richtig angegeben wird (erstes Byte nach der ID). In dem String befinden sich Steuer- und Sondereichen, nachfolgende Daten werden nicht mehr richtig interpretiert. Array-Überlauf und fehlerhafte 0-terminierender String in meinem Code habe ich bereits ausschließen können.

Hier mal mein Codeausschnitt:

Code: Alles auswählen

// einlesen der Daten über TCP-Verbindung

int id = empfangeneDaten[0];
int laenge = (unsigned int) empfangeneDaten[1];

if(laenge != 0)
{
    // Zeichen ab empfangeneDaten[2] bis empfangeneDaten[laenge] als String interpretieren
}
Falls jemand über das gleiche Problem gestolper ist und mir Tips geben kann, wäre ich dankbar.

Gruß
Georg

ImmoBirnbaum
Beiträge: 1040
Registriert: 18.01.2004 12:51:32
Aktuelle Projekte: Objektbau in LOD0, Fahrpult, new adventures in VHDL
Wohnort: EPD

Re: TCP-Server: Strings

#2 Beitrag von ImmoBirnbaum »

Mir fehlt da gerade der Ansatz, was genau empfangeneDaten ist. Ist dieses Array schon um die 4 führenden Paketlängenbytes und 0x00 0A (Befehl Data) "bereinigt" bzw. sind evtl. im selben Paket übertragene Werte anderer Simulatorgrößen schon rausgerechnet? Welchen Datentyp hat empfangeneDaten?
SAAB - more than a car

Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

Re: TCP-Server: Strings

#3 Beitrag von Schorsch »

Sorry für die ungenaue Beschreibung, ich steck da wohl zu sehr in meinem Code drin ^^.
"empfangeneDaten" ist bei mir ein CHAR-Array.
int id = empfangeneDaten[0] zeigt auf die ID eines String-Befehls von Zusi.
Packetlängenbytes, Befehl "Data" und evtl. vorher übertragene Simulatordaten wurden korreckt weggerechnet (dies funktioniert auch soweit keine Strings angefordert werden).
Sprich das Array wurde einfach so weit verschoben, dass das erste Array-Element die nächste zu verarbeitende ID ist (in diesem Fall eine String-ID).

Bernhard
Beiträge: 22
Registriert: 11.09.2009 15:44:19

Re: TCP-Server: Strings

#4 Beitrag von Bernhard »

Schorsch hat geschrieben:Nun wollte ich die von Zusi gelieferten String-Werte einlesen, habe da aber so meine Probleme.
Welche Version des Fahrsimulators setzt Du ein? Erst ab 2.4.5.0 wird die Länge von Strings der Dokumentation entsprechend in einem Byte kodiert. Frühere Versionen nutzten dafür - sofern die Datenübertragung von Strings überhaupt funktionierte - vier Bytes little endian. In jedem Fall wäre der tcp- oder hex dump eines kompletten DATA-Befehls für die weitere Fehlerdiagnose sehr hilfreich.

P.S.: Noch eine kleine Korrektur zu Deinem Codeausschnitt: Der String reicht von empfangeneDaten[2] bis empfangeneDaten[laenge + 1].
Zuletzt geändert von Bernhard am 20.01.2010 12:33:03, insgesamt 1-mal geändert.

Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

Re: TCP-Server: Strings

#5 Beitrag von Schorsch »

Bernhard hat geschrieben:Welche Version des Fahrsimulators setzt Du ein? Erst ab 2.4.5.0 wird die Länge von Strings der Dokumentation entsprechend in einem Byte kodiert. Frühere Versionen nutzten dafür - sofern die Datenübertragung von Strings überhaupt funktionierte - vier Bytes little endian.
Ich benutze die aktuelle Version 2.4.7.2
Bernhard hat geschrieben:P.S.: Noch eine kleine Korrektur zu Deinem Codeausschnitt: Der String reicht von empfangeneDaten[2] bis empfangeneDaten[laenge + 1].
Das "laenge + 1" war vermutlich der Fehler.
Versteh ich das jetzt richtig:
Das "+ 1" bezieht sich
physikalischegroessen.htm hat geschrieben:Bei den Strings liefert das erste Byte die Längenangabe des Strings, danach folgt der eigentliche Wert.
auf das Längenangaben-Byte, dieses muss jedoch herausgerechnet werden, oder?

Der Tip scheint geholfen zu haben. Ein erster Testlauf mit einem String schaut vielversprechend aus.
Zusätlich habe ich heute Infos über die erweiterten Datensätze gefunden. Gibt es denn eine vollständigere Liste an Datensätzen, an der man sich orientieren kann?

Nochmals vielen Dank für den Tip,


Gruß
Georg

Bernhard
Beiträge: 22
Registriert: 11.09.2009 15:44:19

Re: TCP-Server: Strings

#6 Beitrag von Bernhard »

Schorsch hat geschrieben:Das "+ 1" bezieht sich [...] auf das Längenangaben-Byte, dieses muss jedoch herausgerechnet werden, oder?
Dieses Byte wird in der Längenangabe selbst nicht berücksichtigt. Der Inhalt von empfangeneDaten könnte also beispielsweise so aussehen:

Code: Alles auswählen

0000   5D 07 47 6C    ..Gl
0004   65 69 73 20    eis 
0008   31             1

Byte 00: 5Dh = 93d = ID "Nächstes Gleis"
Byte 01: 07h = 07d = Länge des folgenden Strings
Byte 02 - 08: String "Gleis 1"
Schorsch hat geschrieben:Gibt es denn eine vollständigere Liste an Datensätzen, an der man sich orientieren kann?
Der Fahrsimulator unterstützt die aus der Dokumentation bekannten 97 IDs sowie ab Version 2.4.6.3 die von mir ursprünglich auf smartcoder.net aufgelisteten 11 IDs, die größtenteils die Daten des Schummelfensters widerspiegeln.

Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

Re: TCP-Server: Strings

#7 Beitrag von Schorsch »

Nochmals vielen Dank für deine schnelle und detailierte Antwort.

Also genau da lag mein Problem. Ich hab "Länge des folgenden Strings" immer mit in die länge des eigentlichen Strings einbezogen. Daher kamen dann natürlich auch die seltsammen Werte.

Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

Re: TCP-Server: Allgemein

#8 Beitrag von Schorsch »

Hi,
mal eine allgemeine Frage:
Nachdem ich jetzt alle Daten von Zusi empfangen kann, stellt sich die Frage, wie interpretieren?

Die offensichtlichen Einheiten/Werte sind "ja klar", nur gibt mir folgende Datensätze ein paar Rätsel auf.
Zu einem wäre da die Einheit des Wertes "Strom" (0x08), ist es Ampere, da ich entweder 15 auf deutschen Bahnen, oder stellenweise -1 auf amerikanischen Strecken lese.

Bezüglich der Querneigung (0x63), wird dort der Wert in Grad angegeben, oder ist es ein prozentualer Wert?

Und was mir besonder "Kopfzerbrechen" bereitet, sind die "LM PZB Zugart U,M,O"-Werte (0x17, 0x18, 0x19). Ich habe diese Werte so interpretiert, dass LM für Leuchtmelder steht und das diese nur an/aus (0 oder 1) anzeigen. Nun zeigt z.B. 0x17 bei mir Werte von 0 bis knapp über 100 an. Das hat mich dann doch ein wenig überrascht.

Wenn mir jemand einen kleinen Tipp geben könnte, wie ich diese Werte verstehen kann, wäre ich über eine kurze Antwort sehr dankbar.

Gruß
Georg

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: TCP-Server: Strings

#9 Beitrag von Christopher Spies »

Hallo Georg,

Größe 8 ist nicht "Strom", sondern "Motorspannung". Wenn Du als Werte 15 und -1 bekommst, ist das vermutlich die Oberleitungsspannung in kV. Die Größen 7 (Motorstrom), 8 (Motorspannung) und 9 (Motordrehzahl) sind ohnehin mit Vorsicht zu genießen. Für viele Fahrzeuge erhält man da völlig unphysikalische Werte, die aber in der Simulation zu einem vorbildnahen Verhalten führen.

Die Querneigung (Größe 99 dezimal = 63 hexadezimal) wird im Bogenmaß angegeben. Positive Werte entsprechen einer Drehung gegen den Uhrzeigersinn (Neigung nach links), negative einer Drehung im Uhrzeigersinn (nach rechts).

Bei den Leuchtmeldern würde ich die tatsächlichen Werte ignorieren und einfach nur mit Null vergleichen. Der Wert 0 bedeutet "Leuchtmelder dunkel", jeder andere Wert bedeutet "Leuchtmelder aktiv". Warum diese Werte trotzdem reell sind und nicht von einem Aufzählungstyp, bleibt rätselhaft.

Gruß
- Christopher

Edit: Gedanken ergänzt
Zuletzt geändert von Christopher Spies am 02.02.2010 19:05:57, insgesamt 1-mal geändert.

Bernhard
Beiträge: 22
Registriert: 11.09.2009 15:44:19

Re: TCP-Server: Strings

#10 Beitrag von Bernhard »

Christopher Spies hat geschrieben:Bei den Leuchtmeldern würde ich die tatsächlichen Werte ignorieren und einfach nur mit Null vergleichen. Der Wert 0 bedeutet "Leuchtmelder dunkel", jeder andere Wert bedeutet "Leuchtmelder aktiv". Warum diese Werte trotzdem reell sind und nicht von einem Aufzählungstyp, bleibt rätselhaft.
Bis auf fünf IDs vom Typ ShortString (0x4D, 0x5C, 0x5D, 0x60, 0x68) und zwei vom Typ TDateTime (0x32, 0x69) sind alle Daten ursprünglich vom Delphi-Typ Single, der Cs float entspricht. Die Werte fast aller Leuchtmelder und der meisten Schalter können jedoch als boolsche Werte aufgefaßt werden, deren zwei Zustände als 0.0 (00 00 00 00) oder 1.0 (00 00 80 3F) kodiert sind. Ausnahmen sind unter anderem "LM LZB-Zielweg (ab 0)" (0x4B) oder "Schalter Fahrstufen" (0x33), deren Daten wiederum als Integer aufgefaßt werden können.

ImmoBirnbaum
Beiträge: 1040
Registriert: 18.01.2004 12:51:32
Aktuelle Projekte: Objektbau in LOD0, Fahrpult, new adventures in VHDL
Wohnort: EPD

Re: TCP-Server: Strings

#11 Beitrag von ImmoBirnbaum »

Bernhard hat geschrieben:Ausnahmen sind unter anderem "LM LZB-Zielweg (ab 0)" (0x4B) oder "Schalter Fahrstufen" (0x33), deren Daten wiederum als Integer aufgefaßt werden können.
Und zwar als Signed Integer, da z.B. beim Kombihebel die Nullstellung des Schalters den Wert 0 hat, die Fahren-Schalterstellungen haben positive Werte, die Bremsen-Schalterstellungen sind negativ. Bei Leuchtmeldern tuts in der Tat die Unterscheidung Null / ungleich Null.
SAAB - more than a car

Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

Re: TCP-Server: Strings

#12 Beitrag von Schorsch »

Danke für die schnellen Antworten.

Ich habe gerade die Physikalischen Größen aus der Protokollspezifikation von Daniel Schuhmann ein wenig erweitert.
Vielleicht ist sie für andere hier im Forum interessant.
Wenn jemand eines der Felder ergenzen oder verbessern will, dass eine aktuelle Version für das Forum entsheht, bin ich sehr dankbar.

Ich habe die ods (OpenOffice Calc) und pdf in ein zip-Archiv online gestellt.

Gruß
Georg

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: TCP-Server: Strings

#13 Beitrag von Carsten Hölscher »

Standard ist single (float).

Integer kommt nur bei Aufzählungstypen usw. zum Einsatz.

Carsten

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: TCP-Server: Strings

#14 Beitrag von Christopher Spies »

Hallo Bernhard,
Bernhard hat geschrieben:Bis auf fünf IDs vom Typ ShortString (0x4D, 0x5C, 0x5D, 0x60, 0x68) und zwei vom Typ TDateTime (0x32, 0x69) sind alle Daten ursprünglich vom Delphi-Typ Single, der Cs float entspricht. Die Werte fast aller Leuchtmelder und der meisten Schalter können jedoch als boolsche Werte aufgefaßt werden, deren zwei Zustände als 0.0 (00 00 00 00) oder 1.0 (00 00 80 3F) kodiert sind. Ausnahmen sind unter anderem "LM LZB-Zielweg (ab 0)" (0x4B) oder "Schalter Fahrstufen" (0x33), deren Daten wiederum als Integer aufgefaßt werden können.
Das stimmt so nicht!
Alle Leuchtmelder (Größen 20 bis 47, 71 bis 73 und 79 bis 82) können als Boole'sche Werte (exakt 0 = aus, ungleich 0 = an) aufgefasst werden.
Die Schalter (Größen 51 bis 70, 74 und 78) sind einfachgenaue Gleitkommazahlen, nehmen aber nur ganzzahlige Werte an. Das gilt auch für die Größen "Fahrstufe" (16) und "LZB-Zielweg" (75). Das meintest Du vermutlich.
Echte 32-Bit-Ganzzahlen sind dagegen die Größen "Türen" (86), "Autopilot" (87), "Reisezug" (88), "PZB-System" (89), "Führerstand sichtbar" (91), "Bremsstellung" (95), "PZB restriktiv" (106) und "PZB Zwangsbremsung" (107).

Ich werde Georg helfen, eine entsprechende Tabelle zu erstellen, damit das zukünftig nicht mehr jeder selbst herausfinden muss. Aus der Zusi-Dokumentation oder der des TCP-Servers geht das alles leider nicht hervor.

Gruß
- Christopher

Nachtrag:
Bernhard hat geschrieben:Der Fahrsimulator unterstützt die aus der Dokumentation bekannten 97 IDs sowie ab Version 2.4.6.3 die von mir ursprünglich auf smartcoder.net aufgelisteten 11 IDs, die größtenteils die Daten des Schummelfensters widerspiegeln.
Wieso "von Dir"? Bist Du Daniel Schuhmann's Zweitaccount?
Zuletzt geändert von Christopher Spies am 03.02.2010 18:35:08, insgesamt 1-mal geändert.

Bernhard
Beiträge: 22
Registriert: 11.09.2009 15:44:19

Re: TCP-Server: Strings

#15 Beitrag von Bernhard »

Christopher Spies hat geschrieben:Das stimmt so nicht! [...]
Vermutlich habe ich mich unklar ausgedrückt, denn ich kann in Deinem posting keinen Widerspruch zu meinem erkennen.
Christopher Spies hat geschrieben:Ich werde Georg helfen, eine entsprechende Tabelle zu erstellen, damit das zukünftig nicht mehr jeder selbst herausfinden muss.
Leider ist es nicht ganz einfach, eine allgemeingültige Auflistung zu finden, denn für verschiedene Fahrzeuge gelten verschiedene Wertebereiche. Liefert zum Beispiel die ID "Spannung" (0x08) bei elektrischen Triebfahrzeugen nach dem Aufgleisen im Normalfall den als Integer interpretierbaren konstanten Wert 15.0 (00 00 70 41), so treten bei dieselelektrischen Triebfahrzeugen veränderliche (echt-)reelle Werte auf. Wie sinnvoll diese sind, ist eine andere Frage und muß wohl von Anwendung zu Anwendung entschieden werden. Im Zweifelsfall ist für die Implementierung von servern und clients einzig die Unterscheidung zwischen 32bit float, 64bit double und Strings mit 8bit breitem Längenpräfix relevant.
Christopher Spies hat geschrieben:Wieso "von Dir"? Bist Du Daniel Schuhmann's Zweitaccount?
Vor meiner Registrierung im Forum, als Daniels Seite noch aktiver als heute war, habe ich ein entsprechendes Kommentar zum Artikel TCP-Datenausgabe für Zusi gepostet. Auch Du hast Dich damals dort beteiligt.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: TCP-Server: Strings

#16 Beitrag von Christopher Spies »

Hallo Bernhard,
Bernhard hat geschrieben:Vermutlich habe ich mich unklar ausgedrückt, denn ich kann in Deinem posting keinen Widerspruch zu meinem erkennen.
ich widerspreche Dir in folgendem Punkt:
Bernhard hat geschrieben:Bis auf fünf IDs vom Typ ShortString (0x4D, 0x5C, 0x5D, 0x60, 0x68) und zwei vom Typ TDateTime (0x32, 0x69) sind alle Daten ursprünglich vom Delphi-Typ Single, der Cs float entspricht.
Es gibt auch Größen, die tatsächlich vom Typ "long integer" (in C) sind, nämlich die Größen 86 bis 89, 91, 95, 106 und 107.
Bernhard hat geschrieben:Leider ist es nicht ganz einfach, eine allgemeingültige Auflistung zu finden, denn für verschiedene Fahrzeuge gelten verschiedene Wertebereiche. Liefert zum Beispiel die ID "Spannung" (0x08) bei elektrischen Triebfahrzeugen nach dem Aufgleisen im Normalfall den als Integer interpretierbaren konstanten Wert 15.0 (00 00 70 41), so treten bei dieselelektrischen Triebfahrzeugen veränderliche (echt-)reelle Werte auf. Wie sinnvoll diese sind, ist eine andere Frage und muß wohl von Anwendung zu Anwendung entschieden werden.
Das ist richtig. Die Wertebereiche hängen vom konkreten Fahrzeug ab. Wie ich schon schrieb, liefern besonders die Größen 7 bis 9 bisweilen seltsame Werte. Für die meisten anderen Größen ist die Interpretation aber verallgemeinerbar.
Bernhard hat geschrieben:Im Zweifelsfall ist für die Implementierung von servern und clients einzig die Unterscheidung zwischen 32bit float, 64bit double und Strings mit 8bit breitem Längenpräfix relevant.
Es gibt auch noch Aufzählungstypen, also 32bit Integer (siehe oben)!
Bernhard hat geschrieben:Vor meiner Registrierung im Forum, als Daniels Seite noch aktiver als heute war, habe ich ein entsprechendes Kommentar zum Artikel TCP-Datenausgabe für Zusi gepostet.
Richtig, das war mir entfallen :O .

Gruß
- Christopher

Bernhard
Beiträge: 22
Registriert: 11.09.2009 15:44:19

Re: TCP-Server: Strings

#17 Beitrag von Bernhard »

Christopher Spies hat geschrieben:Es gibt auch Größen, die tatsächlich vom Typ "long integer" (in C) sind, nämlich die Größen 86 bis 89, 91, 95, 106 und 107.
Du hast recht. 32bit mit float gleichzusetzen, war eine unzulässige Vereinfachung. Die Speicherrepräsentation der von Dir genannten IDs entspricht der einer Ganzzahl und nicht der einer Gleitkommazahl.

Es wäre es interessant, den Bereich und die Bedeutung der möglichen Werte in Eure Tabelle mit aufzunehmen. Zum Beispiel für "Türen" (0x56) oder "PZB-System" (0x59) lassen sich diese Daten relativ einfach aus den Drop-Down-Listen des Fahrzeugeditors ablesen. Warum allerdings auch IDs wie etwa "PZB-Zwangsbremsung" (0x6B) von diesem Typ sind, erschließt sich mir nicht auf den ersten Blick. Entweder es wird tatsächlich zwischen verschiedenen Arten von Zwangsbremsungen unterschieden oder wir sind bei den als boolsche Werte interpretierbaren Ganzzahlen angekommen...

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: TCP-Server: Strings

#18 Beitrag von Roland Ziegler »

Vorsicht mit der Bezeichnung "long int" in C und C++. Das mag unter gewöhnlichem Windows tatsächlich zu 32bit führen. Unter manchen 64bit-Systemen werden daraus aber 64bit-Integer, eine der Hürden bei der Portierung von C/C++-Programmen zwischen Plattformen.

Und wenn wir einmal dabei sind: Auf Plattformen mit Big-Endian, z.B. Java, aber auch manche MicroController gehören dazu, das Drehen der Bytes nicht vergessen. Betrifft Integer und IEEE Floating Point.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: TCP-Server: Strings

#19 Beitrag von Christopher Spies »

Hallo Roland,

Du hast natürlich in allen Punkten Recht.

Gruß
- Christopher

Schorsch
Beiträge: 8
Registriert: 18.01.2010 15:34:05

Re: TCP-Server: Strings

#20 Beitrag von Schorsch »

Hallo zusammen,
Christopher und ich haben die gesammelten Informationen über die physikalischen Daten die über TCP-Schnittstelle abgreifbar sind zusammengefasst.
Bei den Gelb makierten Werte sind wir uns nicht sicher bzw. konnten keine genauere Funktion herausfinden.
Falls jemand noch einen Nachtrag zu diesen Informationen hat, oder allgemeine Verbesserungsvorschläge, nur her damit.
Ich werde versuchen sie so schnell wie möglich in das PDF einzugliedern.

Hier der Link zu dem PDF.

Gruß
Georg

Antworten