gmd

Das eine schliesst das andere nicht aus und es hat nichts mit IT entwicklern zu tun, es ist einfach eine frage auch juengere menschen zu interessieren und ein breiteres publikum anzusprechen. Es ist ein marketing exercise. Wenn du nicht mehr bezahlen willst und zufrieden bist, prima. Aber es lassen sich erweiterungen denken die optional sind, also nicht gekauft werden muessen, aber fuer diejenigen die sie nutzen wollen zur verfuegung stehen. Der autor muss eine zukunftsorientiertes konzept haben dass seine benutzer basis erweitert und nicht nur die bestehenden veranlasst neue versionen zu kaufen. Das ist halt meine meinung und ich behaupte nicht dass das fuer das MBS richtig ist, ich sehe nur das problem die juengeren menschen mit denen ich zu tun habe fuer dinge zu begeistern, die einfach muehsam sind. Es ist normal heutzurage dass man nicht nur ein hobby hat, sondern halbwegs intelligente menschen beschaeftigen sich mit mehreren themen gleichzeitig. Und wenn man von einem zum anderen wechselt, dann ist es schwer jemanden zu begeistern wenn ergebnisse nur muehsam erreicht werden. Ich beschaeftige mich mit microcontrollern, webdesign, amateurfunk, baue meinen eigenen caravan, leite ein IT projekt und gelegentlich benutze MBS fuer ein paar stunden und gehe dann wieder weiter. In allen gebieten werden werkzeuge, module, libraries usw. verwendet um teilprobleme schneller zu loesen und erstellung von loesungen zu automatisieren und zu vereinfachen, das gilt auch fuer hobbies. Ich habe meinem enkel eine busy box gebaut mit allen moeglichen schaltern, leds, gesture sensor, audio decoder usw. gestuert von zwei arduinos. Da verwendet man auch nicht nur transistoren und widerstaende sondern module und programmiert mit libraries und nicht von scratch in maschinencode. Das ist nur ein beispiel. Heute diagnostiziert man kein problem am auto ohne OBDII leser und es gibt viele andere beispiele. Amateurfunk ist am aussterben, da nicht genug innovation moeglcih ist und durch andere gebiete ersetzt wurde. In der vergangenheit war das eine zeitfuellendes hobby fuer viele und die mussten lange lernen fuer die volle lizenz. Heute lernt man die theorie in ein paar tagen und andere dinge nebenbei. Die anforderungen sind andere geworden. Die einzige antwort fuer mich liegt darin die verschiedenen interessen der menschen zu unterstuetzen und nicht einzuschraenken und das geschieht ueber modulare konzepte in der jeder seine loesung findet. Du kaufst auch kein gespann (auto und caravan) sondern beides getrennt fuer verschiedene ansprueche wenn du dir kein spezielles zugfahrzeug leisten kannst. Und viele andere beispiele. Viel interessen lassen sich selten mit einer starren loesung unter einen hut bringen. Es gibt noch viele themen bereiche in denen modularisierung (personalisierung) nicht stattindet und die in der zukunft probleme haben. Ok, das ist jetzt philosophisch. Ich bin jedenfalls offen fuer jede innovation aber gleichzeitug kritisch und verlange nicht von anderen den weg mitzugehen. Kritigfaehigkeit muss man auch behalten, zum beispiel habe ich nie den facebook unsinn mitgemacht und bin auch heute noch ein gegener aus vielen gruenden. Das ist fuer mich nicht innovation, das ist abzocken auf kosten der dummen und davon gibt es offensichtlich viele. gruss gmd

Hallo, nachdem ich ja einiges geschrieben habe was ich mir fuer MBS vorstellen koennte, hier mal ein kompliment. Ich habe mal aus interesse meine beiden anlagen die ich gebaut habe kombiniert. Das ist etwas muehsam wenn man alle layer getrennt haelt aber es geht. Es entsteht eine monsteranlage und ich wollte mal sehen wie die grafik engine das bewaeltigt. Im gesamtbild ist die bildrate etwas niedrig und die bewegung nicht sehr geschmeidig aber wenn man vergroessert dann wird es besser und besser. Ich bin wirklich happy mit der performance und das etwas ruppige fahren im gesamtbild ist eigentlich keit problem weil bei einer solchen anlage der gesamtblick wirklich nicht relevant ist ausser vielleicht zum testen. An der landschaft muss ich noch etwas arbeiten und das geht sehr gut, ohne einschraenkung, trotz der groesse der anlage. Die GPU ist bei 23% und die CPU bei 16%, da ist noch spielraum, allerdings die vorhandene version ist schon ziemlich gut. gruss gmd

Das prizip von libraries, einbinden wenn gebraucht. Ist nuicht einfach, wuerde sehr spezifische programmier konventionen erfordern. Ich habe ein ganz anderes problem mit den traditionellen wegen der definition von komponenten, das betrifft auch rocRail. Man selektiert ein objekt und vergiebt einen namen und stellt eigenschaften ein. Man verlegt gleise eines nach dem anderen und fuegt weichen manuell ein wo man abzweige braucht, ganz zu schweigen vom aufbau der oberleitung. Die meisten dieser funktionen sind altertuemlich. Ich kann ja verstehen woher das kommt und die anzahl der lizenzen rechtfertig nur einen gewissen aufwand. Man koennte auch argumentieren dass es ja ein hobby ist und man halt zeit braucht etwas aufzubauen. Ich sehe das aber anders. Warum baut man module ? um ein endergebnis schneller zu erreichen. Das gleiche gilt fuer landschaftskomponenten. Alle diese ansaetze kommen aus dem traditionellen denken eines realen anlagenbaus. Allerdings kann man heute bessere loesungen schaffen, da wir ja sehr viel mehr computer leistung haben. MBS hat eine sehr gute basis, die grafik engine laeuft gut, die simulation ist schnell gegenueber anderen loesungen, viele ansaetze sind sehr gut gemacht. Allerdings fehlt eine definitionsebene ueber der manuellen erstellung von einzelstrecken. Fangen wir mal klein an: Benennung von objekten ist sicher ein muehsames geschaeft. Das programm koennte hier wesentliche hilfe bieten, z.b. ein anfangsgleis ist benannt (prefix, typkennzeichen, laufende nummer etc gemaess eines abschnitts) beim anfuegen eines gleises kann ein eindeutiger name automatisch erzeugt werden. Das gleiche kann man machen wenn man mehrere objekte markiert. In abhaengigkeit der objekte koennen automatisch namen erzeugt werden mit einer "Namens funktion". Das ist nur ein low level beispiel. Ein block kann als ganzes eingefuegt werden inclusive aller kontakte und logik. Oberleitung kann automatisch verlegt werden. Selektionsfunktionen gehen ueber lange abstrakte listen statt das gewuenschte objekt mit der maus auszuwaehlen weil alle dialoge modal sind. Und vieles mehr... Das MBS ist eines der fortschrittlichen programme, die anderen sind noch rueckstaendiger gemessen an modernen softwaremoeglichkeiten. Man muss sich die frage stellen, ob man an dem vorbild der realanlage bleibt oder ein wirkliches "Spielprogramm" baut. Zum spielen ist jedes Modellbauprogramm ungeeignet, zuviel aufwand um ein wuenschenswertes ergenbis zu erreichen. Nun seit nicht eingeschnappt wenn ich sowas schreibe. Dies ist keine kritik and den nutzern und auch nicht an den autoren. Ein business case zu machen aus dem was ich schreibe ist sicher schwierig wenn nicht unmoeglich, aber wenigstens einige funktionen sollten mehr Wizard aehnlich werden. Ich fuer meinen teil wuerde auch mehr geld bezahlen fuer einen bessere definitionsoberflaeche. Mehr funktionalitaet hat allerdings auch das problem dass sie bessere dokumentation braucht und die ist etwas duerftig mit dem MBS, wenn man das forum weglaesst. Aber auch das forum wird immer schwieriger zu benutzen da die suchergebnisse und antworten nicht nach versionen gefiltert sind. Und wer will schon steuerungsproblem von V4 lesen, oder aelter, wenn er ein Lua problem hat. Nur ein paar gedanken. gruss gmd

Thomas, habe das mit der letzten anlage gemacht. Brauche kein gleisbild und habe andere vorstellungen hinsichtlich des definitionsaufwandes. Sind viele dinge die ich an RocRail nicht mag, unter anderem der definitionsaufwand fuer eine grosse anlage. Ausserdem hat mich die neue EV einfach mal gereitzt dem auf den zahn zu fuehlen. Allerdings fehlen noch etliche dinge fuer meinen geschmack .. werde mal die externe schnittstelle ausprobieren und dann wieder eine pause machen. Habe noch andere projekte Das gleisbild in MBS reitzt mich ueberhaupt nicht da es nicht in einem separaten window laeuft, was ja bei rocrail der fall ist. Geht zuviel platz weg auch wenn ich einen grossen screen habe. Das andere problem was ich mit Lua habe ist dass der font im editor zu klein ist fuer mich und nicht die groesseneinstellung des system font beruecksichtigt. Da benutze ich doch lieber eine andere Entwicklungsumgebung. Werde allerdings das Lua experiment weitermachen bis zu einer funktionierenden Loesung auch wenn sie noch nicht wirklich optimal ist. gruss gmd

Das verstehe ich nicht. Kannst du mir erklaeren was das mit security zu tun hat ? gruss gmd

Noch ein weiterer gedanke zur automatisierung von steuerungserstellung: Lua erlaubt dateien zu schreiben und zu lesen, wir koennen also zustaende persistent machen (festhalten/speichern). Fuer die definitionen von fahrstrassen ist folgende denkbar: Man baut ein einstellgleis und ein script identifiziert den zug und ordent ein paar eigenschaften zu, die man auch editieren kann. Dann startet man den zug und laesst in ueber die moeglichen strecken fahren, die dieser zu kennen soll. Weichen werden manuell gestellt, die steuerung zeichnet weichenstellung und blockfolge auf. Verschwindet der zug auf einem "Rueckfuehrblock" ist die Ausfzeichnung zu ende und der zug wird positioniert (per script angaben auf ein freise gleis dass den ausgangspunkt fuer diesen zug darstellt. Wenn ein kreis enstanden ist wird der zug am ziel/startort angehalten und die einfuehrung ist beendet. Das kann man wiederholen mit allen zuegen die verschiedene routen fahren sollen. Bereits erstellte routen koennen anderen zuegen zugeordnet werden. Auf diese art kann die anlage "lernen" und es ist sogar denkbar sich eine regelbasierte steuerung vorzustellen und nicht ereignis getriebene starre algorithmen. Aber das ist wohl v10 gruss gmd

Ich denke das eine schliesst das andere nicht aus. Wenn man moeglichst realistisch bauen will braucht man sehr differenziertes verhalten der zuege. Wenn man frei baut und eine groessere anlage baut braucht man eine gewiise strukture sonst ist es chancenlos eine gewisse automatisierung zu schaffen die zuverlaessig laeuft. In beiden faellen ist ein gutes konzept einsetzbar wenn es flexibel genug ist. gruss gmd

Andy, guter kommentar. Zum begriff Metaebene: Mit dem ev editor erzeugst du oder verbindest du objekte, variable, events usw. Nehmen wir das beispiel eines events. Wenn du den im EV editor anlegst kannst du einen type zuordnen usw. Mit meta ebene ist gemeint dass du per script diese operationen machen kannst ohne einen editor. Zum beispiel hast du dann auch script element die es erlauben the even baum abzulaufen, zu erweitern usw. Es besteht dann keine einschraenkung mehr was du mit dem script und was du mit dem editor machen kannst. Theoretisch ist der edito als solcher ueberfluessig und man braucht nur noch einen guten text/syntax editor und macht alles per script.. Aber das ist sicher nicht die eigentluche zielsetzung des MBS. Ich denke dass Neo hier einen guten job gemacht hat die EV mit grafischen elementen fuer nicht programmieren zugaenglich zu machen. Das ist alles sehr gut und vernuenftig fuer viele. Fuer mehr abstrakt denkende menschen wie mich ist die automatisierung immer im vordergrund und alles was sich wiederholt ist langweilig, das muss man abkuerzen und dazu sind elementa zum zugriff auf die definitionsebene des MBS nuetzlich. Zum thema block: Ich definiere den block aus steuerungstechnischer sicht (programmierung). Ich bin kein wirklicher Eisenbahner und weiss auch nicht allzuviel ueber die reale blocksteuerung aber habe eine gewisse vorstellung. Hier ein paar gedanken. Wie bereits weiter oben am beispiel geschrieben ist ein block fuer mich eine abzweigungsfreie gleisfolge die vor einfahrt geschuetzt werden kann und am ende ein Blocksignal hat welches die Ausfahrt regelt. Nun ein paar gedanken was im block passieren kann und welche parameter man vorsehen koennte. Ich sehe verschiedene eigenschaften die unterschiedliche typen von bloecken verwenden, allerdings sollte eine einzige logik alle faelle abdecken. Die wesentlichen unterschiede betreffen die behandlung der bloecke durch die steuerung und nicht die bloecke selbst Blocktypen Streckenblock (Untergruppen: Langsamfahrt(Bergfahrt), Schnellfahrt, Ausweichblock) Durchfahrtblock (Bahnhof durchfahrten fuer unterschiedliche zugtypen) Halteblock (Bahnhof halt, Strecken haltepunkt ) Rangierblock Verladeblock Parkblock (Zuege kooenen aufgesetzt werden und von der steuerung erkannt und integriert) und vielleicht noch mehr Bei den eigenschaften ist es manchmal schwer zu entscheiden wo sie hingehoeren, zum fahrzeug order zur strecke oder zu beiden. Beispiel: Eine Lok hat eine maximal geschwindigkeit, die aber gerinegr sein kann je nachdem was dranhaengt und obendrein kann ein block eine geschwindigkeitsbegrenzung bedeuten und das unterschiedlich je nach zugtyp. Hier muss man sicherlich komporomisse machen da man sonst im datenmeer versinkt. Das ist wiederum der vorteil von tabellengetriebenen meta scripts da hier die anzahl der script teile geringer is und in der regel uebersichtlicher als hunderte von verteilten event definitionen.Das haengt stark von der groesse ab. Eigenschaften (Beispiele) Geschwindigkeiten: Einfahrgeschwindigkeit, Bremsgeschwindigkeit, Ausfahrgeschwindigkeit, Streckengeschwindigkeit Betriebszustaende Belegt,Frei,Reserviert,Gesperrt, Befahren, Rangierbetrieb, imBau usw. jeder zustand hat bedeutung und konsequenzen Aktionszustande Einfahrt,Bremsen,Halt,Ausfahrt, Einfahrt moeglich, Ausfahrt moeglich Spezielle Eigenschaften Doppeltraktion abfragen Haltepunkt einhalten Abzweig voraus Einfahrt voraus Vorsignalsteuerung - Langsam fahrt erwarten Unterstuetzen verschiedener signalbilder Lok wechsel Richtungswechsel (mit und ohne Lokwechsel) Doppeltraktion herstellen Doppeltraktion loesen und andere Wenn man die anzahl der moeglichkeiten betrachtet dann ist es ziemlich schnell klar, dass man dies nur mit generischen scripts loesen kann und nicht jeden einzelfall programmieren kann. Das gleiche gilt fuer den anschluss von gleisbild stellwerken. Die erkennung und benennung von gleisen und anbindung an die gbs module muss automatisiert werden. Nur ein paar gedanken. Mein ansatz ist eine solche allgemeine blockverwaltung zu schaffen und dann stueck fuer stueck erweitern und die definitionstabellen anpassen. Das ziel ist es dies nur mit einem zentralen script zu tun, das man nur einmal aendern muss. gruss gmd

Hier ein eindruck von der anlage die ich als test verwende http://vk6gmd.com/anlage_lua.mp4 gruss gmd

Hallo, ich denke es macht sinn einen neuen thread fuer diese diskussion zu machen. Der nachfolgende text ist der kommentar aus meinem script und ich denke es ist besser lesbar als normaler text und nicht als script. --[[ ************************************************* Initialisierung Jeder wesentliche anlagen abschnitt hat eine bezeichnung und abkuerzung, die als prefix fuer komponnten namen verwendet wird. Blockabschnitte sind abzweigungsfreie streckenteile die mit einfahr-/ausfahrsignalen gesichert sind, wobei das ausfahrsignal eines blocks das einfahrsignal fuer den naechsten block darstellt. Zwischen bloecken liegen verbindungsstrassen mit abzweigen, die je nach ziel von der fahrstrassenverwaltung geschaltet werden. Bei groesseren anlagen, wie in diesem fall, gibt es eine vielzahl von bloecken und die erstellung der steuerung kann langwierig sein, wenn keine generalisierte loesung eingesetzt werden kann. Ein weiterer grund fuer zentrale routinen liegt in der groesseren betriebssicherheit (gerigerer testaufwand) und besserer erweiterbarkeit. Zuseatzliche funktionen muessen nur an einer stelle eingefuegt werden, wie z.B. doppeltraktionsabfragen, fahrzeugverwaltung, richtungsbestimmung, haltepunktberechnungen usw. Wenn man differenzierte steuerungen bauen will dann sind eine vielzahl von steuerungseingaben zu verwalten. Dieses konzept soll dazu dienen eine automatische blocksicherung zu erstellen die mit moeglichst wenig programmier und testaufwand implementiert werden kann. Wesentliche Komponenten: 1. Die blockdefinitionen 2. Die initialisierungs routine die alle benoetigten variablen automatisch anlegt und initialisiert 3. Das blockeventmodul mit den event routinen fuer signale und kontakte, sowie der erst-initialisierung pro block 4. Das blockverwaltungs script das die blockzustaende verwaltet 1. Fuer jeden anlagenabschnitt kann eine blockliste mit bis zu 99 bloecken definiert sein (zwei ziffern mit fuehrender null) Alle gleiskontakte und gleise muessen gemaess den namenskonventionen benannt sein. 2. Das vorliegende script erzeugt alle variablen und wird vom script eines jeden blocks aufgerufen (beim abspeichern) 3. Das blockeventmodul wird einfach kopiert je nach anzahl der bloecke und das script jedes blockes wird angepasst (index position in blockliste) 4. Blockverwaltung ist als user defined event implementiert der bei aktivierung eines gleiskontaktes aufgerufen wird. Ich habe die gleiskontakte alle zusammengefasst damit die zuordnung schneller geht. Ich werde auch eine nachfolger verbindung ohne strassenverwaltung einbauen um einfache blockfolgen ohne weichen schnell zu realisieren. Die blockverwaltung ist auch eine grundlage fuer die harfenansteuerung eines bahnhofs mit gleisauswahl. Nicht enthalten hier bisher ist die strassenverwaltung die die bloecke verbindet und vorgaenger und nachfolger bereitstellt. Das ist der naechste schritt ]]-- Hier ein beispiel einer blockliste -- liste aller bloecke in diesem abschnitt -- index 1: Event modul -- index 2: Block index (postfix) -- index 3: abschnitt prefix fuer alle namen blocksSMUFK = { { $("SMUFK-Block01"), "01" , "SUMFK-" }, { $("SMUFK-Block02"), "02" , "SUMFK-" }, { $("SMUFK-Block03"), "03" , "SUMFK-" }, { $("SMUFK-Block04"), "04" , "SUMFK-" } } -- das objekt fuer das eventmodul wird beim abspeichern initialsiert Hier die initialisierung -- Initialisiere alle namen und werte fuer den block -- Parameter: Blockliste fuer einen abschnit , Blocknummer -- Die variablen werden automatisch angelegt - manuelle definition nicht erforderlich function initBlockParams ( blockIndex, blockListe) block = blockListe [blockIndex][1] -- lade objekt fuer event modul if block.variables["PInitialised"] ~= 1 then bNum = blockListe [blockIndex][2] -- block nummer fuer namens postfix pref = blockListe [blockIndex][3] -- namens prefix fuer block komponenten block.variables["blockListe"] = blockListe -- uebertrage block parameter block.variables["PBlock-Number"] = bNum block.variables["PBlock-Name-Prefix"] = pref block.variables["Name-GK-AK"] = pref .. "AK-B" .. bNum -- erzeuge modul variablen mit kontaktnamen block.variables["Name-GK-EK"] = pref .. "EK-B" .. bNum block.variables["Name-GK-BK"] = pref .. "BK-B" .. bNum block.variables["Name-GK-HK"] = pref .. "HK-B" .. bNum block.variables["Name-GL-AK"] = pref .. "AG-B" .. bNum -- erzeuge modul variablen mit gleisnamen block.variables["Name-GL-EK"] = pref .. "EG-B" .. bNum block.variables["Name-GL-BK"] = pref .. "BG-B" .. bNum block.variables["Name-GL-HK"] = pref .. "HG-B" .. bNum -- finde alle objekte zu den gleisen und siganle - mehr performant fuer gleis- und statusabfragen objekt = layout:getEntityByName( block.variables["Name-GL-BK"] ) -- finde objekt bremsgleis block.variables["Objekt-GL-BK"] = objekt objekt = layout:getEntityByName( block.variables["Name-GL-HK"] ) -- finde objekt haltegleis block.variables["Objekt-GL-HK"] = objekt objekt = layout:getEntityByName( block.variables["Name-GL-AK"] ) -- finde objekt ausfahrgleis block.variables["Objekt-GL-AK"] = objekt block.variables["Name-BS"] = pref .. "BS-B" .. bNum -- name block signal objekt = layout:getEntityByName( block.variables["Name-BS"] ) -- finde objekt blocksignal block.variables["Objekt-BS"] = objekt -- erzeuge status variablen block.variables["B-Einfahrt"] = 0 -- absichtlich numerisch und nicht boolean block.variables["B-Bremsen"] = 0 block.variables["B-Halt"] = 0 block.variables["B-Belegt"] = 0 block.variables["B-Gesperrt"] = 0 block.variables["B-Ausfahrt"] = 0 block.variables["B-Ein-Erlaubt"] = 0 block.variables["B-Reserviert"] = 0 -- Objektvariable blockListe -- wird verwendet wenn kontakt getriggert wird um das eventmodul zu identifizieren -- da man mit script den event tree nicht traversen kann objekt = layout:getEntityByName( block.variables["Name-GK-EK"] ) -- finde objekt objekt.variables ["blockListe"] = blockListe -- lege objekt variable an mit liste aller bloecke objekt = layout:getEntityByName( block.variables["Name-GK-BK"] ) -- finde objekt objekt.variables ["blockListe"] = blockListe -- lege objekt variable an mit liste aller bloecke objekt = layout:getEntityByName( block.variables["Name-GK-HK"] ) -- finde objekt objekt.variables ["blockListe"] = blockListe -- lege objekt variable an mit liste aller bloecke objekt = layout:getEntityByName( block.variables["Name-GK-AK"] ) -- finde objekt objekt.variables ["blockListe"] = blockListe -- lege objekt variable an mit liste aller bloecke block.variables["PInitialised"] = 1 end end Das script pro block --[[ Dieses script muss fuer jeden block angepasst werden nachdem das event modul kopiert wurde Im event Kontakte muessen alle relevanten kontakte des blocks mit oder verknuepft verbunden sein --]] -- Initialisiere alle namen und werte fuer den block -- Parameter: a) Index in der block definition in der globalen blockliste -- b) Name der blockliste fuer dieses segment initBlockParams(1,blocksSMUFK) Das script im event Kontakte eines blockmoduls --[[ Generisches script das nach kopieren des eventmoduls immer richtig ist --]] -- Parameter: kontakt objekt $("Gleiskontakt hat ausgeloest"):invoke(contact) Hier die Blockverwaltung ohne viel detail, nur die grobe struktur (Pseudo code siehe weiter unten) --[[ Die zentrale blockverwaltung - nur ein auszug --]] -- ************************************************* -- Hilfsfunktionen -- -- Aus dem kontakt namen wird der blockindex erzeugt (letzte beiden buchstaben des namens) function getBlock (contact) cName = contact.name -- lade kontakt name bIndex = tonumber( string.sub (cName, (string.len(cName))-1 , string.len(cName)) ) -- blocknummer sind die letzten beiden ziffern bl = contact.variables ["blockListe"] -- die blockliste ist in einer objekt variablen blockEvent = bl [bIndex][1] -- hole das event modul objekt fuer den block return blockEvent end --- !!!!!!!!!!!!!! Achtung !!!!!!! functions muessen hier zuerst definiert sein -- Einfahr kontakt function bearbeiteEK (block) block.variables["B-Einfahrt"] = 1 end -- Brems kontakt function bearbeiteBK (block) block.variables["B-Bremsen"] = 1 block.variables["B-Einfahrt"] = 0 end -- Halt kontakt function bearbeiteHK (block) block.variables["B-Bremsen"] = 0 block.variables["B-Halt"] = 1 end -- Ausfahr kontakt function bearbeiteAK (block) block.variables["B-Halt"] = 0 block.variables["B-Ausfahrt"] = 1 end -- ************************************************** Eingang fuer event Gleiskontakt ********************* -- Gleiskontakte eines blockes bearbeiten - zuerst festellen welcher kontakt block = getBlock(KontaktObjekt) -- hole das event modul objekt fuer den block -- strikte namenskonventionen erforderlich fuer alle kontakte und gleise if string.find (KontaktObjekt.name,"EK") ~= nil then bearbeiteEK(block) elseif string.find (KontaktObjekt.name,"BK") ~= nil then bearbeiteBK(block) elseif string.find (KontaktObjekt.name,"HK") ~= nil then bearbeiteHK(block) elseif string.find (KontaktObjekt.name,"AK") ~= nil then bearbeiteAK(block) end Die event struktur mit erzeugten modulvariablen pro block Kontakte mit allen kontakt objekten verbunden und hier der pseudocode der blocksteuerung (vereinfacht ohne alle spezialfunktionen - vorsignalsteuerung fuer langsamfahrt usw. ) BlockParameter Ausfahrgeschwindigkeit, Verzoegerungsfaktor, SignalRueckstellzeit,HatVerlaengertesHaltegleis FunktionsParameter BlockIndex Gleiskontakte Signale Gleise Variablen Bloecke Einfahrkontakt (EK) Blocksignal (BS) Einfahrgleis (EG) B-Einfahrt B-Nachfolger Bremskontakt (BK) Blockvorsignal (VS) Bremsgleis (BG) B-Bremsen B-Vorgaenger Haltekontakt (HK) Haltegleis (HG) B-Halt B-Abzweig Ausfahrkontakt (AK) Haltegleis (HG2) B-Belegt B-Einfahrt Ausfahrgleis (AG) B-Gesperrt B-Ausfahrt B-Ein-Erlaubt B-Reserviert B-Reserviert Wenn "ein" dann wird einfahrt blockiert fuer einen parallelblock. Wird verwendet an Y kreuzungen die einfahrt zu koordinieren. Gleiches gilt fuer ausfahrten von einem zu zwei gleisen EK ausgeloest if EK then B-Einfahrt = ein B-Belegt = ein // Falls einfahrt erlaubt fuer nachfolger if B-Nachfolger.B-Ein-Erlaubt == ja then Blocksignal = go // Signal GO Blockvorsignal.LangsamErwarten = aus else Blockvorsignal.LangsamErwarten = ein end end BK ausgeloest if BK and B-Blocksignal == stop then BG.vehicle.speed = BG.vehicle.speed *Blockparameter.Verzoegerungsfaktor B-Einfahrt = aus B-Bremsen = ein end HK ausgeloest B-Bremsen = aus if HK and Blocksignal == stop then B-Halt = ein HG.vehicle.speed = halt if Blockparameter.HatVerlaengertesHaltegleis == ja then HG2.vehicle.speed = halt end else B-Ausfahrt = ein B-Reserviert = aus B-Halt = aus HG.vehicle.speed = Blockparameter.Ausfahrgeschwindigkeit if Blockparameter.HatVerlaengertesHaltegleis == ja then HG2.vehicle.speed = Blockparameter.Ausfahrgeschwindigkeit end end AK ausgeloest (Optional: kann auch mit rueckstellzeit erreicht werden) if AK and AG.vehicle.vorhanden == ja then B-Ausfahrt = aus B-Belegt = aus Blocksignal = stop else Fehlerbedingung: Blockausfahrt geschaltet aber nicht erfolgt. end Blocksignal geschaltet if Blocksignal == go and Nachfolger.B-Reserviert == aus and B-Nachfolger.B-Ein-Erlaubt == ja and HG.vehicle.vorhanden == ja then Nachfolger.B-Reserviert = ein B-Ausfahrt = ein B-Halt = aus B-Bremsen = aus B-Reserviert = aus HG.vehicle.speed = Blockparameter.Ausfahrgeschwindigkeit if Blockparameter.HatVerlaengertesHaltegleis == ja then HG2.vehicle.speed = Blockparameter.Ausfahrgeschwindigkeit end if SignalRueckstellzeit > 0 then After SignalRueckstellzeit then Blocksignal = stop B-Belegt = aus B-Ausfahrt = aus end end else Blocksignal = stop end Ich hoffe das geht nicht uebers ziel hinaus fuer einen post. Ich habe keine einfache demoanlage sondern nur eine grosse mit vielen bloecken, deswegen der versuch der automatisierung der definitionen. Mit einigen weiteren meta funktionen in LUA koennte ich das noch weiter vereinfachen. Die zwei wesentlichen aspekte dabei sind: Dynamisches anlegen von event strukturen und dynamisches verbinden von ausloesenden gleiskontakten zu events. Das heist im wesentlichen man braucht eine metaebene auf der man die definitionen mit script bearbeiten kann, dann wird alles einfacher , oder im endeffekt eine eigene externe steuerung zu bauen, was aber nicht der sinn dieser uebung war. RocRail habe ich fuer dieses projekt nicht vorgesehen. Falls ihr interessiert seid kann ich weiter berichten. Jetzt habe ich erst mal wieder was anderes zu tun, fuer eine weile. gruss Gmd

ich bin dabei meinen ansatz zu dokumentieren und eine vereinfachte version zu posten.

Wow du bist frueh, beide antworten passen leider nicht ... ich werde nochmals einen versuch machen. Ich bin mir bewusst ueber namen vs objekt id's - das ist nicht mein problem. Es ist anders. Beispiel: EventModul1 Event1 Event2 EventModul2 Event1 Event2 Nehmen wir mal an dass die Events trigger events sind, Wenn ich $("Event1") benutze welchen der beiden objekte bekomme ich ? und die zweite frage war ob ich mit objekt.contact den gleiskontakt setzen kann war dann $("Event1").contact = layout:getEntityByName("Gleiskontaktname") anstatt mit dem event editor ist das klarer ? Sorry, wenn ich mich immer zu kurz ausdruecke. Gruss Gmd

Hallo, bin ein stueck weiter. Wenn man versucht einen event zu addressieren wird der event zweig nicht beruecksichtigt, sondern nur der name selbst. Die namen muessen aber nicht eindeutig sein, was verstehe ich da nicht ? Ausserdem noch eine frage. Wenn ich einen event objekt fuer einen gleiskontakt habe kann ich mit objekt.contact den richtigen kontakt zuweisen ? Das wuerde helfen Danke, Gruss Gmd

Ja es klingt kompliziert ist es aber nicht wirklich da am ende nur ein einziges recht kurzes script dabei rauskommt. Das problem ist die parametrisierung, aber vielleicht faellt mir nochwas ein. Bin schon ein stueck weiter. Danke fuer die schnellen antworten. gruss gmd

I found the string functions though .. I read somewhere here that there are no string functions ... but I finally went to Lua.org and had a read .. so I can generate all the names ... great .. still have to solve the event issue .. regards Gmd

Ich versuche es, Bin dabei ein allgemaines block konzept zu bauen mit ein- und ausgangs abzweigung. Tabellen legen die namen der kontakte, gleise, signale und variablen fest und mit getEntityByName werden die objekte identifiziert. Ich koennte auch die objekte direkt zuordnen ueber variablentyp objekt, aber die auswahl ist zu langwierig da die selektionsfunktion nicht effizient ist. Es ist einfacher namen in tabellen einzutragen. Wenn man string funktionen haette waere das natuerlich auch per LUA moeglich, so muss ich die namen von hand in die tabellen eintragen. Fuer jede komoponente, einfahrkontakt, bremskontakt usw. brauche ich ein ereignis und muss das objekt zuordnen und ein generisches script eintragen. Ich kann natuerlich eine struktur anlegen die ich einfach kopiere muss aber immer noch die tatsaechlichen trigger objekte zuordnen. Mit einer besseren scriptloesung kann man das mit einer einzigen tabelle loesen. Das gleiche gilt fuer strassen von bahnhofsharfen usw. Damit kann ich auch mein doppeltraktions problem loesen ohne "lange" haltegleise. Kannst du mit dieser beschreibung etwas anfangen ? gruss gmd

Hallo, kann ich mit LUA dynamisch event definitionen erzeugen die persistent bleiben ? Gruss Gmd

Das hast du misverstanden. Doppelclick auf ein wort selektiert das wort und nachfolgender drag nach rechts ohne mouse taste loszulassen selektiert das naechste wort usw. bis maus haelt. Das kann man verwenden um strings zwischen quotes schneller zu selektieren. Prima, habe ich gerade entdeckt .. Ja das ist moeglich aber nicht wirklich praktikabel , nur wenn ich alle meine haltepunkte ueber eine generische funktion bediene und mit tabellen parametrisiere. Sonst ist es zuviel aufwand. Ein weiterer punkt ist dass CTRL C nicht funktioniert wenn man im eventeditor einen variablennamen kopieren will wenn das namensfeld zum umbennen geoeffnet und der name selektiert ist. Nur rechtsclick copy funktioniert. Tastenkommando nicht. Gruss gmd

Hallo an alle, Habe seit laengerer zeit mal wieder mit MBS gespielt und die V5 installiert. Die neuen funktionen mit gleiskontakten und lua script haben mich veranlasst mal eine steuerung zu bauen. Habe etliche harfen und verzweigungen realisiert mit derzeit ueber 15 zuegen in betrieb. Ist noch lange nicht fertig aber habe einen guten ueberblick. Natuerlich lerne ich mit der fortschreitenden realisierung und die strukturen die ich am anfang geschrieben haben werden im laufe der zeit besser und uebersichtlicher. Wesentliches problem sind die namenskonventionen fuer objekte. Alles in allem laeuft das sehr gut. Hier ist was mir bisher aufgefallen ist oder was ich vermisse: Doppelclick und drag um worte/texte zu selektieren im script editor. Script editor hat kein zeilenende. Cursor down geht nicht hinter das letzte zeichen der naechsten zeile sondern "ins leere". Ist etwas laestig wenn man andere editoren gewoehnt ist. Funktionstaste um event editor aufzurufen. Gleiches gilt fuer cursor hoch. Cancel taste in event editor anstelle jedesmal zu fragen ob gespeichert werden soll. Liste von event definitionen die ein objekt (weiche,signal,variable) beeinflussen (search in event editor - vielleicht habe ich was uebersehen) In der objekt auswahl liste muss man jedesmal die filter neu setzen wenn man die ueberfluessigen gleise die nicht umbenannt sind und andere auszublenden. Waere sowiso nuetzlich ein filter zu haben fuer user named objects anstelle alle anzu zeigen. Man waehlt ueblicherweise kein objekt aus das nicht explizit benannt wurde. Wenn in trace window ein filter objekt gesetzt ist wird ein scriptfehler nicht angezeigt. Erst wenn man ohne filter die simulation laufen laesst erscheint ein moeglicher scriptfehler. Nuetzlich fuer test waere wenn man die events fuer einen zweig des baumes auschalten kann. Wenn man einen gut strukturierten event baum hat ist das nuetzlich fuers testen. Bei einer groesseren anlage und complexeren event strukturen ensteht moeglicherweise chaos bei scriptfehlern die nicht immer vermeidbar sind wenn man groessere scripts baut. Das hat mich schoen viel zeit gekostet weil ich nicht jedesmal alle zuege vom gleis nehmen will. Habe selbst ueber variablen einen ein/aus von teilen des event baums organisiert, ist aber laestig. Gleiskontakte sind super und im zusammenhang mit script erlauben alles was mir derzeit in den sinn kam bis auf das problem doppeltraktion. Naja das kann man loesen wenn man laengere brems oder haltegleise macht oder aber mehrere gleise benennt und abfragt. Laengere gleise haben den nachteil von verschiedenen haltepunkten, mehrere brems oder haltegleise machen wesentlich mehr aufwand im script und benennung. Das ist kein wunsch sondern nur eine feststellung. Das program weiss natuerlich wenn ein zug doppeltraktion hat und koennte das automatisch loesen oder man laesst die zweite lok als dummy mitlaufen was ja moeglich ist, aber beim dampf will man das ja nicht. Vielleicht gibt es andere vorschlaege. Habe noch einige andere punkte die ich anders loesen wuerde, aber es ist alles eine frage der prioritaeten nicht wahr ? Generell, gute version. Keine probleme bei der migration, allerdings habe ich keine ereignisse migriert sondern nur objekte. Hatte nur einen crash bisher, war aber eine ganz komische situation und nicht reproduzierbar. Programm lauft zuverlaessig und schnell auf meinem PC, Grafik ist schnell genug fuer mich derzeit, alles in allem bin ich wirklich zufrieden mit der V5. Gruss aus Australien Gmd

ein update, habe die offenen teile mit fueller komponenten ergaenzt, just for fun wie wir hier sagen. In der realen welt sind das abnehmbare teile ohne wesentliche fumktion. Viele details fehlen noch unter anderem die oberleitung, aber in der derzeitigen version werde ich die wohl nie ergaenzen, da zuviel aufwand. Ich meine der versuch der oberleitungsdefinition ist bemerkenswert und sieht toll aus, aber der aufwand bei einer solchen anlage is einfach zu gross alles manuell zu definieren. Ich habe die weichen und bloecke alle in rockrail definiert und bin dabei nun alle signale und rueckmelder zu definieren um einen automatikbetrieb zu ermoeglichen. Ist auch viel manueller aufwand jeden einenzelnen rueckmelder in rocrail und dann auch in 3dmsb zu definieren mit 3-4 rueckmeldern pro block und ueber 100 bloecken. Rocrail hat uber 1400 fahrstrassen erzeugt. hier das bild: https://teutanic.com.au/update_11_7.jpg gruss gmd

ok, werde ich probieren, hatte ich mal vermutet und eingegeben aber war auch nichts. Ich habe noch nicht ganz verstanden wer mit wem wann ueber welches port kommuniziert. gruss gmd PS: Habe rocrail deinstalliert, neueste version installiert, alle ini files geloescht, einen workspace aufgemacht damit ich rocrail properties eingeben kann, controller lan definiert mit port 31285 und rocstudio hat connected, finally. Habe keinen plan der was tut, aber zumindest steht die kommunikation. Jetzt kann es weitergehen. uff Danke fuer den tip was mich verwirrt hat ist dass in rocstudio 8051 fuer rocrail angezeigt wird, das macht keinen sinn fuer mich. Es sieht wie eine port vorgabe aus die auf der anderen seite eingestellt sein muss. wenn ich auf der rocrail seite als lan controller 31285 eingebe dann wuerde ich erwarten dass ich das im rocstudio fuer die rocrail seite auch tun muss. Sorry macht keinen sinn fuer mich. Ok, wein gleisplan connected mit dem layout. Kann einen train starten und steuern. Jetzt beginnt die fleisarbeit alle weichen und sensoren zu definieren, und die zuege und die signal .. naja das wird ne weile dauern. Muss mir erst ein gutes system ueberlegen. Zumindest habe ich ja dann die exakte list fuer die realanlage und bereits die steuerung fertig. Das ist ja der sinn der sache. Habe dann ein paar jahre zeit den rest der elektronik zu bauen und die fehlenden brocken "einzusammeln" auf meinen reisen. Ich hatte hunderte von baeumen die ich alle verkauft habe vor jahren. Waren alle selbstgemacht, die muss ich neu machen usw. Ist aber nicht zu schwierig, hier findet man genuegend "stamm und ast material" und schaumstoff habe ich auch genug um flocken zu machen.

not working, going to bed .. will make a problem post tomorrow, I think it has to do with the controller entry in rocrail, tried lan ..aber no joy Irgendetwas habe ich uebersehen. vielleicht liest NEO dies dann kann ich mir den post im anderen forum sparen. gruss gmd

ok, habe post gefunden der wohl zutrifft. wie folgt: Habe das Problem gefunden. (War natürlich mein Fehler, weil ich nicht den Link "ersten Schritte mit Rocrail" gelesen hatte) Weil ich keinen Arbeitsbereich eingestellt hatte, wurde der Server nicht automatisch gestartet. Ohne Server keine Verbindung! Das geht aus der Beschreibung "RocStudio - Steuern des 3D-Modellbahn Studios über Rocrail" leider nicht ganz klar hervor. (RocStudio wartet auf den Start von Rocrail und dem 3D-Modellbahn Studio. Sobald beide Programme gestartet sind, verbindet das RocStudio diese miteinander.) Habe keinen workspace gemacht und rocrail server ist nicht automatisch gestartet so wie das oben sagt. werde das jetzt probieren. gruss gmd PS: das wars nicht, server war gestartet - 23:02:39 initPlan() READY

nope, haha das ware zu einfach .. auto faehrt nicht - tank leer .. lol mouse ueber plugin icon zeigt (connecting..) habe gerade auf meinem laptop installiert mit original settings ohne meine dpp++ digint entries .. alles standard .. gleiches problem .. also aus der box funktioniert es nicht fuer mich. gruss gmd RocRail kommuniziert mit meinem Arduino .. irgendwas in the rocrail.ini vermute ich ..

Andy, nein, RocStudio connected nicht .. zeigt connecting ... findet aber die partner nicht. ports sind richtig eingestellt, beide programme laufen, debug window zeigt keine events. Noch keine idee .. Auch die demo anlage geht nicht, aber kein wunder da rocstudio nicht connected. schlagerfuzzi1 .. habe noch nicht viele definitionen in den tabellen. Wenn ich mal einen vernuenftigen stand habe mache ich das gerne. Habe noch ein paar komponenten zu ergaenzen. gruss gmd