Versuch einer automatischen Fahrtraßensteuerung mit realistischem Bremsverhalten in Lua

[HaNNoveraNer]

Hallo

Tja, eigentlich dachte ich, ich habs fertig.
Aber irgendwie ist noch der Wurm drin.
Ich habe ein paar kleine Problemchen:

Ein SIgnal wird nicht durch seinen Kontakt zurückgesetzt, daher mußte ich einen zusätzlichen Kontakt hinzufügen.
Manchmal bleiben Züge an den SIgnalen hängen, obwohl sie eine Anforderung gesendet haben müßten.
Manchmal werden Signale geschaltet, die im Programmcode garnicht angesprochen werden.
Ich habe lange nach Fehlern gesucht, aber jetzt komme ich nicht weiter. *verzweifelt*
Und ganz merkwürdig: Bei den FSEnde Kontakten habe ich das Gefühl, daß sie nicht beim Verlassen aktiviert werden, sondern schon früher!?

Ich habe keine Ahnung, ob es unter euch Lua und MBS Spezialisten gibt, die sich das ganze Konstrukt mal ansehen könnten,
und es auch verstehen. Aber für Fragen bin ich ja da.
Vielleicht finden wir gemeinsam irgendwelche Fehler?
Ich wäre dankbar für jede Unterstützung, unabhängig davon, ob meine Steuerung nun so sinnvoll ist, oder nicht,
geht es erstmal darum, Fehler zu finden.

Ich stelle die Testanlage mal hier ein.
Einfach starten und abwarten, bis ein Fehler passiert.

Hinweise: Die Fahrtraßen/Routen zu den einzelnen Zugarten (Personen/Güter) stehen in den Signalen.
Ebenso die Haltezeiten. Zu jeder Fahrstraße exitiert ein Anforderungskontakt und ein Endkontakt, der sie wieder auflöst.
Die Gleise sind in den FS Listen enthalten. Die aktivierten Fahrstraßen in einer Tabelle im  Modul FS. Und die Anforderungen in einer weiteren Tabelle.
 

fahrstraßen_test.mbp

Bearbeitet 2. Februar 2020 von HaNNoveraNer

[Timba]

vor 3 Stunden schrieb HaNNoveraNer:

Ein SIgnal wird nicht durch seinen Kontakt zurückgesetzt, daher mußte ich einen zusätzlichen Kontakt hinzufügen.

Ich hatte es schon mal, dass ein Signal nicht richtig auf dem Gleis "eingerastet" war. Das ist von außen nicht sichtbar. In dem Fall kann der Kontakt des Signals nicht funktionieren. Hast du das schon überprüft? Wenn du das Signal etwas hin und her bewegst siehst du, wann und ob es eingerastet ist. Wenn das Signal korrekt auf dem Gleis eingerastet ist, funktioniert es präzise und zuverlässig wie ein Gleiskontakt.

[Goetz]

So viel kann ich bislang (nach einem ersten ernsthaften Probelauf) sagen:

Zweimal ist der Betrieb aus dem Ruder gelaufen und in beiden Fällen war der Grund identisch. Im Signal FSSig0010 war der benötigte Eintrag für den Zug leer.
Ich habe die Testläufe im Video aufgezeichnet und dabei das Ereignsprotokoll neben der Anlage geöffnet.

So konnte ich die Fehlermeldung sehen, dass beim verzögerten Aufruf von "Ein Signal mit Schlagwort BREMSSIGNAL schaltet" in Zeile 7 des Skripts ein leerer Index das Problem verursacht hat. Im Protokoll sah ich, dass Signal 10 das angesprochene Signal war.

Beim zweiten Testlauf habe ich daher die Variablen von Signal 10 anzeigen lassen. Es dauerte diesmal wesentlich länger, bis derselbe Fehler auftrat. Aber der Fehler war dann identisch. Es gibt offenbar eine Konstellation, in der der Zugname im Signal 10 vorzeitig gelöscht wird. Ob ich mittels Aufzeichnung herausfinde, was genau diese Konstellation ist, muss ich schauen. Generell sind solche Aufzeichnungen sehr hilfreich, weil man so ein "was bisher geschah" verfügbar hat. (Aber da sage ich dir nichts Neues )

Anlagen schalten im Fehlerfall übrigens nur dann auf Pause, wenn das Ereignisprotokoll sichtbar ist. Andernfalls geht der Betrieb weiter, aber vermutlich unter falschen Bedingungen, weil der Rest des Fehler-verursachenden Skripts nicht mehr ausgeführt wurde. Ohne Ereignisprotokoll sieht man also möglicherweise nicht den eigentlichen Fehler, sondern Spätfolgen an anderer Stelle.

[HaNNoveraNer]

Hi Götz

Die Signale schalten irgendwann ohne auslösendes Fahrzeug.
Dürften also garnicht schalten. Daher bleibt auch das vehicle leer.

Ich vermute Timingprobleme mit dem Timer und dem Rest der Steuerung.
Dadurch kommt es vielleicht zu Problemen mit den dynamischen Tabellen.

Ich werde mal die Tabellen umstellen, Speicher haben wir ja genug.
Mal sehen, ob es dann besser wird...

Danke fürs Anschauen!

Gruß
Thomas

[Goetz]

vor 10 Minuten schrieb HaNNoveraNer:

Ich werde mal die Tabellen umstellen

Dann nimm doch auch gleich diese "Objektsuche per Namen" aus den einzelnen Ereignissen. Das ist doch Unsinn die immer wieder neu anzustoßen, wenn sie sich nie ändert.

Geh im Basisskript hin und such beim Start einmal zu jedem STOP Kontakt das zugehörige Signal (per Namen) . Das gefundene Objekt speicherst du in einer Variablen im Kontakt. Dann kannst du im Betrieb direkt auf diese Variable zugreifen.

[Timba]

vor 1 Stunde schrieb Goetz:

Anlagen schalten im Fehlerfall übrigens nur dann auf Pause, wenn das Ereignisprotokoll sichtbar ist.

Wenn ich mir die Ergänzung erlauben darf:

Anlagen schalten im Fehlerfall übrigens nur dann auf Pause, wenn das Ereignisprotokoll sichtbar ist und das fragliche Ereignis/die Ereignisgruppe nicht ausgefiltert ist.

 

Ist nur eine Kleinigkeit, aber ein Nutzer, der vielleicht die Überwachung der Objektvariablen ausgeschaltet hat könnte sich wundern, warum die Anlage trotz Fehler bei der Übergabe einer Objektvariablen nicht anhält.

[HaNNoveraNer]

@Goetz
Optimierungen kommen später.
Wir 3 müssen uns erstmal näher kennenlernen; das 3DMBS, Lua und ich.

 

Bearbeitet 3. Februar 2020 von HaNNoveraNer

[HaNNoveraNer]

Hier eine neue Version.
Die Tabellenverwaltung habe ich total neu konzipiert.
Es ist immer noch eine Testversion mit vielen prints und Debuginformationen.
Aber für die Analyse vielleicht nicht verkehrt.

Ziel ist es, nur 4 Kontakte und 1 Signal in alle zu automatisierenden Anlagen zu importieren.
Mehr braucht es nicht für eine Fahrstraße.
An diesen 5 Objekten kann man alles Einstellen von der Haltezeit über die Art der Züge bis zum Bremsweg.
Ohne den Code, die Bedingungen und Ereignisse anzufassen.
Man muß lediglich noch die Gleise einer Fahrstraße in eine Liste eintragen (markieren und einfügen)

Was kann das Modul?
- Routen erkennen (Die Züge sind mit einer Route versehen, oder auch nicht, wie man möchte)
- Alternative Wege berechnen
- Sanftes Bremsen mir eingestellter Verzögerung
- Manuell aufgestellte Hindernisse erkennen, oder Wagen, die auf einem Gleis zurückbleiben
- Geschwidingkeiten vorgeben
- Mehrere mögliche Routen durch Zufall auswählen
- Fahrstraßen verriegeln
- Weichen verriegeln durch umschalten von anderen Fahrstraßen
- Weiterfahren, wenn kein Halt am Signal notwendig ist

Was soll noch ergänzt werden?
- Kopfgleise
- Richtungswechsel
- Automatisches Aufgleisen auf dem gelben Gleis (jetzt muß man den richtigen Zeitpunkt abpassen :-)
und vieles mehr

Das MBS bietet viele Möglichkeiten, seine Ideen selbst zu verwirklichen. Ein sehr gutes Konzept!

Gruß
Thomas

 

Play drücken und F12 und mitfahren ;-)

fahrstraßen_test.mbp 

 

 

Bearbeitet 3. Februar 2020 von HaNNoveraNer

[HaNNoveraNer]

Heute habe ich die Steuerung erweitert für den Schienenbus.
Damit ist jetzt auch das Ein- und Ausfahren in einen Kopfbahnhof möglich.
Dazu braucht es nur 2 weitere Kontakte.

P.S. Habe leider vergessen das Signal FSSig0012 unsichtbar zu schalten. Das ist nur für den Fahrtrichtungswechsel.

fahrstraßen_test.mbp

Bearbeitet 4. Februar 2020 von HaNNoveraNer

[HaNNoveraNer]

Heute habe ich mal versucht, das was ich im 3DMBS programmiert habe, mit Rocrail nachzubauen.
Der Aufwand ist erheblich größer, aber man wird mit einem Gleisbildstellpult und besserem Überblick belohnt.
War etwas knifflig, da ich weder Rockrail noch das MBS gut kenne.
Um die störenden Geschwindigkeitssprünge auszugleichen, die Rockrail durch Setzen der Ist- statt der Sollgeschwindigkeit erzeugt, habe ich
meine Lua Brems Routinen aus der Anlage einfach weiter benutzt und etwas angepaßt.

Hier ein Test für einen Block auf Gleis 2:

Video zur Rocrail Steuerung mit Lua Bremsroutinen

Bearbeitet 9. Februar 2020 von HaNNoveraNer