AndreasWB

Hallo @Goetzm, was bitte ist bei Beschleunigung und Beschleunigung der Unterschied? Bei einem Fahrzeug mit Antrieb ggf. auch durch den Motor oder beim Wagen (vergessen Bremse anzuziehen) durch Gravitationswirkung. Die Änderung des Bewegungszustands ist dieselbe. Selbst wenn die Programmierer das evtl. durch verschiedenen Methoden in der Klasse hinterlegt haben (sofern überhaupt OOP programmiert). Mit Respekt Andreas

Hallo @Goetz, das kann man so nicht sagen. Sinnvoll ist geanu diese Einstellung beim Ablaufberg. Damit werden Dinge möglich, mit denen man auch physikalische Grundgesetze (hier den Impulssatz) demonstrieren kann. Allerdings sollte man solches nicht bei der großen Bahn versuchen - Duck und wech ... Video: https://mega.nz/file/hrNVgCpb#goM2Nfc2iXh6memXdQxPFKVMuN8SaQZHYO5iTGAmdic Eigentlich ist das Thema schon alt. Ich hatte es bereits unter V6 umgesetzt. Mit den neuen Möglichkeiten in der EV für V9 macht es natürlich etwas mehr Spaß. Gruß Andreas

Der eindeutige Rat vom Softwarearchitekten: Redundanzen vermeiden - sonst kommt es zu Anomalien. Gruß Andreas

Hallo @guenter.strickmann, im Prinzip ist Dein Gedanke und auch Deine Strategie OK. Allerdings finde ich in Deiner letzten Anlage keine Tabelle "Tab". Ich habe auf die Schnelle eine vereinfachte Ausführung eines Kopfbahnhofs gebastelt. Anlage siehe Anhang. Alle Tabellenfelder, die Du schreiben willst, müssen vorher vorhanden sein. Ist bei Dir, soweit ich gesehen habe, auch der Fall. Nun zur Tabelle: Es ist "nur" eine Tabelle für den gesamten Bahnhof. Jeder End-Kontakt kennt die Nummer seines Gleises. Ich habe pro Gleis nur zwei Variable (Tabellenspalten) definiert. Für jedes Gleis gibt es in der Tabelle jeweils eine Zeile (soweit folge ich in der Beschreibung der bekannten Tabellenart (Datenbanken, Excel, usw.) Das ist in MBS etwas anders (warum auch immer?) Hier muß man eine Liste der Tabellenzeilen erstellen. Daher ist die "Tabelle" zunächst vom Typ Liste (Liste der Tabellen-Zeilen). In jedem Listeneintrag (Zeile) definiert man die Spalten (In MBS "Tabelle" genannt). Und genau das spiegelt sich dann auch im Aufbau dieser Modul-Variablen wider. Für jeden Listeneintrag muß ich also ein Element vom Typ "Tabelle" definieren. Hier fällt auf, daß man keinen Namen vergeben kann, sondern die Namen dann innerhalt der Tabellen(-zeile) die Spaltennamen sind. Wie spricht man das dann in der EV an? Etwas verwirrend im Zusammenbau, aber final funktioniert es dann. Und die Logik mit "unserem" Tabellen-Verständnis stimmt ja auch in der Schreibweise: (Tabellenname)[Zeilenindex][Spaltenindex]. Im Anhang findest Du auch die Anlage. Beim Einfahren in einem Gleis trägt sich die Lok ein; beim Verlassen löscht sie wieder ihren Eintrag. Gruß Andreas Test Tabelle schreiben.mbp

Hallo @guenter.strickmann, ich hatte unlängst einen Beitrag zur Ablaufsteuerung in einem Kopfbahnhof hier eingestellt. Der gesamte im Video gezeigte Ablauf ist voll automatisch. Basis dafür ist u. a. eine "Servicetabelle", deren Struktur die angehängte Abbildung zeigt. Vielleicht kann dies für Dich als weitere Anregung dienen (auch wenn das mit BW und Drehscheibe natürlich etwas antiquiert ist). Gruß Andreas

Danke @streit_ross, ich habe bewußt den "Bearbeitungs-Modus" für das Video benutzt, da sonst die Tiefenschärfe leider zu gering ist. Für Modellbahn ist das mit der geringen Tiefenschärfe ja auch das übliche Problem der Fotografen. "Wieso ist alles drumherum so unscharf? Das habe ich mit den Augen doch alles scharf gesehen." Der Dampfausstoß bei den Modellen ist ein echtes Problem. Wurde schon öfter hier diskutiert. Ich weiß, daß bei Loks, die im Schuppen abgestellt werden, das Feuer aber auf einem Minimum gehalten wird. Natürlich braucht es dann immer noch sehr lange, bis wieder volle Leistung vorhanden ist. Daher werden die Loks für den alltäglichen Einsatz wohl irgendwo draußen unter vollem Feuer geparkt. Beim Modell der Br81 ist mir aufgefallen, daß der Fahr-Sound voll weitertönt, obwohl die Lok steht. Und vergleicht man die Modelle hier mal mit EEP, ... - Aber das ist wohl eine volkommen andere Plattform. -> Ich sehe gerade: Bei den Weichen hätte er dann aber bitte auch ewtas mehr ins Detail gehen dürfen. Und die Sperrsignale sind auch keine Reichsbahn-Signale ... Zu meinem Video muß ich noch sagen, daß es mir auf die Gestaltung des Ablaufs mittels EV ankam. Für das Video mußte ich bei den verschiedenen Kamera-Positionen stückeln, da einige Abläufe auch parallel stattfinden. Der gesamte Ablauf jedoch läuft ohne jeglichen manuellen Eingriff in genau dieser Form durch. Gruß Andreas

Hallo zusammen, neben dem Zusammenbasteln der umfangreichen Gleisanlagen habe ich mir auch Gedanken gemacht, wie die wesentlichen Abläufe in MBS automatisch gesteuert werden können. Dazu habe ich eine stark vereinfachte Ausführung der Konstellation Kopfbahnhof mit BW als kleine Anlage erstellt. Natürlich benötigt es im Vorfeld auch eine konzeptionelle Beschreibung der Betriebsabläufe und der notwendigen Informationen für die Automatisierung. Diese findet sich in dem angehängten pdf. Der erste Teil des Hauptablaufs (Ankunft eines Zuges und danach Abstellen von Wagen und Lokomotive) ist soweit fertiggesteltl und in diesem kleinen Film zu betrachten. -> https://mega.nz/file/5it1QbAQ#RDe7uBIxSFf2sx-olxmbQ9tcyFMuNRroGx4U2Pk0MhI Da an den einzelnen Punkten der Abläufe sowohl Gleiskontakte, als auch Signale und Fahrstraßen zahlreiche individuelle Aufgaben und Abhängigkeiten haben, ist eine erschreckende Zahl von Abläufen in der EV entstanden. Gruß Andreas Ablauf Zugwechsel.pdf

Hallo @Phrontistes, wenn Du Zitatschnipsel aus dem Zusammenhang reiß, versteht niemand mehr, worum es da geht. Habe ich gesehen. Es fehlt z.B. der gesamte Überbau (Programm-Rahmen) der Prozedur (benutzerdefiniertes Ereignis in MBS-EV). @prinz: Daß Du das Ergebnis in eine extra Variable außerhalb der Prozedur (benutzdefinierts Ereignis) stecken mußtes, liegt ganau an dem, was ich beschrieben habe: Prozedruren besitzen keine Rückgabe ihrer Ergebnisse. Klar können Sie tun was auch immer sie wollen, das aufrufende Programm bekommt es nicht direkt zurückgegeben, sondern nur über den von Dir bechriebenen Umweg. Das ist aber keine saubere Software-Architektur. Und über die asynchrone Abarbeitung hatte ich auch geschrieben. Wenn dann mehrere Prozeduren auf dieselben Variablen zugreifen, kann es genau zu den von Dir beobachteten Verwirrungen kommen. Also ein weiterer Grund, die von mir beschriebenen Aspekte im Hinterkopf zu behalten. So - das war's von meiner Seite zu diesem Thema. Gruß Andreas

Sorry @Goetz, aber ich zitiere mal aus der Oberfläche zur Erstellung der EVs: "Wann wird das Ereignis ausgelöst? Manuell durch eine Ereignis-Aktion()" Es ist also ein Programmschritt einer anderen EV, die dieses "Unterprogramm" aufruft. Es wird nicht direkt durch den Benutzer, bzw. einem Gleiskontakt, einem schaltenden Signal, ... gestartet. Also nicht durch ein Ereignis auf der Anlage direkt.

Hallo @Swen44 und die anderen, vielleicht mal ein paar Grundsätzliche Erklärungen zu diesem Thema. Die Begriffe "Hauptprogramm" und "Unterprogramm" sind in der Programmierung übliche Begriffe. Ein Hauptprogramm ist das, was vom Benutzer oder anderen Initiatoren gestartet wird. Es gibt aber auch Aufgaben, die immer wieder mal durchgeführt werden müssen. Um diese nicht für jede Ausführung extra wiederholt zu schreiben (unnötige Redundanz), wird jede Aufgabe einmalig im Programm-Code hinterlegt und dann im übergeordneten Programmablauf an der richtigen Stelle aufgerufen. Das sind dann eben die sogannten "Unterprogramme". Das Ganze steht auch im Zusammenhang mit Modularisierung (auch Wiederverwendung) und senkt den Wartungsaufwand von Software erheblich. Es gibt aber zwei verschiedene Arten dieser Unterprogramme: Funktionen Diese Art von Unterprogramm erzeugt am Ende seines Ablaufs ein Ergebnis, das im übergerodneten (aufrufenden) Programm weiterverarbeitet werden soll. Hier springt also die Verarbeitung vom aufrufenden Programm in diese Funktion. Erst wenn die Funktion fertig ist und das Ergebnis an das aufrufende Programm übergeben wurde, arbeitet das aufrufende Programm mit dem nächsten Programmschritt weiter. Das ist wohl auch das, worann @Swen44 dachte. Prozeduren Hier haben wir es mit eigenständigen Unterprogrammen zu tun, die vom aufrufenden Programm angestoßen werden und eben ihr eigen Ding machen, ohne ein Ergebnis an das aufrufende Programm zu übergeben. Das Ganze läuft also programm-logisch gesehen parallel (unabhängig; asynchron) ab. Daher macht das aufrufende Programm einfach ohne Unterbrechung mit seiner nächsten Anweisung weiter, weil es ja eben nicht auf das Unterprogramm warten muß. Das ist der Mechanismus, der in der grafischen EV in MBS zur Anwendung kommt. Wenn jetzt LUA eine hablwegs normale Programmiersprache ist, werden hier beide Formen von Unterprogrammen unterstützt. Nicht aber in der grafischen EV von MBS. Ich hoffe, das trägt etwas zur Aufklärung bei. Gruß Andreas

Hallo, vielleicht kann ich Informationen zur Aufklärung beitragen. In einem anderen Zusammenhang arbeite ich mit einem Render-Programm, daß mit Blender kompartibel ist. Das Problem der Lichtsäume trat da bei einer bestimmten Render-Engine (3Delight) auf. Die Methodik bestimmter Belichtungs-Mechanismen erinnert mich stark an die Wirkung in MBS. Was war der Effekt? Die Lichtsäume traten auf, wenn zwei Oberflächen sehr nahe beieinander lagen oder sich direkt berührten (Hier die Räder des Skateboards auf dem Boden). In den Render-Einstellungen gab es für die Erzeugung der Abschattung eine "shadow-bias". Diese hatte einen minimal einstellbaren Wert. Mehr durch Zufall habe ich herausgefunden, daß ich eine Kopie der Grundebene von unten näher an die Grundebene heranlegen mußte, als der Wert der "shadow-bias" - und der Lichtsaum war verschwunden. Was die Render-Engine macht und welche Algorithmen dahiner stecken, bleibt Geheimnis der Entwickler der betreffenden Render-Engine. Vielleicht kann mein Beitrag ja einen Hinweis zur Lösung geben, da diese Familie dieser Anwendungen nach den gliechen Prinzipien arbeitet. Gruß Andreas

Hallo @moon2018, hm merkwürdiges Angebot. Laut KATO-Homepage gibt es solche Gleise nicht. -> somit auch nicht im MBS-Katalog. Gruß Andreas

Hallo @ChristianV und Kollegen, das Problem wurde bereits in dieser Diskussion thematisiert. Hier findet Ihr auch einen derzeitigen workaround. Gruß Andreas

Ergänzung: weil ich gerade in Deinem Post sehe: "Alle Fahrzeuge auf Kontakt XY" Steht ein Zug mit Steuerwagen (Antrieb ausgeschaltet) am Gleiskontakt eines Signals, wird doch auch der "Losfahr-"Befehl an die Lok übermittelt. Außerdem bekommt man bei Abfrage immer das Triebfahrzeug-Objekt übertragen, nicht den Steuerwagen, der ja eigentlich auf dem Kontakt steht. -> Also komplett inkonstistentes Verhalten. Gruß Andreas

Hallo @Goetz, ich denke eher, daß der Themekomplex schon irgendwie zusammenhängt. Zum Thema mit hintereinander folgenden Anweisungen an Fahrzeuge (egal ob Einzellok oder Zugverband) sollte es doch so sein, daß nach der einmaligen Befehlsübermittlung das "Fahrzeug" auf neue Anweisungen neu reagieren können sollte, auch wenn ein vorheriger Befehl noch nicht komplett abgearbeitet ist. Vor allem, weil hier Einzelfahrzeuge sich anders verhalten, als längere Fahrzeugverbände. Anderes Beispiel, das mich zu diesem Post veranlaßt hat: Steht eine Tenderlok alleine auf dem Gleiskontakt (der grün-gelbe), kann man ihr alles übermitteln, was ich in der ersten Gruppe aufgezählt habe. Ist noch etwas angehängt, z. B. ein Tender oder wie hier ein Wagen, funktioniert die Geschwindigkeitszuweisung nicht mehr. Oder: Am Ende der Schuppengleise befindet sich jeweils ein End-Kontakt. Dort wird die Lok, egal ob Tenderlok oder mit Schlepptender, angehalten, die Fahrtrichtung erfolgreich umgekehrt. Der Befehl zum dann später wieder losfahren funktioniert aber nur bei der Tenderlok. Bei einer 01 oder 05 oder 18 mit Schlepptender nicht. Eigentlich das gleiche unterschiedliche Verhalten, wie beim (nicht-) blockieren von Schiebebühne und Drehscheibe. Nach objektorientiertem Paradigma ist ein Zug eine Aggregation aus Triebfahzeug(en) und Anhängern und zeigt egal wie zusammengestellt immer identisches Verhalten. Im MBS leider nicht. Genau das kostet hier immer wieder Stunden mit dem Finden des Fehlers und Basteln entsprechender workarounds. So toll Euer Programm ansonsten auch ist, an manchen Stellen ist es schlicht zum Verzweifeln und kostet unnütz Zeit. Nichts für Ungut Gruß Andreas