THEMA: Z21 Simulator

Hallo Vincent,

whow! Zu den Busanbindungen:

Ohne extra Hardware ist eigentlich nur LN-over-IP möglich, was auch WLAN-Loconet ermöglicht. Für physisches LN braucht man einen Locobuffer (seriell oder USB-VCOM). Noch etwas schwieriger ist die Anbindung an einen physischen X-BUS oder R-BUS, das ist beides eine RS-485 mit 9-Bit Protokoll.
Ich weiß nicht wie es bei Linux ist, aber Windows kann das nicht, da geht nur 8-Bit Datenübertragung mit dem Trick dass man 8 Bit+Parity einstellen kann (even oder odd) und die Paritätsfehler auswertet, das gilt sowohl für HW-COM als auch für V-COM. Anscheinend kann das selbst der FTDI Treiber nicht, also müsste man einen Dongle mit einer VCOM-fähigen MCU bauen (ATmega32U, PIC18F1xx5x, ESP32, etc.).

Grüße, Peter W.

Grüß dich Peter

Öhm, soweit vorgedacht gedacht hab ich ehrlich gesagt noch nicht. Ich implementier das Z21 Protokoll grad quasi on-demand parallel zu meinem Projekt dazu. In meiner Naivität hätte ich die Bus-Geräte für den Simulator schlichtweg "gemocked", so wie dies ja aktuell für die Loks und Weichen auch passiert.

Wichtig war mir in erster Linie zu lernen wie die ganze Kommunikation abläuft und wie die App reagiert. Und da hilfts einfach enorm mal eben so Nachrichten wie "einen Kurzschluss" raushauen zu können. :p

lg
Vincent

Servus  Vincent,

war ja auch nur als Info gedacht dass Du für Dich die "Weichen" im Programm richtig stellst. Ich hab auch ehrlich gesagt keine Ahnung wie genau die Z21 den XBus auf LN übersetzt und vice versa. Mocken ist natürlich einmal der richtige Ansatz, wenn Du weißt auf welche Befehle die reagieren?
Speziell bei LN hat man ja immer das Problem mit den Kommandos die nicht in der öffentlichen Doku aus der Personal License von Digitrax stehen, wie z.B. F12-F31 etc. Dazu gibt es lauter proprietäre Uhlenbrock Extensions under NDA. Ich lese oberflächlich bei der Loconet Hackers Google Group mit, da ist das Thema Nr. 1 eigentlich immer "unbekanntes Kommando" und meist lautet die Antwort: Schau in den Source von JMRI ob Du es findest. Erst kürzlich ging es glaube ich um F-Tasten Gruppen wo die Daisy anscheinend wieder mal was anders macht.
Insoferne kann ich z.B. Piko verstehen dass die auf Dritte pfeifen und den ganzen Krams nocheinmal from scratch entwickeln. Wenn man sich da hinein tigert, verbrennt man so viel Zeit...

Grüße, Peter W.

Ah super, Danke für die Info und die Vorwarnung!

Ich weiß eh noch nicht wann ich da dazu kommen werd. Die für mich aktuell wichtigsten Teile hab ich mal implementiert. Jetzt fehlt noch ein Haufen Doku... Den Rest mach ich dann wenns mich juckt oder halt Bedarf besteht. Aktuell hat das Projekt für dass ich die Implementierung eigentlich geschrieben hab nämlich noch gar keine Bus Anbindung. :)

Wenn man sich bilden will kann man bei folgenden Quellen über LocoNet schlau(er) werden:

* JMRI Source

* RocRail Source aus der dessen Zeit vor Closed Source

* Hans Tanner's source vom IoTT projekt (etwas schwer zu finden aber tief in den Gedärmen von GitHub war da was)

* pgathow z21 (da ist die Linzenz allerdings so dass man da nix direkt übernehmen will)

Ich seh mir das mit deiner Z21 bestimmt noch genauer an, aber ich hab gerade etwas viele Projekte....

Der einzige Grund LocoNet/HW zu unterstützen ist dass viele Leute schon einiges an Geld in Handkontroller für den Bus versenkt haben und gewisse auch haptisch recht gut sind (was allerdings nicht für das Digitrax Standardbrett gilt) oder eben "der Standarkontroller FRED".

Grüße,
Harald.

Version v0.3.2 ist online:
https://github.com/ZIMO-Elektronik/Z21/releases/tag/v0.3.2

- Diverse Bugfixes rund um den bunten Misch-Masch aus big und little endian Adressen
- Einstellbare Quality-of-Service Fehlerrate

Hallo,



Nicht nur. Ich z.B. experimentiere gerade mit Z21 (schwarz) und dem Track-Control Stelltisch, m.W. die einzige Lösung auf dem Markt wo man ohne Kabelsalat und riesigen Kosten einen haptisch ansprechenden Stelltisch zusammenbekommt.

Nachdem das ein Uhlenbrock-Produkt ist, hängt er natürlich am Loconet. Aus Platzmangel hab ich vorübergehend anstelle des echten Stelltischs als Notnagel ein IB-Control I an der Z21 hängen. Aber es geht ja im Moment hauptsächlich darum, ob die Uhlenbrockteile mitkriegen was sie anzeigen sollen und das geht damit auch ganz gut.

Momentaner Kenntnisstand:

- Loconet-Zugnummernerkennung funktioniert mit Roco 10808 und wird sauber am IB-Control angezeigt (10808 natürlich am CAN-Bus, am R-Bus gehts nicht)
- Loconet-Belegtmeldung ist nicht ganz so stabil, beim Strom einschalten fehlt sie, erst bei Änderungen sieht man was
- Belegtmeldung mit Roco 10819 bringt nichts, kommt nicht am Loconet an
- Nachdem ich bei meinen alten 63340 etwas Bauchweh habe wegen der Massebrücke im Uhlenbrock Loconet, hab ich derzeit die Module x016LN-CS und x016-ES von duweisstschonwem in Erprobung. Das LN hängt direkt im Z21 Loconet und meldet einwandfrei auch gleich nach dem Einschalten.

Momentanes Fazit: Wenn ich noch eine Möglichkeit finde, beim Einschalten die Belegtmeldung der 10808 abzufragen, wäre das eine stabile Lösung. Wünschenswert wäre natürlich einen 16-fach Rückmelder mit Railcom zum Preis des 10808 zu finden, die aber immer noch deutlich billiger ist, als einen MarCo in jeden einzelnen Block zu hängen. Der müsste eben nur die proprietären UB Lissy-Messages senden, damit die Uhlenbrockteile die Adresse auch anzeigen. Da sehe ich außer Roco im Moment nichts.

Aber das wird jetzt zuviel. Eigentlich wollte ich nur sagen "Es geht nicht nur um Handregler".

Gruß,
Helmut

Hallo Vincent,

auf jeden Fall ein interessantes Projekt. Ich habe eine selbstgebaute Z21-ESP32 im Einsatz, basierend auf Z21PG. Es wird LAN, Railcom, S88, Temperatursensor Dallas und Programmiergleis unterstützt.. Ich kann mich über WLAN mit der Z21 mobile App verbinden. Die App erkennt allerdings, dass es sich nicht um eine von Fleischmann gefertigte Zentrale handelt und begrenzt die Nutzung auf eine Loks. Kennst du dieses Verhalten?

Gruß
Andre

Grüß dich

Ja das Verhalten kenn ich, es wurde als ROCO damals Anfing die App für Dritthersteller einzuschränken auch eifrig hier im Forum diskutiert. Ich halte dieses Verhalten allerdings für legitim.

Wenn ich mir etwas wünschen könnte dann wäre es eine gratis Lizenz für nicht-kommerzielle Selbstbauten, allerdings ist es wohl utopisch das irgendwie umzusetzen und zu kontrollieren.

lg
Vincent

Mit etwas Glück findet man im Netz noch eine ältere Version der Z21 App, die dieses Verhalten noch nicht kannte. Natürlich verbietet sich dann die Andorid Update Funktion. Alternativ kann man über eine Gebühr auch die volle Funktionalität wieder freischalten.

Hallo Vincent und Uli,

danke für eure Info. Da kann man dann wohl nicht viel machen. Ist aber auch nicht so schlimm, da alles andere funktioniert.

Gruß
Andre

Wenn es die App erkennt ist die Simulation nicht gut genug könnte man sagen.

Ja, lang darüber diskutiert. Der Mechanismus ist auch in der Protokollspezifikation nicht erklärt, also entspricht die App nicht der Spezifikation oder andersrum.

Für den Preis (mehr als viele vergleichbare Apps) den man bezahlt um die App für Drittzentralen anwenden zu können würde ich mir dann erwarten dass man dafür auch Support bekommt. Wenn man das Kleingedruckte liest aber Pustekuchen.

Es gibt ältere Versionen bei APK Pure, die sind so weit ich weiß auch nicht mit einem Updatezwang versehen, zumindest bis jetzt noch nichts davon gehört oder bemerkt.

Grüße,
Harald.

Version v0.3.3 ist online:
https://github.com/ZIMO-Elektronik/Z21/releases/tag/v0.3.3

- Bugfix für das absolut irre Format der Zubehördecoder-Adressen für die POM Lese/Schreibbefehle

Hallo Vincent,

Warum aber nicht gleich auch für den Mac ?


Beste Grüße

Randy

Hallo Randy

PRs werden gerne entgegen genommen.

lg
Vincent

Wie compiliert man eigentlich mit gcc für MacOS auf einer anderen Plattform?

Grüße, Peter W.

Via Docker und z.B. GitHub Actions, bzw lokal via nektos/act.
Ich hab von OSX aber nicht den Hauch einer Ahnung, deshalb lass ich das.

Version v0.3.4 ist online:
https://github.com/ZIMO-Elektronik/Z21/releases/tag/v0.3.4

- Bugfix Zubehördecoder-Adress Format war immer noch falsch...

Version v0.3.8 ist online:
https://github.com/ZIMO-Elektronik/Z21/releases/tag/v0.3.8

- Docker und OSX Support
- Undokumentierte CV Befehle der WLAN Maus hinzugefügt
- Workaround für Checksummen Fehler der WLAN Maus

Hallo Vincent,

cool. Habe es gerade heruntergeladen. Das erleichtert mir den Test mit meinem WLAN-Regler FRANKYmini (s.a. Chat) und ich sehe auch gleich, was er sendet (statt das Ergebnis an meiner DR5000 zu beobachten).

Vielen Dank!

Viele Grüße
Frank

Ich nochmal. Nun hängt der Simulator. Gerade noch hat er funktioniert, nun jedoch - auch nach seinem Beenden und Neustart inkl. Clear Data, kann man nur das Hilfefenster auswählen, jedoch keinen der Tabs (um bspw. einen Nothalt zu simulieren). Woran könnte das liegen, Vincent?

Viele Grüße
Frank

Edit: Gut, ich sehe nun, dass der Client sich verbinden muss, sonst läuft der Simulator nicht. Verstanden.
Edit 2: Darf ich zu "Undokumentierte CV Befehle der WLAN Maus hinzugefügt" fragen, welche das wären?
Wenn ich deinen  z21sim nehme und eine WLAN-Maus anhänge, sendet die für CV-Prgr. CV3=3
LAN_X_CV_WRITE_ALT  24 16 00 02 03 00 (gut, _ALT ist dein Zusatz wohl für Alternative)
während ich sende
LAN_X_CV_WRITE         24 12 00 02 03 7D (gemäß X-Bus-Protokoll v1.13).
Ist also 24 16 ein Beispiel für deine Aussage undokumentierter Befehle? Da jedoch meine DR5000 das auch versteht, wäre das vielleicht undokumentiert aber offenbar nicht unbekannt ...