gmd Geschrieben 7. März 2020 Geschrieben 7. März 2020 (bearbeitet) 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-ReserviertB-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 endBK ausgeloest if BK and B-Blocksignal == stop then BG.vehicle.speed = BG.vehicle.speed *Blockparameter.Verzoegerungsfaktor B-Einfahrt = aus B-Bremsen = ein endHK 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 Bearbeitet 7. März 2020 von gmd
gmd Geschrieben 7. März 2020 Autor Geschrieben 7. März 2020 Hier ein eindruck von der anlage die ich als test verwende http://vk6gmd.com/anlage_lua.mp4 gruss gmd
HaNNoveraNer Geschrieben 7. März 2020 Geschrieben 7. März 2020 Hallo gmd Die Anlage gefällt mir. Das Script ist was für Leute, die sich drauf einlassen wollen. Gruß Thomas
Andy Geschrieben 7. März 2020 Geschrieben 7. März 2020 Hallo gmd, auf jeden Fall schon mal eine hochinteressante Anlage. Was die Steuerung angeht, werde ich da auch eine Lücke finden müssen, um mir das Programm mal genau anzusehen. Da bin ich momentan auch ziemlich voll. Ich finde es aber wichtig, dass da mal verschiedene Konzepte ausprobiert werden. Die größte Problematik dabei wird wohl sein, dass hier Programmierer und Modellbahner noch weit auseinander liegen. Wenn Du dann von Metaebene sprichst, habe selbst ich Schwierigkeiten zu folgen und die Bahner hören dann sofort auf zu lesen. Wenn Programmierer hier untereinander über ein Problem diskutieren, dann sind Fachbegriffe natürlich von Vorteil, denn sie sparen zwei Sätze. Ansonsten werden Texte halt länger (was die meisten auch wieder nicht mögen). Es kann also nur scheibchenweise vorangehen und der Boden muß da mal festgetreten werden. Ich bemühe mich deshalb eigentlich schon eine Weile um die Fragestellungen: durch was sollte ein BLOCK im MBS genau festgelegt sein was soll alles innerhalb eines Blocks möglich sein wie sollen sich Blöcke untereinander verhalten Hier müßten wir mal so eine Art internes Grundgesetz formulieren, mit dem Programmierer dann arbeiten können. Und dazu gehört sicherlich auch die Frage, was von der komplexen Signalverordnung für uns relevant ist und wie es sinnvoll modifiziert werden kann, insbesondere im Hinblick auf Abstände von Signalen etc. Diese Diskussion ist längst überfällig und sehr wichtig! Gruß Andy
Timba Geschrieben 7. März 2020 Geschrieben 7. März 2020 Hallo Andy, vor 32 Minuten schrieb Andy: Hier müßten wir mal so eine Art internes Grundgesetz formulieren das ist ein sehr ambitioniertes Vorhaben. Ich bin gespannt, ob es von Erfolg gekrönt sein wird. Wie beim Modellbau werden vermutlich die Fraktionen der möglichst nah an der Realität orientierten Nutzer und die der "ich baue wie's mir gefällt"-Nutzer aufeinander prallen. Beide Seiten haben auf ihre eigene Art schließlich recht, nur geht nicht beides gleichzeitig. Gruß Timba
gmd Geschrieben 7. März 2020 Autor Geschrieben 7. März 2020 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
gmd Geschrieben 7. März 2020 Autor Geschrieben 7. März 2020 24 minutes ago, Timba said: Hallo Andy, das ist ein sehr ambitioniertes Vorhaben. Ich bin gespannt, ob es von Erfolg gekrönt sein wird. Wie beim Modellbau werden vermutlich die Fraktionen der möglichst nah an der Realität orientierten Nutzer und die der "ich baue wie's mir gefällt"-Nutzer aufeinander prallen. Beide Seiten haben auf ihre eigene Art schließlich recht, nur geht nicht beides gleichzeitig. Gruß Timba 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 Geschrieben 7. März 2020 Geschrieben 7. März 2020 Es ist auf jeden Fall mal von Vorteil, derlei Überlegungen zu sammeln, zu ordnen, zu vervollständigen. Wahrscheinlich verbergen sich da im Forum auch schon wichtige Posts. Es wird, wie Timba schreibt, verschiedene Ansichten geben. Man kann dann aber vielleicht auch Programm-Module verschiedener Komplexität erzeugen. Das alles unter dem Aspekt KANN benutzt werden, bleibt aber natürlich jedem freigestellt. Gruß Andy
gmd Geschrieben 7. März 2020 Autor Geschrieben 7. März 2020 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
Andy Geschrieben 7. März 2020 Geschrieben 7. März 2020 (bearbeitet) Dateien lesen/schreiben ist aus Sicherheitsgründen tabu! p.s.: das 'Lernen' geht schon. Nutze ich sogar schon. Es muß halt ein Transfer zwischen Lua- und Objektvariablen geschehen. Gruß Andy Bearbeitet 7. März 2020 von Andy
gmd Geschrieben 7. März 2020 Autor Geschrieben 7. März 2020 39 minutes ago, Andy said: Dateien lesen/schreiben ist aus Sicherheitsgründen tabu! Das verstehe ich nicht. Kannst du mir erklaeren was das mit security zu tun hat ? gruss gmd
HaNNoveraNer Geschrieben 7. März 2020 Geschrieben 7. März 2020 (bearbeitet) Hallo gmd Willst Du es gerne selber machen, oder unbedingt in Lua programmieren? Oder was ist der Grund, daß Du alles nochmal erfinden möchtest, was Du mit dem RocStudio Plugin und der langjährigen Erfahrung der Rocrail Programmierer schon mit der Blocksteuerung und der grafischen Oberfläche machen kannst? Die Rocrail Scripte erlauben DIr auch dort alle Freiheiten. Gruß Thomas Bearbeitet 7. März 2020 von HaNNoveraNer
gmd Geschrieben 7. März 2020 Autor Geschrieben 7. März 2020 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
Timba Geschrieben 7. März 2020 Geschrieben 7. März 2020 vor 2 Stunden schrieb 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. Wir scheinen aneinander vorbei zu reden. Was ich meinte: Der Realist möchte alles perfekt an der Realität orientiert, kein Signal vergessen und jedes an der richtigen Stelle. Ein anderer hingegen ist nicht daran interessiert, sondern baut gerne frei und ohne Zwänge. Zwar gebe ich dir recht, dass auch letzterer eine gewisse Struktur braucht, die kann und wird aber völlig anders aussehen als die des Realisten. Möglicherweise stören ihn Dinge sogar, da sie Ressourcen brauchen, die er gerne an anderer Stelle eingesetzt hätte. Aber egal, ich wollte auch nicht so verstanden werden, dass ich das Vorhaben unsinnig finde, im Gegenteil, aber ich habe halt Zweifel, ob es gelingt, eine einheitliche Lösung zu finden, die allen Zielen gerecht wird. Deswegen schrieb ich ja: Ich bin gespannt! Gruß Timba
Timba Geschrieben 7. März 2020 Geschrieben 7. März 2020 vor 2 Stunden schrieb Andy: Man kann dann aber vielleicht auch Programm-Module verschiedener Komplexität erzeugen. Zielführender fände ich ein modular aufgebautes Programm, das sich ggf. "abspecken" lässt, statt verschiedener Programm unterschiedlicher Komplexität. Also sozusagen einen "Kern" als Grundgerüst und aufbauend verschiedene Tools, die sich löschen lassen ohne dass der Kern seine Funktionalität verliert. Wenn du verstehst was ich meine. Gruß Timba
Andy Geschrieben 7. März 2020 Geschrieben 7. März 2020 vor 2 Stunden schrieb gmd: Das verstehe ich nicht. Kannst du mir erklaeren was das mit security zu tun hat ? Was da beleidigte Leberwürste anstellen können, muß man doch keinem erklären.
gmd Geschrieben 8. März 2020 Autor Geschrieben 8. März 2020 9 hours ago, Timba said: Zielführender fände ich ein modular aufgebautes Programm, das sich ggf. "abspecken" lässt, statt verschiedener Programm unterschiedlicher Komplexität. Also sozusagen einen "Kern" als Grundgerüst und aufbauend verschiedene Tools, die sich löschen lassen ohne dass der Kern seine Funktionalität verliert. Wenn du verstehst was ich meine. Gruß Timba 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
Timba Geschrieben 8. März 2020 Geschrieben 8. März 2020 Moin, vor 4 Stunden schrieb gmd: Ich fuer meinen teil wuerde auch mehr geld bezahlen fuer einen bessere definitionsoberflaeche. siehst du, und genau das ist eben das andere Problem: Deine Sicht, deine Anforderungen an das Programm, etc., sind - genau wie meine eigenen - nur eine von vielen. Andere finden das Programm vielleicht "gerade noch bezahlbar". Oder die bestehende Definitionsoberfläche (was immer damit gemeint sein soll) ist ihnen bereits etwas zu komplex. Für mich ist das MBS, so wie es ist, genau richtig. Ich liebe es so wie es ist. Natürlich inklusive aller Weiterentwicklungen. Das Problem des Entwicklers ist ja ein ganz anderes als deins: Er muss ein Produkt schaffen, dass möglichst viele Nutzer einbindet, nicht nur anspruchsvolle IT-Spezialisten und Menschen, die mehr Geld bezahlen würden. Ich finde, das ist dem Entwickler sehr gut gelungen. Mit einem Produkt, das den doppelten oder dreifachen Preis kostet und sich an versierte IT-Entwickler richtet, gäbe es MBS vermutlich gar nicht mehr. Gruß Timba
gmd Geschrieben 8. März 2020 Autor Geschrieben 8. März 2020 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
Timba Geschrieben 8. März 2020 Geschrieben 8. März 2020 vor 36 Minuten schrieb gmd: Der autor muss eine zukunftsorientiertes konzept haben dass seine benutzer basis erweitert und nicht nur die bestehenden veranlasst neue versionen zu kaufen. Ich denke, das hat er. Passt vielleicht nicht mit deiner Sicht der Dinge zusammen, aber das ist halt manchmal so.
gmd Geschrieben 8. März 2020 Autor Geschrieben 8. März 2020 keine problem, ich muss nicht recht haben, ist nur meine meinung gruss gmd
gmd Geschrieben 9. März 2020 Autor Geschrieben 9. März 2020 Demo anlage F3B894BE-083C-4BA5-AF2D-47D96E71973F Habe kleine testanlage gebaut um mein script separat zu erweitern und nicht die grosse anlage mitschleppen. Ist in weniger als einer stunde entstanden, dabei ist die benennung der objekte der loewenanteil der arbeit. Habe einen herzschlag zugefuegt der verhindert dass ein dead lock passiert. Habe ausserdem die externe schnittstelle angeschaut und einen weg gefunden elemente eine fahrstrasse automatisch zu benennen. Werde mir ein plugin bauen was das tut. Kein lust in meiner grossen anlage das alles manuell zu vervollstaendigen. gruss gmd
HaNNoveraNer Geschrieben 9. März 2020 Geschrieben 9. März 2020 Hi gmd Statt die Kontakte alle aufzuzählen, die ein Ereignis auslösen, könntest Du mit einem Schlagwort arbeiten. Gruß Thomas
gmd Geschrieben 9. März 2020 Autor Geschrieben 9. März 2020 Ja waere ein gedanke aber das ist eine weitere eben in der definition. Im selektionsfenster fuer die kontakte cann ich den prefix eingeben und bekomme lle kontakte direkt angezeigt das ist unwesentlich mehr aufwand als ein schlagwort zuordnen und erspart die definition des schlagwortes. So sehe ich das derzeit. Wenn mann events per script definieren koennte und die kontakte zuordnen per script waere es noch einfacher. gruss gmd
HaNNoveraNer Geschrieben 9. März 2020 Geschrieben 9. März 2020 (bearbeitet) Dann kannst Du als Auslöser einen beliebigen Kontakt als Event definieren (einmalig, und nie wieder anfassen) und darin dann den tatsächlich auslösenden Kontakt an Dein Skript übergeben... Dann laufen ALLE Kontakte über dieses Event in Dein Skript rein. Bearbeitet 9. März 2020 von HaNNoveraNer
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen.
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden