Zusi-Forum

Nein, natürlich nicht. Ich bin bei den offiziellen Dateien geblieben.
Den Angleicher als solchen habe ich aber auch gar nicht bedient.
Die Angleicher-Thematik war ja nur ein Seiteneffekt; die H-Bremse ist doch das Thema hier.

Grüße
Michael

Du müßtest schon meinen Testfall nachspielen, wenn wir hier weiter kommen wollen.

Carsten

Dann mache ich auch das. Kleinen Moment bitte.

EDIT: Vielleicht ist es bereits etwas spät, aber ich finde im Reiter "Eingabegeräte" keinen Eintrag "Angleicher". Der war doch dort anzutreffen? Oder habe ich Tomaten auf den Augen?

Grüße
Michael

Bremse überlädt auch, wenn ich Angleicher von * (Default) zum Beispiel auf I verlege.

Beim Versuch, nach der Schnellbremsung und Wiederanfahren über die 50 km/h-Umschaltschwelle die H-Bremse per Eingabetool anzusteuern (Stufe 5), kommt reproduzierbar der Socket-Fehler, danach wird "die Verbindung erfolgreich geschlossen". Wenn ich das Eingabetool dann neu starte und verbinde, funktioniert die H-Bremse fürs Erste. Führe ich erneut eine Schnellbremsung aus und probiere einen weiteren Test, gibt es vorgenannten Socket-Fehler.

Grüße
Michael

Also hast Du auch in der offiziellen 218 den Angleicher auf eine fahrpultinterne Zuordnung umgeändert?

Es geht um die ftd-Datei.

Carsten

Wenn ich die Arbeitsanweisung jetzt richtig verstehe, soll also in der ftd-Datei der Eintrag der Tastaturzuordnung für die Angleicher-Baugruppe von "Führerbremsventil" auf "Fahrpultintern_01" geändert werden, korrekt?

Beobachtungen:
- Bremse überlädt nach erster Bremsung und Auslösen (auf 6 bar)
- Bei Schnellbremsung wird etwa bei Fahrzeugstillstand ein "TCP-Socket-Fehler #0" gemeldet, das TCP-Tool muss neu gestartet werden.
- Danach Beschleunigen über 60 km/h und erneutes Schnellbremsen bis zum Stillstand. Beim Versuch, mittels TCP-Tool die Bremse zu lösen, Zugriffsverletzung im Simulator.

Ich gebe zu, dass mit dem wiederholten Aussteigen des TCP-Tools sowie dem letztgenannten Effekt ein Nachstellen und sinnvolles Analysieren nicht gut möglich ist. Ist das TCP-Tool nur leidlich "betriebsstabil", oder führt hier ein Zusi-Programmfehler zu diesen Problemen? Bitte hier weitere Instruktionen zum Vorgehen, um das Problem weiter einkreisen zu können.

Grüße
Michael

Hat jemand Drittes mal die Muße, das zu testen?

Carsten

Ich teste das mal.

Es ist einfach derselbe Bug/undokumentierte Funktionalitaet wie beim Angleicher, nur mit der Baugruppe "Dynamische Bremse deaktivieren". Leicht reproduzierbar mit Tastaturzuordnung = Tast_DynBremse, Tastaturaktion = TastAkt_Absolut und ueber "Raste-Nr." nacheinander die Werte 0, 9, 0 schicken.

Ach die Baugruppe hatte ich gar nicht gesehen - wozu braucht man die denn hier? Die sollte man dann auch auf einen internen Kanal legen.

Carsten

Die echte Lok hat halt einen Schalter, mit dem man die Hydrobremse stillsetzen kann. Da ich dachte, dass ich damit irgendwelchen Hardcore-Simulanten eine Freude machen würde, hatte ich den seinerzeit eingebaut.

Wenn diese bei Führerbremsventil bzw. Dyn-Bremse untergebrachten Doppelfunktionen Angleicher und "Dyn-Bremse deaktivieren" so problematisch sind, dann sollten sie vielleicht schon Zusi-seitig von der Tastaturzuordnung Führerbremsventil / Dyn-Bremse getrennt werden, anstatt dass jeder Betroffene diese Probleme bei sich zuhause privat fixen muss.

Es betrifft nur die Ansteuerung per TCP und dll. Da kriegt Zusi die auf dem gleichen Kanal liegenden Kommandos für die Geräte nicht auseinandersortiert.

Carsten

Also ein Problem in der TCP-Schnittstelle, verstehe ich das richtig?
Siehst Du die Möglichkeit, das in absehbarer Zeit zu beheben?

Grüße
Michael

Die Funktion "Dyn. Bremse aus" wird von ZD auch beim KISS via Tastendruck angesteuert.

Grüße
Jens

Da sind aber keine Probleme bekannt, oder? Der hat ja auch keine dyn. Bremse als separaten Hebel.

Workaround für Fahrpultbastler wie gesagt: In der ftd-datei umlegen auf fahrpultinterne Zuordnung. Man braucht ja eh eine spezielle ftd-datei für das Fahrpult.

Carsten

Carsten Hölscher hat geschrieben:Da sind aber keine Probleme bekannt, oder? Der hat ja auch keine dyn. Bremse als separaten Hebel.

Mir ist nur das Problem bekannt, dass bei Drücken von [5] auf dem Num-Block im FLIRT-Fst die dyn. Bremse deaktiviert wird und bei nochmaligem Drücken wieder aktiviert. Das Problem hatte Wolfgang Hütter am Anfang des Threads schon mal beschrieben.

Grüße
Jens

Carsten Hölscher hat geschrieben:Workaround für Fahrpultbastler wie gesagt: In der ftd-datei umlegen auf fahrpultinterne Zuordnung. Man braucht ja eh eine spezielle ftd-datei für das Fahrpult.

Was ist der empfohlene Workaround fuer Autoren von TCP-Zusatzprogrammen, die mit beliebigen Fuehrerstaenden funktionieren sollen?

Ergänzende Anmerkung: Üblicherweise ist doch keine geänderte ftd-Datei erforderlich, um das Fahrpult über TCP anzubinden. Oder übersehe ich hier etwas?

Und meine Anregung, einen speziellen "Fahrpult-Modus" programmseitig zu hinterlegen, ist ja seinerzeit verworfen worden.

Grüße
Michael

@Johannes: Gibt es denn sowas bisher?

Mir ist noch kein Fahrpult begegnet, bei man nicht die ftd-Datei anfassen sollte. Bei der 218 z.B. das Zurückfedern und die mechanischen Koppelungen. Die hat das Pult ja in Hardware, so dass man sie nicht doppelt softwareseitig braucht.

Carsten

Carsten Hölscher hat geschrieben:@Johannes: Gibt es denn sowas bisher?

Ist Steven nicht mit einer derartigen Schnittstellenimplementierung zugange? Ich habe das dunkel in Erinnerung. Möglicherweise kann Edwin hierzu Näheres sagen, sofern er mitlesen sollte.

Mit Blick auf potentielle weitere Anwendungen wäre es natürlich schon wünschenswert, Fehler in Implementierungen zu beseitigen, anstatt die derzeitigen und künftigen Nutzer in Workarounds zu schicken. Wenn das eigentliche Problem fachlich durchdrungen ist, und da sind wir ja wohl auf dem Wege, dann müsste die Behebung doch machbar sein, oder?

Grüße
Michael