Seite 1 von 1

TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 02.08.2022 20:52:50
von nonesense
Betrifft die ID 03, Grund der Zwangs- oder Betriebszwangsbremsung
Nach Geschwindigkeitsüberschritung wird 6 (v-Max-Überwachung) übertragen, der Wert nach aufheben der Zwangsbremsung nicht mehr zurückgesetzt.
In Zusi Display äußert sich das darin, dass die ZB zwar nicht her visualisiert wird, der Alarm aber weiter abgespielt wird.

Habe die Strecken zu Testzwecken auf ETCS Levbel 1 umgebaut.
Zug: 69219 mit Vectron.
Gefahren mit Autopilot.

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 02.08.2022 21:03:15
von Carsten Hölscher
Den Alarm spielt aber Zusi selbst, das hat mit TCP nichts zu tun.

Carsten

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 02.08.2022 21:23:34
von nonesense
Ah OK, es ist nur der Infoton, der extern angefordert werden kann.
Wie auch immer, ist der Ständige Alarm eine Begleiterscheinung.

Nachtrag:
Ich schließe nicht wegen des Alarms darauf, dass der Wert nicht zurückgesetzt wird! Das habe ich schon im TCP gesehen.

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 03.08.2022 22:16:03
von nonesense
Das scheint generell immer zu sein. Unabhängig von Autopilot oder nicht.
Das Problem betrifft auch die Zwangsbebetriebsbremsung, ID 65 -> 05 -> 16.

Der Alarm wird bei Auftreten einer ZB mit Autopiliten solange abgespielt, bis man manuell eine wetere ZB verursacht und diese dann aufgehoben wird. Das ist aber wohl ein anderer Fehler an einer anderen Stelle.

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 04.08.2022 08:00:42
von Jens Haupert
Hallo,

der Alarm bleibt auch "hängen", sprich dudelt dauerhaft, bis er erneut ansteuert wird, wenn man mit im schnellen Vorlauf (F4) eine solche Stelle kommt.

Grüße
Jens

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 20.08.2022 12:25:33
von nonesense
Wie sieht es denn inhaltlich aus, mit dem von mir berichteten Problem?
Ich kann ja verstehen, wenn es, sofern es als Fehler anerkannt wird, keine hohe Priorität hat. Aber ich würde schon gerne wissen, ob ich in meinem Code den Wert Null (Keine ZB) in der ID 02 0A 65 05 03 berücksichtigen kann oder ob ich einen Workaround finden muss.
Bis mein Code öffentlich wird, wird noch auch trotz Dürre noch viel Wasser den Rhein runter laufen, insofern kann ich damit leben, wenn eine Lösung nur langfristig kommt. Ich muss es aber wissen.

Sollte beabsichtigt sein Zusi dahingehend nicht anzupassen, wäre meine Bitte den Wert "0: Keine Zwangsbremsung" aus der Doku zu entfernen. Das ist für Entwickler sonst irreführend.

LG
Jens

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 21.08.2022 17:33:34
von Carsten Hölscher
Mach mal nichts - außer den Fahrplan zu nennen, bei dem das auftrat.

Carsten

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 21.08.2022 22:01:52
von nonesense
Das ist der Fahrplan Lehrte-Harburg_2018_13Uhr-22Uhr. Ich habe den aber für Tests provisorisch auf Level 1 umgebaut.
Habe ein Debugausgaben angefertigt, die den gesamten Knoten 05 (System aus der ETCS-Familie - Betriebsdaten) ausgibt. Die, wo sich nur Geschwindigkeiten ändern habe ich rausgeschnitten:

Code: Alles auswählen

01    level:  "level_1"
02    ActiveMode  "mode_FS"
09    TargetSpeed:  0
0B    brakeApplicationPointDistance:  -1383.54
0A    targetDistance:  78
0C    releaseSpeed:  20
0D    permittedSpeed:  28
0E    AlertSpeed:  32
0F    serviceBreakSpeed:  33
10    EmergencyBreakSpeed:  35
11    permittedSpeedReducing:  true
13    trackAheadFreeRequestState:  "taf_notActive"
08 01 radio:  "radio_connectionEstablised"
======================================================================
01    level:  "level_1"
02    ActiveMode  "mode_FS"
09    TargetSpeed:  0
0B    brakeApplicationPointDistance:  -1384.85
0A    targetDistance:  77
0C    releaseSpeed:  20
0D    permittedSpeed:  28
0E    AlertSpeed:  32
0F    serviceBreakSpeed:  33
10    EmergencyBreakSpeed:  35
11    permittedSpeedReducing:  true
13    trackAheadFreeRequestState:  "taf_notActive"
16    reasonOfSrvBrakeEnumeration:  "reason_overSpeed"      <<<<<<<<<<
08 01 radio:  "radio_connectionEstablised"
1A 01 textMessage:  "reason_overSpeed"                      <<<<<<<<<<
======================================================================
01    level:  "level_1"
02    ActiveMode  "mode_FS"
03    ReasonOfEmrBreak  "reason_overSpeed"                  <<<<<<<<<<
04    reasonOfEmrBreakText  ""
09    TargetSpeed:  0
0B    brakeApplicationPointDistance:  -1461.99
0A    targetDistance:  0
0C    releaseSpeed:  20
0D    permittedSpeed:  0
0E    AlertSpeed:  18
0F    serviceBreakSpeed:  20
10    EmergencyBreakSpeed:  20
11    permittedSpeedReducing:  true
13    trackAheadFreeRequestState:  "taf_notActive"
16    reasonOfSrvBrakeEnumeration:  "reason_overSpeed"      <<<<<<<<<<
08 01 radio:  "radio_connectionEstablised"
1A 01 textMessage:  "reason_overSpeed"                      <<<<<<<<<<
======================================================================
01    level:  "level_1"
02    ActiveMode  "mode_FS"
03    ReasonOfEmrBreak  "reason_overSpeed"                  <<<<<<<<<<
04    reasonOfEmrBreakText  ""
09    TargetSpeed:  0
0B    brakeApplicationPointDistance:  -1461.99
0A    targetDistance:  0
0C    releaseSpeed:  20
0D    permittedSpeed:  0
0E    AlertSpeed:  18
0F    serviceBreakSpeed:  20
10    EmergencyBreakSpeed:  20
11    permittedSpeedReducing:  true
13    trackAheadFreeRequestState:  "taf_notActive"
08 01 radio:  "radio_connectionEstablised"
1A 01 textMessage:  "reason_overSpeed"                      <<<<<<<<<<
======================================================================
01    level:  "level_1"
02    ActiveMode  "mode_FS"
09    TargetSpeed:  0
0B    brakeApplicationPointDistance:  -306.226
0A    targetDistance:  1155
0C    releaseSpeed:  20
0D    permittedSpeed:  107
0E    AlertSpeed:  111
0F    serviceBreakSpeed:  112
10    EmergencyBreakSpeed:  114
11    permittedSpeedReducing:  true
13    trackAheadFreeRequestState:  "taf_notActive"
08 01 radio:  "radio_connectionEstablised"
Es ist offenbar so, dass die betreffenden IDs vor und nach den Zwangsbremsungen nicht mit übertragen werden.

Gruß
Jens

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 22.08.2022 00:14:01
von Carsten Hölscher
Also ich bräuchte bitte einen reproduzierbaren Fall mit Anleitung, möglichst im offiziellen Bestand.

Carsten

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 22.08.2022 20:59:16
von nonesense
OK,
mit DGS 58581 aus Lehrte-Bardowick_FiktiverTakt_2018_04Uhr-14Uhr lässt sich das schnell reproduzieren.

Gruß
Jens

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 23.08.2022 00:51:31
von Carsten Hölscher
Hier liegt vermutlich ein Mißverständnis vor. Das Attribut kommt überhaupt nur im Paket 65... vor, wenn eine Zwangsbremsung anliegt.

Carsten

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 23.08.2022 07:55:22
von nonesense
Dann liegt aber eine Fehler in der Doku vor, denn diese sieht den Zustand ohne anstehender Zwangsbremsung explizit vor:
Zusi Doku 11.3.3 hat geschrieben:Grund der Zwangs- oder Betriebszwangsbremsung
0: Keine Zwangsbremsung
6: v-Max-Überwachung
7: Funktionsprüfung
10: Rechnerausfall
11: ETCS-Nothalt überfahren
15: ETCS-Halt überfahren
16: ETCS: Stillstands-
/Rücklaufüberwachung ausgelöst
17: ETCS: nicht quittiert
18: ETCS: Funkausfall
19: ETCS: Balisenstörung
20: ETCS: manueller Levelwechsel
27: Allgemeine Störung
28: Stromversorgung fehlt
Es gibt ja noch mehr Attribute, deren Wert nur durch deren Absens im nächsten Paket wieder auf Default zurückgesetzt werden. Als ein solches in der Doku zu erkennen ist z.B. das Attribut 0F in den ETCS-Betriebsdaten:
Zusi Doku 11.3.3 hat geschrieben:Zugneustart (nur Zusi → Client)
1: Zug wurde neu gestartet bzw. neu übernommen
Gruß
Jens

Re: TCP: Grund der ETCS-ZB wird nicht zurückgesetzt

Verfasst: 23.08.2022 14:33:29
von Carsten Hölscher
0 ist der interne Wert für den Zustand. Bin jetzt nicht 100% sicher, ob er evtl. auch mal verschickt wird.

Carsten