Zitat

---

Aber ich denke, dass das ja noch an anderen Stellen relevant ist (bspw. Weichenrückmeldung). Phillip kannst du die das mal bitte Anschauen? Danke schonmal.

---

Hallo René,

danke dir, jupp dort ist noch ein Fehler beim Shiften. Leider ist das bei dem OPC_INPUT_REP etwas anders als bei dem OPC_SW_REQ. Aber jetzt sollte es passen
Habe das für den Detektor und die Weichen angepasst und die Dateien erneut abgelegt. LINK v4.89 (09.04.2021)

Zitat

---

nachdem ich die V4.89 aufgespielt habe stellte ich als erstes fest, dass die Multimaus beim Einschalten kurz "Err13" zeigt, was sie mit den Versionen V4.85-V4.88 nicht gemacht hat.

---

Hallo Ralf,

das liegt an dem "Warten..." auf die Rückmeldung (Timeout 5 sec.) des LAN-Interface. Hier wird versucht eine IP über DHCP zu beziehen.
Wenn das nicht erfoderlich ist dann in der "config.h" den "#define DHCP" abschalten. Hatte das diesmal nicht default auf deaktiviert gesetzt!

Hallo Phillip,

vielen Dank!

Aber:
Bei mir ging es gar nicht mehr. In Zeile 875 und 890, das switch case OPC_SW_REQ habe ich auch mal in geschweifte Klammern gesetzt, dann ging es. Die waren vorher zwar auch nicht da, aber nach dem ich sie hinzugefügt habe ging es super.

Warum auch immer, da das case ja mit break schließt... Egal bei mir gehts so!

Danke!!!!!!!!

René

Hallo @ Philipp - vielen Dank

Nach der Aktualisierung meiner 3 z21 Steuerungen auf v489 ist mir folgendes aufgefallen.
Die IP-Adresse wird wieder je auf Default, 192.168.0.111 zurückgesetzt,
ich verwende für jede z21 eine eigene config.h mit individueller Mac Adresse.
Frage: kann in die config.h zusätzlich die gewünschte IP-Adresse mit aufgenommen werden z.B 192.168.2.111(112,113)

Es ist relativ umständlich die IP-Adresse die dann im 192.168.0 Netz ist, auf die gewünscht umzustellen.

Danke und viele Grüße
Josef

Zitat

---

Hallo @ Philipp - vielen Dank

Nach der Aktualisierung meiner 3 z21 Steuerungen auf v489 ist mir folgendes aufgefallen.
Die IP-Adresse wird wieder je auf Default, 192.168.0.111 zurückgesetzt,
ich verwende für jede z21 eine eigene config.h mit individueller Mac Adresse.
Frage: kann in die config.h zusätzlich die gewünschte IP-Adresse mit aufgenommen werden z.B 192.168.2.111(112,113)

Es ist relativ umständlich die IP-Adresse die dann im 192.168.0 Netz ist, auf die gewünscht umzustellen.

Viele Grüße
Josef

---

Hallo Josef,

ja das ist leider so. Denn dadurch, dass bei einem ersten Upload nicht alle EEPROM Wert korrekt gesetzt worden sind wird dies jetzt beim Starten immer abgefragt und alles aktualisiert, bzw. korrekt initialisiert. Das passiert nur einmalig und wird dann im EEPROM vermerkt. So das in Zukunft nicht mehr passiert.

Falls später nochmal ein Rücksetzten aller EEPROM Werte notwendig ist, klappt das jetzt auch mittels des Power ON RESET.

Hallo Bastler,

mit dem kleinen Kreis habe ich auch mal den Automatikbetrieb ausprobiert.
Mit Windows 10, Rocrail-WIN64, der Zentrale mit der Version 4.89 und dem 8fach Rückmelder.
Es funktioniert jetzt ca. 30 Minuten ohne Fehler.
Hier ein kurzer "Kurzfilm".



Viel Spaß beim Basteln
Andreas

Hallo Rocrailer,
Habt ihr bei Rocrail Automatikbetrieb und zusätzlichen Steuern anderer Loks (nicht fahren) sondern Licht ein/aus, Sound, ... das Problem, das es Anfangs sofort reagiert und nach mehreren Minuten manchmal nur noch Zeitverzögerung reagiert?

Viele Grüße
Josef

Hallo Rocrailer,
Habt ihr bei Rocrail während des (alte bis aktuelle Version) Automatikbetrieb, z21 V480 - V487 und zusätzlichen Steuern anderer Loks (nicht fahren) sondern Licht ein/aus, Sound, ..Stop Taste, das Problem, das es Anfangs mit Multimaus sofort reagiert und nach mehreren Minuten manchmal nur noch 2 - 10 sec. Zeitverzögerung reagiert?
Wie wenn der Xnet Bus einschlafen würde, Steuerung über PC Rocrail während dessen weiterhin möglich.

Viele Grüße
Josef

Zitat

---

Hallo Rocrailer,
Habt ihr bei Rocrail während des (alte bis aktuelle Version) Automatikbetrieb, z21 V480 - V487 und zusätzlichen Steuern anderer Loks (nicht fahren) sondern Licht ein/aus, Sound, ..Stop Taste, das Problem, das es Anfangs mit Multimaus sofort reagiert und nach mehreren Minuten manchmal nur noch 2 - 10 sec. Zeitverzögerung reagiert?
Wie wenn der Xnet Bus einschalten würde, Steuerung über PC Rocrail während dessen weiterhin möglich.

Viele Grüße
Josef

---

Hallo Josef,

damit ich das nachvollziehen kann musst du mehr Details nennen. Wieviele Loks werden betrieben, also für welche Anzahl an Loks gab es einen Befehl von irgendeinem Client.
Welche Softwareversion hat die Multimaus? Leuchtet die Xpressnet led weiterhin, fürs Auge, dauerhaft? Wieviele XpressNet Geräte sind an dem Bus angeschlossen? Wie ist die Konfiguration der Zentrale, welche Interfaces sind aktiv?

Hallo Philipp,

Dieses Verhalten "XpressNet pausiert" ist mir bereits seit Frühjahr 2018 mit V480 aufgefallen.
Rocrail Betrieb - Not Stop mit der multiMAUS funktioniert sporadisch nicht oder viel zu spät.
es passiert nach mehreren Minuten (ca. ab 10 Min) und behebt sich dann auch selbst wieder, wie wenn auf was gewartet würde.
es passiert mit meinen beiden z21PG Steuerungen mit Version V480, V483, V485, V486, V487 und V489
es passiert bereits wenn nur eine Lok im Rocrail im Automatikbetrieb fährt,
auch wenn nur eine multiMAUS am XpressNet angeschlossen ist, sonst zusätzlich 4x Lokmäuse 2
mit allen Rocrail Versionen (x32/x64) bis aktuellste, die ich im Einsatz hatte.
LocoNet, Wlan habe ich deaktiviert.
das Verhalten ist sporadisch, (manchmal 30 Minuten, 3 Loks, kein Fehler), nicht fest reproduzierbar, ich kann es an nichts festmachen.

Xpressnet send /receive LED "gelb" leuchtet auch im Fehlerfall fürs Auge dauerhaft, muss ich noch beobachten, noch offen!

Multimaus Version: Software: 1.02, X-Bus: V3.6, Zentrale: Multimaus

deswegen habe ich mir s88-N_DCC_Sniffer https://jo-fri.github.io/Eisenbahn/DCC_Sniffer/index.html gebaut, direkt an die z21 anstecken oder nach letzten s88-N Modul.
wenn benötigt, kann ich Trace Unterlagen mit DCC-Sniffer(V1,V2) am s88-N Ausgang erstellen.
oder Debug Unterlagen am z21PG USB Ausgang

Habe gestern 3/4 Stunde getestet - kein Fehler.

eine Frage an alle Rocrail'er, ist euch solch ein Verhalten auch aufgefallen? ober bin ich damit alleine?

Viele Grüße und bleibt Gesund
Josef

Hallo Josef,

du kannst doch mal ein W-LAN-Modul an deiner Zentrale ergänzen. So dass du den Sketch ohne Änderungen testen kannst.
Das keine Bauteile für den LocoNet-Anschluss vorhanden sind, sollte hier nicht stören.

Ich hatte auf einer Platine auch mal das W-LAN-Modul nicht eingesetzt und es kam auch zu Verzögerungen. (als würde der Arduino immer wieder auf etwas im Programmablauf warten)

Viele Grüße
Andreas

Danke Andreas,

ich habe leider keine einziges WLAN Modul, arbeite nur über LAN.
Frage: zum Test, funktioniert das Programm mit aktiven "#define WIFI" aber ohne Hardware?

Viele Grüße
Josef

Hallo Josef,

ich würde es mal so testen. Du kannst doch mal den Sketch 4.89 nutzen und kommentierst nur das W-LAN aus. Also ein Test mit LocoNet und für einen zweiten Test nutzt du den Sketch unverändert. Während der Tests können die aktiven aber ungenutzten Ports empfindlich sein, also nicht auf die Pins fassen. Die IP Adresse kannst du schon im Sketch einstellen.

Viele Grüße
Andreas

Zitat

---

Frage: zum Test, funktioniert das Programm mit aktiven "#define WIFI" aber ohne Hardware?

---

Hallo Josef,

ein 'define WIFI' klappt ohne Hardware, aber beim Starten wird dann nach einem WLAN-Interface gesucht. Das dauert dann etwas (20 sec.) bis die Zentrale merkt, dass keins vorhanden ist und einfach weiter macht.
Ich nutze selbst auch zum Test einen Aufbau ohne WLAN, allerdings ist dann auch kein XpressNet vorhanden.

Wenn das WLAN-Interface nicht aktiviert ist, dann gibt es auch keine Verarbeitung von Serial Daten im Code. Das könnte sich dann auf die Geschwindigkeit für den Durchlauf einer "LOOP" auswirken.

XpressNet arbeitet nach dem Abfrage-Prinzip, d.h. es wird immer jeder Slot (Handregler) abgefragt ob dieser Daten zu senden hat. Dauert das zu lange, hat man als Nutzer das Gefühl die Multimaus ist sehr langsam. Das kann passieren wenn zum Beispiel Störungen auf den XpressNet-Bus einwirken und somit Daten erkennt werden die nicht vorhanden sind. Die Zentrale wartet dann immer an jedem Slot den Timeout ab, so dauert die Abfrage aller 32x XpressNet Slots sehr lange und die Multimaus reagiert sehr langsam. Deshalb auch die Frage nach dem Zustand der SEND/RECEIVE LED an der Zentrale. Wartet diese sehr lange an den einzelnen Slots beim Lesen sollte sie dunkler leuchten!
Du kannst bitte auch mal die Spannung mit einem Multimeter an dem PIN 9 des MEGAs messen. So können wir feststellen ob es möglicherweise an der Hardware liegt und diese Störungen auf dem Bus verursacht. Der Grund kann zum Beispiel zu lange Kabeln oder einen nicht korrekt terminierender Bus sein.

Hallo Philipp,

Ich teste nun im Rocrail Automatikbetrieb mit V489, mit "allem" WLAN, LocoNet, Railcom außer DHCP, auch wenn ich die Hardware nicht habe.
verwende Standard config.h, es funktioniert auch alles, keine XpressNet Hänger in der ersten 1/4 Stunde.

habe aber noch andere "Rocrail Probleme", sporadisch:
"Ghost train in block" oder" The route to the destination block is not set."

Bin weiterhin am Testen (am Wochenende)

Viele Grüße
Josef

Hallo Josef,

Zitat

---

habe aber noch andere "Rocrail Probleme", sporadisch: (nicht für hier)
"Ghost train in block" oder" The route to the destination block is not set."

---

diese Meldungen kenne ich auch von Rocrail.

"Ghost train in block"
Es war bei mir ein Isolier-Schienenverbinder der nicht richtig isoliert hat. Es wurde vereinzelt, sporadisch ein Melder des Folgeblock mit ausgelöst.

" The route to the destination block is not set."
Hier hatte ich nicht für alle Loks die Berechtigung in den Routen eingetragen.
(Der Neuzugang war nur in der Tabelle "Loks" eingetragen)

Viele Grüße
Andreas

Hallo Andreas,

Zitat

---

" The route to the destination block is not set."
Hier hatte ich nicht für alle Loks die Berechtigung in den Routen eingetragen.
(Der Neuzugang war nur in der Tabelle "Loks" eingetragen)

---

Das passiert auch leicht, wenn man beim Ausfüllen der Lok-Tabelle den optionalen Eintrag ~Elektrokok auswählt, dann erwartet Rocrail, dass die mit dieser Lok zu befahrenden Strecken (Blöcke) auch als "elektrifiziert" gekennzeichnet sind, damit Rocrail sie im Automatik Betrieb (z.B. im Aquariumsmodus) nicht versehentlich dorthin schickt.

MfG

vik

Hallo Josef,

deine ghost trains können auch durch den Haken loconet detector in den Einstellungen zur Zentrale verursachte werden.

Gruß René

Hallo Viktor,

danke für deinen Hinweis, von dieser "Stolperstelle" habe ich auch schon im Rocrail-Forum gelesen. Und ich hatte auch erst eine Lok so eingestellt.

Viele Grüße
Andreas

Danke euch allen, werde am Wochenende testen / kontrollieren.
Josef

Hallo Philipp,
neues Thema Signal: DCC_S88
Mir ist folgendes aufgefallen, seit der Aufteilung des DCC Signales V483 Mega von Pin 6 DCC Power geschaltet, auf Pin 11 DCC_S88 Dauersignal für s88-N und LocoNet. Ich verwende zur Weichensteuerung / Rückmeldung Weich88-N https://www.digital-bahn.de/bau_s88n/weich88-n_2v7.htm diese haben ein LED2 "DCC Befehl auf Raildata" erkannt,
wenn das DCC Signal von Pin 6 kommt blinken dieses nur bei einen aktiv ausgegebenen Befehl,
wenn das DCC Signal von Pin 11 kommt blinken dieses LED2 zusätzlich unregelmäßig, auch ohne das aktiv ein Befehl ausgegeben wird.

deswegen habe ich mir s88-N_DCC_Sniffer https://jo-fri.github.io/Eisenbahn/DCC_Sniffer/index.html gebaut, direkt an die z21 s88-N anstecken oder an letzten s88-N Modul Eingang.
In meinen z21 Mega Schaltplan https://jo-fri.github.io/Eisenbahn/Z21/z21_Mega_TLE5206.svg habe ich einen Jumper Pin 6, Pin 11, zu DCC_S88 gebaut um schnell umzuschalten.

Ergebnis des Mitlesen:
Das DCC Signal auf Pin 6 ist immer sauber / störungsfrei.
Das DCC Signal auf Pin 11 hat sporadisch zusätzliche Befehle von unterschiedlichsten nicht verwendeten Adressen.

Getestet habe ich dieses Verhalten mit meinen beiden z21PG Steuerungen (V483 bis V489)
V480 hat nur DCC Pin 6 ist immer sauber / störungsfrei.

viele Grüße
Josef

Zitat

---

Ergebnis des Mitlesen:
Das DCC Signal auf Pin 6 ist immer sauber / störungsfrei.
Das DCC Signal auf Pin 11 hat sporadisch zusätzliche Befehle von unterschiedlichsten nicht verwendeten Adressen.

Getestet habe ich dieses Verhalten mit meinen beiden z21PG Steuerungen (V483 bis V489)
V480 hat nur DCC Pin 6 ist immer sauber / störungsfrei.

---

Hallo Josef,

aufgrund deiner Angabe ich habe mich hingesetzt und den Quellcode angeschaut. Dann einen kleinen Aufbau bestehend aus Arduino MEGA mit Ethernet Shield als Zentrale und einen weiteren als Sniffer, je an PIN 6 und PIN 11 angeschlossen ist aufgebaut.
Im Quellcode werden beide Signale "gleizeitig" erzeugt und diese müssen somit identisch, bis auf die fehlende RailCom Austastlücke an PIN11, sein. Dies zeigt sich dann auch im Sniffer, hier werden alle Pakete der beiden Signale korrekt erkannt. Auch ein weiterer Test des Timings gab nur maginale Schwankungen der Bitfolge aus. Dabei sind diese für ein '1' Bit zwischen 56 - 60 µs und für ein '0' Bit bei 96 - 100 µs.
Einzig was auffällig ist, das beim Umschalten bzw. vielen Daten auf dem Z21-Protokoll, dies auch Auswirkungen hat auf das DCC-Signal! Hier bingt der Prozessor aufgrund der nicht möglichen parallelen Verarbeitung mehr IDLE-Nachrichten aufs Gleis zu senden - es sind aber auch hier keine fehlerhaften Pakete vorhanden.

In meinem Test hatte ich 10 Loks aktiv (Fahrstufe = '0') je ein "3-Byte" Paket und zusätzlich noch je Lok eine Funktion aus der ersten Funktionsgruppe "4-Byte" Paket -> Das entspricht 20 Pakete die dauerhaft durch die Zentrale wiederholt wurden. Dabei zeigten sich keine Veränderung oder fehlerhafte Lokaddressen in dem Datenstrom an PIN11, sowohl mit und ohne aktiver Gleisspannung, als auch bei Änderung des RailCom Status (EIN-AUS).

Hier ein Doppelauszug (Pin 6 und Pin 11) eines IDLE-Paket der Zenrale mit und ohne RailCom und einer 17x Preamble:

Einzige was ich noch auf meiner To-Do Liste habe und was man auch gut im Diagramm sieht ist, dass der RailCom Cutout ein halbes '1'-Bit zu spät beginnt.
Hier ein Snipp mit allen drei Signalen (oben nach unten: Pin 11, Pin 6, Pin 39). Man sieht gut das gerade beim Pin 39 das Cutout zu groß ist!

Hallo Philipp,
zu Thema Signal: DCC_S88
Mir ist folgendes aufgefallen, wenn ich das DCC Signal von Pin 6 DCC, auf Pin 11, DCC_S88 DCC Dauersignal für s88-N per Jumper umstecke,
erkennt Weich88-N https://www.digital-bahn.de/bau_s88n/weich88-n_2v7.htm über Ausgabe LED2 "DCC Befehle auf Raildata s88-N Pin8"
wenn das DCC Signal von Pin 6 kommt blinken dieses nur bei einen aktiv ausgegebenen Befehl,
wenn das DCC Signal von Pin 11 kommt blinken dieses LED2 zusätzlich unregelmäßig, auch ohne das aktiv ein Befehl ausgegeben wird,
dieses Verhalten ist weiterhin so, bei mir fest reproduzierbar, hat aber anscheinend keine weiteren Auswirkungen.

Deswegen hatte ich den s88-N_DCC_Sniffer https://jo-fri.github.io/Eisenbahn/DCC_Sniffer/index.html gebaut, mit ursprünglich 390 Ohm in Reihe zur LED und Opto Koppler, dieses führte beim Mitlesen mit "DCC_Sniffer2.ino" zu sporadisch falschen Adress-Ausgaben in PuTTY, ich habe nun diesen Widerstand auf 1 Kohm erhöht und es werden nun nur noch korrekte Adressen Ausgaben.

Ich nehme an das die "fehlende" Signallücke die Weich88-N Module zum sporadischen blinken der "LED2" auf allen Modulen bewegt, (Befehl empfangen) ohne das es negative Auswirkungen hat.
ich hatte dieses gemeldet weil ich einen Fehler vermutete.

nun suche ich weiter mit meinen sporadischen XpresNet Hänger, heute konnte ich keinen feststellen.


Großen Dank für diene Bemühungen, Super Leistung von Dir.
Josef

Hallo Philipp,

Zitat

---

... was ich noch auf meiner To-Do Liste habe und was man auch gut im Diagramm sieht ist, dass der RailCom Cutout ein halbes '1'-Bit zu spät beginnt.
Hier ein Snipp mit allen drei Signalen (oben nach unten: Pin 11, Pin 6, Pin 39). Man sieht gut das gerade beim Pin 39 das Cutout zu groß ist!

---

Das deckt sich mit meiner Messung 2018 und ist dürfte der Grund für die verschluckten Kanal 1 Teil-Nachrichten sein, was wiederum dazu führt, dass die Adressen aus dem Kanal 1 nicht angezeigt werden können, weil sie gemäß Hammingcodierung vom Detektor als ungültig verworfen werden...

MfG

vik

Hallo Bastler,

für die Zentrale habe ich ein “Add On” aufgebaut und getestet.
Den Schaltplan gab es auf der Seite von Philipp. (Full LocoNet Interface mit L9110)

Auf einer kleinen Platine sind zwei RJ12 Buchsen und ein Motortreiber DRV 8871 aufgebaut.
So wird die Zentrale mit LocoNet B Anschluss erweitert. Die Schaltung habe ich erfolgreich mit dem LocoNet Booster und dem Rückmelder getestet.



Viel Spaß beim Basteln
Andreas

Hallo zusammen,

Zitat

---

Hallo Philipp,

Zitat

---

... was ich noch auf meiner To-Do Liste habe und was man auch gut im Diagramm sieht ist, dass der RailCom Cutout ein halbes '1'-Bit zu spät beginnt.
Hier ein Snipp mit allen drei Signalen (oben nach unten: Pin 11, Pin 6, Pin 39). Man sieht gut das gerade beim Pin 39 das Cutout zu groß ist!

---

Das deckt sich mit meiner Messung 2018 und ist dürfte der Grund für die verschluckten Kanal 1 Teil-Nachrichten sein, was wiederum dazu führt, dass die Adressen aus dem Kanal 1 nicht angezeigt werden können, weil sie gemäß Hammingcodierung vom Detektor als ungültig verworfen werden...

---

habe die DCC Bibliothek angepasst so dass jetzt die RailCom-Lücke um ein halbes '1'-Bit verlängert ist:

Damit entspricht das Signal dem, welches von der OpenDCC Zentrale erzeugt wird.
Die geänderte Bibliothek kann hier heruntergeladen werden:
https://github.com/Digital-MoBa/DCCInterfaceMaster