Fixed: Unterstützte Zentrale DCC++EX

[vikr]

Hallo Teddy,

eine erste Implementation der Sensoren...
... Bin gespannt auf Feedback.

leider scheint mir Deine erste Lösung nicht ganz sozial verträglich mit den anderen Modellbahn-Steuerprogrammen zu sein. RailControl scheint irgendwie direkt in die Konfiguration zu schreiben, die der Arduino normalerweise selbst beim nächsten Start läd.
Das hat zur Folge, dass Rocrail oder WDP sich nicht mehr mit dem von RailControl umkonfigurierten Board verstehen und die dort deklariertenEingänge vertauscht sind. Diese Ummappen sollte meines Erachtens in einer anderen logischen Ebene liegen, die erst beim Start des Steuerprogrammes erfolgt.
Bei meinem UNO ist PIN 2 mit dem Stromfühler an Gleisabschnitt A verbunden, PIN 4 mit dem Stromfühler an Gleisabschnitt B, PIN 6 mit dem Stromfühler an Gleisabschnitt C und PIN 7 mit dem Stromfühler an Gleisabschnitt D. In allen Modellbahn-Steuerprogramm sollten die auf RM01, 02, 03, und 04 gelegt werden können. Das wär sehr schön, wenn das auch in RailControl so wäre, man kann dann zwanglos von einem Programm auf ein Anderes wechseln kann ohne DCCpp neu in den Arduino zu laden.

MfG

vik

[teddy]

Hallo vik

leider scheint mir Deine erste Lösung nicht ganz sozial verträglich mit den anderen Modellbahn-Steuerprogrammen zu sein.

Cool formuliert

RailControl scheint irgendwie direkt in die Konfiguration zu schreiben, die der Arduino normalerweise selbst beim nächsten Start läd.

Dem Arduino muss jedem Pin eine ID zugeordnet werden über die er dann den Zustand mitteilt. Die ID ist frei wählbar. Von dem her ist es eher Zufall, wenn die Software die ID identisch wählt. Da ich nicht weiss, wie die anderen die IDs verteilen wird das ein schwieriges unterfangen das "sozialverträglich" zu gestalten, ist aber nicht unmöglich.

Dann ist da noch das Mapping zwischen physischem Pin und logischem Pin in der Software. Das ist grundsätzlich nicht schwierig, stellt mich aber vor die Frage, wie die anderen Softwaren an die Info kommen, wie das Mapping denn sein muss. Offenbar ist es je nach Gerät anders...

Gruss
Teddy

[vikr]

Hallo Teddy,

Dem Arduino muss jedem Pin eine ID zugeordnet werden über die er dann den Zustand mitteilt. Die ID ist frei wählbar. Von dem her ist es eher Zufall, wenn die Software die ID identisch wählt. Da ich nicht weiss, wie die anderen die IDs verteilen wird das ein schwieriges unterfangen das "sozialverträglich" zu gestalten, ist aber nicht unmöglich.

Dann ist da noch das Mapping zwischen physischem Pin und logischem Pin in der Software. Das ist grundsätzlich nicht schwierig, stellt mich aber vor die Frage, wie die anderen Softwaren an die Info kommen, wie das Mapping denn sein muss. Offenbar ist es je nach Gerät anders...

ich glaube die orientieren sich letzlich alle an JMRI:
https://www.jmri.org/help/en/html/hardw ... sors.shtml

wie auch generisch genauer von Geoff Bunza beschrieben:

https://model-railroad-hobbyist.com/mag ... ec/arduino

https://model-railroad-hobbyist.com/node/34392

https://model-railroad-hobbyist.com/sit ... can1_4.zip

beim Uno (Nano etc.):
#define Sensor_Pin_Max 20 // Max sensor pin NUMBER (plus one) Mega=70,UNO,Pro Mini,Nano=20
#define Sensor_Pin_Start 2 // Starting Sensor Pin number (usually 2 as 0/1 are TX/RX
#define Sensor_Offset 0 // This Offset will be ADDED to the value of each Sensor_Pin to determine the sensor
// number sent to JMRI, so pin D12 will set sensor AR:(12+Sensor_Offset) in JMRI
// This would allow one Arduino Sensor channel to set sensors 2-69 and another to
// Set sensors 70-137 for example; this offset can also be negative
#define Sensors_Active_Low 1 // Set Sensors_Active_Low to 1 if sensors are active LOW
// Set Sensors_Active_Low to 0 if sensors are active HIGH
#define open_delay 15 // longer delay to get past script initialization
#define delta_delay 4 // Short delay to allow the script to get all the characters
int i;
char sensor_state [70]; // up to 70 sensors on a Mega2560
char new_sensor_state ; // temp to process the possible state change
char incomingByte = 0; // working temp for character processing

beim Mega:
#define Sensor_Pin_Max 70 // Max sensor pin NUMBER (plus one) Mega=70,UNO,Pro Mini,Nano=20
#define Sensor_Pin_Start 2 // Starting Sensor Pin number (usually 2 as 0/1 are TX/RX
#define Sensor_Offset 0 // This Offset will be ADDED to the value of each Sensor_Pin to determine the sensor
// number sent to JMRI, so pin D12 will set sensor AR:(12+Sensor_Offset) in JMRI
// This would allow one Arduino Sensor channel to set sensors 2-69 and another to
// Set sensors 70-137 for example; this offset can also be negative
#define Sensors_Active_Low 1 // Set Sensors_Active_Low to 1 if sensors are active LOW
// Set Sensors_Active_Low to 0 if sensors are active HIGH
#define open_delay 15 // longer delay to get past script initialization
#define delta_delay 4 // Short delay to allow the script to get all the characters
int i;
char sensor_state [70]; // up to 70 sensors on a Mega2560
char new_sensor_state ; // temp to process the possible state change
char incomingByte = 0; // working temp for character processing

Was ich allerdings nicht genau weiß, ist wie z.B. mit PINs (z.B. mit PIN 2) umgegangen wird, wenn sie z.B. schon für ein Ethernetshield eingesetzt werden und als Output oder Input nicht mehr zu Verfügung stehen...
Aber das ist eine Hardwareänderung, auf die man sich als User vorbereiten muss. Wenn man z.B. ein W5100 verwenden will sollte man PIN 2 gar nicht benutzen. Beim UNO wird daher meist auf die Unterstützung von WLAN ganz verzichtet und ausschließlich USB unterstützt, damit hat man insgesamt acht IO-Pins. Beim MEGA wird meist auf PIN 2 als IO-PIN verzichtet, weil man ja reichlich IO-Pins zur Verfügung hat.

Ich finde es wichtig, dass ein Anfänger möglichst wenig konfigurieren muss, d.h. er sollte DCC++BaseStation für den Uno auf den Uno laden können und dann wissen, dass er genau acht Pins für Output oder Rückmelder hat. Dabei gehe ich eigentlich davon aus, dass die Weichen normalerwise über DCC (d.h. einen DCC-Decoder) geschaltet werden und keinen IO-PIN belegen. Defaultmäßig sollten m.E. daher alle PINs als IINPUT eingestellt werden. Die API dient als in erster Linie dazu die RMs in RailControl einem der möglichen IOs zuzuordnen und weniger dazu die PINs als Input oder Augang einzustellen. Oder übersehe ich da etwas?

MfG

vik

[vikr]

Hallo Teddy,

kann man sich in Railcontrol irgendwo Versionsnummer und build anzeigen lassen?

MfG

vik

[teddy]

Hallo vik

Wenn du RailControl startest wird es im Log ausgegeben.

Gruss
Teddy

[teddy]

Hallo vik

Das mit dem Licht, das nicht geschaltet werden kann erscheint mir komisch. In den Logs ist das Schalten des Loklichts korrekt drin. Kannst du andere Lokfunktionen korrekt schalten?

Was mich erstaunt ist, dass du überhaupt einen Sensor zum Schalten gebracht hast. Der Empfangs-Thread für das Empfangen der Sensor-Stati wurde jeweils gerade wieder beendet. Das sollte aber in der neuesten Version korrigiert sein.

Und die Benamsung der Sensoren bei JRMI ist mir nicht klar. Denn JRMI bringt ein separates Config-Tool mit, wo die Adresse (wählbar von 0-32267) und der effektive Pin beliebig gemappt werden kann. Ist zwar super flexibel, aber nicht sehr kundenfreundlich.

Gruss
Teddy

[vikr]

Hallo Teddy,

Das mit dem Licht, das nicht geschaltet werden kann erscheint mir komisch. In den Logs ist das Schalten des Loklichts korrekt drin. Kannst du andere Lokfunktionen korrekt schalten?

Habe ich nicht probiert, da ich in als Testloks nur zwei Loks mit Licht eingesetzt habe.

Was mich erstaunt ist, dass du überhaupt einen Sensor zum Schalten gebracht hast. Der Empfangs-Thread für das Empfangen der Sensor-Stati wurde jeweils gerade wieder beendet. Das sollte aber in der neuesten Version korrigiert sein.

Nein ich konnte unter Railcontrol nur konfigurieren, aber mir keine Meldung anzeigen lassen. Habe nur festgestellt, dass das elektrisch unveränderte DCCppTestbrett nach einer Konfiguration mit Railcontrol nicht mehr funktionierte, weil die Pin-Zuordnung im Arduino durch Railcontrol geändert wurde und nicht mehr da war, wo Rocrail oder WDP sie erwarteten. Beide Programme haben ja einen Rückmeldemonitor, wo man sich ansehen kann auf welchen logischen Rückmeldernummern etwas passiert wenn man einen der Arduino-Pins belegt. Natürlich kann man das jedesmal wieder Programm spezifisch anpassen, aber das geht praktisch nur bei einer handvoll RMs und ist fehlerträchtig.

Und die Benamsung der Sensoren bei JRMI ist mir nicht klar. Denn JRMI bringt ein separates Config-Tool mit, wo die Adresse (wählbar von 0-32267) und der effektive Pin beliebig gemappt werden kann. Ist zwar super flexibel, aber nicht sehr kundenfreundlich.

Ja, deshalb gibt es eine Defaulteinstellung. Die Arduino-Pins sind je nach Board durchnummeriert. Im zweiten Schritt werden von dieser Nummerierung automatisch nur die Pins gezählt, die als IO unter DCCpp mit diesem Board verwendet werden können. Und nur die werden erneut von 1 bis N durchnummeriert und den logischen RMs 1 bis N zugeordnet. Defaultmäßig sind von diesen IO-PINs des Arduino keine als Ausgang deklariert, weil das i. d. R. über Decoder adressiert wird die am Gleissignal hängen. Wenn man Weichen/Signale über die Ausgänge des Arduino schalten will, braucht man ein IO-Zuordnungs-Tool, wie es sie von JMRI oder Rr oder WDP gibt. Dort können die zur Verfügung stehenden PINs als I oder O konfiguriert und kann einer beliebigen Nummer im jeweiligen Adressraum für Sensoren (I) oder Schalter (O) zugeordnet werden.

Ich bin jetzt bis Mitte September im Urlaub und kann deshalb erstmal leider nicht testen.
Fände es aber schön, wenn man die Version/Buildnummer von RailControl auch in der grafischen Browseroberfläche nachsehen könnte...

MfG

vik

[_DB_]

jetzt bin ich auch in der DCC++EX-Welt angekommen. Neben meiner Märklin HO möchte ich jetzt auch meine LGB digitalisieren. Natürlich mit RailControl.

Ich habe mich also erstmals mit DCC++EX beschäftigt und bin ob der Einfachheit und Nachvollziehbarkeit sehr davon angetan. Mein Märklin-System möchte ich nicht aufgeben, aber im Hinblick auf meine (noch) analogen LGB-Loks möchte ich diese Zentrale gern im Auge behalten!

Und dank RailControl kann ich Weichen, Signale, Lokomotiven auch gut manuell steuern (alle diese Komponenten hängen an eigenen DCC-Adressen). Das funktioniert jetzt schon hervorragend (als LGB-Lok muss zur Zeit allerdings noch eine Märklin-Lok im DCC-Modus herhalten)…

s. erste LogDatei.

Log1.txt

(40.89 KiB) Downloaded 277 times

Um einen einfachen Pendelverkehr in RailControl zu realisieren, benötige ich jedoch min. 2 Rückmelder.

Diese in DCC++EX zu realisieren, ist kein Problem.

Wie ein Zusammenhang zwischen Eingangsbelegung im Arduino und RailControl besteht, darauf kann ich mir noch keinen Reim machen und frage einfach einmal in die Runde, ob Ihr so etwas kennt.

Ich habe mal Pin 8 des Arduinos als Sensoreingang definiert - sonst gibt es keine Sensoreingänge:

Hier ein Terminalauszug nach dem Start des Arduinos:

20:53:11.149 -> <* License GPLv3 fsf.org (c) dcc-ex.com *>
20:53:11.190 -> <* LCD0:DCC++ EX v4.0.0 *>
20:53:11.190 -> <* LCD1:Lic GPLv3 *>
20:53:11.190 -> <* MotorDriver currentPin=A1, senseOffset=0, rawCurrentTripValue(relative to offset)=409 *>
20:53:11.190 -> <* MotorDriver currentPin=A0, senseOffset=0, rawCurrentTripValue(relative to offset)=409 *>
20:53:11.190 -> <iDCC-EX V-4.0.0 / MEGA / MY_L298N_BOARD G-a26d988>
20:53:11.190 -> <* No I2C Devices found *>
20:53:11.190 -> <* MCP23017 I2C:x20 Device not detected *>
20:53:11.190 -> <* MCP23017 I2C:x21 Device not detected *>
20:53:11.190 -> <* Signal pin config: normal accuracy waveform *>
20:53:11.190 -> <* LCD3:Ready *>
20:53:11.190 -> <* LCD2:Power Off *>
20:53:11.190 -> <p0>
20:53:11.190 -> PPA0
20:53:11.190 -> <* LCD3:Free RAM= 5788b *>

Ich definiere Pin 8 als Sensor-ID 8 mit internem Pull-Up-Widerstand:
<S 8 8 0>

Liste alle Ein-/Ausgänge: <S>

Hier der Monitor-Mitschnitt:

<S 8 8 0>
20:54:26.494 -> <O>
20:56:08.690 -> <Q 8 8 0>

<S>
20:57:06.320 -> <Q 8 8 0>

Das Ganze im EEPROM fixieren mit <E>:
20:59:25.242 -> <* EEPROM used: 23/4096 bytes *>
20:59:25.242 -> <e 0 1 0>
—> es gibt also lediglich 1 definierten Eingang (s.o.) - den Q8


Interessant in Log2.txt ist das Belegen des Rückmelders

Log2.txt

(44.79 KiB) Downloaded 291 times

:
Q 8 - Rückmelder belegt
q 8 - Rückmelder frei

Diese beiden Zustände von DCC++EX werden von RailControl offensichtlich in 2 verschiedenen Rückmeldern abgebildet:
2022-09-05 19:03:09.638719: Debug: DCC: 0x0000 3c 71 20 38 3e 0a <q 8>.
2022-09-05 19:03:09.638924: Info: DCC: Status von Pin 1 an S88 Modul 4 ist aus
2022-09-05 19:03:11.429895: Debug: DCC: 0x0000 3c 51 20 38 3e 0a <Q 8>.
2022-09-05 19:03:11.430062: Info: DCC: Status von Pin 1 an S88 Modul 2 ist ein
2022-09-05 19:03:11.561664: Debug: DCC: 0x0000 3c 71 20 38 3e 0a <q 8>.
2022-09-05 19:03:11.561875: Info: DCC: Status von Pin 1 an S88 Modul 4 ist aus
2022-09-05 19:03:16.117747: Debug: DCC: 0x0000 3c 51 20 38 3e 0a <Q 8>.
2022-09-05 19:03:16.117948: Info: DCC: Status von Pin 1 an S88 Modul 2 ist ein
2022-09-05 19:03:16.229052: Debug: DCC: 0x0000 3c 71 20 38 3e 0a <q 8>.
2022-09-05 19:03:16.229263: Info: DCC: Status von Pin 1 an S88 Modul 4 ist aus

Die von RailControl automatisch angelegten Rückmelder bestätigen dies:
Feedback auto added 10/33 (immer rot = belegt) —> Pin 1 an S88 Modul 2 ist immer ein
Feedback auto added 10/65 (immer grün = frei). —> Pin 1 an S88 Modul 4 ist immer aus

Wenn ich pro Modul 16 Eingänge annehme und bei Modul 0 anfange, ist die Zählweise verständlich, wobei ich jedoch nicht verstehe, wieso der von mir definierte Pin 8 auf Arduino-Pin 8 durch RailControl-Eingang 33 UND Eingang 65 abgebildet wird…

Wäre toll, wenn jemand eine Erklärung für mich hätte.

Bis dahin - Detlef

[vikr]

Hallo Detlef,

so wie ich den Log verstanden habe, möchtest Du keine Port-Expander verwenden, sondern ausschließlich die noch freien Pins Deines Arduino.
Mir ist aber nicht klar welchen Arduino Du einsetzt, vermutlich den Mega? Welchen der am Mega durch DCC++EX nutzbaren Pins möchtest Du denn jetzt konkret als Eingänge deklarieren und unter welcher Rückmelder-Nummer? PIN 8 ist sehr ungewöhnlich. Beim Mega würde ich zunächst mal mit PIN 22 als RM 1 starten...

MfG

vik

[teddy]

Hallo Detlef

Danke für deine ausführliche Beschreibung!
Ohne in den Code zu sehen würde ich mal behaupten, dass da noch ein Bug drin ist. Meine Erwartung wäre, dass der Pin 8 am Modul 1 ein und ausgeschaltet werden sollte. Ich werde mir den Code in den nächsten Tagen mal anschauen.

Gruss
Teddy

[_DB_]

Meine Herrschaften - da wart Ihr aber aktiv! Ich habe mir heute einmal alle Beiträge zum Thema genauer angeschaut.

Da ich sozusagen ein Quereinsteiger in dieses Thema bin, habe ich mir einfach mal erlaubt, eine ganz eigene Darstellung zum Thema zu verfassen und nicht auf einzelne Beiträge (so interessant sie auch sein mochten) zu antworten.


Das Ziel sollte sein:
Beliebige Rückmelder auf beliebigen Arduino-Pins in RailControl nutzen - hier am Beispiel Pin22 eines Arduino MEGA

Gegebenes Verhalten von RailControl:
mit jedem Neuanlegen eines Rückmelders wird von RailControl im EEPROM des Arduinos ein weiterer Eingang im Arduino angelegt. Beginnend bei PIN 1 und mit jedem neuen Rückmelder mit aufsteigender Nummerierung ein weiterer. Unabhängig vom im RM angegebenen Anschluß. Darüber hinaus wird für jeden Pin und jeden Zustand des Einganges in RailControl ein eigener Rückmelder angelegt. Und diese fälschlich angelegten Rückmelder werden von allen Eingangs-Pins gemeinsam genutzt.


Was habe ich konkret gemacht?

A
Einen ersten RM in RailControl angelegt. Dieser wird von RailControl im Arduino entsprechend mit der Sequenz <S 1 1 1> im EEPROM des Arduinos gespeichert.

B
Dieser RM wird bei der Konfiguration auf den Anschluß 22 (entsprechend der Arduino-Verdrahtung) gelegt und bleibt in RailControl bestehen. Außerdem wird - nach Beenden von RailControl - der von RailControl fälschlich definierte Eingang Pin 1 des Arduinos gelöscht und mit der Sequenz <S 22 22 1> der Pin 22 über den seriellen Monitor in der Arduino-IDE als Eingang definiert.

Kommentar meinerseits: Bei einem S88-Bus wird von RailControl ja auch nur der verdrahtete Eingang angezeigt - ein Umverdrahten findet nicht statt

C
Der Arduino und danach auch RailControl wird neu gestartet. Das kommentierte Logfile hierzu findet ihr in der angehängten PDF-Datei. In dieser Datei sind am Ende auch meine Diskussionsvorschläge zur Änderung des RailControl-Verhaltens aufgeführt:

1.
 Die Rückmelde-Pins werden in der Arduino-IDE festgelegt. Genau dort wird ja auch entsprechend verdrahtet.
Dies darf m.E. nach nicht in RailControl geschehen.
Das o.g. Beispiel von Pin 3 zeigt deutlich, wohin das führen kann...
Außerdem würde Freiheiten bei der Arduino-Programmierung (eigene Erweiterungen) verloren gehen.
DCC-EX ist eben KEINE Zentrale von der ‚Stange‘.
2.
 Q/q sind lediglich zwei unterschiedliche Zustände H/L des selben Einganges (Arduino-Pins).
Durch die Nummerierung wird der Pin als solches festgelegt.
3.
 Beim Anlegen eines Rückmelders in RailControl sollte die Pin-Nummer bei ‚Anschluss‘ angegeben werden,
dann kann RailControl die Meldung vom Arduino korrekt interpretieren.
Die Rückmelder in RailControl sind also entsprechend der Verdrahtung des Arduinos zu parametrieren.

Ich bin sehr gespannt auf Eure Antworten hierzu - einen schönen Abend noch und - viele Grüße aus Herne - Detlef

[vikr]

Hallo Detlef,

DCC++EX ist ein Programm mit einer Schnittstelle zur Bedienung und Konfiguration.
DCC++EX stelt dazu ein dokumentiertes Kommandozeilentool zur Verfügung.
Einige Einstellungen können im EEPROM gespeichert werden und DCC++EX wird beim nächsten Start dann automatisch entsprechend so konfiguriert. Die Konfiguration der "freien" Pins als Ausgänge oder Eingänge ist sehr flexibel. Welche Pins "frei" sind hängt vom Arduino ab. Wie die Pins auf Port-Expandern angesprochen werden hängt vom eingebundenen Portexpander ab.
Auch Anwenderprogramme, die DCC++ nutzen, können die Konfigurationsdateien lesen und auch im EEPROM abspeichern. Sie sollten das alle exakt genauso machen, wie DCC++EX selbst.

MfG

vik.

[teddy]

Hallo vik

Ich habe im Code noch ein paar Änderungen vorgenommen. Stimmt das nun mit deiner Erwartung überein?

Gruss
Teddy

[_DB_]

Hallo vik, hallo Teddy,

@vik: ich bin - ehrlicherweise - mit DCC-EX noch nicht wirklich vertraut. Daher habe ich einfach ganz pragmatisch den damaligen IST-Zustand bzgl. der Zusammenarbeit mit RailControl beschrieben und daraus den meiner Meinung nach sinnvollen SOLL-Zustand beschrieben bzw. angeregt.

Ob der nun DCC-EX-konform ist, kann ich momentan noch nicht beurteilen, aber diesen SOLL-Zustand hat Teddy meinem Empfinden nach zu 100% umgesetzt. Damit kann ich sehr komfortabel arbeiten!

In der kommenden Woche werde ich meine DCC-EX-CommandStation über Ethernet- und Wifi-Anbindung an RailControl anbinden. Bin schon gespannt.

Gerne möchte ich auch mit Port-Expandern arbeiten, aber das habe ich noch hinten angestellt. Für meine kleine LGB-Bahn genügen die ca. 30 Pins des Mega's für Ein-/Ausgänge vollkommen. Aber ich würde ggf. gern auf Dich zurückkommen, wenn's recht ist.

@Teddy: Super! vielen Dank!

Viele Grüße aus Herne - Detlef

[vikr]

Hallo Teddy,

Ich habe im Code noch ein paar Änderungen vorgenommen. Stimmt das nun mit deiner Erwartung überein?

vielen Dank! Ganz schnell werde ich leider nicht zum Kompilieren und anschl. Testen kommen.
Natürlich ist es bequemer die Konfigurationsdaten aus dem Anwenderprogramm heraus ins EEPROM schreiben zu können, als mühsam per Kommandozeile aus der Arduino-IDE eintippen zu müssen. Die Idee ist ja, dass man seine (ein und dieselbe) Anlage mit ein und demselben fertig konfiguriertem Arduino und DCC++EX, jeweils abwechselnd mit JIMRI, Rocrail, Win Digipet und RailControl einsetzen kann, ohne - beim Wechsel von einem zum nächsten Anwenderprogramm - an den im EEPROM hinterlegten Einstellungen etwas ändern zu müssen, weil sie eben das EEPROM alle exakt so wie DCC++EX selbst beschreiben....

MfG

vik

[_DB_]

Hallo vik,

irgendwie verstehe ich Dich noch nicht.

Meine Vorgehensweise ist grob gesagt doch die:
1. ich erstelle ein Layout der Modellbahnanlage (konkret nutze ich hierzu RailModeller auf dem Mac)
2. ich erstelle ein Layout der Hardware (hier nutze ich konkret Fritzing, auf dem Pi4 und auf dem Mac)
3. ich programmiere den Arduino (vorzugsweise über die Arduino-IDE auf dem Pi4 oder auch auf dem Mac)

Jetzt habe ich einen Arduino gemäß dem Fritzing-Schaltplan verdrahtet und über die Arduino-IDE programmiert vor mir liegen.
Über die Befehl <S 22 22 1> habe ich in der Arduino IDE (mit der ich ja auch den Arduino erst einmal befüllen MUSS) den Pin22 als Eingang für einen Rückmelder verdrahtet, an dem z.B. eine Lichtschranke hängt.

Dann starte ich RailControl - egal ob ich schon einen Gleisplan hinterlegt habe, oder ganz frisch beginne. Sobald sich an diesem Rückmelder etwas ändert, erkennt RailControl jetzt direkt diesen Rückmelder und arbeitet damit.

Was ist daran falsch oder nicht richtig?

Selbst wenn ich vorher mit irgendeinem anderen System wie Digipet oder so gearbeitet habe, muss doch eine Konfiguration mit <S 22 22 1> irgendwie erfolgt sein. Das würde mein Schaltplan und mein Gleisplan ja voraussetzen. Beim S88-Bus wird ja auch gemäß Schaltplan verdrahtet und die Software ändert daran nichts mehr (wäre ja noch schöner!).

Und diese gegebene Konfiguration wird RailControl aktuell nicht mehr verändern und einfach nur nutzen - wie oben bereits beschrieben. Irgendwie verstehe ich Deine Einwände noch nicht. Ich glaube, Du testest erst einmal die aktuelle RailControl Version und dann verstehst Du mich vielleicht besser.

Vielleicht noch etwas zum Verständnis meiner Auffassung zur Hardware: Ich hasse Materialschlachten. CANguru lässt grüßen!

Meine Vorstellung ist es, mit möglichst wenigen Programmen (und idealerweise mit OpenSource-Programmen (und noch besser mit OpenSource-Software auf OpenSource-Hardware)) zu arbeiten. Und wenn ich mit der Programmierumgebung des Arduinos gemäß des Schaltplans auch die IO-Pins definiere, ist das doch optimal, oder?

Und mit allen o.g. Systemen läuft sowohl die Arduino-IDE als auch RailControl wirklich einwandfrei. Ich habe halt irgendwie einen Hang zum Minimalismus, was sich aber auf den Arbeitskomfort nicht auswirken darf! Der Workflow muss schon stimmen!

Hoppla - jetzt gerate ich ins 'philosophieren' - aber ich wollte Dir halt etwas darüber mitteilen, wie ich die Dinge so sehe.

Um Dich besser zu verstehen, wäre es prima, wenn ich auch Deine Ansichten dazu etwas näher kennenlernen könnte.

Viele Grüße aus Herne - Detlef


Ach ja - und ganz aktuell auch noch etwas zur Energie-Effizienz:
mittlerweile starte ich meinen PC überhaupt nicht mehr, wenn es um den Modellbau geht. Denn wenn ich auf den Leistungbedarf eines typischen PC's schaue, wird mir wirklich übel: Mein i5-PC verbrät schon im Leerlauf etwa 3x soviel Energie wie mein MACmini unter Arbeitslast (<20 Watt) und etwa 12x soviel Energie wie man Raspberry Pi 3 (<5 Watt), ebenfalls unter Arbeitslast. Immerhin, das 500W-Netzteil ist ja für die vorhandene 3D-Grafikkarte eingebaut, und wenn ich die 3D-Grafikkarte nicht nutze, hat's halt einen energetischen Totalschaden - der Monitor mit seinen 30W kommt ja in jedem Fall noch dazu!

[vikr]

Hallo Detlef,

Du kannst das selbst testen. Wenn RailControl das genau so macht, wie von DCC++EX vorgesehen, kannst Du über RailControl die gewünschten Sensor-PINs festlegen und sie Dir anschließend mit dem DCC++EX-Kommandozeilentool wieder im Monitor der IDE, anzeigen lassen.

Alles andere scheint mir eher OT.

MfG

vik

[_DB_]

Hallo vik,

ehe ich's später vergesse: was genau meinst Du mit OT?

Wenn ich Dich richtig verstehe, dann sollte jede Software wie RailControl, WinDigiPet usw. die gewünschten Funktionstypen eines Arduino-Pins festlegen können.

Das würde ich grundsätzlich auch begrüßen. ABER

ich gehe mal von einem - sicher auch in der Praxis - sinnvollen Workflow aus:

1. die Planung - Übersichts- und Detailplanung:
mit Hilfe von Tabellen und/oder einem Gleisplan-Programm (in meinem Fall mit RailModeller erstellt)

2. die Umsetzung des Plans in die konkreten Gleistrassen und daran angebundenen Funktionalitäten:
mit Hilfe eines Schaltplans (in meinem Fall mit Fritzing einfach und änderbar erstellt)

3. die Programmierung und Konfiguration des Steuerungsrechners (in unserem Fall die Arduino-IDE)
mit Programmierung meine ich konkret die Programmierung des Arduinos:
mit dem EX-CommandStation-Programm, ggf. auch mit EX-Rail oder auch einer eigenen Programmerweiterung,
mit Konfiguration meine ich konkret die Definition der Arduino-Pins:
welche Pins werden von EX-CommandStation oder auch EX-Rail genutzt (die sollte ich tunlichst nicht anfassen),
welche Pins stellen Ausgänge zum Schalten von Weichen und/oder Zubehör dar (s. Punkte 1/2 oben)
welche Pins stellen Eingänge z.B. für Rückmelder dar (s. Punkte 1/2 oben)

4. die Steuerung der Züge und sonstigen Abläufe auf der Modellbahn und Visualisierung dieser Abläufe (Weichen/Signale/Zugbewegungen):
läuft auf einem Leitrechner mit Monitor und/oder
verteilt auf einem Leit- und einem oder mehreren Visualisierungsrechnern

Während ich den obigen Workflow beschrieben habe, bin ich mir sehr sicher, daß - in der Reihenfolge von 1 nach 4 - grundsätzlich Änderungen an der Hardware und Konfigurationen der Hardware einer Modellbahnanlage durchzuführen sind.

Alles andere (von 4 nach 3 zurück nach 4 und weiter über 2 nach 1 oder wie auch immer) führt meines Erachtens lediglich zu einem Zustand 'quick and dirty' (was habe ich da noch vor 2 Jahren doch gleich noch gemacht?!? und warum eigentlich?).

Und noch abschließend eine Frage an Dich bzw. Teddy, die ich mir noch nicht beantworten kann:
Wie soll RailControl denn überhaupt mitbekommen, wenn ich als Nutzer einer weiteren Leitrechner-Software wie z.B. WinDigiPet eine Umkonfiguration von Eingangspins am Arduino vorgenommen habe?

Änderungen irgendwelcher Art sind doch immer in die anderen Bereiche manuell nachzuführen, oder liege ich da total falsch? Und dann sollte man doch grundsätzlich oben anfangen und unten aufhören - top down, oder?

Als Neueinsteiger in den Bereich Modellbahn und ganz besonders in den Bereich DCC-EX würde ich mich freuen, Deine Meinung darüber zu erfahren.

Ich werde jetzt mal versuchen, den Arduino (die DCC-EX-Zentrale) von RailControl über das Netzwerk anzusprechen. Dazu werde ich dann erst einmal ein Ethernet-Interface für den Arduino integrieren. Hoffentlich gelingt's... drück mir die Daumen!

Viele Grüße aus Herne - Detlef

[vikr]

Hallo Detlef,

es wird wohl leider ein Weilchen dauern bis ich selbst die Sensorkonfiguration mit der aktuellen RailControl- Version testen kann...

OT steht für Off Topic . Gemeint ist, dass viele der Infos etws außerhalb des eigentlichen Thread-Focus liegen.

MfG

vik

[teddy]

Hallo Detlef

DCC-EX bietet wie sein Vorgänger die Möglichkeit, die programmierten Sensoren auch wieder auszulesen. Damit kann man mit einer Software die Sensoren erfassen und nutzen. Sie können dann auch ins EEPROM gespeichert werden. Dann kann man eine Andere Software nehmen und die schon gespeicherten Sensoren auslesen und weiternutzen.

Nun stellt sich die Frage: Wie oft wechseln Modellbahner ihre Zentrale? Jeden Tag? Jede Woche? Jedes Jahr? Nie?

vik möchte die Zentrale dauern wechseln und einfach weiterarbeiten können. Ohne etwas fummeln zu müssen.

Ich glaube er ist damit eine Ausnahme.

Ich habe deshalb am Anfang den Weg gewählt, dass RailControl die konfigurierten Pins gleich selbst programmiert. Zusammen mit der automatischen Erfassung der Pins ist das eine schlechte Idee.

Da es offenbar ein dezidiertes Tool gibt für die Erfassung der Sensoren, habe ich das Speichern in RailControl unterlassen. Es ist somit zwingend nötig das alternative Tool zu verwenden.

Möglich wäre - wenn auch mit viel Aufwand - dass die Funktion des externen Tools in RailControl nachgebaut wird. Quasi dass RailControl die gespeicherten Daten übernimmt und genau so verwendet und man diese auch gleich freizügig bearbeiten könnte.

Ich bleibe im Moment noch dabei, dass RailControl halt auf das externe Tool angewiesen bleibt. Aber wenn jemand möchte, kann er/sie gerne entsprechenden Code zu RailControl beitragen.

Gruss
Teddy