[erl.] MX10: UDP Paketen vom Zentrale kommen nicht an

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 12.07.2018, 21:55

Hallo Rob,

ich kann Dir momentan nur einen Schnellschuß von gestern Abend als Trace anbieten, hatte da nicht mehr viel Zeit zum Ausprobieren. Irgenwie erscheint mir der Anfang des Trace auch etwas gekürzt - oder es kommen jetzt so viele Botschaften durch, daß der Anfang aufgrund der Trace-Länge schon wieder verworfen wurde...
In dem Trace habe ich eine Situation aufgenommen, bei dem der Rückmeldereingang 8 belegt und wieder frei ist (kein Railcom, nur ein Widerstand im Gleis).
Rückmelder NID auf CAN müßte 0xDE0B und der Port (programmierte Zubehöradresse) 4 sein. Da wurde dann der 8. Eingang betätigt (hab aber in diesem Trace selber noch nicht im Detail nachgeschaut ob's auch wirklich stimmt - das waren zumindest die Einstellungen, die ich vorher im Wireshark gesehen habe).

Ich muß die Bahn wieder ein Stück zur Seite schaffen, kann aber evtl. am Wochenende ein etwas kleineres Setup aufbauen um noch ein paar Tests durchzuführen.

Von Zimo habe ich folgende Antwort auf meine Frage bekommen, ob es bekannte Probleme mit Adressen im 10er-Bereich gibt oder irgendwann vielleicht auch mal eine DHCP-Unterstützung gibt:
Ja, das ist bekannt aber kann von ZIMO nicht so leicht gelöst werden, weil die IP vom MX10 (zumindest mit derzeitigen MX10-Software) unbedingt eine statische IP sein muss (dynamische IPs sind nicht erlaubt).

Das eigentliche Problem ist da der verwendete Router, die meisten Router (abhängig vom Chipset des Routers) haben IP-Nummerbereiche für statische und dynamische IPs. Da muss man dann darauf achten, dass die IP vom MX10 unbedingt in den statischen Bereich fällt.

Das MX10 kommt schon mit einer IP 10.0.0.145 zurecht, aber dann sollte kein Router im Spiel sein (daher es geht nur mit direkter PC Verbindung und ausgekreuzten LAN-Kabel), weil IPs ála 10.0.0.145 ziemlich sicher in den typischen dynamischen IP-Bereich der meisten Router (z.B. Fritzbox, alle Netgear-Router,...) fallen.

Gerne können Sie diese Information auch im RocRail Forum posten.

Da bei mir die Adresse aber sicher nicht im dynamischen Bereich des Routers liegt und ich die Probleme auch ohne Router mit der 10er-Adresse habe, habe ich heute noch mal bei Zimo nachgefragt.

Gruß,
Thomas.
You do not have the required permissions to view the files attached to this post.
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 13.07.2018, 07:23

Moin Thomas,

am beste mal Tracen ohne BYTE Level, oder du musst es so einstellen das nur ein Trace Datei erstellt wird.
https://wiki.rocrail.net/doku.php?id=ro ... ce-dateien
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 15.07.2018, 13:36

Hi Thomas,
lastcowboy wrote:So eine SCH...!!! :mad:
MX10 IP-Adresse auf 192.168.1.145 und entsprechende Einstellung in Rocrail geändert (sonst nix!), MX10 direkt mit dem Win-PC verbunden und Win-PC Adresse entsprechend angepaßt: Und schon steht die Kommunikation, MX32-Betätigungen kommen auch bei Rocrail an. Wieso funktioniert die 10er-Adresse nicht (=> Zimo...)?!?!?

ich habe jetzt wieder mein Test MX10 und musste feststellen das 192.168.100.x auch(immer noch) nicht funktioniert.
Ich bin nicht bereit meint Heimnetz um zu stellen, und ich habe Zimo gemeldet das ich erst dann wieder weiter mache an der MX10 nachdem das IP Problem behoben ist.
Vielleicht sollte Zimo die Firmware Sources mal frei zur Verfügung stellen bei gitlab.com oder so.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 15.07.2018, 19:19

Hallo Rob,

rjversluis wrote:Hi Thomas,
ich habe jetzt wieder mein Test MX10 und musste feststellen das 192.168.100.x auch(immer noch) nicht funktioniert.
Ich bin nicht bereit meint Heimnetz um zu stellen, und ich habe Zimo gemeldet das ich erst dann wieder weiter mache an der MX10 nachdem das IP Problem behoben ist.
Vielleicht sollte Zimo die Firmware Sources mal frei zur Verfügung stellen bei gitlab.com oder so.


ich habe heute noch mal mit den Einstellungen des MX10 gespielt, das MX10 dabei direkt per Ethernet-Kabel mit meinem Rechner verbunden (ohne über mein Heimnetz im 10er-Bereich zu gehen).
Wenn ich eine Adresse im 10er Bereich nehme (MX10: 10.0.0.145, PC: 10.0.0.180), sehe ich zwar Ethernet-Pakete vom MX10 mit Wireshark auf dem Rechner, die kommen aber nicht bei Rocrail an.
Ändere ich nur die Adresse (sonst nichts) in den 192.168er-Bereich (MX10: 192.168.1.145, PC:192.168.1.180), bekomme ich die Handreglerbetätigungen (Lokgeschwindigkeit, Funktionstasten) auch in Rocrail zurückgemeldet.

Ich hab gerade auch mal den 192.168.100er-Bereich ausprobiert - funktioniert bei mir auch nicht, das gleiche wie im 10er-Bereich: Ethernetpakete kommen im PC an, da muß aber irgendwas bei denen falsch sein, daß sie Rocrail nicht akzeptiert/sieht.
Sieht so aus als würde wirklich nur 192.168.1.X funktionieren...

Der Rückmelder-Monitor zeigt aber noch immer nichts an, wenn ich eine Lok im Kreis durch 6 Rückmeldeabschnitte fahren lasse. Wie muß ich den Roco-Rückmelder konfigurieren, damit der Rückmelder-Monitor etwas anzeigt?

Anbei eine (etwas längere) Trace-Datei (BYTE-Level). Lok 111 ist einmal im Kreis durch alle 6 Rückmeldeabschnitte gefahren.

Gruß,
Thomas.
You do not have the required permissions to view the files attached to this post.
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 15.07.2018, 21:22

Hab' noch einen Blick ins Trace-File geworfen: Die Rückmeldung kommt bei Rocrail an:

Code: Select all
    offset:   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |ASCII...........|
    --------------------------------------------------------- |----------------|
    00000000: 08 00 40 00 01 16 0B DE 04 00 00 11 6F C0 00 00 |..@.........o...|
20180715.195448.718 r9999B zcanread OZimoCAN 1211 Message nid=0xDE0B target=0x0004 dlc=8 group=1 cmd=5 mode=2
20180715.195448.718 r9999B zcanread OZimoCAN 1228 ACCESSORY COMMAND GROUP
20180715.195448.718 r9999I zcanread OZimoCAN 0830 ACCESSORY: cmd=5, mode=2, dlc=8, nid=DE0B, target=0004 d=00 11 6F C0 00 00
20180715.195448.718 r9999c zcanread OZimoCAN 0743 nid=DE0B port=0 type=17 loco=49263


d=00 11 6F C0 00 00
----------------------
00: Rückmeldereingang 1
11: 1. und 2. Lokadresse(?)
C06F: Lokadresse dez. 111 (0x6F) - die ersten zwei Bits könnten Richtungsinfos o.ä. sein - die Lok hat zumindest Adresse 111, nicht 49263...
0000: keine 2. Lokadresse

Wie bekomme ich die Information jetzt Rückmeldeereignissen/Rückmeldern in Rocrail zugewiesen?
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 16.07.2018, 06:36

Moin Thomas,

prima! :)

Momentan werden da nur StEin und MX9 ausgewertet.
Ich werden es mit Roco 10808 ergänzen.
:coding:

NID 0xD000-0xDFFF "Module"
war für zwei Jahre noch nicht vorhanden.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 16.07.2018, 07:01

Hallo Thomas,

es ist jetzt drin inkl. Korrektur für die Lok Adresse.
Bitte testen und berichten.
14090+
https://wiki.rocrail.net/rocrail-snapshot/
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 20.07.2018, 20:41

Hi Rob,

es funktioniert, super, der Rückmeldemonitor zeigt nun alle 6 Blöcke mit der durchfahrenden Lokadresse an.
Danke für die schnelle Umsetzung.

Ein interessanter Nebeneffekt: Wenn die Lok im Stillstand ist, meldet der Roco-Rückmelder nach einiger Zeit den Block über CAN wieder frei, die LED am Belegtmelder selbst bleibt aber die ganze Zeit an und zeigt Belegung - nicht wirklich konsistent... :?
Sobald die Lok wieder anfährt (auch bei kleinster Fahrstufe), gibt's auch wieder eine korrekte Rückmeldung über CAN. Da scheint im Rückmelder noch nicht alles so ganz ausgereift zu sein.

Ich spiele am Wochenende mal ein bißchen mit den Rückmeldungen (mehrere Railcom-Loks in einem Block, Loks mit/ohne Energiespeicher, usw.) und berichte dann.

Anbei noch ein Trace, falls Du einen Blick in die Rückmeldung werfen willst. Sieht soweit eigentlich gut aus.

Gruß,
Thomas.
You do not have the required permissions to view the files attached to this post.
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 21.07.2018, 09:35

Hallo Thomas,

Da scheint im Rückmelder noch nicht alles so ganz ausgereift zu sein.

passt zum Zentrale; Hat der gleiche reife Zustand.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 21.07.2018, 15:32

Hallo Rob,

ich hab ein paar neue Erkenntnisse:

1)
Die Aussetzer sind wohl "nur" Railcom-Aussetzer, über CAN wird die Belegtmeldung weiterhin in der Botschaft Accessory Port6 [Grp 0x01, Cmd 0x06, Mode 0b10] übertragen. Nur die Accessory Data Botschaft schickt "keine Railcom-Rückmeldung" (sprich: keine erkannte Adresse bzw. Adresse 0x0000).
Wertet Rocrail nur Accessory Data aus oder auch Accessory Port6?
Belegung bzw. Freimeldung wie schon am 08.07. beschrieben:
lastcowboy wrote:Accessory Port wird immer direkt vor Accessory Data geschickt
Type ist bei mir immer 0x01 - keine Ahnung, wofür das steht.
Value ist 0x0100 (bei low byte first, also DB5 = 0x00 und DB6 = 0x01) bei Verlassen des Blocks und 0x1100 (B5 = 0x00 und DB6 = 0x11) bei Eintritt - auch da erschließt sich mir die Bedeutung bisher nicht, könnte eine vereinfachte Belegtmeldung (ja/nein) sein...

Ich denke, es ist sinnvoll für die Belegtmeldung Accessory Port6 zu verwenden und Accessory Data nur für die Railcom-Rückmeldungen, denn...

2)
... bei Loks ohne Railcom wird nur Accessory Port6 übertragen, nicht Accessory Data.
Ein Trace einer Fahrt durch alle Blöcke mit einer Lok ohne Railcom ist angehängt.

3)
Wenn zwei Loks mit Railcom in einem Block sind, werden deren Adressen so wie in der Zimo-CAN-Spezifikation für MX9 beschrieben als Type 0x11 übertragen und zusätzlich wird Type 0x12 gesendet mit zweimal 0x0000 als Lokadresse 3 und 4.
Kann es sein, daß Rocrail den Type nicht auswertet und immer die zuletzt übertragenen Accessory Data als Rückmeldung nimmt? Das würde zumindest erklären, warum Rocrail den Block fälschlicherweise als frei meldet, wenn eine zweite Lok hineinfährt. Da Type 0x12 mit zweimal 0x0000 als Adresse nach Type 0x11 mit den beiden erkannten Lokadressen übertragen wird, dürften die 0x0000er die tatsächlichen Adressen in Rocrail überschreiben.
Wenn eine dritte Railcom-Lok in den Block fährt, wird der wieder als besetzt gemeldet und die Adresse aus Type 0x12 angezeigt. Verläßt die dritte Lok den Block, wird er wieder fälschlicherweise als frei gemeldet. Wenn danach die zweite Lok den Block verläßt und nur noch eine Lok im Block ist, ist er wieder besetzt (dann kommt auch keine Type 0x12 Botschaft mehr).
Traces mit zwei bzw. drei Loks hab ich angehängt.

Lösung könnte hier wieder sein, Accessory Port6 für die Belegtmeldung zu nutzen, da wird die Belegung auf jeden Fall angezeigt.
Es könnte auch helfen, in Accessory Data den Type mit auszuwerten und primär den Type 0x11 zu nutzen (oder alle vier Lokadressen auszuwerten, falls mehrere Adressen pro Block in Rocrail unterstützt werden - wobei Type 0x12 nur gesendet wird, wenn mehr als eine Railcom-Lok im Block ist).
Diese Logik könnte auch bei MX9 gleich sein - hab' da leider keines zum Ausprobieren.

4)
Die Aufgleisrichtung/Orientierung der Lok wird im zweithöchsten Bit (Bit 14, wenn bei 0 angefangen wird zu zählen) der Lokadresse gemeldet.
Beispiel Lokadresse 111:
Fahrtrichtung vorwärts rechte Schiene "P", linke Schiene "N" => Bit 14 gesetzt, Adresse also 0xC06F
Fahrtrichtung vorwärts linke Schiene "P", rechte Schiene "N" => Bit 14 nicht gesetzt, Adresse also 0x806F

Die Bedeutung des höchstwertigsten Bits hat sich mir noch nicht erschlossen...


Das alles klingt nach vielen Wünschen und viel Arbeit - aber es könnten auch Z21-Nutzer davon profitieren, die den Roco-Rückmelder über CAN angeschlossen haben... :wink:
Und evtl. MX9-Nutzer.
Ein weiterer Nebeneffekt bei Auswertung von Accessory Port6 Botschaften: Auch die ABA-Eingänge des MX10 könnten dann als Rückmeldeeingänge genutzt werden, die werden laut CAN-Spezifikation als Port 0x00...0x07, Type 0x20 über Accessory Port6 Botschaften geschickt.

Gruß,
Thomas.
You do not have the required permissions to view the files attached to this post.
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 21.07.2018, 16:17

Hi Thomas,

port wird auch ausgewertet für mx9 und stein.
Mit welche nid meldet sich dann der roco module?
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 21.07.2018, 16:46

NID ist 0xDE0B

Code: Select all
    offset:   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |ASCII...........|
    --------------------------------------------------------- |----------------|
    00000000: 06 00 4C 02 01 1A 0B DE 04 00 03 01 00 11       |..L...........  |
20180721.144509.718 r9999B zcanread OZimoCAN 1240 Message nid=0xDE0B target=0x0004 dlc=6 group=1 cmd=6 mode=2
20180721.144509.718 r9999B zcanread OZimoCAN 1257 ACCESSORY COMMAND GROUP
20180721.144509.718 r9999I zcanread OZimoCAN 0851 ACCESSORY: cmd=6, mode=2, dlc=6, nid=DE0B, target=0004 d=03 01 00 11 00 00
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby rjversluis » 22.07.2018, 06:51

Moin Thomas,

ACCESSORY PORT6 war noch nicht unterstützt in Rocrail.
Ab 14100 bitte testen.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 28.07.2018, 12:00

Hallo Rob,

zwei Punkte sind mir bei der neuen SW aufgefallen:

1)
Belegtmeldung funktioniert, aber die Blöcke werden nicht mehr freigemeldet, wenn eine Lok ohne Railcom den Block belegt.
Bei einer Lok mit Railcom funktioniert die Freimeldung.

2)
Die Belegtmeldung über Accessory Port6 hat einen offset von -1 im Vergleich zur Belegtmeldung über Accessory Data.
Bei einer Lok mit Railcom hat das zur Folge, daß zwei Blöcke belegt gemeldet werden (der korrekte Block n sowie der Block n-1).

BYTE-Level Traces liegen bei.

Gruß,
Thomas.
You do not have the required permissions to view the files attached to this post.
lastcowboy
 

Re: Zimo MX10: UDP Paketen vom Zentrale kommen nicht an

Postby lastcowboy » 28.07.2018, 14:33

Nochmal hallo,

ich hab' noch ein bißchen mit den ABA-Eingängen des MX10 rumgespielt - mit etwas durchwachsenen Ergebnissen...

Die gute Nachricht: Die ABA-Eingänge werden prinzipiell in Rocrail in der Accessory Port6 Botschaft erkannt und angezeigt - allerdings wie beim Roco-Rückmelder nur die Belegtmeldung, nicht die Freimeldung. Das liegt aber vermutlich daran, daß bei den ABA-Eingängen der Analogwert ausgewertet werden muß, der Wert geht bei offenem Schalter nicht auf 0. Im Prinzip sollte man jeden Eingang doppelt nutzen können, einmal nach +5V und einmal nach GND geschaltet. Ist der Eingang offen, schwebt er irgendwo im mittleren Bereich (DB5 ~0x7F - schwankt aber doch ziemlich).
Das MX32 zeigt (einigermaßen) korrekt, ob der Eingang auf +5V (Pfeil nach oben) oder auf GND (Pfeil nach unten) geschaltet ist (die +5V gehen bei meiner Testschaltung allerdings nicht immer zuverlässig wieder auf den offenen Schwebezustand zurück - vermutlich muß man da besser noch einen Spannungteiler parallel zu den Schaltern legen, der den mittleren Bereich sauberer als mittlere Spannung für "offen" definiert als es die offenen Eingänge intern machen...).

Das größere Problem bei den ABAs: Der Zustand wird nicht jedesmal von der MX10 Absenderadresse (NID) gemeldet, sondern manchmal mit der NID eines anderen Gerätes am CAN! :shock:
Es wird aber jedesmal in DB1 und DB2 die korrekte ZubehörNID (Adresse vom MX10) als Rückmelderadresse gemeldet, egal welche NID die Accessory Port6 Botschaft schickt.
Ob das Verhalten bewußt so ausgelegt ist, und, wenn ja, warum, werde ich mal bei Zimo erfragen...

In meinem Testsetup werden die ABA-Eingänge teilweise mit der NID vom MX10 (0xC076), teilweise mit der vom MX32 (0xC3F1) und teilweise mit der vom Roco-Rückmelder (0xDE0B) gesendet, jedesmal aber mit der Adresse vom MX10 in DB1 und DB2 als ZubehörNID.
Es sieht so aus, als würde Rocrail die NID auswerten, nicht die ZubehörNID in DB1 und DB2. Das führt bei mir nun dazu, daß bei Betätigung eines ABA-Eingangs manchmal fälschlicherweise ein Roco-Rückmeldereingang als belegt gemeldet wird (immer dann, wenn die ABA-Meldung mit Roco-Rückmelder NID und MX10 ZubehörNID geschickt wird).
Evtl. wäre es da geschickter, die Zübehör NID in DB1 und DB2 statt der Absender-NID auszuwerten. Ich versuche mal die Philosophie hinter diesem Verhalten bei Zimo zu erfragen.

Eine weitere Ungereimtheit bei den ABA-Eingängen: In der Zimo-CAN-Spezfikation steht, daß die ABA-Eingangszustände als Type 0x20 gemeldet werden, bei mir kommt aber immer Type 0x40. Auch da frag ich mal bei Zimo nach.

Ich hab mal zwei Traces angehängt, beim ersten wird fünfmal ABA1 gegen GND geschaltet und wieder geöffnet, beim zweiten fünfmal gegen +5V.

Gruß,
Thomas.
You do not have the required permissions to view the files attached to this post.
lastcowboy
 

PreviousNext

Return to Zentralen (DE)