[Spatzlosti]

Liebe Modellbahn-Experten,

Ich habe ein Problem mit den Belegtmeldern und deren Anzeige im Z21 APP und in WinDigipet. Wenn ich die Systeme einschalte, werden die belegten Gleisabschnitte nicht als belegt angezeit.

Meine Anlagekonfiguration ist die folgende: H0, DCC, Z21 mit Router, DR4088LN-CS, Z21 APP, WinDigipet 2018

Detailbeschreibung des Fehlers:

1.Ich starte als erstes das System Z21 und den Router
2.An den Belegtmelder DR4088LN-CS blinkt die grüne Betriebslampe
3.An denjenigen Belegtmelder DR4088LN-CS wo ein Gleisabschnitt mit einer Lok belegt ist, flackert die rote Lampe (sie zeigt an, dass mindestens an einem der 16 Belegtabschnitten eine Belegung vorliegt)
4.Ich starte das Z21 APP auf dem IPAD und gehe auf das Gleisbild wo die belegten Abschnitte angezeigt werden sollte. Es wird kein belegter Gleisabschnitt angezeigt. Die Loksteuerung z.Bsp. «Fahren» funktionieren normal
5.Ich starte WinDigipet mit der Anlageversion. Die Verbindung zur Z21 wird grün angezeigt. Die normalen Funktionen wie Loksteuerung funktionieren normal. Auch auf diesem Gleisbild wird keine Belegung der belegten Gleisabschnitte angezeigt.
Aus meiner Sicht sollte doch beim Starten des Systems die korrekte Anzeige in den Systemen erfolgen. Auch für die Steuerung ist das elementar, weil sonst die Sicherheit nicht gewährleistet ist.

Workaround/Übergangslösung:
Beheben kann ich die Situation indem ich einer der folgenden Punkte ausführe:
Variante 1: An der Z21 die Notstop Taste 2x drücken (Not Ein/Not Aus) > dann wird sofort im APP und in WinDigipet die Gleisbelegung angezeigt
Variante 2: In WinDigipet trenne ich die Verbindung zur Z21: Verbindung Trennen und neu initialisieren > dann wird sofort im APP und in WinDigipet die Gleisbelegung angezeigt

Fehlersuche
Bei der Fehlersuche habe ich eine einfache Testumgebung mit 2 Belegtmeldergleise aufgebaut: Ich habe dank meinem Fachhändler alle Geräte (Z21+Router/Belegtmelder/Kabel) leihweise von einer Demoanlage austauschen können. Der Fehler war immer noch derselbe.

Vermutung Fehler war nicht immer, erst durch Firmware update der Z21 neu entstanden?
Ich bin mir nicht 100% sicher, aber ich bin der Meinung, dass das nicht immer so war. Ich vermute, dass bei einem der letzten Firmware upgrade 1.32/1.33 der Z21 an der Loconet-Schnittstelle etwas verändert wurde.

Meine Frage an Experten im Forum
1. Ist das Thema auch einem von Euch in der gleichen Form bekannt?
2. Welche Systemkonfiguration habt ihr im Einsatz?
3. Gibt es auch Anlagen mit der gleichen Konstellation, wo der Fehler nicht auftritt
4. Gibt es Empfehlungen zur Systemkonstellation/andere Produkte usw.


Gruess Ruedi

[Draisine]

Hallo Ruedi,

Dein Beitrag ist zwar schon knapp 3 Monate alt (ich sehe gerade + 3 Jahre, oh Gott, das grenzt ja schon an Leichefledderei) und ich weiß nicht ob Dein Problem mittlerweile behoben ist. Es gibt hierzu leider keine Antworten. Per Zufall bin ich auf den Beitrag gestoßen. Ich habe zwar keine Z21, nutze aber dennoch die Z21App und auch die besagten Belegtmelder als LN und auch als S88 von Digkeijs und auch von YAMORC. Der Unterschied, ich nutze eine DR5000 mit Upgrade DR9401 von YAMORC.

Da ich derzeit an der Konzeption eines Gleisbildstellpults unter Verwendung der beschriebenen Belegtmelder auch mit direkter Abfrage und Ansteuerung des Loconets dran bin, stellt sich für mich auch die Frage nach der Abfrage der Belegtmelder-Stati. Hierzu habe ich verschiedene Test durchgeführt.

1. Test Einschalten der Zentrale, Power-ON, gilt auch nach Nothalt):
Der Belegtmelder-Monitor der Zentrale zeigt die aktuellen Belegtmeldungen ordnungsgemäß an

2. Starten der Z21App nach bereits erfolgter Einschaltung der Zentrale:
Die Z21App zeigt die aktuellen Belegtmeldungen ordnungsgemäß an

3. Prüfen der Belegtmeldung über Auslesen der Loconet-Informationen:
Ist die Zentrale bereits eingeschaltet und hochgefahren, werden nach Einschalten meines Loconet-Adapters und Abfrage der Status-Meldungen keine Informationen über das Loconet übertragen.
Erst wenn ich die Zentrale einschalte, etwa durch drücken von Power-On, wird der Status abgefragt und Meldungen werden angezeigt.
Gleiches gilt für einzelne Melder, sollte sich deren Zustand ändern. Ich gehe davon aus, daß Zustandsänderungen zu einem Event auf dem Loconet-Bus führen, den ich per Programm abfange und anzeige.
Füge ich vor Abfrage in der Programmschleife ein Power-ON-Signal ein (Loconet OP-GPON), so führt dies im Zusammenhang mit der verwendeten Zentrale immer zu einer Gesamtabfrage der Status-Meldungen, auch wenn diese sich vorher nicht geändert haben. Dann werden die Belegtmeldungen auf meinem Programm-Monitor ebenfalls richtig angezeigt.

Auf gut deutsch gesagt, bei mir funktioniert das Ganze mit der Besonderheit nach Punkt 3. Entspricht in etwa dem dem was Du als Workaround beschreibst.

Aufgrund der verwendeten, unterschiedlichen Zentralen sind die Ergebnisse nicht 1:1 übertragbar. Es zeigt allerdings, daß die DR4088LN-CS (LN), DR4088-CS (S88N) als auch die YAMORC-Pendants YD6016LN-CS (LN) und YD6016ES-CS (S88N) richtig funktionieren auch oder insbesondere auch mit der Z21App. Es zeigt sich bei meinen Tests aber auch, daß bei den LN-Signalen nur Änderungen der Stati angezeigt werden, sofern keine Gesamt-Statusabfrage durch die Zentrale oder möglicherweise auch durch die Z21App angetriggert werden.

Ich denke, daß Dein Problem nicht bei verwendeten Belegtmeldern, sondern bei der Z21 zu suchen ist bzw. deren neuester Firmware. Meine Vermutung. Da diese Zentrale häufig im Einsatz ist und als ausgereift gelten sollte, wundert es mich, daß bislang keine Antworten auf Deinen Beitrag erfolgt sind.

Also richtig weiterhelfen kann ich Dir mit meinen Antworten nicht, außer daß die Belegtmelder bei meiner Konfiguration inkl. Z21App funktionieren.
Ich meine aber irgendwo gelesen zu haben, daß Roco einen Hinweis gegeben hätte, daß die verwendete Kombination mit Z21 und Digikeijs-Belegtmeldern bei der neueren Firmware der Z21 zu Problemen führen kann. Oder besser gesagt nicht funktioniert. Warum auch immer.

Aufgrund des Alters Deines Beitrags, was ich erst gesehen habe nachdem ich die Antwort bereits formuliert und eingestellt habe, kann das Problem natürlich auch ein Software-Problem bei der Z21App gewesen sein, was mittlerweile längst behoben ist. Vielleicht kannst Du ja mal eine kurze Rückmeldung geben, ob Dein Problem behoben ist und was die Ursache war. Wäre nett. Danke

Grüße Thomas

[a-zett]

Probleme mit DR4088, wenn es sich um viele handelt, sind länger bekannt (suche nach Interrogate hier im Forum). Länger als der Thread alt ist. Die Firmware hat damit nichts zu tun, ihr Update hilft dabei auch nicht.

Mein Firmware-Update vor ein paar Monaten allerdings führte zu gravierenden anderen Problemen. Das würde ich nie wieder tun, zumal es keinen Weg zurück gibt. Jetzt führt jeder einzelne Programmierschritt aus der App dazu, dass die Z21 nicht mehr reagiert und neu gestartet werden muss. Die App und der PC mit TC dann aber auch und das Handy muss natürlich wieder ans WLAN, denn das ist ja dann aus. Programmiert werden kann nur noch im Maintenance Tool, das aber lange Adressen nicht unterstützt und daher umständlich und dazu ortsgebunden ist. Sobald ich eine Adresse festgelegt habe, verwende ich daher nur noch POM, aber da kann ich nicht auslesen. Auch ist es vorher nie passiert, dass Doppeltraktionen nach dem Neustart nicht mehr anfahren können, bevor man sie getrennt und wieder gebildet oder die Loks gar einzeln angefahren hat.

Never touch a running system!

[moppe]

Zitat von a-zett im Beitrag #3

---

Mein Firmware-Update vor ein paar Monaten allerdings führte zu gravierenden anderen Problemen.

---

Wer du nicht selber wünscht zu herausfinden was los ist.

Zitat von a-zett im Beitrag #3

---

Das würde ich nie wieder tun, zumal es keinen Weg zurück gibt.

---

Das ist nicht korrekt. Du kannst immer deiner Z21 ein ältere firmware Version geben.


Klaus

[ludwig2020]

Hallo,

Zitat von moppe im Beitrag #4

---

Das ist nicht korrekt. Du kannst immer deiner Z21 ein ältere firmware Version geben.

---

hier der Beweis dazu, Auszug aus Mail als die Z21 noch massive Probleme hatte

Zitat

---

...falls dies für Sie in Frage kommt: Wir könnten Ihnen die Beta-Version V 1.25 zum Test anbieten (notfalls können Sie jederzeit mit dem Maintenance-Tool wieder auf V 1.24 zurückkehren!

---

[a-zett]

Ja, wenn man eine Version weiterdreht, aber nicht, wenn es viele auf einmal sind. Der funktionierende Stand war fünf Jahre alt.

Aber wer meint, er hat das im Griff: Bitte gerne. Wer sich da nicht sicher ist, lässt es besser.

[Draisine]

Ich wollte jetzt hier nix lostreten, Zumal das Thema eh schon alt ist, was ich aber erst im Nachhinein gesehen habe. Und möglicherweise mittlerweile auch schon erledigt ist.

So wie ich das interpretiere lag das Problem an der Z21. Oder zumindest an der Kombination mit den besagten Belegtmeldertypen?

Weil bei mir funktioniert das bei meiner Konfiguration einwandfrei, bis auf den beschriebenen Punkt 3, der allerdings auch nicht so ganz herstellermäßig vorgesehen ist.
Ok, habe in meiner Testkonfiguration aber auch nicht viele DR4088 dran. Was ich aber dennoch sehen kann, ist, daß beim Hochfahren der Zentrale ein Feuerwerk an Meldungen kommt, die über das LN laufen. Konkret 64 Meldungen aus vier Belegtmeldern (1 x 4088LN-Cs daran 3 x DR4088CS S88N und 1 x YD6016-ES-CS am S88N-Bus der Zentrale. Ich denke allerdings, daß das bei anderen Bus-Systemen ähnlich ist. Das findet allerdings nur 1 x während des Hochfahrens statt. Danach ist Ruhe auf dem Bus und es wird nur noch gemeldet, wenn sich was ändert.

Grüße Thomas

[a-zett]

Wenn die Belegtmelder mehr werden, wird das Loconet überlastet. Wenn es nicht möglich ist, das "Feuerwerk" zeitlich zu entzerren und die Belegtmelder irgendwann aufhören zu senden, fehlen dann Meldungen. Die Z21 hat damit nichts zu tun. Wie hast du dieses Feuerwerk messen können? Welcher Monitor zeigt dir das?

[Draisine]

Ich habe das Feuerwerk nicht gemessen, sondern mir die Events anzeigen lassen. Feuerwerk ist vielleicht auch etwas übertrieben, es sind in meinem Fall halt 64 Meldungen active/inactive die beim Einschalten gelesen werden. Anschließend nur noch Event-abhängig. Aber selbst bei 500 Meldungen sollte das LN nicht zusammenbrechen. M. W. verwendet LN eine asynchrone Übertragung mit Handshake und Paritätsprüfung. Also daß dabei Meldungen verschluckt werden kann ich mir nicht vorstellen.
Es könnte natürlich sein, da die Zentrale beim Starten soviel Informationen liefert bzw. anfordert, daß das LN damit beschäftigt ist und keine weiteren Datensendungen möglich sind. Das war m. W. eines der Probleme bei der DR5000 bei hoher Anzahl von Meldern. Das ist aber m. E. kein Problem des LN sondern wie die Zentrale die Daten verarbeitet. Und wie das LN in der Zentrale umgesetzt wird, d. h. adaptiert ist. Bei der DR5000 mit Upgrade und komplett neu geschriebener Yamorc-Firmware soll dieses Problem angeblich nicht mehr bestehen. Die Z21 könnte allerdings dasselbe Problem haben bzw. auch gehabt haben. Das ist aber eigentlich nicht mein Thema.

Mein Aufbau Arduino mit LocoNet-Shield und angepasstem Monitor-Sketch in eigenem Stellwerk-Programm (im Aufbau). Ich habe geprüft unter welchen Bedingungen die Meldungen kommen, da ich diese weiterverarbeiten möchte. Auch dann, wenn die Zentrale bereits läuft und ich anschließend mein Hardware-Stellwerk einschalte. Da habe ich nämlich genau das beschrieben Problem, daß die Belegtmelder nicht neu gelesen werden. Außer ich sage das dem LN, z. B. mit Spannung an oder Weiche schalten (muß ich noch testen). Deswegen auch mein Interesse und die Antwort auf den Eingangsbeitrag.

Grüße Thomas

[Instandsetzung]

Hallo zusammen,

Zitat von Draisine im Beitrag #9

---

. . . Es könnte natürlich sein, da die Zentrale beim Starten soviel Informationen liefert bzw. anfordert, daß das LN damit beschäftigt ist und keine weiteren Datensendungen möglich sind. Das war m. W. eines der Probleme bei der DR5000 bei hoher Anzahl von Meldern. Das ist aber m. E. kein Problem des LN sondern wie die Zentrale die Daten verarbeitet.

---

Da liegst Du leider total falsch.
Es ist definitiv ein Problem der Rückmeldemodule ( im Zusammenspiel mit der Art der Datenübertragung im LocoNet ).

Ich möchte jetzt nicht noch mal alles wiederholen. Lese Dir doch einfach den Beitragsfaden durch, den man findet, wenn man LocoNet und interrogate in die Suche eingibt. ( Kann den Link leider nicht einfügen, da ich dieses mit dem Taschenfernsprecher nicht hinbekomme. )
Dort findest Du nicht nur Beiträge von a-zett und mir, sondern auch von Karst Drenth, dem Entwickler besagter Module.

MfG Oliver

[Draisine]

Alles klar, habe es gefunden.

Glücklicherweise habe ich bislang nur zwei DR4088LN. Der Rest sind S88N und Yamorcs.

Grüße Thomas

[a-zett]

Hier geht es auch endlich weiter. Ich habe jetzt Platinen von Floodland.nl, von denen ich mit zwei Adern über zweipolige Uhlenbrock Schaltdekoder im Startmakro Äste des Loconet unterbrechen will. Leider hat Conrad alle Teile zur Testplatine aber keine Stecker geliefert...

Bild entfernt (keine Rechte)

[vikr]

Hallo A-Zett,

Zitat von a-zett im Beitrag #12

---

Hier geht es auch endlich weiter. Ich habe jetzt Platinen von Floodland.nl, von denen ich mit zwei Adern über zweipolige Uhlenbrock Schaltdekoder im Startmakro Äste des Loconet unterbrechen will. Leider hat Conrad alle Teile zur Testplatine aber keine Stecker geliefert...

---

ich bin gespannt, wie es bei Dir weitergeht, vermute aber Du erwartest zuviel, nicht nur von Conrad.

Wie jedes Netzwerk gibt es auch bei LocoNet eine Auslastung, ab der es eng wird und nicht mehr genug Zeit übrig bleibt, die Kollisionen ordnungsgemäß abzuarbeiten. Die Baudrate ist in der Spezifikation festgelegt, so daß der Weg über eine Erhöhung der Taktfrequenz verbaut ist.
Die Bandbreite eines LocoNet ist für heutige Erwartungen niedrig.
Peter Giling hat vor 15 Jahren - mit Rob Verslius zusammen - versucht mit "LocoNet over LAN" einen Ausweg zu designen, der aber von den LocoNet nutzenden Modellbahnern nicht angenommen wurde.
Es bleibt der Weg zu versuchen - für verschiedene Aufgaben - mehrere Netze parallel zu betreiben, insbesondere die Rückmeldungen, in ein eigenes LocoNetzwerk auszulagern. Dabei bleibt natürlich viel von dem eigentlichen Charme des Loconet-Konzeptes auf der Strecke.

Das hier beschriebene Problem ist aber m.E. In erster Linie auf eine von der Spezifikation und dem Design ganz unabhängige Fertigungsschlamperei seitens der Firma Digikeijs - bei der Substitution von schwer erhältlichen Bauteilen - zurückzuführen:
DR4088LN-OPTO: ACHTUNG - verändertes Design!

Es ist eins der Beispiele dafür, was passiert, wenn Kaufleute verpflichtet werden, fachliche Entscheidungen - ohne entsprechende Expertise - treffen zu müssen.

MfG

vik

[a-zett]

Vik, ich hatte schon früher berichtet, dass im Experiment ein Ast mit nicht zu vielen Belegtmeldungen vollständig angezeigt wird, wenn man dessen Stecker zieht und wieder einsteckt und genau das will ich im Startmakro nachbilden. Aus TC-Sicht behebe ich damit nur einen Schönheitsfehler, denn ob rot oder weiß angezeigt, das Fahrzeug im Block kennt TC ja noch. Dass ich den Stecker ziehen musste, weil erst danach neue Meldungen in TC ankommen, scheint behoben seit der Schattenbahnhof eine eigene Uhlenbrock Stromversorgung hat und der Z21 Loconet-Ausgang nicht mehr überlastet ist.

[vikr]

Hallo A-Zett,

Zitat von a-zett im Beitrag #14

---

Vik, ich hatte schon früher berichtet, dass im Experiment ein Ast mit nicht zu vielen Belegtmeldungen vollständig angezeigt wird, wenn man dessen Stecker zieht und wieder einsteckt und genau das will ich im Startmakro nachbilden. Aus TC-Sicht behebe ich damit nur einen Schönheitsfehler, denn ob rot oder weiß angezeigt, das Fahrzeug im Block kennt TC ja noch. Dass ich den Stecker ziehen musste, weil erst danach neue Meldungen in TC ankommen, scheint behoben seit der Schattenbahnhof eine eigene Uhlenbrock Stromversorgung hat und der Z21 Loconet-Ausgang nicht mehr überlastet ist.

---

der ursprüngliche TE hatte ein ähnliches Problem auch:

Zitat von Spatzlosti im Beitrag #1

---

Workaround/Übergangslösung:Beheben kann ich die Situation indem ich einer der folgenden Punkte ausführe:Variante 1: An der Z21 die Notstop Taste 2x drücken (Not Ein/Not Aus) > dann wird sofort im APP und in WinDigipet die Gleisbelegung angezeigtVariante 2: In WinDigipet trenne ich die Verbindung zur Z21: Verbindung Trennen und neu initialisieren > dann wird sofort im APP und in WinDigipet die Gleisbelegung angezeigt

---

und in WDP ist dann tatsächlich eine spezielle Strategie als Workarround - für dieses Problem in dieser im Titel genannten LocoNet-Umgebung (Z21 / Digikeijs DR4088LN-CS) - implementiert worden, so daß man nicht mehr bei jedem Start manuell eingreifen muss.

MfG

vik

[Elektrobahner]

Hallo A-Zett,

Deine Lösung habe ich auch geplant, um dieses Problem zu lösen. Allerdings dachte ich daran, alle LN-Leitungen kurz zu unterbrechen, um den Refresh („Stecker ziehen“) auszulösen. Wenn ich Deinen Beitrag mit den Platinen richtig verstehe, willst Du nicht alle LN-Leitungen unterbrechen, sondern nur zwei. Kannst Du verraten, welche das sind? Relais mit zweipoligen Umschalter sind ja einfacher zu bekommen, als sechspolige.

Viele Grüße,
Christian

[a-zett]

Die Frage ist berechtigt, denn die beiden Threads zur Spannungsversorgung und zum Interrogate-Problem sind genau so spannend wie länglich und jetzt, wo ich die nochmal gelesen habe, werden hier die Leitungen 1 und 6 geschaltet, die sich aber bei Loconet-T nicht unterscheiden

Loconet-Interrogate bei Z21 und TC9?

während hier von den Plusleitungen 2 und 5 die Rede ist und explizit davon, die Datenleitung genau nicht über Relaiskontakte zu führen um Störungen zu vermeiden

Loconet-Interrogate bei Z21 und TC9?

Ich denke, Letzteres ist richtig. Mal schauen, wann meine Buchsen nachgeliefert werden und ich Zeit habe, das auszuprobieren.

[Elektrobahner]

Danke! Die Hinweise in den Threads auf die Leitungen sind mir in der Tat durchgegangen, obwohl ich beide interessiert verfolge.

Ich würde mich freuen, wenn Du Deine Erfahrungen hier teilen würdest!

Viele Grüße,
Christian