gmd Geschrieben 9. März 2020 Autor Geschrieben 9. März 2020 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
gmd Geschrieben 9. März 2020 Autor Geschrieben 9. März 2020 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
gmd Geschrieben 9. März 2020 Autor Geschrieben 9. März 2020 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
gmd Geschrieben 11. März 2020 Autor Geschrieben 11. März 2020 Die naechste version 5CB72297-8285-461B-A14F-B30EA6C50C48 Alle anderen sind entfernt. Mit weichenschaltung, geschwindigkeits parametern per block, wartezeiten per halteblock, automatische durchfahrtsanforderung Vor- und sperrsignale sind noch nicht versorgt, nur verbunden. Langsamfahrt erwarten und manuelles sperren eines einfahrtgleises wird noch irgendwann erweitert. Das script wird als naechstes erweitert um mehrere anlagenabschnitte zu definieren. Jeder abschnitt kann bis zu 99 bloecke enthalten. Das kann allein durch definition der drei tabllen im hauptscript erfolgen. Programmierung ist nicht erforderlich. Derzeit is nur eine abschnitt definition unterstuetzt. Der naechste schritt muss sein diese tabellen auch durch ein interaktives tool zu erstellen ueber die externe schnittstelle. gruss gmd
gmd Geschrieben 28. März 2020 Autor Geschrieben 28. März 2020 http://vk6gmd.com/MBScompanion.mp4 Hier ist ein movie der ein paar der implementierten funktionen zeigt. Habe einiges an fortschritt gemacht. Wesentliche ziele: Aufbau einer steuerung auf einer hoeheren ebene, die vorgefertigte bausteine verwendet die parametrisiert werden.. Dies beinhaltet schattenbahnhof steuerung, kopfbahnhofsteuerung usw. Bei allen anlagen faellt auf dass alle teilaspekte der steuerung sich immer wiederholen. Das ist jetzt keine kritik, viele anlagen die ich angeschaut habe sind wirklich toll gemacht, mit viel liebe zum detail und recht aufwendigen steuerungen. Aber es faellt eben auf dass zu wenig varianten implementierbar sind, weil es einfach zuviel aufwand macht. Das gleiche gilt fuer stellpult und auch rocrail. Man benoetigt einfach mehr tools, die implementierung von features vereinfachen. Ein wesentlicher teil ist die namensvergabe. Wenn amn mehere tausend objekte auf der anlage hat (und ich meine damit gleise und weichen und nicht vegetation) dann ist es extrem muehsam alle zu benennen. MBS erzeugt keine eindeutigen namen automatisch. Gruppieren zu bloecken, zuordnen von kontakten, signalen usw. ist manuell. Das ist richtig aufwand. Bei einer realanlage verwendet man auch bausaetze und steuermodule und die wenigsten bauen sich ihre elektronischen module selbst sondern verwenden fertige bausteine. Das gleiche und mehr strebe ich an. Viele viel mechanismen, die ich hier noch gar nicht beschreiben kann, weil es einfach zu viel aufwand waere es zu diesem zeitpunkt zu erklaeren. Man muss es sehen, dann ist es einfacher. Objekt gruppen verwalten um layer verwaltung zu vereinfachen, automatisch weichenstrassen abfahren und speichern, variablen dynamisch erkennen und anzeigen zur diagnose, detaillierte defaults fuer geschwindigkeiten etc. verwalten, und das alles als voraussetzung fuer eine automatisierte, interaktiver erstellung eines steuerpultes. Das nur mal grob. Der movie zeigt einige beispiele aber das wesentliche ist, dass ale definitionen von einem lua script unterstuetzt werden, welches alle mechanismen automatisch auf der anlage umsetzen, wenn die name stimmen und die bloecke richtig definiert sind. Zuege konfiguriren, automatisch zum anfangspunkt setzen, fahrplaene definieren usw. Naja mal sehen wie weit ich komme. Rocrail ist jedenfalls keine alternative mehr fuer mich, einfach zu muehsam. gruss gmd
HaNNoveraNer Geschrieben 28. März 2020 Geschrieben 28. März 2020 (bearbeitet) Hi gmd Da hast Du mal Recht. Ich merke auch gerade den Aufwand mit Rocrail. Es dauert sehr lange, alles zu verknüpfen und zu definieren. Nichtsdestotrotz muß ich meine Anlage jetzt erstmal damit fertigstellen, obwohl es langsam etwas nervt. Liegt aber auch daran, daß ich mich in 3-4 Wochen in das ganze Rocrail einarbeiten mußte und noch lange nicht alles begriffen habe. Und kämpfe mit dem Datenaustausch zum Rocstudio bei Neustart der Programme. Du darfst allerdings die Freiheiten des Anwenders nicht vernachlässigen, bei Deinen Bemühungen alles zu automatisieren. Gruß Thomas Bearbeitet 28. März 2020 von HaNNoveraNer
gmd Geschrieben 28. März 2020 Autor Geschrieben 28. März 2020 Thomas, ich baue das fuer mich und nicht als allgemein verwendetes tool. Jede form der abstraktion veringert die freiheitsgrade. Wenn man eine library von funktionen benutzt dann ist man auf die bereitgetellten leistungen angewiesen und kann nicht durchgreifen. Das ist ja nicht der sinn. Jede form der automatisierung erzwingt eine gewisse standardisierung, das ist unvermeidbar. gruss gmd
HaNNoveraNer Geschrieben 28. März 2020 Geschrieben 28. März 2020 Achso, nur für Dich. Dann ist es glaube ich für viele hier nicht mehr interessant.
gmd Geschrieben 29. März 2020 Autor Geschrieben 29. März 2020 Das ist ein misverstaendnis Thomas. Wer es verwenden will der kann das tun, aber ich schreibe das nicht um ein tool zu machen fuer die allgemeinheit. Das beduetet dass ich auch keine feature requests bereucksichtige wenn sie fuer mein konzept keinen sinn machen, aber jeder kann die source haben und aender was er will. Allerdings ist das nicht wirklich trivial wenn man WPF und C# nicht gut kennt. Aber ich denke dass mein konzept fuer einige auch verwendbar sein wird und ich habe kein problem damit. Jedenfalls kann man nicht auf dauerhafte unterstuetzung rechnen. gruss gmd
EASY Geschrieben 29. März 2020 Geschrieben 29. März 2020 Hallo gmd, es ist zwar schade, daß es nur eingeschränkt allgemein wird, aber ich finde es gut, daß Du es so eindeutig klarstellst. Gruß EASY
gmd Geschrieben 29. März 2020 Autor Geschrieben 29. März 2020 EASY, das ist kein boeser wille, es ist einfach eine notwendigkeit. Um ein solches konzept zu realisieren muss ich festlegungen treffen, die einige gestaltungsfreiheiten einschraenken. Wenn ich dann moeglichst viel freiheitsgrade offenlassen will dann wrde ich nie fertig. Also fange ich mal mit einem knozept an das mir so in den sinn kommt. Wir werden ja sehen wie weit das geht und wie einschraenkend das wirklich ist. Ein beispiel: Ich wered ganz feste namenskonventionen haben. Es ist denkbar auch diese definierbar zu machen aber das macht alles noch komplizierter. Wenn jemand mit diesen namenskonventionen nicht einverstanden ist weil er sein eigene konzept hat, dann ist das ein problem. Es gibt viele punkte an denen ich hacks bauen muss, weil die schnittstelle manche funktionen nicht erlaubt. Die werde ich in der zukunft anpassen muessen. Ob ich da tue wenn eine neue schnittstelle kommt weiss ich nicht. Also kann ich nicht versprechen dass das irgendwie sinn macht allgemein verwendet zu werden. gruss gmd
gmd Geschrieben 30. März 2020 Autor Geschrieben 30. März 2020 Hallo, Naechste Stufe: Semi automatische blockerkennung mit umbenennung der elemente. http://vk6gmd.com/Blockerkennung.mp4 Voraussetzung ist dass die objekte eindeutig benannt sind. Das wird mit der funktion Naming gemacht. Die sorgt dafuer dass alle relevanten elemente einn eindeutigen namen bekommen. Dann kann die funktion blockerkennung laufen wie im movie. Hiermit werden alle bloecke konfiguriert. Aehnliches werde ich fuer Fahrstrassen machen, die dann gespeichert werden mit allen weichenstellungen. Wenn ich die grundfunktionen alle fertig habe, dann kann ich mich der hoeheren kunst der steuerung widmen. Ich habe mir einen weg gebaut mit dem ich auch die gleiskontakte gemeldet bekomme. Alle objekt die erkannt sind werden gemaess meinen namenskonventionen umbenannt, die fuer die steuerscripte erforderlich sind. gruss gmd
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