Hallo Thomas,

Quote

es ist richtig, das ich die SW von Andreas benutze, welche auch sehr gut funktioniert

Ok, das hatte ich mir schon gedacht. Ich kenne nämlich aktuell keine Software für die Umsetzung virtueller COM Port zur CC Schnitte auf Ethernet.

Quote

Auffällig ist das sporadische Auftauchen der Fehlfunktion und auch nur bei dem Versuch der Fahrtrichtungsänderung über die CS 2 Server SW. Ich mal ein paar Test ohne eine MS2 anzuschließen (wobei die Ladenneu auch ist).

Daß der Fehler immer bei einer bestimmten CAN Nachricht auftritt, ist schon merkwürdig. Ich hätte da eher Probleme bei hoher Last erwartet.

Quote

Also zusammenfassend scheint es bei bestimmten ausgehenden Datenpaketen ein Interpretationsproblem duch die Gleisbox zu geben. Eventuell hilft noch folgende Info: wenn ich CanView von M laufen lasse sinddie normalen Meldungen: "Nothalt / Richtungswechsel / ..." Gelegentlich nur noch "Nothalt" und plötzlich eine Meldung "Rückmeldung der MS 1: xxxxxxxxxx" dann stürzt die Märklin Sofware final ab.

Den Absturz der Märklin Software würde ich so interpretieren, daß die Parameter der zuletzt empfangenen CAN Nachricht ungültig und außerhalb des dokumentierten Breichs liegen (z.B. DLC > 8 o.ä.). Wenn es da in der Software keine Überprüfung auf gültige Werte gibt, können Abstürze die Folge sein. Ich hab bisher noch nicht mit dem CanView getract. Aber "Rückmeldung MS 1" sollte doch eigentlich nicht in der Kommunikation MS2 - CS2.exe auftreten? Ich hab bei mir keine MS1 Nachrichten mit der MS2.

Auch wenn mir Stephan widersprochen hat, sieht das für mich sehr deutlich danach aus, daß hier ein CAN Frame "verschoben" gelesen wurde. Das würde dann zu den ungültigen und falsch interpretierten Daten führen. Und die Ursache dafür können tatsächlich verlorene Bytes sein. Wenn die Software von Andreas nicht per Timeout nicht komplett gelesene Frames verwirft (oder das Timeing gerade ungünstig war), passiert genau das. Das Problem könnte dann unter hoher Last auftreten. Evtl. auch als Folge eines Hardwareproblems.

Kannst du mal per Wireshark einen Netzwerktrace auf dem Loopback Interface machen? Dann sieht man sowohl die empfangenen Bytes als auch den Timestamp dazu.

Tschüß
Michael

Hallo Stephan,

Quote

Falls es ohne die MS2 sauber funzt, schlage ich als nächstes ein Reset der MS2 auf Werkseinstellungen vor (wenn sie alleine am Bus ist, Gleise nicht angeschlossen, damit sich nicht sofort nach dem Reset eine mfx-Lok anmelden tut). Dann MS2 ab vom Bus, Gleise anschließen, CS2.exe starten, Gleisspannung einschalten, Betrieb testen, MS2 anstöpseln (ja, man kann die MS2 problemlos im laufenden Betrieb ab- und anstöpseln!) und alles nochmal probieren. Wie gesagt Orakelei, bin gespannt was sich da tun würde.

Ich denke, ein Reset der MS2 auf Werkseinstellung ist nicht nötig. Mir ist bisher nicht bekannt, daß die Software der MS2 einen Fehler hat, der korrupte CAN Nachrichten erzeugt. Auch wenn ich es natürlich nicht zu 100% ausschließen kann.

Ich kann mir vorstellen, daß beim Betrieb ohne MS2 das Problem nicht auftritt. Mit der cs2.exe als Master geht ja die MS2 in den Slave Modus und sollte dann die Loknamen von der cs2.exe abfragen. Dabei dürfte kurzzeitig ein höherer Traffic auf dem CAN Bus auftreten. das wäre für mich sehr plausibel, daß dann ein solches Problem auftreten kann. Ohne MS2 fehlt dieser Traffic.

Deshalb interessiert mich zuerst mal der Netzwerktrace, um mir die CAN Nachrichten anzuschauen. Danach kann man weiter in eine bestimmte Richtung orakeln.

Tschüß
Michael

P.S.
Ich kann den Trace dann aber erst nach Weihnachten auswerten.

Hei Michael,

ich orakel ja auch nur rum. Meine Vermutung war, dass die CS2.exe eventuell nicht die gleichen Parameter (bzw. Adresse, ID) von mfx-Loks nutzt wie die MS2. Das gibt zB unter Rocrail auch nen Kuddelmuddel und führt dazu, dass Rocrail die Loks nicht mehr steuern kann, wohl aber die MS2. DAS wiederum weiß ich aus eigener Erfahrung, und aus dem Rocrail-Forum kommt dazu die Lösung. Passiert nur unter mfx, ich weiß ja nicht was Thomas fährt. War nur ein Ansatz.

Hätte die MS2 einen Bug, würde der Reset den ja auch gar nicht beheben.

Gruß Stephan

3-Leiter-Spielbahner, Anlagepläne liegen derzeit wegen Umbau im Haus auf Eis, sonst eigentlich: C-Gleis, Rocrail, CS2 mit Booster zum reinen Fahren, PC-Schnitte + Gleisreporter zum Melden, Intellibox mit Delta-Boostern zum Schalten und für alles andere.

Und ich ergänze dann auch gleich noch, was das Problem mit Rocrail+MS2 unter mfx ist:

Es gibt 2 Betriebsmöglichkeiten:

1. Rocrail übernimmt die mfx-Anmeldungen neuer Loks, die MS2 nutzt die Datenbank von Rocrail. (Rocrail = Master)
2. umgekehrt.

Bei 1. ist das Problem, dass wenn Rocrail nicht aktiv ist, man eine Lok neu aufs Gleis setzt, die MS2 der Lok eine ID zuweist. Startet man dann Rocrail, erhält die Lok von Rocrail ebenso eine ID. Diese muss nicht zwingend die gleiche sein. Und dann gehts schief. In der Anleitung zu Rocrail, Zentrale "mgbox", ist das so beschrieben. Rocrail muss in dieser Betriebsart zuerst gestartet werden, und dann muss per Rocrail die Gleisspannung eingeschaltet werden, dann funzt das.

Vielleicht haben CS2.exe und MS2 das selbe Problem miteinander, da die MS2 sich zum Master ernennt, wenn kein anderer widerspricht. Diese Situation kann an einer echten CS2 mit angeschlossener MS2 ja nicht vorkommen, so dass eine MS2 auf so eine Umgebung softwaretechnisch nicht vorbereitet zu sein braucht.

Gruß Stephan

3-Leiter-Spielbahner, Anlagepläne liegen derzeit wegen Umbau im Haus auf Eis, sonst eigentlich: C-Gleis, Rocrail, CS2 mit Booster zum reinen Fahren, PC-Schnitte + Gleisreporter zum Melden, Intellibox mit Delta-Boostern zum Schalten und für alles andere.

Hallo Stephan,

Quote

Vielleicht haben CS2.exe und MS2 das selbe Problem miteinander, da die MS2 sich zum Master ernennt, wenn kein anderer widerspricht. Diese Situation kann an einer echten CS2 mit angeschlossener MS2 ja nicht vorkommen, so dass eine MS2 auf so eine Umgebung softwaretechnisch nicht vorbereitet zu sein braucht.

Die cs2.exe sendet Pings mit dem Gerätetyp 0xeeee. Wenn diese Pings von der MS2 empfangen werden, dann geht die MS2 in den Slave Modus, da sie denkt, sie wäre an eine CS2 angesteckt. Das hab ich bei mir schon beobachtet und in meiner Software für den ARM Minicomputer berücksichtigen müssen, wenn die MS2 für die Lokanmeldung zuständig sein soll. Das dürfte genauso wie mit einer richtigen CS2 funktionieren.

Tschüß
Michael

Hi Stephan,

Quote

ich orakel ja auch nur rum.

ich ja auch ;-)

Quote

Meine Vermutung war, dass die CS2.exe eventuell nicht die gleichen Parameter (bzw. Adresse, ID) von mfx-Loks nutzt wie die MS2. Das gibt zB unter Rocrail auch nen Kuddelmuddel und führt dazu, dass Rocrail die Loks nicht mehr steuern kann, wohl aber die MS2. DAS wiederum weiß ich aus eigener Erfahrung, und aus dem Rocrail-Forum kommt dazu die Lösung. Passiert nur unter mfx, ich weiß ja nicht was Thomas fährt. War nur ein Ansatz. Hätte die MS2 einen Bug, würde der Reset den ja auch gar nicht beheben.

Das ist klar, 2 Instanzen für die Lokanmeldung können nicht funktionieren. Aber die Fehlerbeschreibung paßt meiner Meinung nach nicht so gut auf diesen Fall. Es dürfte für den Fall keinen Einfluß auf das Schalten der Weichen geben. Ich würde dann erwarten, daß sich Lokfunktionen, Fahrtrichtung und Geschwindigkeit von der cs2 nicht mehr steuern lassen und nicht noch die Geschwindigkeit. Bei einer falschen ID darf gar nichts mehr für die Lok gehen.

Zuerst war es auch nur eine Vermutung, die passen könnte, aber nicht muß. Aber mit den Ausgaben von CanView und dem anschließenden Absturz der cs2.exe ist wohl auf jeden Fall eine korrupte CAN Message bearbeitet worden. Da bin ich mir recht sicher. Deshalb würde ich gern mal den Netzwerktrace sehen. Vielleicht kann man erkennen, ob tatsächlich Bytes verschluckt wurden. Zumindest sollte man sehen, daß eine ungültige CAN Nachricht gesendet wurde.

Tschüß
Michael

Hallo Stephan, hallo Michael,
ich werde in den nächsten Tagen weitere Tests machen und Euch informieren - schon mal Danke für die tolle Unterstützung und Fehlersuche!
Gruß und gute Nacht wünscht Thomas

Hallo Michael, hallo Stephan,
alle Test ohne MS2 und mit deaktivierten sonstigen Netzwerkkomponenten führen zum selben Ergebnis. Habe ein Protokoll mit Wíreshark erstellt. Leider weiß ich nicht wie ich das am besten übermitteln soll. Selbst ein Screenshot als png kann ich nicht einfügen. Habe es jetzt an Michael per Mail gesendet. Was mir heute Abend noch aufgefallen ist. Immer wenn ich am LapTop das WLAN aktiviere kommt es zu Störungen beim Verbindungsaufbau, meistens geht es dann nicht. Eigentlich sollte das aber mit dem Loopadapter so nicht auftreten. Irgendwas habe ich bestimmt immer noch falsch eingestellt - IT Kaufmann vor 30 Jahren gelernt und heute nichts mehr richtig an den Haken kriegen!
puh .... egal
Gruß Thomas

Hallo Thomas,

du hast Recht, der Loopback-Adapter sollte das WLAN nicht beeinflussen. Meine Empfehlung: Loopback-Adapter löschen und neu einrichten. IPv6 dabei deaktivieren und nur eine IPv4-Adresse und Netzmaske konfigurieren. WLAN nochmal testen, das muss dann trotz Loopback laufen.

Gruß Stephan

3-Leiter-Spielbahner, Anlagepläne liegen derzeit wegen Umbau im Haus auf Eis, sonst eigentlich: C-Gleis, Rocrail, CS2 mit Booster zum reinen Fahren, PC-Schnitte + Gleisreporter zum Melden, Intellibox mit Delta-Boostern zum Schalten und für alles andere.

Hallo,
sorry für die schlechte Formulierung - das WLAN läuft prima, aber der Loopadapter und der Verbindungsaufbau zur CC geht dann nur noch sporadisch!
Thomas