Fragen zur TCP-Schnittstelle

[Carsten Hölscher]

Kam nur bei Indusi I54 vor? Dann sollte es mit der beta von eben laufen.

Carsten

[Wolfgang E.]

Vermutlich war das Unterscheidungskriterium I54 und nicht der angeforderte Zugkraftsollwert pro Achse. Macht auch mehr Sinn. Auf jeden Fall habe ich das Phänomen mit der neuesten Software nicht mehr beobachtet und gehe davon aus, dass der Fehler behoben ist. Danke!

Ob das führende Fahrzeug einen Antrieb hat, kann ich mittlerweile ermitteln und auch welches das erste Fahrzeug mit dem Eintrag Mehrfachtraktion hinter dem Führenden ist und ob es einen Antrieb hat. Damit sollte die Umschalterei dann klappen.

Viele Grüße Wolfgang

[Wolfgang E.]

Um die Zugkräfte der einzelnen Fahrzeug und Antriebe zu bekommen, könnte man vermutlich die Werte aus Status Zugfahrdaten (02 0A AB) lesen. Das würde ich aber auf später verschieben.

Ich würde gerne auch ZUB und ETCS auf meinem Hardware-MFA darstellen. Nun fehlen dort natürlich einige Leuchtmelder, so dass ich Kompromisse eingehen muss. Von diesen drei Systemen kommt ja immer nur eins gleichzeitig vor, richtig?

Zunächst LZB und ZUB: Wenn das entsprechende Ü aktiv ist, werden die Signale für Ü, G und S an die MFA geschickt. GStEin würde ich auf B legen und die Störung auf den Sammelstörmelder des Führertischs.

Für die ETCS würde ich schauen, ob der aktive Level größer 1 ist, um das Ü leuchten zu lassen? Dann schicke ich die Werte für Sollgeschwindigkeit und Zielgeschwindigkeit und -entfernung an das MFA? Sonst noch?
Wie ist es in den echten MFA mit ETCS in 101 (Versuch), 401 und 411/415 umgesetzt (gewesen)? Wie ist es in ZusiDisplay für den ICE-T umgesetzt?

Viele Grüße Wolfgang

[nonesense]

Eine Frage zur ETCS ID 00 04 -> 00 08 (ETCS-Quittierschalter)
Kann es sein, dass diese ID nicht oder nur in richtung DMI funktioniert?
Das Übertragen von verlegt (2), gefolgt von Grundstellung (2) hat keinen Effekt.

Eine Bitte zur ETCS ID 00 05 -> 00 14 (Override aktiv)
Wäre es möglich diesen, neben dem einzigen Wert Override aktiv (1), noch um den Wert Override nicht aktiv (2), zu ergänzen?

Gruß
Jens

[Carsten Hölscher]

1: Ja, richtig erkannt. In die andere Richtung müsste man wohl ein Tastaturkommando schicken, oder wie löst ZD das?

2: Wär kein Problem, aber ist halt dann der Fall, wenn das Attribut fehlt.

Carsten

[Jens Haupert]

1: Ja, richtig erkannt. In die andere Richtung müsste man wohl ein Tastaturkommando schicken, oder wie löst ZD das?

Genau.

[Wolfgang E.]

Eine neue Herausforderung, den Betrieb mit Zusi schöner zu machen:
Wen man die Simulation startet, kennt Zusi natürlich die Stellungen der Schalter des Führertischs nicht, da sie nur einmal beim Starten übertragen werden und danach nur noch bei Änderungen. Zum Startzeitpunkt interessiert sich Zusi aber noch nicht dafür und verwirft die Informationen. Also bin ich hingegangen und werte die Informationen "Status Ladepause" und "Zug neu übernommen" aus und sende dann einmal alles. Leider ist auch das noch zu früh, da diese Infos einmal nach dem Laden des Fahrplans kommen, Zusi die Befehle aber erst nimmt, wenn der Führerstand auf dem Bildschirm erscheint.
Gibt es dafür ein brauchbares Kriterium? Aktuell habe ich eine unbenutztes Taste des Führertisches mit der Sendeaufforderung belegt.

Viele Grüße
Wolfgang

[Carsten Hölscher]

Du hast doch für das Pult einen eigenen Client programmiert? Der müsste doch die Schalter kennen?
Oder welcher Anwendungsfall liegt vor?`

Carsten

[F. Schn.]

Also ich hab etwas gebraucht, deswegen wiederhole ich mal:

Du hast einen TCP-Client (Fahrpult), der die Stellung von Haptischen Schaltern an Zusi überträgt.
Die Stellung der Schalter werden nur an Zusi übertragen, wenn sie sich ändern.
Wenn der TCP-Client verbunden ist, während der Zug noch nicht aufgegleist ist, verwirft Zusi diese Informationen.

Also mein Vorschlag, ohne es getestet zu haben:
Ich vermute, dass Zusi das Paket "Status Zugverband" sendet, sobald der Zug aufgegleist wurde oder wendet.

[Wolfgang E.]

Der Client kennt natürlich die Schalterstellungen. Aber so wie Zusi das mit den Anzeigen auch macht, werden nur Änderungen übertragen. Ich suche nach einem Kriterium, um die Schalterstellungen alle einmal zu senden. Status Zugverband wird gesendet, sobald die Simulation geladen ist, also vor dem Aufgleisen des Zuges und somit, bevor sich Zusi für Schalterstellungen interessiert.

Zweites Problem: Wenn ich zu einem anderen Zug wechsele, werden die Anzeigen von Zusi nicht zurückgesetzt. Wenn ich beispielsweise zuerst einen Zug in Indusi-Stellung U fahre und danach einen in Stellung O, so bleibt der blaue LM 55 an. Mit welchem Ereignis im Protokoll lösche ich sinnvollerweise alle Anzeigen? Lösche ich zu früh, werden die Anzeigen möglichrweise nochmal gesetzt. Lösche ich zu spät, so werden die neuen Anzeigen ebenfalls gelöscht.

Viele Grüße
Wolfgang

[nonesense]

Mit welchem Ereignis im Protokoll lösche ich sinnvollerweise alle Anzeigen?

Ich nutze dafür die Änderung der Zugnummer.
Weiter trenne ich dem Moment die Verbindung und baue sie neu auf. So zwinge ich Zusi mir alle gefragten Daten neu zu senden.

Gruß
Jens

[F. Schn.]

Zweites Problem: Wenn ich zu einem anderen Zug wechsele, werden die Anzeigen von Zusi nicht zurückgesetzt. Wenn ich beispielsweise zuerst einen Zug in Indusi-Stellung U fahre und danach einen in Stellung O, so bleibt der blaue LM 55 an.

Also alle anderen Programme wie z.B. ZusiMeter bekommen das auch hin. Da wären also mehr Details erforderlich, u.A. kann man ja die PZB ja mit verschiedensten IDs auslesen.

Mit welchem Ereignis im Protokoll lösche ich sinnvollerweise alle Anzeigen?

Sinnvollerweise mit gar keinem. Jeder Leuchtmelder wird individuell gelöscht. Wo das nicht geht, müsste man sich individuell anschauen, warum es nicht geht. Gut möglich, dass es da bestimmte Situationen gibt, über die man noch mal getrennt reden muss.

[Wolfgang E.]

Zweites Problem: Wenn ich zu einem anderen Zug wechsele, werden die Anzeigen von Zusi nicht zurückgesetzt. Wenn ich beispielsweise zuerst einen Zug in Indusi-Stellung U fahre und danach einen in Stellung O, so bleibt der blaue LM 55 an.

Also alle anderen Programme wie z.B. ZusiMeter bekommen das auch hin. Da wären also mehr Details erforderlich, u.A. kann man ja die PZB ja mit verschiedensten IDs auslesen.

Ich benutze 0002 000A 0065 0003 0030 für alles größer I60 und für I54 und I60 gezwungenermaßen 0002 000A 0065 0003 0008. Für die anderen beiden Melder entsprechend. Das Ganze funktioniert aber auch mit LZB-Führungsgrößen, die stehen bleiben, wenn man während der LZB-Führung den Zug auf eine Baureihe ohne LZB-Ausrüstung wechselt.
ZusiDisplay werde ich mir anschauen. Das ist nicht so einfach, weil man bei ZusiDisplay die Baureihe beibehalten muss. Aber ich werde schon Züge mit gleichem Tfz und unterschiedlichen Indusi-Stellungen finden.

Sinnvollerweise mit gar keinem. Jeder Leuchtmelder wird individuell gelöscht. Wo das nicht geht, müsste man sich individuell anschauen, warum es nicht geht. Gut möglich, dass es da bestimmte Situationen gibt, über die man noch mal getrennt reden muss.

Wenn jeder LM bei einem Zugwechsel von Zusi gelöscht wurde, hätte ich kein Problem. Vermutlich ist die von Jens realisierte Lösung am sinnvollsten. Einfach trennen und neu verbinden, wenn die Zugnummer sich ändert. Das löst leider noch nicht das Problem, wie man erfährt, dass Zusi nun bereit ist, Befehle zu empfangen.

Viele Grüße Wolfgang

[F. Schn.]

Gut, ZusiMeter wird mit Sicherheit 0002 000A 0065 0003 0008 auswerten. Wenn du von I60 auf PZB90 wechselst, wird sich 0002 000A 0065 0001 ändern. Den Rest werde ich mir die Tage mal anschauen. Beim Neuverbinden bin ich ehrlich gesagt skeptisch.

[HaraldB]

Zusi wird doch wohl den Führerstand mit allen Schaltern in Grundstellung aufgleisen (ggf. "In Grundstellung verlegt"), oder verstehe ich das Problem nicht?

Wenn man da was Spezielles will (z.B. Batteriehauptschalter aus), muss man doch ohnehin eigene Führerstände, Fahrzeuge und Fahrpläne erstellen und verwenden.

Im generischen Fall kommt man an den Zugfahrplan über 0002.000C.0001 und kann aus der Zugdatei den Aufgleiszeitpunkt auslesen.
Die Fahrplan-Uhrzeit kommt dann in der konfigurierten Periode auf 0002.000A.0023 und/oder (0011..0013). Zur Aufgleiszeit sollte auch der zurückgelegte Weg 0002.000A.0019 in allen sinnvollen Fällen auf einen Wert größer 0 gehen.

Wird der Zug rollend aufgegleist/übernommen (Geschwindigkeit 0002.000A.0001 ungleich 0), sind vielleicht nicht alle Stellungen schaltbar (z.B. Rischa). Da kann man anhand Betätigungsvorgang 0002.000B überprüfen, ob ein Schalter geschaltet hat und welche Funktionen ausgelöst wurden.

Im Stand ist u.U. der Türwahlschalter verlegt. Das müsste durch Daten zu Status Türsystem 0002.000A.0066 angezeigt werden, oder man dreht den ein- bis viermal auf links (oder rechts) bis er da ist wo er soll.

Was soll sich dem am Verhalten des Sim und am TCP-Protokoll ändern? Man kann die Netzwerkeinstellung "Daten nur bei Änderungen schicken" abwählen, vielleicht bekommt man da den Grundzustand in geeignetem Umfang zur geeigneten Zeit übermittelt - aber das habe ich bisher noch nicht probiert/gebraucht.

Wichtig ist, wann kein Wert als unverändert und wann als 0 gilt.
Das muss man im Kontext behandeln, insbesondere für Zugbeeinflussung, Türsystem und Betätigungsvorgänge.
In der Doku steht dann

Wenn es eine Änderung [ ... ] gab, wird immer das komplette Paket übertragen ...

Wenn also ein Status Zugbeeinflussung 002.000A.0065.0001 kommt, geht erstmal kurz eben schnell alles "darunter" auf 0 und wird ggf. durch folgende Attribute und weitere Knoten neu gesetzt.
Für die Betätigung ist das ja völlig natürlich, für "statische" LM vielleicht nicht.

Was ich nicht weiß: Hab ich das Thema verfehlt?

[F. Schn.]

Zur ersten Frage denke ich in Teilen ja, aber der Lösungsvorschlag birgt zusätzliche Probleme.

Es geht wie gesagt darum, dass ein TCP-Client nicht ständig alle Haptischen Schalterstellungen an Zusi senden will. Er muss stattdessen erkennen, wann er ALLE Stellungen an Zusi auf einmal senden muss. Das muss er machen, nachdem der Zug aufgegleist wird (nicht schon nach der Erstauswahl im Hauptmenü) und nachdem der Zug die Fahrtrichtung wechselt. Wenn er das nicht macht, hat man ein Problem, wenn vor der Zugwende der Hebel auf "Bremsen" steht, nach der Zugwende aber Zusi den Standardwert aus dem Führerstand übernimmt.

Und da bei der nächsten Zugwende der Hebel eventuell auch auf etwas anderem als "Bremsen" stehen kann, hilft der selbst-Umbau von Führerständen leider nicht.

Und bei Wenden hilft der Trick mit der Aufgleiszeit auch nicht, zumal er auch nicht hilft, wenn der Zug verspätet aufgegleist wird. (Und er ist Aufwendig.)

Man bräuchte also ein Paket, dass sich selten ändert, und das sich mindestens dann ändert, wenn der Zug aufgegleist wird und er wendet. Und die Kriterien dürfte das Zugbildungs-Paket 0002 000A 008E erfüllen. Und wenn nicht, wäre der implizite Wunsch, ein Paket zu machen, dass eben gesendet wird, nachdem Zusi einen Führerstand neu geladen hat (= aufgegleist oder gewendet).

[HaraldB]

Für den generischen Fall (beliebiger Zug) wird wohl ein einzelnes Kriterium, ein einzelnes Paket, nicht reichen.

Für mein ATO-Spielzeug führe ich einen "Digital Twin" des Zug-Zustands und kann daher aus einer Kombination von Zustandsänderungen über die Zeit in Zusammenhang mit Laufweg, Streckenkilometer, Fahrplan, Zug und Streckendateien meine Schlüsse ziehen.

Trotzdem sind Wenden zugegeben "tricky", denn es kann sich ja sowohl der Zugverband ändern als auch der Führerstand (Lok <-> Steuerwagen, Kombi-Schalter stellungsabhängig zu zeitabhängig, etc.), bei überraschenderweise gleichbleibendem Laufweg der Zugspitze. Aber das eben im Regelfall nur, wenn der Zug steht und im Fahrplan im begrenzten Umkreis des aktuellen Kilometerstands, Laufwegs und Signals ein Richtungswechsel und/oder eine Änderung des Zugverbands aufgeführt ist.

Ich müsste mal bei einer Fahrt im RegioShüttle schauen, ob meine Detektion ausreicht.

[Wolfgang E.]

Im Prinzip hätte ich gerne eine Information von Zusi, mit der es alle Schalterstellungen anfordert. Die also gesetzt wird, wenn der Zug gerade aufgegleist worden ist. Also der Moment, in dem die Führerstandsgrafik auf dem Bildschirm erscheint.
Zudem wäre ein Signal gut, mit dem man Zusi auffordern könnte, einmalig alle Anzeigewerte zu schicken. Dann würde ich aufgrund der Aufgleissituation alle Anzeigen bei mir löschen und dann von Zusi neu anfordern.

Solange es das alles nicht gibt, werde ich mir für das Senden der Schalter mit dem Betätigen von Zuglicht Ein behelfen und über die Lösung von Jens nachdenken sowie über die Idee mit dem zurückgelegten Weg von Harald.

[F. Schn.]

Grundsätzlich wäre da eine Erweiterung der ID 0002 000C 0005 naheliegend.

In der Gegenrichtung gibt es ähnliche Knoten unter 0002 010B 000E. (Da ist ein Fehler in der Doku, da fehlt der Link und der sollte auf 1D anstatt 1C verweisen.)

(Wie gesagt schaue ich mir das aber noch mal an, einerseits die PZB und dann der Einwand, dass die Zugbildung bei Zugwende nicht aktualisiert wird, ob ich da jeweils einen Tipp geben kann, was man schon jetzt machen könnte.)

[Wolfgang E.]

Ich schreibe jetzt einmal alle Bediendaten wenn
- die Führerstandsdatei sich ändert oder
- Zug neu übernommen von 1 auf 0 wechselt oder
- Ladepause zuende gesetzt wird oder
- der zurückgelegte Weg von 0 auf einen anderen Wert wechselt.

Damit habe ich bisher, also zwei Stunden ausprobieren, gute Erfahrungen gemacht. Erster Zug geht, Zug- oder Fahrplanwechsel geht und Zugwende auch. Vielen Dank für die Hinweise.

Viele Grüße
Wolfgang