-
Gesamte Inhalte
118 -
Benutzer seit
-
Letzter Besuch
Letzte Besucher des Profils
588 Profilaufrufe
-
da hast du recht @Goetz, und das ist eine wunderbare Eigenschaft des Studios, das leisten aber viele Biotope, in denen Lua haust, auch! ich denke, jetzt ist zum "Breakpoint" Thema genug gesagt danke, sagt der Liftboy die Steuerung meines Schattenbahnhofs, dem im Forum ein paar mal geholfen wurde, ist fertig und kann in meine "Landsberg" Anlage eingebaut werden (das ganze ist ja ein Test für eine geplante "reale" Anlage) 3-15-Build.9.3.test-sbhf.4.mbp
-
Hallo @EASY zum Löschen finde ich sonst auch nichts. Mein nebenbei zum Testen verwendeter "https://onecompiler.com/lua/" löscht mit nil alles! was man nirgendwo sieht ist, ob der garbage-collector alles erwischt (da ist lua aber scheinbar gut) Grüße vom Liftboy
-
danke ! @Neo wie kann ich eine variable endgültig löschen? schreibe ich x.variables.y = nil, dann wird sie weiterhin mit type==nil geführt lösche ich sie mit dem Editor, dann ist sie endgültig verschwunden Grüße vom Liftboy
-
ok ich hab eine schnelle Methode gefunden: ich schreibe "Stop()" --- findet er nicht --- stoppt den Ablauf Es darf natürlich keine function "Stop" geben Grüße vom Liftboy
-
Hallo, wie setze ich in der Ereignisprotokollierung am einfachsten einen "breakpoint". Goetz hat mal was angedeutet...finde ich nicht mehr frägt der Liftboy
-
Hallo @Roter Brummer Es gibt ja 4 Gleise, G1,G2,G3,G4, ich habe nur das Problemgleis G1 rausgezogen. Wenn's dich interessiert gibt's den Download weiter oben Grüße vom Liftboy
-
Hallo @Neo, @Hawkeye nochmals danke für eure Bemühungen, ich habe mein Problem jetzt komplett durchdrungen (manchmal wäre die Analyse vor der Synthese besser!) Vielleicht hilft es ja anderen Benutzern auch, deswegen folgende Skizze der Situation: Loc "c" fordert die FS P.N->wird reserviert weil Loc "b" steht auf G1 und fordert FS G1.A, blockiert gleichzeitig C.G1 Lok "a" ist auf dem Weg nach C und wird bald C.G1 fordern (Entscheidung von meinem sceduler) "b" gewinnt vor "c" und fährt los, blockiert nicht länger C.G1, blockiert aber weiterhin P.N "a" kommt zwischenzeitlich und bekommt sofort C.G1(frei) aber sollte von P.N eigentlich reserviert sein. Fazit : im weiterem Verlauf wird "c" nicht schnell weiterkommen, es sei denn "c" bekommt im Schattenbahnhof C.G2 | C.G3 | C.G4 (alle nicht gezeichnet) zugeordnet Mein Eingriff: wenn P.N angefordert ist, wird C.G1 im sceduler blockiert (einfach), damit wird P.N priorisiert Hinweis: das im Ablauf versteckte Problem(von Hawkey und Neo beschrieben) habe ich durch Trennung der Gleise gelöst Grüße vom Liftboy
-
Hallo @Hawkeye, hat Neo eigentlich schon auf das Problem reagiert? ich habe 8.5.5.0 im Einsatz. Das Problem tritt sporadisch wieder auf, ich versuche gerade es sauber zu extrahieren und melde mich dann nochmals Grüße vom Liftboy
-
Hallo, Nachschlag: wo finde ich die ersten Analysen dieses Problems, deren Anlagen und die Lösungen Grüße vom Liftboy
-
Hallo @Hawkeye @Goetz, shame on me, danke für die schnelle Analyse, das Ding läuft jetzt perfekt, nur mit Fahrstraßen. Interessant zu sehen ist, wie die beiden sections auseinanderlaufen und sich wieder ordnen - ohne weitere Steuerung. danke und Grüße vom Liftboy
-
Hallo @Goetz, ich hatte das auch im Kopf und habe die Gleise getrennt - ohne Erfolg Grüße vom Liftboy
-
Hallo, ich habe einen Schattenbahnhof, der aus 2 gespiegelten Teilen mit je 4 Gleisen besteht (section 36 und section 37). Zum Testen gibt es jeweils einen Zubringer bestehend aus 2 Gleisen und auf der Zubringer Strecke mit je einem Ausweichgleis. Jede section ist im Prinzip eine Kehrschleife. Zwischen den sections gibt es eine Verbindung die in beiden Richtungen befahrbar ist. Jeder Ausgang dieser Verbindung führt in die gegnerische Kehrschleife in umgekehrter Richtung ! Um den Wechsel-Betrieb zu Vereinfachen gibt es 2 Definitionen : Ausfahrgleis ist jeweils Gleis 2 Einfahr-Gleis ist jeweils Gleis-1 Die Programmierung ist äußerst einfach und läßt 8 Züge ohne Kollision (in meinem Test ca 3.000 mal == 1 Nacht, ohne Problem) fahren Alles wird über Fahrstraßen gesteuert. Das Ende einer Fahrstraße fordert die darauffolgende an. In der Einfahrt zu den 4 Gleisen entscheidet ein simpler loop über die (freien) Gleise Die Fahrstraßen funktionieren perfekt bis auf eine Ausnahme und deswegen poste ich hier: die Einfahrt aus section 36 in die section 37(Gleis-1) führt ab und zu zu deadlocks weil: die section 37 das Gleis-1 (das eigentlich durch die Fahrstraße vorbelegt ist) ebenfalls belegt extrahiert zeigt sich die Situation G1 37C->---|-----Gleis1----------------->| $("37C.37G1") |<----Gleis1------------------|-----<-37P $("37P.37N2-Umfahrt") N2 es geht um die Fahrstraße "36P.36N2 Umfahrt" versus "36C.G1" (section 36) es geht um die Fahrstraße "37P.37N2 Umfahrt" versus "37C.G1" (section 37) Ich muß diese Situation manuell abfangen durch präventives Blockieren der potentiellen Fahrstraßen Freigabe EIGENTLICH IST DAS EINFACH, ABER ES SOLLTE NICHT NOTWENDIG SEIN Zu finden im Script "Gleiskontakt Verteiler Abschnitt C wird ausgelöst" der Taster "TEST START" kann jederzeit ausgelöst werden, er löscht alle Fahrstraßen er entriegelt alle Weichen er gleist alle Test-Loks auf er startet alle Test-Loks er setzt alle counters zurück Ich glaube letztendlich ist der Betrieb selbsterklärend Hoffentlich schreckt die lange Erklärung niemand ab und hoffe auf Aufklärung des Phänomens durch einen erfahrenen MBS'ler (ich hab da zwei im Kopf) Danke sagt der Liftboy Test-36-37-problem.mbp
-
danke für Deinen Tip, @Hawkeye, ich habe den Feature-Wunsch gestellt ! Grüße vom Liftboy
-
Hallo @Neo, ich habe in meiner 1/2 jährigen MBS-Karriere immer wieder während der Konstruktionsphase, eine Event-Aktion: "layout:getEntitybyMouseSelect " vermißt. Zuletzt beim immer wiederkehrendem Aufgleisen einer Test-Lok, die ich, wenn Sie aufgegleist ist mit einem "Start-Button" zur weiteren Verwendung bediene. Bei solchen und ähnlichen Aktionen lassen sich schnell zwei,drei weitere mouse-clicks einsparen - im Beispiel das händische aufgleisen... meint der Liftboy