[smf]

Hallo zusammen,

meine Gleisbox schaltet nach bisher nicht erkennbarem Muster ab, wenn ich eine Weiche schalten will. Je mehr Weichen geschaltet werden, desto wahrscheinlicher wird es, und wenn der Fehler aufgetreten ist, scheint es danach gehäuft zu sein. Mal funktioniert es zehn Minuten problemlos, dann wieder drei Abschaltungen in zwei Minuten.

Setup: Gleisbox an C-Gleis, fünf Weichen mit integriertem Dekoder, Versorgung des Antriebs aber über eigenes Netzteil. Der Schaltbefehl wird jeweils ausgelöst über eigene Software, die Abschaltung der Gleisbox wird von dieser gemeldet über die meines Erachtens etwas merkwürdige CAN-Botschaft SYSTEM-STOP mit DLC=4 (laut Doku muss DLC=5 sein, m.E. sollte es kein SystemCommand mit DLC=4 geben, oder?!?).

Hat jemand so etwas schon mal beobachtet? Wenn ja: kann man etwas dagegen tun? Aktuell sende ich halt SYSTEM-GO, dann läuft's wieder...

Vielen Dank im Voraus und Grüße
Stefan

[bertr2d2]

Hallo Stefan,

Zitat

---

Hallo zusammen,

meine Gleisbox schaltet nach bisher nicht erkennbarem Muster ab, wenn ich eine Weiche schalten will. Je mehr Weichen geschaltet werden, desto wahrscheinlicher wird es, und wenn der Fehler aufgetreten ist, scheint es danach gehäuft zu sein. Mal funktioniert es zehn Minuten problemlos, dann wieder drei Abschaltungen in zwei Minuten.

Setup: Gleisbox an C-Gleis, fünf Weichen mit integriertem Dekoder, Versorgung des Antriebs aber über eigenes Netzteil. Der Schaltbefehl wird jeweils ausgelöst über eigene Software, die Abschaltung der Gleisbox wird von dieser gemeldet über die meines Erachtens etwas merkwürdige CAN-Botschaft SYSTEM-STOP mit DLC=4 (laut Doku muss DLC=5 sein, m.E. sollte es kein SystemCommand mit DLC=4 geben, oder?!?).

Hat jemand so etwas schon mal beobachtet? Wenn ja: kann man etwas dagegen tun? Aktuell sende ich halt SYSTEM-GO, dann läuft's wieder...

---

kannst Du uns einen Mitschnitt der CAN Pakete geben, in etwa so ?:

1
2
 

00008B50  05  00 00 00 00 00
0001533C  05  00 00 00 00 00
 

Ein Überlast klingt am plausibelsten. Aber würde so aussehen, wie Du bereits gesagt hast (DLC 5):
(CS2.exe mit GFP Simulator)

1
2
 

  40.233 --> *00015c3c  06  43 54 1c 60 0a 01  #  System a uid=43541c60 Ueberlast kanal=1
  40.244 --> *00015c3c  05  43 54 1c 60 00     #  System a uid=43541c60 Stop
 

Welche Software-Version hat Deine Gleisbox ?

Gruß

Gerd

[smf]

Hallo Gerd,

vielen Dank für Deine Antwort. Das Paket habe ich nicht abgespeichert, daher weiß ich (momentan) den Hash-Wert nicht mehr - das muss ich nochmal aufnehmen. Normalerweise wäre Stopp bei mir

1
 

00 00 736B 05 00000000 00000000
 

Das wird aber nicht ausgelöst, auch nicht bei Überlast (selbst bei "vollem" Kurzschluss). Die erwähnte sporadische Nachricht von der Gleisbox lautet:

1
 

00 00 xxxx 04 00000000 00000000
 

Gleisbox-Softwarestand ist 1.39 - den habe ich nach einem MS2-Update von der aktuellen CS3 auf die Gleisbox gespielt. Vielleicht war das das Problem...

Viele Grüße - Stefan

[bertr2d2]

Hallo Stefan,

Zitat

---

Hallo Gerd,

vielen Dank für Deine Antwort. Das Paket habe ich nicht abgespeichert, daher weiß ich (momentan) den Hash-Wert nicht mehr - das muss ich nochmal aufnehmen. Normalerweise wäre Stopp bei mir

1
 

00 00 736B 05 00000000 00000000
 

Das wird aber nicht ausgelöst, auch nicht bei Überlast (selbst bei "vollem" Kurzschluss). Die erwähnte sporadische Nachricht von der Gleisbox lautet:

1
 

00 00 xxxx 04 00000000 00000000
 

---

am besten, Du schneidest alles nochmal mit und postest nochmal das Ergebnis. Ein Zeitstempel für jedes CAN-Frame wäre auch sehr hilfreich.

Zitat

---

Gleisbox-Softwarestand ist 1.39 - den habe ich nach einem MS2-Update von der aktuellen CS3 auf die Gleisbox gespielt. Vielleicht war das das Problem...

---

1.39 passt. Das ist die aktuellste Version und IMHO auch stabil.

Gruß

Gerd

[smf]

Hallo Gerd,

vielen Dank für die schnelle Antwort. Nochmalige Aufnahme mit Zeitstempeln erfolgt voraussichtlich am Donnerstag, dann habe ich wieder Zugriff auf die Bahn...

Viele Grüße - Stefan

[smf]

So, heute Nachmittag konnte ich testen. Der Abschaltbefehl war heute System-Stop mit DLC=8 und nicht mit DLC=4, und es hat offenbar etwas mit dem Timing zu tun: wenn ich in meiner Software alle Pakete anzeige, wird diese minimal verzögert und der Abschaltbefehl kommt nicht. Zeige ich keine Pakete an, schaltet die Gleisbox irgendwann innerhalb von wenigen Minuten "zuverlässig" ab. Dies habe ich mit einer zusätzlichen CAN-Schnittstelle aufgezeichnet, auch das Timing ist drin. Die entsprechende Aufbereitung schaffe ich aber nicht mehr vor dem Abendessen.

[smf]

...und hier nun die Auswertung einer der Aufnahmen des unbeabsichtigten Abschaltens (links die bereinigte Ausgabe des mhs-TinyCan-Monitor und rechts mit Erklärung):

1
2
3
4
5
6
7
8
9
10
11
12
13
 

46.057; 00080300; 6; 00 00 00 02 01 2C        ; 00 08 0300 06 00000002 012C0000: MSG set loc speed locId=0002, speed=300
46.058; 00094B77; 6; 00 00 00 02 01 2C        ; 00 09 4B77 06 00000002 012C0000: RSP set loc speed locId=0002, speed=300
47.831; 00236727; 8; 00 01 00 03 00 01 05 0A  ; 00 23 6727 08 00010003 0001050A: RSP S88 event id=010003, devId=01, pinId=003, old=0, new=1, time=050A
47.874; 00160300; 6; 00 00 30 01 01 01        ; 00 16 0300 06 00003001 01010000: MSG switch equipment equId=3001, pos=1, power=1
47.874; 00080300; 6; 00 00 40 08 02 BC        ; 00 08 0300 06 00004008 02BC0000: MSG set loc speed locId=4008, speed=700
47.874; 00000300; 5; 00 00 00 02 03           ; 00 00 0300 05 00000002 03000000: MSG loc emergency stop locId=0002
47.875; 00000300; 5; 00 00 00 02 03           ; 00 00 0300 05 00000002 03000000: MSG loc emergency stop locId=0002
47.875; 00094B77; 6; 00 00 40 08 02 BC        ; 00 09 4B77 06 00004008 02BC0000: RSP set loc speed locId=4008, speed=700
47.876; 00014B77; 5; 00 00 00 02 03           ; 00 01 4B77 05 00000002 03000000: RSP loc emergency stop locId=0002
47.876; 00014B77; 5; 00 00 00 02 03           ; 00 01 4B77 05 00000002 03000000: RSP loc emergency stop locId=0002
47.877; 00014B77; 8; 00 00 00 00 00 00 00 00  ; 00 01 4B77 08 00000000 00000000: RSP system stop
 
 

Das loc-emergency-stop sendet mein Programm zweimal, da ich aktuell noch nicht prüfe, ob meine Daten bestätigt werden, und dann bei emergencyStop durch zweimaliges Senden auf Nummer Sicher gehen möchte. Die beiden Antworten kommen noch durch, und eine Millisekunde später sendet die Gleisbox das RSP-system-stop, womit auf dem Gleis alles steht. Das Verhalten war heute spätestens nach drei Minuten reproduzierbar.

Bei der Variante, dass mein Programm selbst die Pakete auf der GUI ausgibt, trat das Problem in über einer Stunde nicht auf. Es scheint also zu funktionieren, wenn die Nachrichtenrate auf eine Nachricht innerhalb von etwa ein bis zwei Millisekunden begrenzt wird. Dann kommt zum Beispiel auch das RSP-loc-emergency-stop auf die erste MSG vor Absenden der zweiten MSG. Eine genaue Versuchsreihe dazu habe ich heute nicht mehr geschafft, da ich mich heute erst mal zwei Stunden damit beschäftigt habe, warum das Abschalten "plötzlich" nicht mehr auftritt... Insbesondere wäre mir nicht bewusst gewesen, dass da irgendetwas "unzulässig" wäre (so habe ich z.B. in der CAN-Doku gelesen, dass bei Stream-Operationen auf die jeweilige Antwort gewartet werden muss, log-emergency-stop fällt ja aber nicht in diese Kategorie).

Ich bin für jeden Tipp dankbar - einfach "auf gut Glück" zu verzögern (um wie lange, oder bis die Antwort kommt, oder...?) fände ich sehr unbefriedigend.

[bertr2d2]

Hallo Stefan,

Zitat

---

Ich bin für jeden Tipp dankbar - einfach "auf gut Glück" zu verzögern (um wie lange, oder bis die Antwort kommt, oder...?) fände ich sehr unbefriedigend.

---

ich verwende momentan ein Delay von 10ms zwischen einzelnen CAN-Frames, da bei mir die MS1 ausgestiegen war, wenn zu viele CAN-Frames direkt hinter einander kamen. CAN Frames zu wiederholen, damit sie auf jeden Fall ankommen finde ich überflüssig bzw. kontraproduktiv. Zudem achte ich darauf, das der CAN-Bus nicht zu stark belastet wird. Wenn z.B. Anfragen zur Konfiguration über Netzwerk eintreffen (CAN über Ethernet) werden diese nicht auf den CAN-Bus dupliziert, sondern gehen auch über Netzwerk wieder raus.
Ich muss gestehen, das bei mir eher externe Programme wie Rocrail oder CS2.exe zum Einsatz kommen und von daher das Risiko von starker CAN-Bus Belastung selten sind.

Das von Dir beobachtete Problem der Gleisbox hatte ich bisher nicht feststellen können.

Gruß

Gerd

[smf]

Hallo Gerd,

vielen Dank für Deine Rückmeldung. 10ms delay wären ja in der Tat deutlich mehr als zwei Nachrichten pro Millisekunde. Wenn Du sonst ausgestiegene MS1 beobachtet hast, spräche ja einiges dafür, dass die Gleisbox "einfach auch nicht mehr packt". Dann werde ich experimentieren, wahrscheinlich reicht bei mir ja schon ein Delay von 1-2 ms. Ich werde berichten, was die Tests ergeben (könnte allerdings etwas dauern). Außerdem werde ich Deiner Meinung folgen und die Nachrichten nicht mehr replizieren. Allein das sollte die Problematik der extrem schnellen Nachrichten etwas entschärfen.

Bei mir läuft "komplett alles" mit graphischer Oberfläche auf einem BananaPi oder zum Testen auf dem Laptop mit TinyCAN. Bei Interesse kann ich die Software gerne hier vorstellen, derzeit ist sie halt noch "sehr beta" - ich nehme aber an, hier sind alle gut versorgt.

Viele Grüße - Stefan

[bertr2d2]

Hallo Stefan,

Zitat

---

Hallo Gerd,

vielen Dank für Deine Rückmeldung. 10ms delay wären ja in der Tat deutlich mehr als zwei Nachrichten pro Millisekunde. Wenn Du sonst ausgestiegene MS1 beobachtet hast, spräche ja einiges dafür, dass die Gleisbox "einfach auch nicht mehr packt". Dann werde ich experimentieren, wahrscheinlich reicht bei mir ja schon ein Delay von 1-2 ms. Ich werde berichten, was die Tests ergeben (könnte allerdings etwas dauern).

---

das Ergebnis interessiert mich sehr.

Zitat

---

Außerdem werde ich Deiner Meinung folgen und die Nachrichten nicht mehr replizieren. Allein das sollte die Problematik der extrem schnellen Nachrichten etwas entschärfen.

---

Ich denke, das nimmt schon ein gutes Stück Last runter.

Zitat

---

Bei mir läuft "komplett alles" mit graphischer Oberfläche auf einem BananaPi

---

Nutzt Du nicht den CAN Teil des BPi ? Mit den canutils hat man auch eine prima Analyse Tool Sammlung.

Zitat

---

oder zum Testen auf dem Laptop mit TinyCAN. Bei Interesse kann ich die Software gerne hier vorstellen, derzeit ist sie halt noch "sehr beta" - ich nehme aber an, hier sind alle gut versorgt.

---

ja, sicherlich. Aber interessieren tut es mich auf jeden Fall.

Gruß

Gerd

[smf]

Hallo Gerd,

ja, ich nehme den CAN-Anschluss des BPi, die canutils habe ich aber bislang nicht benutzt. Ich habe nur einen selbst geschriebenen Mini-Treiber als Wrapper für mein Programm, welches dann unabhängig von der eigentlichen Schnittstelle arbeitet - aktuell unterstütze ich eben BananaPi-CAN, MHS-TinyCAN und Ethernet (zum Beispiel an einer CS2). Außer den Hardware-Sachen ist alles in Java geschrieben, so dass es auf PC unter Windows, Linux oder eben auch auf einem Banana Pi direkt läuft. Die Software stelle ich dann bei Gelegenheit in einem eigenen Thread vor - da es wohl noch etwas dauert, wollte ich anbei mal ein Screenshot des aktuellen Standes anhängen - leider sagt das Forum aber bei gif, png und jpg "ungültige Dateiendung". Da muss ich also wohl erst noch tiefer ins Forum einsteigen...

Viele Grüße - Stefan

[bertr2d2]

Hallo Stefan,

Zitat

---

Hallo Gerd,

ja, ich nehme den CAN-Anschluss des BPi, die canutils habe ich aber bislang nicht benutzt. Ich habe nur einen selbst geschriebenen Mini-Treiber als Wrapper für mein Programm, welches dann unabhängig von der eigentlichen Schnittstelle arbeitet - aktuell unterstütze ich eben BananaPi-CAN, MHS-TinyCAN und Ethernet (zum Beispiel an einer CS2).

---

der Mini-Treiber würde mich interessieren. Kann man den irgendwo einsehen ? Der A20 CAN-Controller hat so seine Macken. Ich kann Dir nur empfehlen, Deinen CAN-Wrapper auf SocketCAN zu trimmen. SocketCAN ist relativ einfach - siehe can2eth. Der Vorteil: Du hast alle Linux SocketCAN Systeme gleich mit eingefangen. BTW: CS3 nutz auch SocketCAN.

Zitat

---

Außer den Hardware-Sachen ist alles in Java geschrieben, so dass es auf PC unter Windows, Linux oder eben auch auf einem Banana Pi direkt läuft. Die Software stelle ich dann bei Gelegenheit in einem eigenen Thread vor - da es wohl noch etwas dauert, wollte ich anbei mal ein Screenshot des aktuellen Standes anhängen - leider sagt das Forum aber bei gif, png und jpg "ungültige Dateiendung". Da muss ich also wohl erst noch tiefer ins Forum einsteigen...

---

Bin gespannt darauf

Gruß

Gerd

[smf]

Hallo Gerd,

oh je, ich hab da irgendeine japanische Seite mit Anleitung für can4linux benutzt... Anbei mein Wrapper, da habe ich aber vorher noch drin rumeditiert und bin noch nicht fertig mit Testen nach dem Editieren...

Viele Grüße - Stefan

PS: die ZIP-Datei konnte ich problemlos anhängen...

[smf]

Hallo zusammen,

hm, also gezipped darf ich das gif hochladen, das eigentliche gif-Bild nicht. Anbei also mal ein Screenshot vom aktuellen Stand meiner Software auf der sehr einfach gehaltenen Testbahn.

Viele Grüße - Stefan

[Erich Müller]

Hallo Stefan,

Bilder musst du bei einem Bilderhoster oder auf eigenem Webspace hochladen und dann hier mit

1
 

[img](URL des Bildes)[/img]
 

einbinden. Dabei darf die längere Seite des Bildes maximal 1024px messen.

[smf]

Hallo Erich,

ah ok. Das mit den 1024 Punkten hatte ich gelesen, das mit dem externen Hoster aber wohl verpasst. ops:

Viele Grüße - Stefan

[smf]

Hallo Gerd,

ich konnte bereits heute Nachmittag testen. Mit 1ms Delay und abgeschalteter Duplizierung trat der Fehler auch nach über anderthalb Stunden nicht mehr auf.

Vielen Dank insbesondere für den Tipp, mal mit Timing und Absender aufzunehmen - das hat meine Software so weit verzögert, dass das veränderte Verhalten den entscheidenden Hinweis auf ein tatsächlich vorliegendes Timing-Problem gab. Ich hab ja mit viel gerechnet (von thermischen Problemen bis hin zu Stromschwankungen), aber dass die Gleisbox einfach nicht so viele Pakete so schnell will...

Viele Grüße - Stefan

[st-oldie]

Hallo Stefan,

Zitat

---

10ms delay wären ja in der Tat deutlich mehr als zwei Nachrichten pro Millisekunde. Wenn Du sonst ausgestiegene MS1 beobachtet hast, spräche ja einiges dafür, dass die Gleisbox "einfach auch nicht mehr packt". Dann werde ich experimentieren, wahrscheinlich reicht bei mir ja schon ein Delay von 1-2 ms. Ich werde berichten, was die Tests ergeben (könnte allerdings etwas dauern).

---

Ich hab von einem Entwickler den Hinweis bekommen, daß die Gleisbox nur eine begrenzte Anzahl CAN Msgs zwischenspeichern kann. Die Queue für Fahr- und Schaltbefehle soll laut Experimenten 3 Messages umfassen, wenn ich mich richtig erinnere. Sein Vorschlag war, nicht eine feste Zeit zu warten sondern die Nachrichten in eine Queue zu packen und wenn die Nachricht von der Gleisbox mit gesetztem Respons Bit zurückgeschickt wird, die nächste Nachricht zu schicken. Ich hab den Vorschlag in meiner Software umgesetzt und bisher keine Probleme gesehen. Das Verfahren sorgt dafür, daß erst dann die nächste Nachricht geschickt wird, wenn die vorherige bearbeitet ist. Damit ist man nicht an das feste Zeitraster gebunden sondern kann die CAN Msgs so schnell versenden, wie sie bearbeitet wrden können.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat

---

Ich hab von einem Entwickler den Hinweis bekommen, daß die Gleisbox nur eine begrenzte Anzahl CAN Msgs zwischenspeichern kann. Die Queue für Fahr- und Schaltbefehle soll laut Experimenten 3 Messages umfassen, wenn ich mich richtig erinnere. Sein Vorschlag war, nicht eine feste Zeit zu warten sondern die Nachrichten in eine Queue zu packen und wenn die Nachricht von der Gleisbox mit gesetztem Respons Bit zurückgeschickt wird, die nächste Nachricht zu schicken.

---

ah, das erklärt einiges Vielen Dank für die Info.

Gruß

Gerd

[smf]

Hallo Michael,

aha, in der Tat sehr interessant. Vielen Dank für den Tipp!

Viele Grüße - Stefan

[smf]

Zitat

---

Hallo Stefan,

Zitat

---

Hallo Gerd,
Bei Interesse kann ich die Software gerne hier vorstellen, derzeit ist sie halt noch "sehr beta" - ich nehme aber an, hier sind alle gut versorgt.

---

ja, sicherlich. Aber interessieren tut es mich auf jeden Fall.

Gruß

Gerd

---

Hallo zusammen,

für die Mitleser hier: ich habe einen neuen Thread erstellt unter

viewtopic.php?f=7&t=147280

Viele Grüße - Stefan