Drehscheibe Modellbahn mit RF24

Whandall verstehe die Zeilen nur nicht wirklich.

enum Typen {
machSchritte,
stop,
};

struct Packet {
byte type;
int daten;
Packet() : type(stop), daten(0) {}
Packet* befehl(byte welchen, int info = 0) {
type = welchen;
daten = info;
return this;
}
} data;

Das Beispiel benutzt ein Paket aus Befehl und Wert.

Es gibt bisher zwei Befehle, machSchritte (könnte auch fahre Position an sein) und stop.

Das Paket hat einen Konstruktor der type und daten sinnvolle Startwerte verpasst,
sowie eine Funktion befehl die einen typ/Befehl und (optional) einen Wert in das Paket einträgt
und die Adresse des Pakets zurückgibt.

Ein Objekt Paket mit dem Namen data wird definiert.

Ich glaube du bist flexibler wenn du nicht nur einen einzelnen int überträgst.

Der Rückkanal benutzt in dem Beispiel das alte Format,
eine Erweiterung der Typen um z.B. restSchritte könnte auch das abdecken.

Whandall was meinst du mit flexiebler, kann nicht wirklich folgen. Die Bühne reagiert ja auf Zahlen die an sie gesendet werden. Na gut man könnte vielleicht die Anzahl der Schritte und die Richtung mit einmal übertragen. Dadurch würde man sich die zusäzliche Berechung in der Bühne sparen. Meinst du das so in der Art?

Du musst keine Werte mit magischen Nebenwirkungen versehen.

Was meins du mit "magischen Nebenwirkungen"?

Acki1985:
Bei der Zahl für Stop dachte ich an 0. Oder ist das ungünstig?

Ja magische Nebenwirkungen sind ungünstig.

Was nimmst du für 'weiter geht's' nach einem Stop?

Whandall:
Was nimmst du für 'weiter geht's' nach einem Stop?

Da wollte ich einfach die nächste Anzahl an Schritten senden. Also 1 bis 48 für rechtsrum und 101 bis 148 für links rum.

Wen du keinen Rat haben willst, dann halt nicht.

Doch ich bin Froh wenn ich Tip`s bekomme. Das Problem ist nur das ich nicht so recht verstehe was sie bedeuten. Verstehe diese Zusammengefassten Sachen leider nicht. :frowning:

Ich danke dir Whandall das du mir hilfst.

Jetzt weis ich was du mit weiter gehts nach einem Stop meinst.

Wenn die Bühne per Nothalt gestoppt wurde und wieder losfahren soll muss sie ja einen Befehl erhalten. Dazu müsste sie sich aber die aktuelle Position merken und die restlichen Schritte nachdem sie wieder angefahren ist, weiter runter zählen. Oder?

Acki1985:
Doch ich bin Froh wenn ich Tip`s bekomme. Das Problem ist nur das ich nicht so recht verstehe was sie bedeuten. Verstehe diese Zusammengefassten Sachen leider nicht. :frowning:

Ich verstehe nicht was du mit "zusammengefasste Sachen" meinst.

struct kannst du nachschlagen, die Funktionen sind nur bequem,
könnten genauso normale Funktionen mit einem Zeiger auf die struct sein.
(Was sie ja auch sind, der erste Parameter wird nur versteckt und mit this angesprochen,
zusätzlich wird der Zugriff auf die Attribute der struct ermöglicht.)

Acki1985:
Jetzt weis ich was du mit weiter gehts nach einem Stop meinst.

Wenn die Bühne per Nothalt gestoppt wurde und wieder losfahren soll muss sie ja einen Befehl erhalten. Dazu müsste sie sich aber die aktuelle Position merken und die restlichen Schritte nachdem sie wieder angefahren ist, weiter runter zählen. Oder?

Ich würde nicht die Schritte als Kommando schicken, sondern die Zielposition und ja,
die Bühne sollte ihren gesamten Zustand alleine verwalten (wieviele Schritte wohin, aktuelle Position, ...)

Befehl mit diesem Kontext könnte z.B. sein 'gib mir die aktuelle Position' oder
'gib mir den Zustand' (steht, gestoppt, läuft, ...)

Sowas ist leicht mit den zwei (oder mehr) Feldern zu implementieren, siehst du den Vorteil?

Das würde ja quasi bedeuten das der Sender nur den Encoder auswertet, den aktuellen wert auf dem Display anzeigt und den Encodertaster abfragt. Und natürlich die entsprechenden Befehle (neue Position, Anhalten, Weiter fahren an die Bühne Sendet? Und die aktuelle Position und die Restlichen Positionen empfängt. Sehe ich das richtig?

So ungefähr würde ich mir das vorstellen, ja.

Den aktuellen Zustand könnte der Sender abfragen, während der Bewegung könnte er von der Bühne
die Restschritte, vielleicht zusätzlich noch wann er eine Abfahrtsmöglichkeit erreicht hat, erhalten.

Insofern würde ich für beide Richtungen mehr als einen Wert verschicken,
vielleicht ist das typ/wert Paar ja auch für beide Richtungen einsetzbar.

Mir erschlißt nur nicht was du mit "Insofern würde ich für beide Richtungen mehr als einen Wert verschicken," meinst. Da komm ich nicht mit. Kannst du versuchen mir das etwas ausführlicher zu erklären?

Die Antworten sollten ebenso nicht nur einen Wert übertragen,
sondern z.B. restschritte(10), position(1), Zustand(5), ... was auch immer.

Guten abend alle zusammen,

also sollte ich nicht nur Werte sondern auch Worte übertragen? Meinst du das so?

Controller sendet zu Bühne --> rechts, fahren, 25 Schritte.

Bühne sendet zu Controller --> fahre, rechts, noch 24 Schritte.

Meinst du das so Whandall?

Ja, so etwas in der Art.

Wäre doch viel einfacher auszuwerten als einzelne Zahlen, und viel erweiterungsfähiger.

Also würde man text und Zahlen übertragen und das alles mit einmal?

Man bräuchte so zu sagen nur einmal senden und es wären alle Informationen enthalten, egal ob sie benötigt werden oder nicht?

Wer redet von Texten?

Du könntest in beide Richtungen das gleiche Format benutzen, ein Kode und ein Wert.

Wenn du mehr als zwei Knoten betreiben willst (und auch grundsätzlich) ist ein Feld für den Absender praktisch,
um Paketverluste zu erkennen ein laufender Zähler (beide Felder könnten Bytes sein).