PZB Bug in allen vR Loks seit BR111

Disclaimer:
0. Zunaechst mal habe ich NULL Hoffnung, dass vR diese Bugs in den alten Produkten repariert. Sie wissen z.B. mittlerweile sehr wohl wie man die Startprogrammbefreiung korrekt einbaut, haben diese Bugs aber in BR111 und BR143 belassen (bei der BR111 kann man den Bug durch den Kauf der ORoten mit Quelltext selber fixen). Ich habe den Bug, den ich hier beschreibe bei mir in der 132/232 und der 112 gefixt (durch Wrapperskripte, die die Funktion OnControlValueChange abfangen) und werde nach und nach Wrapperskripte fuer alle anderen Loks erstellen. Allerdings kann ich die nicht anbieten, da VR solche Sachen unterdrueckt. Ich habe seinerzeit die mit der ORoten BR111 publizierten Luaskripte verbessert, aber der Eintrag wurde einfach gesperrt. Das ist vielleicht nachvollziehbar, da kommerzielle Produkte eben aufwendig getestet werden muessen, und ein Fehler der in der 120, 103, E03, 243, 156, 112 etc. ueberall vorhanden ist, wuerde einen enormen Testaufwand erzeugen. Und Support von Fremdaenderungen ist nervig bzw. Suizid, weil man ja die Qualitaet der Aenderung ueberhaupt nicht kennt!
1. Der Bug ist ein Fehler in der PZBFREI-Logik seit der BR111 (dort nicht), also in allen Produkten wie z.B. BR232 bis zur aktuellen BR112! (Getestet mit 232, 243, 112)
2. Ich bitte, dass jemand den Bug wenigstens bei der BR112 nachvollzieht und an den VR Support meldet (ich habe keine Supportmoeglichkeit auf der VR Webseite gefunden). So kann er hoffentlich wenigstens in den aktuellen Loks UND ALLEN ZUKUENFTIGEN gefixt werden.

Bugbeschreibung:
Die VR Loks nach der BR111, die aber alle auf dem PZB Code der BR111 aufsetzen, haben einen Programmierfehler in der PZB-FREI Logik, durch den man bei einer Befreiung aus einer Zwangsbremsung nach verpasster Wachsambetaetigung am 1000Hz aus der Sicht des Skriptcodes auch gleichzeitig eine Befreiung aus einer restriktiven Ueberwachungskurve erzeugt. Dadurch bekommt man am naechsten scharfen 500Hz Magnet IMMER eine Zwangsbremsung.

Technisches [fuer Herrn Golz/vR]:

Die PZBFrei-Logik innerhalb OnControlValueChange funktioniert ungefaehr so:

Bei der BR111:
Falls Taste Frei gedrueckt
___Falls TasteFreibereitsgedrueckt=FALSE und ZWBaktiv=TRUE und weitere Bedingungen
______behandle Variante Frei aus ZWB
______ZWBaktiv=FALSE
______TasteFreibereitsgedrueckt=TRUE <--- verhindert dass die anderen beiden Falls-Bloecke abgearbeitet werden
___Falls TasteFreibereitsgedrueckt=FALSE und ZWBaktiv=FALSE und weitere Bedingungen:
______behandle Variante Frei aus 1000Hz
______Markiere Befreiung als unzulaessig falls kommender scharfer 500Hz
______TasteFreibereitsgedrueckt=TRUE
___Falls TasteFreibereitsgedrueckt=FALSE und ZWBaktiv=FALSE und weitere Bedingungen:
______behandle Variante Frei aus restriktive Ueberwachung
___fertig
fertig

BR232, BR243, BR112, und hoechstwahrscheinlich 120, 103, E03, 110, 140, 156, 243:
Hier ist folgendes passiert (weiss ich als Softwareentwickler aus Erfahrung zu 99% Gewissheit). Bei den Entwicklungen nach BR111 schaute Herr Golz auf diese komplexen if-Schleifen und sah die gleiche Bedingung TasteFreibereitsgedrueckt=FALSE in allen Falls-Zweigen. Wenn die Bedingungen in den Schleifen sich wechselseitig ausschliessen, gewinnt man an Performance wenn man die Abfrage rauszieht. Wenn man nach einer langen Zeit auf seinen eigenen Code schaut, passiert genau sowas!

Falls Taste Frei gedrueckt
___Falls TasteFreibereitsgedrueckt=FALSE <- Abfrage wurde herausgezogen. Damit fehlt aber die "Barriere" zwischen den kommenden Falls-Zweigen
______Falls ZWBaktiv=TRUE und weitere Bedingungen
_________behandle Variante Frei aus ZWB
_________TasteFreibereitsgedrueckt=TRUE <--- verhindert NICHT MEHR dass die anderen beiden Falls-Bloecke abgearbeitet werden!
_________ZWBaktiv=FALSE <--- dadurch wird der einer der naechsten Zweige (meistens Befreiung aus restriktiver Ue.) AUCH aufgerufen
______Falls ZWBaktiv=FALSE und weitere Bedingungen:
_________behandle Variante Frei aus 1000Hz
_________Markiere Befreiung als unzulaessig falls kommender scharfer 500Hz
_________TasteFreibereitsgedrueckt=TRUE
______Falls ZWBaktiv=FALSE und weitere Bedingungen:
_________behandle Variante Frei aus restriktive Ueberwachung
______fertig
___fertig
fertig

Danke fuer den Hinweis. Trotzdem ist es besser, wenn ein paar erfahrene! Leute das erst verifizieren koennen. Man muss das so testen, dass man in freier Fahrt (aus dem Startprogramm raus) auf ein rotes Hauptsignal zufaehrt und am Vorsignal nicht mit Wachsam bestaetigt. Nach der noetigen Befreiung kriegt man am 500er eine erneute ZWB, mit dem Hinweis vom Hilfesystem, dass man sich unerlaubt aus einer restriktiven Ueberwachung befreit haette.

Kannst Du das bestaetigen?

@Steinchen

- Dem kann ich nicht zustimmen. Zumindest bei meinen gekauften vR PRodukten wird mit vorbildgerechter PZB geworben. Die PZB war vielleicht 2012 in Beta. Die LZB ist sicherlich immer noch im Betastatus aufgrund von TS Limitierungen. Fuer die PZB gibt es keinen Grund warum sie nicht korrekt programmiert werden koennte (in dem begrenzten Umfang der von Anfang an kommuniziert wurde, also ohne multiple UeF) und keine TS Limitation. Der Bug hier ist ein reiner und kleiner Fehler, nicht mehr und nicht weniger.

- Ausserdem ist die gute PZB von vR fuer viele ein Alleinstellungsmerkmal und Kaufgrund -- ich kaufe vR und nicht GBE Loks WEGEN der Aufruestung und der PZB!

- Selbst wenn dem so waere (PZB in Beta), verstehe ich den Zweck des Beitrages nicht? Gerade dann waere doch dieser Bugreport besonders wichtig???

Egal was fuer Resultate andere hier bekommen, hoffe ich sehr, dass Herr Goltz das hier zufaellig liest -- falls er sich den Code kurz anschaut, wird er sofort sehen, dass hier ein Bug vorliegt.

Ich bin kein vR Basher und bemuehe mich sehr, alles respektvoll darzulegen, denn ich hoffe natuerlich, dass ich die naechsten Loks ohne aufwendige Bytecodeanalysen und Eigenbaufixes einfach voller Freude fahren kann. Es waere natuerlich immer noch wuenschenswert, wenn irgendeinmal ein assets\virtualrailrods\sharedlib oder so gebaut werden koennte, so dass man mit EINEM Update alle PZB-Loks und LZB-Loks reparieren koennte. Ich bin immer noch der Meinung, dass man das modular hinbekommen koennte...

Steinchen:
wir haben nicht das Jahr 2013! Die PZB ist nicht als Beta deklariert. Behauptungen dass der TS nicht fuer komplizierte Zugsicherungssysteme ausgelegt, sind zu allgemein und treffen auf die PZB nicht zu! Jeder hier akzeptiert die Einschraenkungen gegenueber der original-PZB Hard- und Software. Ich habe sich noch niemanden ueber den Mangel an mehrfachen, sich ueberlagernden Ueberwachungsfunktionen der PZB beschweren hoeren. Allerdings ist der Bug hier nicht dem TS, oder der Machbarkeit, sondern einem Fluechtigkeitsfehler anzulasten!

D.h. wenn ich in meinem Szenario einen Fehler mache und dafuer eine ZWB kassiere, moechte ich nicht auch noch eine weitere sinnlose kassieren -- vorallem dann, wenn man fuer viele hochwertige Addons ziemlich viel Geld bezahlt hat! Dieses Problem ist innerhalb von wenigen Minuten zu beheben. Alles was in Zusi oder Loksim gemacht werden kann, kann im TS auch gemacht werden. Software bleibt Software! Auch Zusi und Loksim bieten m.W.n. keine mehrfachen UeF wie die originale PZB an. Die mehrfachen Verweise sowohl auf den vermeintlichen Betastatus (stimmt einfach nicht fuer 243, 156, 110, 140, 112) als auch die TS-Limitationen haben mit dem Thema hier nichts zu tun - also bitte beim Thema bleiben!

Ich glaube/hoffe nicht, dass vR so mimosenhaft ist. Hier hat jedenfalls niemand genoergelt?! Es gibt einen unschoenen Bug, der spielendleicht zu beheben ist. Ich habe ihn durch Eigenarbeit auf dem Silbertablett praesentiert, und genau erklaert wo welche Aenderung im Skriptcode noetig ist.

Wenn Dir die PZB mit diesem Problem reicht oder gefaellt, warum postest Du dann hier? Willst Du mich und andere ueberzeugen, dass der Kaiser Kleider anhat, uns also dieses Problem auch gefallen oder nicht stoeren soll?

Ich glaube nicht an das Ende von EL. EL ist fuer mich das Herz des vR Marktes. Ich glaube, dass die vR Mitarbeiter auch mit Kritik umgehen koennen und keine unaufrichtigen Lobhudeleien hoeren wollen, sondern Lob dort, wo sie fuer vieles zu loben sind, und Kritik dort, wo man noch nachbessern kann.

Zitat von Prelli

Warum sollte ich an einem VSig mit (Vr0 wegen Hp0) absichtlich kein Wachsam drücken?

Haha -- der Bug betrifft nur Leute, die nicht immer perfekt fahren (Bei mir: kleine Tochter wollte etwas -> VSig uebersehen, Zwangsbremsung. Dann erneute ZWB am naechsten scharfen 500er und vr Hilfesystem meinte unerlaubtes Befreiung aus Restriktion.)