Versuch einer Blockverwaltung

[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

 

  

 

 

Bearbeitet 7. März 2020 von gmd

[gmd]

Hier ein eindruck von der anlage die ich als test verwende

http://vk6gmd.com/anlage_lua.mp4

gruss

gmd

 

[HaNNoveraNer]

Hallo gmd

Die Anlage gefällt mir.
Das Script ist was für Leute, die sich drauf einlassen wollen.

Gruß
Thomas

[Andy]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

keine problem, ich muss nicht recht haben, ist nur meine meinung

gruss

gmd

[gmd]

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]

Hi gmd

Statt die Kontakte alle aufzuzählen, die ein Ereignis auslösen, könntest Du mit einem Schlagwort arbeiten.

Gruß
Thomas

[gmd]

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]

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