gmd

Ja sicher aber multithreading und timeout handling ist weder in Java noch in C# ein problem. Werde das posten wenn es soweit ist. Derzeit gehe ich erst mal an die Weichensteuerung in der Blockverwaltung. gruss gmd

Und hier ist die C# version. Projekt initialisiert als WPF application und fuer test mal gerade in die window class eingebaut. Das wird natuerlich anders in einer richtigen app. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Windows; using System.Windows.Controls; using System.Windows.Data; using System.Windows.Documents; using System.Windows.Input; using System.Windows.Media; using System.Windows.Media.Imaging; using System.Windows.Navigation; using System.Windows.Shapes; using System.Net; using System.Net.Sockets; using System.Diagnostics; namespace MBS { /// <summary> /// Interaction logic for MainWindow.xaml /// </summary> public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); Socket socket = null; TcpClient tcpClient = new TcpClient("127.0.0.1", 31286); NetworkStream networkStream = tcpClient.GetStream(); try { Debug.WriteLine("Waiting for connection"); while (tcpClient != null) { Byte[] data = new Byte[1024]; String responseData = String.Empty; // Read the event data Int32 bytes = networkStream.Read(data, 0, data.Length); //(**This receives the data using the byte method**) responseData = System.Text.Encoding.ASCII.GetString(data, 0, bytes); //(**This converts it to string**) Debug.WriteLine(responseData); } } catch (Exception e) { socket.Close(); } } } } gruss gmd

Hallo, loesungen fuer Python und VisualBasic hatte ich gefunden. Andy hat eine C++ version, die er mir nettwerweise zur verfuegung gesteltt hat. Hier ist eine Java version und dann mache ich noch einen test mit C# bevor ich mich entscheide ob C# oder Java verwende. package mbs_listener; import java.io.BufferedReader; import java.net.Socket; import java.net.UnknownHostException; import java.io.IOException; import java.io.InputStreamReader; import java.net.InetAddress; /** * * @author gmd */ public class MBS_Listener { final static String ip = "127.0.0.1"; final static int port = 31286; /** * @param args the command line arguments */ public static void main(String[] args) { Socket socket = null; byte[] tempIn = new byte[1024]; InetAddress target = null; BufferedReader in = null; String inputLine; boolean connected = true; try { target = InetAddress.getByName(ip); socket = new Socket(ip, port); socket.setSoTimeout(1000); in = new BufferedReader(new InputStreamReader(socket.getInputStream())); } catch (UnknownHostException e) { System.out.println(e); } catch (IOException e2) { System.out.println(e2); } while (connected && in != null && socket != null) { try { inputLine = in.readLine(); System.out.println("Client said : " + inputLine); if (inputLine == null) { System.out.println("Client Disconnected!"); connected = false; } } catch (java.net.SocketTimeoutException e) { System.out.println("Timed out trying to read from socket"); } catch (IOException e2) { System.out.println(e2); } } } } Das ist nur ein einfacher listener. Wenn ich mich entschieden habe welchen weg ich gehe mache ich ein einfaches multithreaded bidirektionales beispiel bevor ich dann weiter ausbaue. Das wird ne weile dauern. Vielleicht is ja jemand interessiert. Obiges beispiel kann mit Netbeans geladen werden. gruss gmd

Hier ist die verbesserte version. Muss erweitert werden fuer mehrere blocklisten. Werde das tun wenn ich die weichen verwaltung eingebat habe. E7BF2785-7534-4720-9729-3C75BB1417D1 Jetzt ist nur noch erforderlich die definitionstabelle zu erstellen und die komponenten alle richtig zu benennen. Bevor ich weitermache werde ich mir ein programm bauen und die schnittstelle benutzen um strassen automatisch zu erkennen und benennen. Ich werde das so loesen dass ein zug auf einer voreingestellten strecke faehrt und waehrend der fahrt die gleise und weichen erkannt und automatisch benannt werden. Mit den signalen muss ich mir noch etwas ueberlegen, vielleciht kann ich ueber die position (koordinaten) eine zuordnung finden. sollte moeglcih sein. Wenn das funktioniert sollte der definitionsaufwand fuer eine groesse anlage drastisch sinken. Damit sollte auch die information zur verfuegung stehen das GBS oder auch rocRail besser zu parametrisieren. Mal sehen wie weit ich komme. gruss gmd

Habe mal schnell umgebaut .. Eine kontakt routine und eine signalroutine. Werde meine variablen in ein gleis packen dann brauche ich auch die eventmodule nicht mehr. Das dauert etwas laenger das anzupassen und zu testen, lohnt sich aber, damit schrumpft das ganze nun wirklich auf generischen code und definitionstabellen. Die benennung der objekte ist auch geloest (im prinzip), dann kan ich meine monsteranlage etwas effizienter automatisieren. Danke nochmals fuer den tip. gruss gmd

Ok, ich sehe dein argument. Macht sinn, ein problem dabei fuer mich. Wenn ich das umstelle auf alle kontakte ueber zentralen event dann muss ich aufpassen wenn ich das in analge mit vorhandenen konatkten einbaue die noch nicht de konventionen entsprechen, die muss ich filtern. Generell has du recht. Das gleiche gielt fuer Signale, soweit habe ich nocht nicht gedacht. Ist halt gut eine loesung zur diskussion zu stellen. Ich werde die demo anlage mal umbauen ... werde eine zweite version machen. Danke fuer den vorschlag gruss gmd

berechnet und gezeichnet sind zwei par dinge. Neo sagte gezeichnet und das betrifft den bildaufbau (weniger objekte, schneller zeichnen, groesserer zoom faktor weniger details schnelleres bild) bewegte objekte muessen allerdings berechnet werde so wie ich das sehe. Zuege und autos fahren weiter auch wenn sie unsichtbar sind. gruss 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

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

Das ist wohl richtig. Entscheidend ist der zoom faktor, also bildausschnitt, und das laesst schliessen zumindest bei meinem system, dass der bildaufbau der entscheidende faktor ist und nicht die berechnung der positionen. Das spielt sicher die CPU/Gpu eine rolle. Eine schnelle gpu mit langsamer cpu hat sicher einfluss auf die berechnung aber das haengt auch stark von dem aufbau des programms ab. Ich denke dass bei heutiger cpu leistung zur zeite der engpass im bildaufbau besteht, insbesondere mit vielen schatten etc. Reduzieren der bildqualitaet (details, schatten usw) wird die frame rate erhoehen und maximale gpu leistung kann nicht abgeruefen werden wenn das programm nicht dafuer vorbereitet ist (stichwort raytracing). Ich habe eine relativ bescheidene grafik karte in meinem system und die gpu ist nur mit max 25% ausgelastet. gruss gmd

keine problem, ich muss nicht recht haben, ist nur meine meinung gruss 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