
Hallo alle zusammen,
im Rahmen der Umstellung auf die neue Engine, ist euch sicher bekannt, dass auch die Scriptsprache umgestellt wird. (Vorerst) kann bei Scripten (nur) mit Rust gearbeitet werden*.
Aus diesem Grund haben Teneberus und ich uns mal hingesetzt und überlegt, was wir aufgrund unserer Erfahrungen mit dem bisherigen Script-System im Bereich der Kommunikation (Fahrzeug <> Fahrzeug, Fahrzeug <> Modul, Modul <> Modul) verbessern können. Auch wollten wir auf die neuen Möglichkeiten, die Rust uns bietet, zurückgreifen. Weil wir nicht allwissend sind und auch nicht jeden Anwendungsfall kennen, wollen wir hier unsere Vorschläge präsentieren und Feedback/ Verbesserungsvorschläge sammeln.
Grundlagen Erklärung
Als Erstes möchte ich für alle einmal das grundlegende Konzept für die neue Script Kommunikation erklären:
Die wichtigste Änderung gegenüber dem System in Pascal ist es, dass in Zukunft nicht mehr zwischen MessageToChild, MessageToParent, Broadcast, Kupplungsvariablen, etc. unterschieden wird. In Rust wird alles unter einer Message zusammengefasst. Dies bietet die Vorteile, dass Nachrichten flexibler an verschiedene Ziele zugestellt werden können und spart auch den Aufwand verschiedene Empfangsfunktionen im Script definieren zu müssen. In Zukunft können alle Messages über eine Funktion fn on_message(&mut self, msg: Message); empfangen werden.
Darüber hinaus kann die Beschränkung auf die drei Datentypen String, Single, Integer wegfallen. Eine Nachricht kann ab jetzt jeden beliebigen Inhalt haben, solange dieser die Traits [Serialize, Deserialize] erfüllt.** Darüber hinaus verfügt eine Message über 2 bzw. 3 Parameter, welche namespace, identifier, [bus] sind.
Der Identifier bildet dabei wie bisher den Namen der Nachricht. Dieser kann frei gewählt. Mit dem Namespace wird eine Nachricht einer bestimmten Kategorie zugeordnet. Dies ist auch wichtig, dass wenn 2 Personen denselben Namen für eine Nachricht werden, diese sich nicht überschreiben und es zu Fehlern kommt. Namespaces können z.B. Std für Lotus Standard Messages sein, oder man kann sein eigenes Kürzel, bzw. den Nickname verwenden. Der Wert Bus ist optional bei der Definition einer Message. Die Hauptfunktion ist es, anhand der Bus-Id das Versenden von Nachrichten auf einem bestimmten Bus über die Kupplung zu erlauben oder zu verhindern. Analog zu dieser Funktionsweise im alten System.
Das Letzte, was ich noch als Grundsatz erklären will, ist das Versenden von Messages. Hierzu wird es eine Funktion geben, welcher man als Parameter die zu versendende Message und eine Liste mit Empfängern übergibt. Die Neuerungen hierbei sind, einerseits, dass man direkt an mehrere Empfänger senden kann und andererseits nur noch eine allgemeine Sende-Funktion hat und nicht mehr wie bisher verschiedene, je nach Empfänger. Als Empfänger für Messages gibt es einige Optionen, die ich hier nur mal kurz anreißen will: ***
- Myself (Sendet an den Absender der Nachricht)
- ChildByIndex (Sendet an einen bestimmten Modulslot)
- Broadcast (Sendet an alle)
- AcrossCoupling (Sendet über die vordere oder hintere Kupplung)
- Parent (Sendet von Modulen an der übergeordnete Fahrzeug)
- ...
Mit diesen Grundlagen über das neue Message-System möchte ich als Nächstes vorstellen, welche Änderungen wir uns bei den Standard-Messages überlegt haben. Dabei geht es in diesem ersten Beitrag erstmal nur um die wirklichen Basics. Funktionen und Features, welche noch nicht implementiert sind, folgen zu einem späteren Zeitpunkt.
Die hier vorgestellten Messages werden alle im Standardumfang definiert sein und können direkt als Struktur verwendet werden. Außerdem wird es Helfer-Funktionen geben, mit welchen das Versenden dieser Messages vereinfacht wird.
Fahrzeugnummer
Bisher wurde hier ein String unter dem Namen VEH_NUMBER versendet. Dies wollen wir auch so beibehalten. Die neue Message in Rust sieht wie folgt aus:
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgVehNumber {
- pub value: String,
- }
- message_type!(MsgVehNumber, "Std", "Vehiclenumber"); // Namespace: "Std", Identifier: "Vehiclenumber" (Bus wird nicht definiert)
Diese wird/ soll beim Versenden per Broadcast an das eigene Fahrzeug und alle Module versendet werden. Es findet keine Übertragung per Bus über die Kupplung statt.
Batteriehauptschalter & Batteriespannung
Hierfür haben wir uns dazu entschieden, diese beiden Informationen zusammenzulegen. Rust bietet die Möglichkeit, dass Varianten eines Enums einen Datenpayload tragen. Dieses wollen wir hierfür nutzen, um so beide Informationen zusammen zu übertragen. Wir man im Codeausschnitt für enum Batteryvoltage sehen kann, wird mit dem Zustand On auch eine Float Zahl mitübertragen. Diese stellt die normierte Batteriespannung dar (Also 0.0 = Keine Spannung, 1.0 = Sollspannung) Im Zustand Off muss keine Spannung übertragen werden, da die Batterie getrennt ist.
Mit dieser Message ersetzen wir die bisherigen BATTERYSWITCH (integer) und VOLTAGE (single). Hier der passende Ausschnitt aus dem Code:
- #[derive(Default, Debug, Copy, Clone, Serialize, Deserialize)]
- pub enum Batteryvoltage {
- On(f32),
- #[default]
- Off,
- }
- ...
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgBatteryvoltage {
- pub value: Batteryvoltage,
- }
- message_type!(MsgBatteryvoltage, "Std", "Batteryvoltage"); // Namespace: "Std", Identifier: "Batteryvoltage" (Bus wird nicht definiert)
Alles anzeigen
Wie auch bei der Wagennummer werden diese Informationen nur an alle Empfänger in einem einzigen Fahrzeug versendet.
Eine Wichtige weitere Sache ist, dass Batterie = Aus für alle Objekte der Standard ist. Wird ein Fahrzeug zu Beginn bereits mit eingeschalteter Batterie gespawnt, muss diese Information initial einmal versendet werden.
Modulansteuerung
Diese Message wird die alte Message MAINSWITCH (integer) ersetzen und erweitern. Wir wollen den Informationsgehalt wie folgt erweitern. Zum einen gibt es für jede Ein/ Ausschaltnachricht eine Information, wo gerade der Zustand geändert wurde. So können z.B. zentale Bordrechner, die Script technisch mit in einem IBIS-Terminal enthalten sind auch korrket ein und ausschalten. Die Werte ACab und BCab geben dabei an, ob im jeweiligen Fahrzeug einer der beiden Fahrerstände aufgerüstet wurde. Mit dem Zustand NoCab kriegen auch die Module in den geführten Fahrzeugen die Information, dass im Zugverband jetzt ein Fahrerstand aufgerüstet wurde. Die andere Änderung ist ein Boolean Parameter in der Einschaltnachricht. Mit dieser kann der Befehl "Quickstart" (Wert = true) übermittelt werden. Dadurch sollen Module den Boot-Prozess überspringen und direkt im Dauerbetrieb laufen. Dies bietet unter anderem die Vorteile, dass man beim Debuggen des Moduls nicht lange Startprozeduren abwarten muss und sorgt gleichzeitig dafür, dass bei der "Fahrzeug platzieren" Startoption "Fahrbereit" auch das Modul im aktiven Fahrerstand direkt verfügbar ist. Bisher musste man hier ja ein wenig schummeln. Hier, der Code (gekürzt) dazu zum draufgucken:
- #[derive(Debug, Copy, Clone, PartialEq, Eq, Serialize, Deserialize)]
- pub enum PowerSignalCabin {
- ACab,
- BCab,
- NoCab,
- }
- ...
- #[derive(Debug, Copy, Clone, Serialize, Deserialize)]
- pub enum PowerSignalState {
- On {
- quickstart: bool,
- cabin_id: PowerSignalCabin,
- },
- Off {
- cabin_id: PowerSignalCabin,
- },
- }
- ...
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgPowerSignal {
- pub value: PowerSignalState,
- }
- message_type!(MsgPowerSignal, "Std", "PowerSignal"); // Namespace: "Std", Identifier: "PowerSignal" (Bus wird nicht definiert)
Alles anzeigen
Durch die enthaltene Information über den Fahrerstand, wir diese Message auch direkt per Broadcast an alle Module (und das eigene Fahrzeug) versendet. Durch die Möglichkeit, dass Module in Zukunft wissen, welchem Fahrerstand sie zugehörigen sind, können diese passend reagieren. Die Nachricht wird ebenfalls NICHT über die Kupplung übertragen und muss von jedem Fahrzeug selbstständig für seine Module generiert werden. Auch hier ist für alle Objekte der Standardzustand ausgeschaltet.
Modulbeleuchtung
Hier haben wir wieder weniger vorzuschlagen. Wir ersetzen hiermit den bisherigen Broadcast LIGHT (single). Dieser ist nun ein Wert vom Typ f32. Der Wertebereicht soll dabei die normierte Helligkeit sein, also 0.0 = Licht aus & 1.0 = Sollhelligkeit.
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgLight {
- pub value: f32,
- }
- message_type!(MsgLight, "Std", "Light"); // Namespace: "Std", Identifier: "Light" (Bus wird nicht definiert)
Grundsätzlich sollen alle Module diese Information erhalten. Eine Abweichung, wenn verschiedene Module z.B. an verschiedenen Lichtkreisen hängen, ist auch möglich. Die Message wird explizit NICHT über die Kupplung übertragen und muss in/ für jedes Fahrzeug im Zugverband selbst versendet werden.
Haltewunsch
Bisher wurde hier der Boradcast STOPREQUEST (single) verwendet. In unserem Vorschlag bleibt die Funktion erhalten, nur der Datentyp wird zu Boolean verändert.
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgStopRequest {
- pub value: bool,
- }
- message_type!(MsgStopRequest, "Std", "StopRequest"); // Namespace: "Std", Identifier: "StopRequest" (Bus wird nicht definiert)
Wie auch bei den vorherigen Messages wird diese NICHT über die Kupplung übertragen. Soll aber ansonsten alle Module im Fahrzeug erreichen. Sollte es in einem Fahrzeug mehrere Haltewunsch-Kreise geben (z.B. eine einem Bus im Vorderwagen und im Nachläufer), können natürlich Messages mit verschiedenen Empfängern gesendet werden. Fahrzeuge ohne Haltewunsch (z.B. historische Züge oder U-Bahnen) müssen diese Information natürlich nicht bereitstellen.
Geschwindigkeit
Über dieses Thema haben wir etwas länger nachgedacht. Wir greifen hier die Idee der Message VELOCITY (single) auf, welche bisher nur den Bordrechner erreicht hat. In unserer Überlegung kam auch die Idee auf, statt der Geschwindigkeit des Fahrzeugs, die gefahrene Wegstrecke oder direkt einen festgelegten Wegimpuls zu verwenden. Von diesen Ideen sind wir jedoch wieder abgerückt, da die Geschwindigkeit einfach am vielseitigsten einsetzbar ist und gleichzeitig auch die meiste Informationsmenge bereitstellt.
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgVelocity {
- pub value: f32,
- }
- message_type!(MsgVelocity, "Std", "Velocity"); // Namespace: "Std", Identifier: "Velocity" (Bus wird nicht definiert)
Der Wert wird im Metern pro Sekunde versendet. Das Vorzeichen bildet dabei die Fahrtrichtung ab. Auch diese Message wird NICHT über die Kupplung versandt, muss aber in jedem Fahrzeug gesendet werden. Wichtig ist hier, dass verschiedene Module auch verschiedene Geschwindigkeiten bekommen.
Türzustand
Kommen wir abschließend noch zur Information des Tüerzustands. Im bisherigen Lotus wurden hier zwei verschiedene Nachrichten verwendet. Einmal ATBUSSTOP (integer) und DOORSOPEN (integer). Diese wollen wir jetzt zusammen führen. Dabei wird nun nicht mehr nur die Information "Türfreigabe" ja/nein enthalten sein, sondern auch der Zustand ob die Türen zentral geöffnet wurden und auf welcher Seite die Türen freigegeben/ geöffnet sind.
- #[derive(Debug, Default, Clone, Serialize, Deserialize, PartialEq)]
- pub enum DoorState {
- #[default]
- Closed,
- Released(DoorSide),
- Open(DoorSide),
- }
- #[derive(Debug, Default, Clone, Serialize, Deserialize, PartialEq)]
- pub enum DoorSide {
- #[default]
- Right,
- Left,
- Both,
- }
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgDoorState {
- pub value: DoorState,
- }
- message_type!(MsgDoorState, "Std", "DoorState"); // Namespace: "Std", Identifier: "DoorState" (Bus wird nicht definiert)
Alles anzeigen
Wie auch die anderen Messages zuvor wird diese Information NICHT über die Kupplung übertragen, um so bei asymetrisch gekuppelten Fahrzeugen die Türseite nicht zu verdrehen. Hier kann es natürlich auch mehrere Kreise geben, z.B. in Bussen für den Vorderwagen und den Nachläufer. Wichtig ist nur, dass alle Module einmal diese Info bekommen.
Feedback
Damit wären wir am Ende der ersten Runde der Präsentation unseres Vorschlags. Gebt bitte Feedback und vorallem Veränderungs-, Verbesserungsvorschläge oder stellt auch Rückfragen, wenn nötig. Teneberus und ich können das alles nur aus unserer Perspektive betrachten und haben vielleicht bestimmte Aspekte garnicht im Blickfeld gehabt. Damit wir mit der neuen Version von Lotus aktualiserte Standards bekommen, die hoffentlich alle mit nutzen um so eine möglichst große Kompatibilität erreichen zu können.
Die nächsten Themen, die wir be-/ überarbeiten wollen, sind der Zugbus und als Teil davon die FIS-Nachrichten zwischen Bordrechnern und Modulen. Falls es hier schon im vorhinein Input git, könnt ihr den auch gerne schon äußern.
Und damit danke für die Aufmerktsamkeit.
* = Grund dafür ist, dass die API/ Schnittstelle erstmal vollständig entwickelt werden muss. Da ist es nur unnötiger Mehraufwand, gleichzeitig Schnittstellen zu mehreren Sprachen gleichzeitig zu bearbeiten. Weitere Sprachen werden bestimmt in Zukunft möglich sein, dazu kann ich aber keine Aussagen treffen.
** = Wer mit diesen Begriffen noch nichts anfangen kann, dem empfehle ich hier das Offizielle Rust Book (Offizielles Tutorial der Sprache), ist auch auf Deutsch verfügbar.
*** = Kein Anspruch auf Vollständigkeit, und teilweise gekürzt
===========================================================================

Hello everyone,
As part of the changeover to the new engine, you are probably aware that the scripting language is also being changed. (For the time being) scripts will (only) be able to be created in Rust*.
For this reason, Teneberus and I sat together and thought about what we could improve in the area of messaging (vehicle <> vehicle, vehicle <> module, module <> module) based on our experience with the previous script system. We also wanted to make use of the new possibilities that Rust offers us. Because we are not omniscient and do not know every use case, we want to present our suggestions here and collect feedback/suggestions for improvement.
Basic explanation
Firstly, I would like to explain the basic concept of the new script communication to everyone:
The most important change compared to the system in Pascal is that in future there will no longer be a distinction between MessageToChild, MessageToParent, Broadcast, clutch variables, etc.. In Rust, everything is combined under one Message. This offers the advantage that messages can be delivered more flexibly to different destinations and also saves the effort of the need to define different receive functions in the script. In future, all Messages can be received via a function fn on_message(&mut self, msg: Message);.
In addition, the restriction to the three data types String, Single, Integer no longer exists. From now on, a message can have any content as long as it fulfils the [Serialize, Deserialize] traits.** In addition, a message has 2 or 3 parameters, which are namespace, identifier, [bus].
As before, the identifier is the name of the message. This can be freely chosen. The namespace is used to assign a message to a specific category. This is also important so that if two people use the same name for a message, they do not overwrite each other and errors occur. Namespaces can be e.g. Std for Lotus Standard Messages, or you can use your own acronym or nickname. The Bus value is optional when defining a message. The main purpose is to allow or prevent the sending of messages on a specific bus via the coupling based on the bus ID. Similar to this function in the old system.
The last thing I want to explain as a basic principle is the sending of messages. For this purpose, there will be a function to which you pass the message to be sent and a list of destinations as parameters. The new features here are, on the one hand, that you can send directly to several recipients and, on the other hand, that you only have one general send function and no longer different ones depending on the recipient as before. There are several options as destinations for messages, which I will only briefly outline here: ***
- Myself (Sends to the sender of the message)
- ChildByIndex (Sends to a specific module slot)
- Broadcast (Sends to all)
- AcrossCoupling (Sends via the front or rear coupling)
- Parent (Sends from modules to the parent vehicle)
- ...
With these basics about the new message system, I would next like to present the changes we have considered for the standard messages. This first article is only about the real basics. Functions and features that have not yet been implemented will follow at a later date.
The messages presented here will all be defined in the standard scope and can be used directly as a structure. There will also be helper functions to simplify the sending of these messages.
Vehicle number
Previously, a string was sent here under the name VEH_NUMBER. We want to keep this as it is. The new message in Rust looks like this:
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgVehNumber {
- pub value: String,
- }
- message_type!(MsgVehNumber, "Std", "Vehiclenumber"); // Namespace: "Std", Identifier: "Vehiclenumber" (Bus is not defined)
This is/ should be sent via broadcast to the own vehicle and all modules when sending. There is no transmission by bus via the coupler.
Main battery switch & battery voltage
We have decided to merge these two pieces of information. Rust offers the option of variants of an enum carrying a data payload. We want to use this to transfer both pieces of information together. As you can see in the code snippet for enum Batteryvoltage, a float number is also transmitted with the On state. This represents the normalised battery voltage (i.e. 0.0 = no voltage, 1.0 = default voltage) In the Off state, no voltage needs to be transmitted as the battery is disconnected.
This message replaces the previous BATTERYSWITCH (integer) and VOLTAGE (single). Here is the appropriate excerpt from the code:
- #[derive(Default, Debug, Copy, Clone, Serialize, Deserialize)]
- pub enum Batteryvoltage {
- On(f32),
- #[default]
- Off,
- }
- ...
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgBatteryvoltage {
- pub value: Batteryvoltage,
- }
- message_type!(MsgBatteryvoltage, "Std", "Batteryvoltage"); // Namespace: "Std", Identifier: "Batteryvoltage" (Bus is not defined)
Alles anzeigen
As with the car number, this information is only sent to all recipients in a single vehicle.
Another important thing to note is that Battery = Off is the default for all objects. If a vehicle is spawned with the battery switched on at the start, this information must be sent once initially.
Module power control
This message will replace and extend the old message MAINSWITCH (integer). We want to extend the information content as follows. Firstly, for each switch-on/switch-off message there is information on where the status has just been changed. For example, central on-board computers that are technically included in an IBIS terminal can also switch on and off correctly. The values ACab and BCab indicate whether one of the two driver's cabs has been activated in the respective vehicle. With the NoCab status, the modules in the accompanied wagons also receive the information that a driver's cab has now been upgraded in the train set. The other change is a Boolean parameter in the switch-on message. This can be used to transmit the ‘Quickstart’ command (value = true). As a result, modules should skip the boot process and run directly in steady operation. One of the advantages of this is that you don't have to wait for long start procedures when debugging the module and it also ensures that the module is directly available in the active driver's cab when the ‘Place vehicle’ start option ‘Ready to drive’ is selected. Previously, you had to cheat a little here. Here is the code (shortened) for you to look at:
- #[derive(Debug, Copy, Clone, PartialEq, Eq, Serialize, Deserialize)]
- pub enum PowerSignalCabin {
- ACab,
- BCab,
- NoCab,
- }
- ...
- #[derive(Debug, Copy, Clone, Serialize, Deserialize)]
- pub enum PowerSignalState {
- On {
- quickstart: bool,
- cabin_id: PowerSignalCabin,
- },
- Off {
- cabin_id: PowerSignalCabin,
- },
- }
- ...
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgPowerSignal {
- pub value: PowerSignalState,
- }
- message_type!(MsgPowerSignal, "Std", "PowerSignal"); // Namespace: "Std", Identifier: "PowerSignal" (Bus is not defined)
Alles anzeigen
The included information about the driver's cab means that this message is also sent directly to all modules (and the driver's own vehicle) via broadcast. The possibility of modules knowing in future which driver's cab they belong to means that they can react appropriately. The message is also NOT transmitted via the coupling and must be generated independently by each vehicle for its modules. Here too, the default status is switched off for all objects.
Module lighting
Here again we have less to suggest. We are replacing the previous broadcast LIGHT (single). This is now a value of type f32. The value range should be the normalised brightness, i.e. 0.0 = light off & 1.0 = default brightness.
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgLight {
- pub value: f32,
- }
- message_type!(MsgLight, "Std", "Light"); // Namespace: "Std", Identifier: "Light" (Bus is not defined)
In principle, all modules should receive this information. A deviation is also possible if different modules are connected to different lighting circuits, for example. The message is explicitly NOT transmitted via the coupling and must be sent in/for each vehicle in the train itself.
Stop request
The boradcast STOPREQUEST (single) was previously used here. In our proposal, the function is retained, only the data type is changed to Boolean.
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgStopRequest {
- pub value: bool,
- }
- message_type!(MsgStopRequest, "Std", "StopRequest"); // Namespace: "Std", Identifier: "StopRequest" (Bus is not defined)
As with the previous messages, this is NOT transmitted via the coupler. However, it should otherwise reach all modules in the vehicle. If there are several stop request circuits in a vehicle (e.g. a bus in the front vehicle and in the rear vehicle), messages can of course be sent with different receivers. Vehicles without a stop request (e.g. historic trains or underground trains) do not have to provide this information.
Speed
We have been thinking about this topic for a while. We are taking up the idea of the message VELOCITY (single), which has so far only reached the on-board computer. We also considered the idea of using the distance travelled or a fixed distance pulse instead of the vehicle's speed. However, we abandoned these ideas, as speed is simply the most versatile and also provides the most information.
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgVelocity {
- pub value: f32,
- }
- message_type!(MsgVelocity, "Std", "Velocity"); // Namespace: "Std", Identifier: "Velocity" (Bus is not defined)
The value is sent in metres per second. The +/- sign represents the direction of travel. This message is also NOT sent via the coupling, but must be sent in every vehicle. It is important here that different modules also receive different speeds
Door condition
Finally, we come to the door status information. Two different messages were used here in the previous Lotus. One is ATBUSSTOP (integer) and the other is DOORSOPEN (integer). We now want to merge these. This will no longer only contain the information ‘door release’ yes/no, but also the status of whether the doors have generally been opened and on which side the doors are released/opened.
- #[derive(Debug, Default, Clone, Serialize, Deserialize, PartialEq)]
- pub enum DoorState {
- #[default]
- Closed,
- Released(DoorSide),
- Open(DoorSide),
- }
- #[derive(Debug, Default, Clone, Serialize, Deserialize, PartialEq)]
- pub enum DoorSide {
- #[default]
- Right,
- Left,
- Both,
- }
- #[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
- pub struct MsgDoorState {
- pub value: DoorState,
- }
- message_type!(MsgDoorState, "Std", "DoorState"); // Namespace: "Std", Identifier: "DoorState" (Bus is not defined)
Alles anzeigen
As with the other messages before, this information is NOT transmitted via the coupling so that the door side is not twisted in the case of asymmetrically coupled vehicles. Of course, there can also be several circuits here, e.g. in buses for the front end and the rear end. It is only important that all modules receive this information once.
Feedback
This brings us to the end of the first round of the presentation of our proposal. Please provide feedback and, above all, suggestions for changes and improvements or ask questions if necessary. Teneberus and I can only look at this from our perspective and may not have focussed on certain aspects. So that we get updated standards with the new version of Lotus, which hopefully everyone will use in order to achieve the greatest possible compatibility.
The next topics we want to work on/revise are the train bus and, as part of this, the FIS messages between on-board computers and modules. If you have any input in advance, please feel free to let us know.
And thank you for your attention.
* = The reason for this is that the API/interface has to be fully developed first. It is just unnecessary extra work to work on interfaces for several languages at the same time. Other languages will certainly be possible in the future, but I cannot make any statements on this.
** = If you are not yet familiar with these terms, I recommend the Official Rust Book (official tutorial for the language).
*** = No claim to completeness, and partly shortened