"webbasierte" Zeitmessung

  • Ähhh ... ist meine Idee jetzt so beknackt, dass Ihr dazu nix mehr sagen wollt?


    Und gleich noch eine Frage hinterher: Wie würdet ihr die Kommunikation zwischen Translator und RMS lösen - ich finde im Moment TCP Sockets ganz elegant.

    Gruß
    Martin

  • ebay Werbung
  • Hier mal das Diagramm. Und hier liegt das Original und kann dort von Euch bearbeitet werden. Mitarbeit erwünscht! https://oasis.sandstorm.io/sha…B7r2q1oRJV_0MzzdHXATFKNLD
    Und du hast mit deiner Anmerkung völlig recht: Erstmal die Definition fertig machen (mir sind die Sprachen fast egal) und dann kleine Teile fertigstellen um darauf aufbauend weiterzumachen.


    webbasierteZeitmessung (1).png


    Tja, hier unterscheidet sich mein Ansatz von deinem.
    Ich würde eben nicht für jede Bahn eine Schnittstelle definieren, sondern eine für alle.
    Dafür würde ich separieren zwischen Aktoren (Inputkanäle) und Reaktoren (Konsumenten).
    Auch würde ich das RMS nicht zentral sehen - es könnte mehrere RMS geben, und die könnten auch nur Teilfunktionen übernehmen.


    Mein Aufbau sähe daher eher so aus:RMS-Architekturkonzept.png


    Es gibt reine Aktoren (z.B. Chaosschalter), reine Reaktoren (z.B. Anzeigeschirme) und Systeme die beides sind (z.B. RMS).
    Da könnten dann auch beliebig viele Bildschirme dran hängen, auch Smartphones oder Monitore.




    Ob das tatsächlich so ausreichend ist kann ich noch nicht beurteilen. Insbesondere was die Anbindung mehrerer Bahnsysteme anbelangt, denn ich überblicke noch nicht alles, insbesondere was CockpitXP anbelangt.
    Die Idee wäre aber schon, dass es bei je einer Schnittstelle für Aktor und Reaktor bleibt. Anhand der Anfrage kann man dann ja identifizieren, um welche Art Aktor es sich handelt und das entsprechend dann berücksichtigen.



    Und ja, Sockets wären jetzt auch mein Ansatz.

    2 Mal editiert, zuletzt von Mayday ()

  • auch wenn es doof ist, ich hab jetzt eigentlch nur kritik :D
    nimmt man nicht immer sensor (das, was bei dir aktor ist) und dann einen aktor (das, was bei dir reaktor ist)?
    was kann denn der rms für inputs geben - oder anders: wofür ist der rückkanal?
    chaosschalter würde ich zudem noch verallgemeinern zu input-signalen.


    mehr hab ich gerade beim überfliegen nicht anzumerken.

  • Namen ... Schall und Rauch :D
    Ob das mit den Aktoren jetzt so stimmt weiß ich nicht genau, gemeint sind einfach Konsumenten, also Teile des Systems, die Informationen bekommen bzw. auf Informationen warten/horchen.
    Ein Sensor ist ein Akteur, aber nicht jeder Akteur muss ein Sensor sein. Das RMS kann beispielsweise Einstellungen vornehmen, ein Rennen starten, etc. Somit ist es ein Akteur (und das passt dann von der Namensgebung her doch etwas besser als Sensor).
    Das war die Idee.


    Aber natürlich hast du Recht, der Chaosschalter steht exemplarisch für einen Sensor - der bessere Begriff in diesem Kästchen wäre Sensor.

  • siehste - an die ablaufsteuerung des rennens über den rbs habe ich überhaupt nicht gedacht... Wobei das ja auch eine überschaubare Menge an befehlen sein sollte, die alle rbs können müssen.

  • Also erst mal vorweg: Kritik ist nicht doof, sondern zumindest von mir auch erwünscht. Es hilft ja nix, wenn ich mir ein vermeintlich tolles System ausdenke, was dann bei anderen nicht sinnvoll einsetzbar ist.


    Zu deinem Post: Es wird immer Ein- und Ausgänge geben. Die Eingänge sind denke ich klar. Sensoren der Analogbahn z.B. um die Zieldurchfahrt der einzelnen Slots zu bestimmen. Aber es gibt durchaus auch Ausgänge. Z.B. werden gerne mal Relais geschaltet, die bei bestimmten Situationen (Chaos, ... ) den Bahnstrom abschalten. Da braucht man dann Ausgänge - oder wie Mayday es beschreibt Reactoren.


    Zu Maydays letztem Post schreibe ich heute Nachmittag noch was. Da muss ich noch einmal in Ruhe drauf schauen ...

    Gruß
    Martin

  • ebay Werbung
  • So, nun mal noch ein paar Gedanken von mir ... ich hatte die letzten Tage wenig Zeit, daher erst jetzt eine Rückmeldung von mir.


    Ich bin mir nicht sicher, ob ich die Beschreibung und das Diagramm von Mayday richtig verstanden habe, daher noch ein paar Fragen und Anmerkungen von mir. Ich glaube nämlich immer noch, das wir gar nicht so weit auseinander liegen :)


    Mayday hat an meinem Konzept bemängelt, das ich für jede Bahntechnik eine eigene Schnittstelle bauen will. Da müssen wir uns mal kurz über den Begriff klar werden. Ich hätte vielleicht von einer Schnittstellendefinition sprechen sollen. Diese Schnittstellendefinition gilt für alle Bahntypen und deckt alle Anforderungen der möglichen Bahnen ab. Das bedeutet aber auch, das diese Schnittstellendefinition mit der Zeit wächst, wenn ein neuer Bahntyp mit neuen Anforderungen dazukommt. Diese Schnittstelle würde aus meiner Sicht mit Telegrammen arbeiten. So in der Art wie:

    • "Neue Runde für Fahrzeug X" (ginge bei allen Bahntypen und wäre ein Telegramm von Bahn Richtung RMS)
    • "Chaostaster betätigt" (ginge bei allen Bahntypen und wäre ein Telegramm von Bahn Richtung RMS)
    • "Bahnstrom aus" (ginge bei allen Bahntypen müsste aber unterschiedlich umgesetzt werden (Analog: Relais schalten/digital: Begehl an CU senden) und wäre ein Telegramm von RMS Richtung Bahn)
    • "Startprozess starten" (wäre für die CU möglich und wäre ein Telegramm vom RMS an die "Bahn")
    • "Startampel X einschalten" (wäre für die CU möglich, bei analogen Bahnen mit selbst gebauter Startampel notwendig und wäre auch vom RMS Richtung Bahn)

    Ich würde es so lösen, das jede Bahntechnik (analoge Bahn per Cockpit XP USB Box, digitale Carrera CU, digitale Carrera BB, analoge Bahn mit selbstgebauter Hardware, ...) mit einem eigenen kleinen Stück Software (bei mir der Translator) dafür sorgt, das die Signale und Sensoren der Bahn so ausgewertet werden, das man diese Informationen per Telegramm über die gemeinsame Schnittstelle an das RMS senden kann, bzw. von dort empfangen kann. Wenn man das pro Bahntyp getrennt macht, ist die Schwelle für andere Entwickler geringer ihren eigenen Translator zu schreiben, da sie nicht auf die anderen Bahntypen Rücksicht nehmen müssen und den Translator in der Lieblingssprache programmieren könnten. Die Telegramme werden schließlich per Socket mit dem RMS ausgetauscht. Das ist TCP und völlig unabhängig von irgendwelchen Sprachen.


    Bleiben wir bei dem Beispiel Digitalbahn mit CU: der Translator würde per Bluetooth oder serieller Kabelverbindung Kontakt zur CU aufnehmen. Gleichzeitig nimmt er per TCP Socket Kontakt mit dem RMS auf. Kommt nun vom RMS der Befehl ein Rennen zu starten, kann er dieses allgemeingültige Telegramm über die Socketverbindung entgegennehmen und in die für die CU nötigen Befehle umwandeln und an die CU senden. Während dem Rennen fragt der Translator ständig bei der CU nach neuen Runden und würde diese Infos in das allgemeingültige Telegramm für "Fahrzeug X neue Rundenzeit Y" übersetzen und an das RMS weitergeben.
    Bei einer analogen Carrera GO, bei der ich mir eine Zeitmessschiene mit Lichtschranke selber gebaut habe und auch eine eigene Startampel gebastelt habe, wäre der Translator auf Bahnseite damit beschäftigt, die Signale der Lichtschranke auszuwerten und wieder in das allgemeine Telegramm "Fahrzeug X neue Rundenzeit Y" zu übersetzen. Ich würde das Auswerten der Signale nicht über die Schnittstelle schicken. Also eben nicht über die Schnittstelle melden "I/O Port 5 hat ausgelöst", sondern das interpretierte Ergebnis dieses Events.


    Ich hoffe meine Idee ist klarer geworden. Es gibt nur eine Schnittstelle zwischen Bahnen und RMS. Diese wird von allen über die Translator per TCP Socket bedient. Man könnte auch auf die Idee kommen, das mehrere Translator gleichzeitig mit dem RMS kommunizieren, wenn ich z.B. noch irgendwelche I/O Ports für Schaltungen an der Bahn brauche (Licht über Relais einschalte - OK blödes Beispiel :) )


    So nun mal zu dem Diagramm von Mayday:


    Du hast mehr von der Seite des Datenflusses auf die Sache gesehen.

    • Der Chaostaster ist z.B. ein Inputsignal.


    • Die CU kann Daten senden und empfangen. Genauso das RMS.


    • Eigentlich kann auch ein Rennbildschirm nicht nur Daten empfangen, sondern auch senden. Schließlich könnte ich mir vorstellen, das der Rennleiter an seinem Tablet den Rennstart oder Chaos per Button auslöst.


    All diese Signale und Befehle laufen bei dir über die Schnittstellen Actor und Reactor ins System.


    Wenn ich jetzt mal bei der CU bleibe, würde die CU per serielle Verbindung an die beiden Schnittstellen Actor und Reactor angebunden werden. Wie soll das gehen? Es ist doch nur eine serielle Verbindung gleichzeitig möglich. Oder ist das eine Abstraktionsebene höher - was ich vermute - und die serielle Verbindung wird von Software aufgebaut (von welcher?) und der Datenfluss darüber landet entweder bei Actor oder Reactor. Wenn das so ist, meinen wir glaube ich das gleiche, oder? Vielleicht mit dem Unterschied, das bei mir nicht eine Software alle Bahntypen bedient, sondern eben für jeden Bahntyp ein Translator existiert. Und ich hätte zwei Schnittstellen. Die eine zwischen Bahn und System und die andere zwischen System und visueller Ausgabe/Steuerung. Die würde ich dann per Websocket realisieren.


    Vielleicht kannst du noch einmal ein paar Sätze über deinen mittleren Teil (Schnittstellen/Kommunikation/StateHolder/AlertManager) schreiben. Dann wird das vielleicht klarer für mich. Ich denke, dass das was ich als RMS bezeichne bei mir auch all das beeinhaltet was du in deinem Diagramm in der Mitte extra aufgeführt hast.

    Gruß
    Martin

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!