FreePZB — eine PZB90 in Lua für alle Lokbauer

Guten Abend, ich bringe Geschenke.

Nachdem ich mir das Trauerspiel mit deutschen Zugsicherungssystemen in Railworks ein wenig angesehen habe, also sehr britische rudimentäre "PZBs" in den Standardloks und unpassende Magnete auf den Strecken, dachte ich mir, dass ich doch zumindest bei den PZBs etwas machen kann. Gibt es dann mal mehr Triebfahrzeuge mit richtigen PZBs sind dann bestimmt auch die Streckenbauer motiviert, korrekte Magnet zu verlegen.

Also Richtlinie der DB AG runtergeladen und mal durchgelesen… Ist doch gar nicht sooo kompliziert wie immer gesagt (es ist nur kompliziert beschrieben). Dann konnte ich nicht widerstehen und habe eine PZB in Lua geschrieben, die das in der Richtlinie beschriebene Verhalten simuliert, mit allen Überlagerungen und mit allen Geschwindigkeitskurven (ja, auch inklusive der Anhebung der Umschaltgeschwindigkeit nach 500 Hz in Zugart O), natürlich mit kontinuierlicher Überwachung. Hauptsächlich fehlt noch die Überwachung der Höchstgeschwindigkeit außerhalb von Beeinflussungen. Sobald es freigeschaltet ist, im Downloadbereich unter Railworks/Sonstiges.

Das Skript ist so ausgelegt, dass es in beliebige Umgebungen eingepflanzt werden kann: Es muss nichts selbstständig im Hintergrund laufen, es greift auf keine externen Funktionen oder Variablen zu, nichts daran ist überhaupt Railworks spezifisch. Im Großen und Ganzen läuft es so ab, dass der Lokbauer selbst die PZB Tasten implementiert und (wie auch immer) die Magnet-Beeinflussungen erfasst und an die PZB Update-Funktion übergibt (mit weiteren Werten wie Geschwindigkeit und Zeit) und als Ergebnis dann den Zustand der Lampen, des akustischen Signalgebers und natürlich des Zwangsbremsventils erhält.

Jetzt bin ich natürlich an Meinungen von Lokbauern interessiert, ob das von mir gewählte Interface passend ist, denn vom Lokbau in Railworks habe ich nicht wirklich eine Ahnung. Ich hatte auch schon angedacht, zur Bequemlichkeit eine zweite Update-Funktion zu bieten, die die zurückgelegte Strecke nicht erwartet (sondern selbst aus der Geschwindigkeit integriert). Ebenso eine Funktion, die die Blinkzustände der Lampen auf einfache An/Aus-Zustände reduziert, damit man sich die Implementation von Blink-Animationen sparen kann.

Und noch eine Frage: Aus der Richtlinie kann ich nicht ganz auf das Verhalten bei Überschreiten der Höchstgeschwindigkeit (also außerhalb Beeinflussungen) schließen, da steht nur, dass erst ein "Warnschuss" mit intermittierendem Zwangsbremsen kommt. Weiß da jemand, in welchem Takt (wie lang an, wie lang aus) das passiert?

Zitat von AndreasB

Und noch eine Frage: Aus der Richtlinie kann ich nicht ganz auf das Verhalten bei Überschreiten der Höchstgeschwindigkeit (also außerhalb Beeinflussungen) schließen, da steht nur, dass erst ein "Warnschuss" mit intermittierendem Zwangsbremsen kommt. Weiß da jemand, in welchem Takt (wie lang an, wie lang aus) das passiert?

Steht doch genau im Text: Ril483.0113 Seite 25 Abschnitt 4.4. Vmax +5 nach 7s die Schnarre und wenns weiter erhöht die ZWB. Bei ZWB und Unterschreitung der Vprüf automatisches lösen der ZWB.

EDIT: wurde das Script denn schon hochgeladen? Würde gern mal einen Blick reinwerfen. So wie ich das verstanden habe hast du die komplette PZB in eine Funktion ausgelagert. Dieses Vorgehen hatte ich bei der 143er und dem BDnrzf auch versucht und bin irgendwie dabei gescheitert da die PZB ja von einigen Umgebungsparametern aus verschiedenen RW-Funktionsbereichen (Update, OnControlValueChange,OnCustomSignalMessage) abhängig ist.

Hab mir das Script mal "oberflächlich" angeschaut. Ein guter Ansatz. Vor allem gefällt mir dass es als eigenständiges Modul ausgelagert ist. Allerdings hab ich genau da meine Bedenken und Probleme. Mir ist schon passiert dass ein Modul nicht richtig angesprochen wurde weil die Updaterate des Games zu langsam wurde. Und hier kommt noch dazu dass immer das komplette P.update() durchlaufen werden muss. Ich weis nich wo die LUA Performancegrenze in RW ist. Manchmal scheint es extrem schnell zu sein und dann mal wieder nicht. Wenn die Verzögerungen zu groß werden arbeitet die PZB fehlerhaft. Müsste man testen.

Bei mir in den Scripts hat die "Zwangsbetriebsbremsung" gar keinen Namen Die Bresmen werden direkt ausgelöst (bei SIFA und Vprüf überschreitung). Man hat ja kein solch zusätzlich angesteuertes Bremsventil. LZB haben wir nicht und werden wir nicht haben solange der Zug nich weis wo er eigentlich ist auf der Strecke.

Zitat von Maik

Steht doch genau im Text: Ril483.0113 Seite 25 Abschnitt 4.4. Vmax +5 nach 7s die Schnarre und wenns weiter erhöht die ZWB. Bei ZWB und Unterschreitung der Vprüf automatisches lösen der ZWB.

Da hab ich gar nicht reingeschaut, nur in die 0111 (PZB in Fahrzeugen ohne LZB). Statt dem Leuchtmelder "G" gibt es da halt das intermittierende Zwangsbremsen, was eben schon die ganze Beschreibung ist. Der Rest mit Dauerbremsen bei weiterer Erhöhung ist wieder gleich.

Zitat

EDIT: wurde das Script denn schon hochgeladen? Würde gern mal einen Blick reinwerfen. So wie ich das verstanden habe hast du die komplette PZB in eine Funktion ausgelagert. Dieses Vorgehen hatte ich bei der 143er und dem BDnrzf auch versucht und bin irgendwie dabei gescheitert da die PZB ja von einigen Umgebungsparametern aus verschiedenen RW-Funktionsbereichen (Update, OnControlValueChange,OnCustomSignalMessage) abhängig ist.

Wenn die Funktion von verschiedenen Stellen aufgerufen werden müsste und nicht an allen die nötigen Informationen vorliegen, dann müssten diese halt zwischengespeichert werden wenn sie sich ändern. Das sollte ja kein großes Problem sein in der Annahme, dass die verschiedenen Stellen auf dieselben globalen Variablen zugreifen können.

Zitat von Maik

Hab mir das Script mal "oberflächlich" angeschaut. Ein guter Ansatz. Vor allem gefällt mir dass es als eigenständiges Modul ausgelagert ist. Allerdings hab ich genau da meine Bedenken und Probleme. Mir ist schon passiert dass ein Modul nicht richtig angesprochen wurde weil die Updaterate des Games zu langsam wurde. Und hier kommt noch dazu dass immer das komplette P.update() durchlaufen werden muss. Ich weis nich wo die LUA Performancegrenze in RW ist. Manchmal scheint es extrem schnell zu sein und dann mal wieder nicht. Wenn die Verzögerungen zu groß werden arbeitet die PZB fehlerhaft. Müsste man testen.

In Railworks konnte ich es natürlich nicht testen, aber in meinem Testprogramm habe ich mal die Prozessorzeit des Lua-Teils über eine Laufzeit von mehreren Minuten anzeigen lassen. Runtergebrochen auf einen Durchlauf waren das so 6 bis 7 µs auf meinem Intel Core 2 Duo E-8600, wobei da dann immer noch die String/Regex Operation dabei sind, um den Zustand für die Kommunikation mit dem Hauptprogramm ein- und auszupacken.

Mit Verzögerungen hätte mein Skript aber kein Problem, es gibt keine Mindest-Aufrufrate oder vorgeschriebenen Aufrufabstände. Die aktuelle Simulationszeit / Strecke muss halt immer übergeben werden, darauf basiert der aktuelle Zustand.

Zitat von LukaAs

"Zwangsbremsung" ist hier der falsche Begriff. Das beschriebene Verhalten der PZB nennt sich "Zwangsbetriebsbremsung". Die Hauptluftleitung, welche die Bremsen steuert, wird bei Zwangsbremsungen immer komplett entleert, um in kürzester Zeit die maximale Bremskraft zu erreichen. Bei der Zwangsbetriebsbremsung wird jedoch nur eine sog. Vollbremsung eingeleitet, das heisst, dass der Zug wie schon gesagt nur verlangsamt wird.

Danke, das macht viel mehr Sinn. Ich habe mich schon etwas gewundert, wie das mit voll entleerter Hauptluftleitung gehen soll, da das ja etwas dauert bis die wieder gefüllt wird. Dazu noch intermittierend…

Zitat von AndreasB

Da hab ich gar nicht reingeschaut, nur in die 0111 (PZB in Fahrzeugen ohne LZB). Statt dem Leuchtmelder "G" gibt es da halt das intermittierende Zwangsbremsen, was eben schon die ganze Beschreibung ist. Der Rest mit Dauerbremsen bei weiterer Erhöhung ist wieder gleich.

So genau muss man es auch nich machen glaub ich. Eine Version der Vprüf Reaktion reicht doch aus. Aber lieber die mit Schnarre und/oder "G" LM und Dauerbremsung bis Vprüf wieder unterschritten wurde. Alles andere kann in RW bei den merkwürdigen Bremseinstellungen mancher Wagen sehr schon zum Flugerlebnis werden.

Zitat von AndreasB

Wenn die Funktion von verschiedenen Stellen aufgerufen werden müsste und nicht an allen die nötigen Informationen vorliegen, dann müssten diese halt zwischengespeichert werden wenn sie sich ändern. Das sollte ja kein großes Problem sein in der Annahme, dass die verschiedenen Stellen auf dieselben globalen Variablen zugreifen können.

Ja gut, zwischenspeichern tut man eh. Du machst es halt innerhalb des "Ojects", ich mach es mit globalen Vars. Nimmt sich nix. Nachdem ich das script gesehen hab ist es auch kein Problem es von verschiedenen Stellen aus aufzurufen und mit Daten zu füttern.

Zitat von AndreasB

In Railworks konnte ich es natürlich nicht testen

Ja das muss man aber. LUA in RW arbeitet "anders" als LUA einfach so. Auch wenn das nicht logisch ist. Aber es tut, glaub mir Die PZB in reiner Theorie zu coden für RW fahrzeuge ist möglicherweise ein holpriger Weg. Ich habs jetzt nicht ausprobiert weil mir das passende Fahrzeug zum "schrotten" fehlt. Vll traut sich ja wer ran das mal zu testen. Ich bleib lieber bei meiner eigenen PZB. Die muss ich eh nochmal neu strukturieren.

Zitat von AndreasB

Mit Verzögerungen hätte mein Skript aber kein Problem, es gibt keine Mindest-Aufrufrate oder vorgeschriebenen Aufrufabstände. Die aktuelle Simulationszeit / Strecke muss halt immer übergeben werden, darauf basiert der aktuelle Zustand.

Ja in der Theorie geht das natürlich. Railworks ist aber leider fern jeder Theorie. Da ist jeden tag Weihnachten und Ostern zusammen was die Masse an "Überraschungen" angeht.

Was vll hier an der Stelle für die eiligen User angemerkt werden sollte, das Script ist nur die PZB Logic selbst. Auswertung der Rückgaben müssen von Fahrzeugersteller/Coder noch erstellt werden. Genauso die Tasten-Zustände müssen stets abgefragt werden damit man sie übergegen kann. Nicht ganz so einfach wenn man kein Dauerfeuer machen will oder 1000 Zeilen Code tippen möchte um Dauerfeuer zu unterbinden. Railworks ist bissel sparsam mit Infos an die LUA Schnittstelle. Man muss Controls immer aktiv auslesen. Pushs gibt es kaum. Nur OnControlValueChange, was auch nur reagiert wenn man mit der Tatstaur bedient.

Bitte nicht als negative Kritik auffassen (ist bei mir irgendwie usus). Ich sage halt was ich meine und pudere es nicht mit Zucker und Streuseln

Zitat von Maik

So genau muss man es auch nich machen glaub ich. Eine Version der Vprüf Reaktion reicht doch aus. Aber lieber die mit Schnarre und/oder "G" LM und Dauerbremsung bis Vprüf wieder unterschritten wurde. Alles andere kann in RW bei den merkwürdigen Bremseinstellungen mancher Wagen sehr schon zum Flugerlebnis werden.

Ja, ich denk mir auch, dass ich da vielleicht nicht übertreiben soll. Wenn die Höchstgeschwindigkeit zu lange überschritten ist, einfach bis unter die Höchstgeschwindigkeit zwangsbremsen und gut is.

Zitat

Ja das muss man aber. LUA in RW arbeitet "anders" als LUA einfach so. Auch wenn das nicht logisch ist. Aber es tut, glaub mir Die PZB in reiner Theorie zu coden für RW fahrzeuge ist möglicherweise ein holpriger Weg. Ich habs jetzt nicht ausprobiert weil mir das passende Fahrzeug zum "schrotten" fehlt. Vll traut sich ja wer ran das mal zu testen.

Ich habe in dem Skript ja nicht mal irgendwelche Funktionen aus der Lua-Standardbibliothek verwendet, das ist wirklich reinstes Lua (außer dem kleinen Block am Anfang um die Datei als Modul einbindbar zu machen, aber das ist ja austauschbar). Was sind denn da Probleme? Wie schlimm kann es denn sein? (Jetzt erwarte ich schon fast eine Antwort wie "Du kannst es dir gar nicht vorstellen…")

Natürlich will ich das alles mal in Railworks sehen, aber vom Lokbau habe ich bisher fast gar keine Ahnung. Wenn es jemand in seine Lok reinpacken will bin ich aber gerne behilflich, das war ja schließlich die Motivation hinter dem Projekt.

Zitat

Ich bleib lieber bei meiner eigenen PZB. Die muss ich eh nochmal neu strukturieren.

Oh, eine andere Motivation für mein Projekt war die falsche Herangehensweise die anscheinend weit verbreitet ist. Nämlich, dass die PZB Überwachungszustände hat, zwischen denen sie wechselt. Dein PZB-Skript kann ich ja nicht lesen, aber aus dem Verhalten und einigen älteren Kommentaren hier im Forum vermute ich, dass es da auch so ist.

Der Trick ist, dass alle Überwachungen unabhängig voneinander parallel laufen. Der zweite Trick ist, dass es drei unabhängige Überwachungen gibt (Befehl 40 ausgenommen), nämlich 1000 Hz, 1000 Hz restriktiv und 500 Hz (restriktiv und nicht restriktiv). An ein paar Stellen gibt es freilich Berührungspunkte, etwa bei der 500 Hz Beeinflussung (ist 1000 Hz restriktiv aktiv, ist Befreiung aktiv), aber ansonsten interessieren die einander nicht.

Dann funktionieren alle Überlagerungen praktisch von allein, es zählt einfach die niedrigste Überwachungsgeschwindigkeit und eine 500 Hz Überwachung löscht die "1000 Hz" Lampe. Versucht man das alles aber in einen globalen Zustand der PZB zu überführen, schlägt gnadenlos die kombinatorische Explosion zu.

Zitat

Was vll hier an der Stelle für die eiligen User angemerkt werden sollte, das Script ist nur die PZB Logic selbst. Auswertung der Rückgaben müssen von Fahrzeugersteller/Coder noch erstellt werden. Genauso die Tasten-Zustände müssen stets abgefragt werden damit man sie übergegen kann.

Dass es nur die reine Logik ist habe ich ja schon am Anfang geschrieben. Die Idee dahinter ist ja, dass die Loks vielleicht alle anders sind, aber die PZB eigentlich immer das selbe. Also statt fünf halbgaren PZBs, weil die Lokbauer die Zeit für 100 andere Dinge brauchen und nicht fürs Einarbeiten in die Feinheiten des PZB Systems, lieber eine korrekte und universelle zum Einbauen. Mit Tasten und Lämpchen sind sie vielleicht routinierter, weil man das auch für andere Dinge braucht.

Das ist auch ein Grund, warum ich für die Lampen nicht nur separate Ein/Aus Zustände definiert habe sondern auch Blinkzustände über mehrere Lampen. Damit kann man eine saubere Animation starten und braucht nicht die PZB-Funktion für jedes gerenderte Frame aufzurufen.

Wünschenswert wäre insbesondere noch ein Standard für Magnete auf den Strecken, damit nicht am Ende Strecken nur mit bestimmten Loks korrekt funktionieren…

Zitat

Nicht ganz so einfach wenn man kein Dauerfeuer machen will oder 1000 Zeilen Code tippen möchte um Dauerfeuer zu unterbinden. Railworks ist bissel sparsam mit Infos an die LUA Schnittstelle. Man muss Controls immer aktiv auslesen. Pushs gibt es kaum. Nur OnControlValueChange, was auch nur reagiert wenn man mit der Tatstaur bedient.

Das ist dann wohl ein generelles Problem womit die Lokbauer so oder so leben müssen. Und ich erwarte ja in meinem Skript nicht, dass gesagt wird "jetzt wurde die Taste gedrückt!" sondern nur, ob sie betätigt sind oder nicht. Wenn dieser Zustand nicht 100% aktuell ist sondern 100 ms alt macht das auch nichts, dann reagiert die PZB halt erst später auf eine Betätigung.

Zitat

Bitte nicht als negative Kritik auffassen (ist bei mir irgendwie usus). Ich sage halt was ich meine und pudere es nicht mit Zucker und Streuseln

Kein Problem, mach ich auch so.

Zitat von AndreasB

Was sind denn da Probleme? Wie schlimm kann es denn sein? (Jetzt erwarte ich schon fast eine Antwort wie "Du kannst es dir gar nicht vorstellen…")

Ne nix Schlimmes. Ich meinte eigentlich dass man es zumindest mal getestet haben sollte. Theoretisch erstellte Scripts mögen in einem synthetischen Test funktionieren aber in der Realität kann es passieren dass es dann doch nicht so geht. Und Railworks macht sowas gern. Ich hab aber nochmal genauer drüber geschaut. Ich erwarte da keine LUA seitigen Probleme.

Zitat von AndreasB

Dein PZB-Skript kann ich ja nicht lesen, aber aus dem Verhalten und einigen älteren Kommentaren hier im Forum vermute ich, dass es da auch so ist.

Nö, lesen kann man das nicht Aber ich darf dir versichern dass es dort genauso abläuft. Ich hatte zwar mal geschrieben dass nicht alle Überlagerungen funktionieren, aber damit meinte ich diese eher seltenen Sonderfälle die auch in der Ril beschrieben sind. Ansonsten laufen alle Überwachungen parallel und sind je nach Gewichtung (also VÜ und restriktiv Modus) im Hintergrund. Kannst du, wenn du die 143er EL hast ja ausprobieren. Magneten sind ja dabei. (zu den Magneten weiter unten)

Zitat von AndreasB

......Mit Tasten und Lämpchen sind sie vielleicht routinierter, weil man das auch für andere Dinge braucht.

Das ist auch ein Grund, warum ich für die Lampen nicht nur separate Ein/Aus Zustände definiert habe sondern auch Blinkzustände über mehrere Lampen. Damit kann man eine saubere Animation starten und braucht nicht die PZB-Funktion für jedes gerenderte Frame aufzurufen.

Das Problem an der Implementation deiner PZB ist aber, dass man die nich ma eben schwupps reinbauen kann. Man muss in LUA noch einiges coden und genau das können 99.9% der Lokbauer nicht wirklich. Da müsstest du also an sich ein Beispiel mitliefern. Und gerade die Methode mit der man dein Script implementieren und ansprechen muss ist vielen prozedual denkenden Menschen nicht geläufig. Wenn du nicht genau erklärst wie man die einbauen muss wird sie keiner einbauen. Gilt für meine eigene Umsetzung aber auch. Die ist nur eben nicht in ein Objekt ausgelagert, weils an sich gar keinen Sinn macht. Dynamisch LUA nachladen kann man in RW eh nicht. Das ist eine Sache die da zB eben nicht funktioniert. Genauso wie Coroutines in Endlosschleifen enden obwohl kein Fehler drin ist. Da kann man auch alles gleich in eine Datei packen. Bei dir ist die Überlegung natürlich die Wiederverwertbarkeit. Deswegen ist auslagern besser. Bei meiner PZB ist das egal. Die wandert nur in vR Fahrzeuge.

Zitat von AndreasB

Wünschenswert wäre insbesondere noch ein Standard für Magnete auf den Strecken, damit nicht am Ende Strecken nur mit bestimmten Loks korrekt funktionieren…

Da habe ich bei meiner PZB eben einen Kompromiss gemacht. Ich reagiere auf zwei Messages und das ist auch kein Thema. Könnten auch 20 verschiedene sein. Macht keinen Unterschied. Die meissten werden sowas als "1000" oder eben "PZB1000" melden und vll lesen ein paar PZB Bastler ja hier und nehmen sich der Methode an. Gibt aber sicher keine grundsätzlichen Richtlienen wie bei der Bahn die man durchsetzen könnte. Da BSI auch keine PZB einbaut gibts aus der Ecke auch keine Standards für die breite Masse. Letztlich sollte man bei der RW Vorlage bleiben und einfach eben "1000", "500" und "2000" senden. Wer anderes macht verbaut sich möglicherweise die Chance dass seine Fahrzeuge überall damit funktionieren.

Zitat von AndreasB

Das ist dann wohl ein generelles Problem womit die Lokbauer so oder so leben müssen. Und ich erwarte ja in meinem Skript nicht, dass gesagt wird "jetzt wurde die Taste gedrückt!" sondern nur, ob sie betätigt sind oder nicht. Wenn dieser Zustand nicht 100% aktuell ist sondern 100 ms alt macht das auch nichts, dann reagiert die PZB halt erst später auf eine Betätigung.

Naja die Problematik dabei habe ich oben schon geschrieben. Um die Tasten auszuwerten und in eine Tabelle (Object) zu stopfen muss man was von LUA oder genrell von OOP verstehen. Das tut kaum einer in der RW Szene. Schau dir doch die ganzen LUAs an von den Fahrzeugen. Da gibt es echt grauenvolle Umsetztungen von simplen Vorgängen. Wo teilweise 3 Zeilen Code reichen stehen 30. Und alles schön mit Dauerfeuer. Controls werden stets und ständig neu geschrieben obwohl sich der Wert nicht ändert etc. etc. pp.. Erwarte also nicht zu viel Scripting Kenntnisse von den Fahrzeugbauern. Denn man braucht 0% LUA Kenntnisse um ein Fahrzeug in RW gangbar zu machen.

hey andreas

i dont know how you wanth to setup your final pzb system but if you need some source like a model and scriptings(my pzb magnetz) that i use on my magnets you can pm me. if you wanth i can make your system compatible with my black forest route where im working on. its possible if your system recieve OnCustomSignalMessage "arg" . i release the magnetz later as little package for route builders.

Ups, so lange wollte ich mit meiner Antwort eigentlich nicht warten…

Zitat von Maik

Nö, lesen kann man das nicht Aber ich darf dir versichern dass es dort genauso abläuft. Ich hatte zwar mal geschrieben dass nicht alle Überlagerungen funktionieren, aber damit meinte ich diese eher seltenen Sonderfälle die auch in der Ril beschrieben sind. Ansonsten laufen alle Überwachungen parallel und sind je nach Gewichtung (also VÜ und restriktiv Modus) im Hintergrund.

Sehr gut, ich hatte nur noch mal den Verdacht, als ich mal mit der 143 EL während einer restriktiven Überwachung (Startprogramm) mit Befehlstaste ein Halt zeigendes Signal überfahren habe. Da fand ich es etwas befremdlich, dass — nein, nicht dass der Signalton und "Befehl 40" sofort und nicht erst nach 2000 Hz Beeinflussung gekommen sind — bei Betätigen der Befehlstaste sofort alles Blinken aufhörte und erst nach Loslassen wieder losging.

Zitat

Das Problem an der Implementation deiner PZB ist aber, dass man die nich ma eben schwupps reinbauen kann. Man muss in LUA noch einiges coden und genau das können 99.9% der Lokbauer nicht wirklich. Da müsstest du also an sich ein Beispiel mitliefern. Und gerade die Methode mit der man dein Script implementieren und ansprechen muss ist vielen prozedual denkenden Menschen nicht geläufig. Wenn du nicht genau erklärst wie man die einbauen muss wird sie keiner einbauen.

Beispiel ist halt die Sache, ich habe erstens keine Erfahrung mit Lokbau und zweitens bisher nicht vor, eine neue Lok zu bauen. Ich wollte jetzt mal schauen, ob ich die 294 auseinanderpfriemeln und da was reinbauen kann, ganz in der Hoffnung, dass da eventuell schon alle PZB Lampen drin sind, wenn auch ungenutzt. Ein bisschen habe ich mich eingelesen und ich glaube mit InputMapper + Controls für die Lampen (auf per Maus bedienbare Tasten kann man ja erst mal verzichten) würde ich schon was hinkriegen, wenn ich aber erst noch ein 3D-Modell für die PZB-Anzeige basteln muss habe ich da noch etwas mehr vor mir…

Zitat

Da habe ich bei meiner PZB eben einen Kompromiss gemacht. Ich reagiere auf zwei Messages und das ist auch kein Thema. Könnten auch 20 verschiedene sein. Macht keinen Unterschied. Die meissten werden sowas als "1000" oder eben "PZB1000" melden und vll lesen ein paar PZB Bastler ja hier und nehmen sich der Methode an. Gibt aber sicher keine grundsätzlichen Richtlienen wie bei der Bahn die man durchsetzen könnte. Da BSI auch keine PZB einbaut gibts aus der Ecke auch keine Standards für die breite Masse. Letztlich sollte man bei der RW Vorlage bleiben und einfach eben "1000", "500" und "2000" senden. Wer anderes macht verbaut sich möglicherweise die Chance dass seine Fahrzeuge überall damit funktionieren.

Genau, aber ich dachte eventuell noch an eine Abkopplung von dem Unsinn, den die Standardsignale machen. Also einen Standard für Messages von Magneten die sagen "Hallo, ich bin ein ernsthafter PZB Magnet!". Und dann die Lok einfach Sachen ignorieren lassen wie Hp 2 Signale die (ohne Vorsignal am Mast) 1000 Hz liefern. Das hatte mir etwas Kopfkratzen beschert ob der Zwangsbremsungen aus heiterem Himmel…

Zitat

Naja die Problematik dabei habe ich oben schon geschrieben. Um die Tasten auszuwerten und in eine Tabelle (Object) zu stopfen muss man was von LUA oder genrell von OOP verstehen. Das tut kaum einer in der RW Szene. Schau dir doch die ganzen LUAs an von den Fahrzeugen. Da gibt es echt grauenvolle Umsetztungen von simplen Vorgängen. Wo teilweise 3 Zeilen Code reichen stehen 30. Und alles schön mit Dauerfeuer. Controls werden stets und ständig neu geschrieben obwohl sich der Wert nicht ändert etc. etc. pp.. Erwarte also nicht zu viel Scripting Kenntnisse von den Fahrzeugbauern. Denn man braucht 0% LUA Kenntnisse um ein Fahrzeug in RW gangbar zu machen.

Oh ja, nachdem ich mich mal etwas im Standardmaterial rumgelesen habe, ist das schon nicht berauschend und dass Cargo Cult Programming hier noch weiter verbreitet ist kann ich mir vorstellen. Wobei die einfachen Dinger, die ganz ohne Skripte auskommen, eher nicht die Zielgruppe für eine realistische PZB sind. Aber ja, ich versuche mich mal beizeiten an einer Referenzimplementierung mit der 294.

Zitat von fopix3d

hey andreas

i dont know how you wanth to setup your final pzb system but if you need some source like a model and scriptings(my pzb magnetz) that i use on my magnets you can pm me. if you wanth i can make your system compatible with my black forest route where im working on. its possible if your system recieve OnCustomSignalMessage "arg" . i release the magnetz later as little package for route builders.

Hmm, thanks, but the magnets by themselves are not very interesting as with my script it would be the engine script's responsibility to translate signal messages to influence states (i.e. which of 500, 1000, 2000 or none is active) anyway. Now, if you would want to lend me your Talent to let me hack in my PZB, that would be something different…

Zitat von AndreasB

ich hatte nur noch mal den Verdacht, als ich mal mit der 143 EL während einer restriktiven Überwachung (Startprogramm) mit Befehlstaste ein Halt zeigendes Signal überfahren habe. Da fand ich es etwas befremdlich, dass — nein, nicht dass der Signalton und "Befehl 40" sofort und nicht erst nach 2000 Hz Beeinflussung gekommen sind — bei Betätigen der Befehlstaste sofort alles Blinken aufhörte und erst nach Loslassen wieder losging.

Mir war als hätte ich das so gelesen. Auch in ZUSI ist es so umgesetzt. Daran habe ich mich orientiert. Ich hatte noch nicht das Vergnügen eine echte PZB bedienen zu dürfen. Das zu ändern ist aber kein Problem.

Zitat von AndreasB

Ich wollte jetzt mal schauen, ob ich die 294 auseinanderpfriemeln und da was reinbauen kann, ganz in der Hoffnung, dass da eventuell schon alle PZB Lampen drin sind, wenn auch ungenutzt. Ein bisschen habe ich mich eingelesen und ich glaube mit InputMapper + Controls für die Lampen (auf per Maus bedienbare Tasten kann man ja erst mal verzichten) würde ich schon was hinkriegen, wenn ich aber erst noch ein 3D-Modell für die PZB-Anzeige basteln muss habe ich da noch etwas mehr vor mir…

Die Hoffnung kann ich dir dann gleich nehmen. Es gibt keine Standardloks die sowas drin haben. Da ist nur drin was auch wirklich benötigt wurde. Alles andere ist nicht vorhanden oder animiert. Da wirst du bauen müssen, oder wen bauen lassen müssen. Gibt ja hier genug Leute die damit kein Problem haben mal eben eine solche Anzeige in eine Lok zu bekommen. Kann man ja als Child reinhängen.

Zitat von AndreasB

Genau, aber ich dachte eventuell noch an eine Abkopplung von dem Unsinn, den die Standardsignale machen. Also einen Standard für Messages von Magneten die sagen "Hallo, ich bin ein ernsthafter PZB Magnet!". Und dann die Lok einfach Sachen ignorieren lassen wie Hp 2 Signale die (ohne Vorsignal am Mast) 1000 Hz liefern. Das hatte mir etwas Kopfkratzen beschert ob der Zwangsbremsungen aus heiterem Himmel…

Genau das tun doch meine Magnete. Die vermelden nicht "1000" sondern "PZB1000" und sind somit "abgekoppelt". Aber mein "PZB-Gerät" in der Lok versteht beide Sprachen, da die PZB auch auf den Standardstrecken ohne zusätzliches Legen von proprietären Magneten funktionieren sollte. Wenn dann 1000er an einem HP ohne vR aktiv sind dann kannst du da eben nichts gegen tun. Macht die Sache doch interessanter, man muss eben immer mal Wachsam drücken auf den vermurksten Strecken. Tun die Tf in Wirklichkeit auch, hab ich schon gesehen. Da wird schon mal "angedrückt" wenn man sich nicht ganz sicher ist.

Zitat von AndreasB

Oh ja, nachdem ich mich mal etwas im Standardmaterial rumgelesen habe, ist das schon nicht berauschend und dass Cargo Cult Programming hier noch weiter verbreitet ist kann ich mir vorstellen. Wobei die einfachen Dinger, die ganz ohne Skripte auskommen, eher nicht die Zielgruppe für eine realistische PZB sind. Aber ja, ich versuche mich mal beizeiten an einer Referenzimplementierung mit der 294.

Die Zielgruppe ist eh sehr klein. Und die Lokbauer die sowas implementieren können zählt man an einer Hand ab. Also entweder du bringst eine Anleitung die genau erklärt wie man deine PZB einbaut, oder kein Mensch wird diese je einbauen. Es kann einfach keiner. Und die die es können die haben ihre eigenenen Umsetzungen. Letztlich ist dem Benutzer egal wie die PZB programmiert ist, wenn sie denn erwartungsgemäß funktioniert. Sich darüber aufregen, dass man eine Zeile nicht eingerückt hat, oder dass man redundanten Code fabriziert, wird sich keiner weil gar keiner was davon versteht. Letztlich muss es nur funktionieren und das möglichst einfach.

Davon ab kann man dein Vorgehen auch nicht mit dem meinen vergleichen. Ich hatte nie vor die PZB einzeln zu verteilen. Die wird in die Fahrzeuge von mir eingebaut und dann is die da eben drin. Punkt. Und passende Magnetausrüstung auf Strecken wird es geben wenn ich eine Strecke baue, oder im Auftrag von vR eine Strecke gebaut wird. Wenn also wer deine PZB verbaut dann ist dein Ziel ja erreicht. Meines ist ein anderes. Ob deine PZB dann "kompatibel" ist hängt bei dir. Ich werde eben weiterhin die Standardmessages beachten. Dazu ist meine PZB noch nicht mal fertig. Es fehlen da nämlich noch die VÜ-Kurven. Da fehlt mir aber das mathematische Grundwissen für die Parabelberechnung. Bei dir ist es auch nur ne gerade Linie die da geprüpft wird (soweit ich das rauslesen kann). Bei der PZB90 ist es aber eine Parabel-Kurve. Dafür bin ich aber zu blöd Man braucht das vll auch gar nicht wirklich. Aber es muss eine Verzögerung rein am Anfang der VÜ sonst bekommt man zu schnell eine geballert. Fahren ja nicht alle vorrausschauend. Wer erst bremst wenn das Signal schon weg ist und die Wachsam Taste gerade so 4sec danach gedrückt wurde, der fängt sich eben eine bei 160km/h, egal ob linear oder parabel VÜ.

Zitat von Maik

Mir war als hätte ich das so gelesen. Auch in ZUSI ist es so umgesetzt. Daran habe ich mich orientiert. Ich hatte noch nicht das Vergnügen eine echte PZB bedienen zu dürfen. Das zu ändern ist aber kein Problem.

Naja, ne echte PZB hatte ich ja auch noch nicht zum rumspielen. Aber in der Richtlinie 0111 steht, dass die Lampe und der Signalton beim Überfahren von 2000 Hz bis Loslassen der Befehlstaste kommen (als "Rücknahmeaufforderung"). Da steht zwar nicht, was sie vor den 2000 Hz machen, aber ich gehe mal davon aus, dass sie eben aus sind. Macht auch Sinn, denn dann weiß man, wann man loslassen kann. Und dass die anderen Lampen unabhängig von der Befehlstaste sind, davon gehe ich mal aus.

Zitat

Macht die Sache doch interessanter, man muss eben immer mal Wachsam drücken auf den vermurksten Strecken. Tun die Tf in Wirklichkeit auch, hab ich schon gesehen. Da wird schon mal "angedrückt" wenn man sich nicht ganz sicher ist.

Ja, ich glaube gelesen zu haben, dass die prinzipiell jedes Signal auf das sie reagieren müssen bestätigen sollen, ob da nun ein Magnet steht oder nicht. Schließlich dient die PZB auch als Fahrtenschreiber und zeichnet auch die Wachsam-Betätigung auf. Im Falle eines Unfalls wird das sehr relevant.

1000 Hz an einem Signal, das eigentlich nur bis Ende der Weiche gilt und einen dann 700 m weit aufhält, ist trotzdem doof.

Zitat

Dazu ist meine PZB noch nicht mal fertig. Es fehlen da nämlich noch die VÜ-Kurven. Da fehlt mir aber das mathematische Grundwissen für die Parabelberechnung. Bei dir ist es auch nur ne gerade Linie die da geprüpft wird (soweit ich das rauslesen kann). Bei der PZB90 ist es aber eine Parabel-Kurve. Dafür bin ich aber zu blöd Man braucht das vll auch gar nicht wirklich. Aber es muss eine Verzögerung rein am Anfang der VÜ sonst bekommt man zu schnell eine geballert. Fahren ja nicht alle vorrausschauend. Wer erst bremst wenn das Signal schon weg ist und die Wachsam Taste gerade so 4sec danach gedrückt wurde, der fängt sich eben eine bei 160km/h, egal ob linear oder parabel VÜ.

Von Parabeln habe ich nichts gesehen. So wie ich das verstehe, gibt es nur linear zur Zeit (1000 Hz) und linear zur Strecke (500 Hz). In den Beispielen sieht man zwar immer Kurven bei 1000 Hz, aber doch nur deshalb, weil das ein Geschwindigkeit/Strecke-Diagramm ist. Wenn der Beispiel-Zug nicht mit konstanter Geschwindigkeit fährt (und in den Beispielen bremsen die immer nach 1000 Hz), sieht eine in der Zeit lineare Kurve auf der Strecke freilich gebogen aus.

Und man soll ja immer höchstens 5 km/h unter der Prüfgeschwindigkeit fahren. Bei Zugart O also höchstens 160 km/h, die Kurve läuft von 165 km/h ab sobald Wachsam losgelassen wird. Wenn man dann noch zwangsgebremst wird, dann ist es wohl auch nötig. Knapp an der Grenze zur Zwangsbremsung gefahren kann man die 700 m runterreissen und sich befreien noch bevor die Prüfkurve auf 85 km/h abgelaufen ist… Der Normalfall sollte das nicht sein.

Zitat

Der LM „Befehl 40“ zeigt ab der Beeinflussung bis zur
Rücknahme der Befehlstaste Dauerlicht.
Eine noch laufende Überwachung 1000 Hz oder
500 Hz wird gemeinsam mit dem LM „Befehl 40“ angezeigt.
Der blaue LM des eingestellten Überwachungsprogramms
zeigt Dauerlicht.

Heist, beim drücken des Befehlstasters geht der blaue LM des aktiven Überwachungsprogramms an. Bei der Beeinflssung geht dann der LM 40 und der LM eventuell laufender 1000hz oder 500hz Beeinflussungen. Genau so habe ich das umgesetzt. Der Signalton des Befehlstasters ist mir nicht ganz klar, deswegen habe ich den direkt an den Taster gebunden. So wie in ZUSI's PZB90 v1.6. Was ich nicht gemacht habe, bisher, ist die Taster "umzudrehen". Noch reagiert es beim Betätigen und nicht beim Loslassen. Aber das ist nur Kosmetik.

Aber die Abweichungen sind dann klar. Du hast die I60R nachgebaut. Ich habe aber die PZ80R als Grundlage benutzt. Die funktioniert offensichtlich etwas anders. Ist auch die neuere Variante. Das ist eben dann PZB90 v1.6 soweit ich das noch weis. Da waren die Ossis mal vortschrittlicher als die DB und so haben die das aus der PZ80 in die schon vorhandene PZB90 übernommen und somit das System erweitert. Die I60R war ja die letzte Indusi Version von der DB.

Zitat von AndreasB

Von Parabeln habe ich nichts gesehen. So wie ich das verstehe, gibt es nur linear zur Zeit (1000 Hz) und linear zur Strecke (500 Hz). In den Beispielen sieht man zwar immer Kurven bei 1000 Hz, aber doch nur deshalb, weil das ein Geschwindigkeit/Strecke-Diagramm ist. Wenn der Beispiel-Zug nicht mit konstanter Geschwindigkeit fährt (und in den Beispielen bremsen die immer nach 1000 Hz), sieht eine in der Zeit lineare Kurve auf der Strecke freilich gebogen aus.

Also zur PZB90 1.6 lagen mir mal Diagramme vor die in der Überwarchungskurve mit Parabeln dargestellt sind. Leider finde ich das Zeug nicht mehr. In der Ril483.0113 sind aber noch Abbildungen der Überlagerungen mit den Parabeln vorhanden. Das macht auch irgendwie mehr Sinn bei den gefahrenen Geschwindigkeiten. Wenn ich an der Vü fahre hab ich nur 5km/h "Zeit" ab 1000hz bis mich die Karre erwischt. Das reicht nicht immer aus. Bei einer Parabel Vprüf hast du etwas mehr Zeit beim Anbremsen und man kann sicher auch etwas sanfter bremsen, was für die Fahrgäste sicher angenehmer ist. Du musst eben zum Ende der Vprüf dann schärfer reinbremsen wenn es noch zu schnell ist. Ich habe die Erfahrung gemacht (wieder in Zusi) dass es damit viel besser geht. Dort müssen definitiv Parabel Vprüf (nur bei der PZB90) laufen. Übrigens läuft die Vprüf nicht nur nach Zeit, sondern auch nach Weg. Ist der Weg vor der Zeit zu Ende gibts eine auf die Backen.

Zitat von Maik

Heist, beim drücken des Befehlstasters geht der blaue LM des aktiven Überwachungsprogramms an. Bei der Beeinflssung geht dann der LM 40 und der LM eventuell laufender 1000hz oder 500hz Beeinflussungen.

Tatsache, denselben Text habe ich auch in der 0111 gefunden. Aber ebenso in beiden Richtlinien etwas weiter unten im Abschnitt "Überwachungsfunktionen während Befehlstastenbetätigung" heißt es, dass die LM der laufenden Überwachungen zusätzlich zu "Befehl 40" leuchten, ohne die Einschränkung, dass der passende blaue LM dauerleuchtet. Muss ich dann mal korrigieren.

Zitat

Genau so habe ich das umgesetzt. Der Signalton des Befehlstasters ist mir nicht ganz klar, deswegen habe ich den direkt an den Taster gebunden.

Seite 14 in der 0113 sagt tatsächlich, dass der Ton während der Betätigung kommt, während Seite 10 in der 0111 sagt, dass der Ton (zusammen mit dem Rest) erst ab 2000 Hz kommt. So, jetzt auch noch die Ril 0112 runtergeladen (PZ 80R, System PZB 90) und die sagt das selbe wie 0111. Kann aber auch unklare Formulierung in 0111 und 0112 sein.

Zitat

Also zur PZB90 1.6 lagen mir mal Diagramme vor die in der Überwarchungskurve mit Parabeln dargestellt sind. Leider finde ich das Zeug nicht mehr. In der Ril483.0113 sind aber noch Abbildungen der Überlagerungen mit den Parabeln vorhanden.

Das wäre interessant zu wissen, wie die realen PZB so implementiert wären. Aber die Richtlinien zeigen lineare Absenkungen bei der Beschreibung der 1000 Hz Beeinflussung. Die anderen Abbildungen sind Beispiele, die alle in x-Richtung die Strecke auftragen und in denen der Zug die Geschwindigkeit verringert — was wie gesagt aus der Geraden in der Zeit etwas kurviges auf der Strecke macht.

Zitat

Das macht auch irgendwie mehr Sinn bei den gefahrenen Geschwindigkeiten. Wenn ich an der Vü fahre hab ich nur 5km/h "Zeit" ab 1000hz bis mich die Karre erwischt. Das reicht nicht immer aus.

Ja, ca. 3,5 km/h/s in Zugart O. Also weniger als zwei Sekunden von 165 auf 159. Aber die Kurve läuft ja erst ab Bestätigung der 1000 Hz, das sind bis zu 4 Sekunden extra (falls man das Signal wirklich erst bemerkt, wenn man daran vorbeifährt). Diese 4 Sekunden bei konstant 160 km/h sind allein schon knapp 180 m, und dann noch Spielraum für sanftes Anbremsen?

Denn wenn die Parabel über der Geraden verläuft, hat der Zug bei Missachtung mehr Strecke und höhere Geschwindigkeit sobald endlich die Zwangsbremsung zuschlägt. Läuft die Parabel zum Ausgleich teilweise unter der Geraden, bekommt man u.U. eine Zwangsbremsung, obwohl man sich an die Richtlinie gehalten hat.

Zitat

Übrigens läuft die Vprüf nicht nur nach Zeit, sondern auch nach Weg. Ist der Weg vor der Zeit zu Ende gibts eine auf die Backen.

Welcher Weg? Bei 1000 Hz ist die Geschwindigkeitskurve zeitabhängig, nur bei 500 Hz wegabhängig. Nach der Kurve gibts natürlich bei beiden konstante Geschwindigkeit wegabhängig. Und klar, nach 1000 Hz kommt wegabhängig irgendwann der 500 Hz Magnet, aber das ist nicht in der PZB implementiert, sondern am Gleis.

Zitat von AndreasB

Welcher Weg? Bei 1000 Hz ist die Geschwindigkeitskurve zeitabhängig

Ja ok, das kollidiert eh mit der Zeitkurve. Aber 700m ab 1000hz wäre auch eine ZWB wenn man nicht unter der Überwachungsgeschwindigleit ist was ja nicht passieren kann falls nicht grad die Zeitüberwachung versagt (man weis ja nie). Also ist das Quatsch. Der LM 1000hz ist aber an diese 700m gebunden und geht erst dann aus.

Mit den Parabeln weis ich halt nicht genau. Ich hab eben schon oft Diagramme gesehen die es so hatten. Das waren keine "möglichen Fahrtverläufe" sondern wirklich die Überwachungskurven. Auch bei der restriktiven Absenkung gibt es diese oft zu sehen. Das kann nur wer genau wissen der PZB Geräte wartet. Ich kenne niemanden der das tut. Dann bleibts eben ne lineare Vprüf. Wird in RW keinen großen Unterschied machen. Hauptsache es funktioniert. So ganz genau muss (und darf) man es auch nicht machen.