[bertr2d2]

Hallo Michael,

ich habe Deine Mail erhalten und die Libs "scanner" und "inipars" erneuert. Das Ergebnis (wie zu erwarten war) ist unverändert: "mrzentrale" stürtzt nach einigen Sekunden ab.

Ich habe gdb auf dem BPi installiert und kann den Fehler jetzt reproduzieren und die Stelle lokalisieren.

Hier der Output von GDB:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 

FSM: evaluate lokname cfg
[lok]
    .name=335 105-3 DB
     [lok]
    .name=
[numloks]
        .wert=1
        ardvers=anew paragraph lok in lok cfg
lok paragraph in lok cfg
new value name=335 105-3 DB in lok cfg
lok name 0 in lok cfg
new paragraph lok in lok cfg
lok paragraph in lok cfg
new value name= in lok cfg
lok name 1 in lok cfg
new paragraph numloks in lok cfg
numloks paragraph in lok cfg
new value wert=1 in lok cfg
number of loks in lok cfg
number of loks in lok cfg is 1
end of lok cfg
request lokinfo 0 >335 105-3 DB< from 1
FSM: new state 3
 
Program received signal SIGSEGV, Segmentation fault.
FsmDo (Data=0xb6ff0042, Data@entry=0xb6fff7b0, SignalNr=<optimized out>, 
SignalData=SignalData@entry=0xbefffc9c) at fsm_do.c:12
12	      FsmSetState(Data, NewState);
 
 

Die Stelle, wo das Programm aussteigt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 

SignalData=SignalData@entry=0xbefffc9c) at fsm_do.c:12
12         FsmSetState(Data, NewState);
######################
# fsm_do.c
 
#include "fsm.h"
 
void FsmDo(FsmStruct *Data, int SignalNr, void *SignalData)
{  int NewState;
    SignalFunctionsType SignalFunctions;
    StateFktType SignalFunction;
 
    SignalFunctions = FsmGetFunctions(Data)[FsmGetState(Data)];
    SignalFunction = SignalFunctions[SignalNr];
    NewState = SignalFunction(FsmGetPriv(Data), SignalData);
    if (NewState != STATE_NO_CHANGE)
       FsmSetState(Data, NewState);
}
 
 

Ein weitere Sache ist mir aufgefallen. Hier die letzten Frames auf dem CAN-Bus:

1
2
3
4
5
6
7
8
9
 

  (2016-01-04 09:41:13.339503)  can0  TX - -  00400300   [8]  6C 6F 6B 69 6E 66 6F 00
  (2016-01-04 09:41:13.340075)  can0  TX - -  00400300   [8]  33 33 35 20 31 30 35 2D  | 335 105- |
  (2016-01-04 09:41:13.340700)  can0  TX - -  00400300   [8]  33 20 44 00 00 00 00 00  | 3 D      |
  (2016-01-04 09:41:13.341393)  can0  RX - -  00410300   [8]  33 20 44 00 00 00 00 00
  (2016-01-04 09:41:13.341907)  can0  RX - -  00420300   [6]  00 00 00 10 F3 A3
  (2016-01-04 09:41:13.342472)  can0  RX - -  00420300   [8]  5B 6C 6F 6B 6F 6D 6F 74
  (2016-01-04 09:41:13.343051)  can0  RX - -  00420300   [8]  69 76 65 5D 0A 20 20 20
 
 

Die Kennung der Lok ist "335 105-3 DB" aber das "B" ist verschluckt. Das muss kein Problem darstellen - komisch ist es aber.

Gruß

Gerd

[st-oldie]

Hallo Rainald,

Zitat von Rainald Adamski

---

ich habe einige Fragen zu der Diskussion. Leider ist mir das technische Niveau zu hoch.

---

Aktuell geht es hier auch um eine Fehlersuche. Und damit ist naturgemäß der Teniklevel sehr hoch bzw. man ist sehr bei Internas.

Zitat von Rainald Adamski

---

Ich bin auf der Suche nach einer Zentrale, die MM, DCC und mfx sprechen kann. Vorab, die die CS ist mir oversized, da ich weiterhin mit einem PC fahren möchte. Derzeit im Einsatz WDP 8.x, IB 1 upgedated, RM über S88-N, 4 Boosterkreise 3xTAMS B3 zum Fahren, 1 x Delta zum Schalten MM
In Zukunft möchte ich mit iTrain fahren, Rocrail ist mir zu kryptisch. Die RM kann ich direkt an den Rechner anschließen, Littfinski HSI oder Tams.

Jetzt konkret zu meiner Frage,
Kann ich meine Vorstellung mit der diskutierten Hardware (BBB, MS2) und meiner installierten HArdware realisieren?
Was benötige ich für zusätzliche Hardware?
Was benötige ich für Software?
Als Handfahrgeräte sind Tablet und MS 2 vorhanden.
Gibt es ein "how to"?

---

Leider kenne ich nicht alle Geräte bzw. die Features. Deshalb kann ich so auf Anhieb nichts dazu sagen. Aber etwas allgemeiner geantwortet:

Wir haben hier 2 Threads über eine solche Lösung, die sich aber in den Eigenschaften etwas unterscheiden. Die grundsätzliche Frage ist wohl, wo sollen bei dir Loks und Magnetartikel verwaltet werden? Macht das dein Steuerungsprogramm auf dem PC und ist die MS2 auch nur ein Slave, der die Daten vom PC übernimmt? Dann ist die [url viewtopic.php?f=7&t=119807]Lösung von Gerhard[/url] möglicherweise das passende. Soll die MS2 die Loks verwalten und lediglich an Ethernet angeschlossen werden? Dann könnte meine Lösung hier das Richtige sein (wenn wir den Grund für den Absturz gefunden haben).

Dazu kommt noch die Frage, wieviel Erfahrung du mit Löten, Konfiguration von Linux, Software compilieren hast. Komplett Plug&Play ist keine Lösung. Sowohl Gerhards als auch meine Software läßt sich erst mal prinzipiell auf jeder Plattform betreiben. Ich hatte mich für das BBB entschieden, weil es damals eines der preiswertesten ARM Boards mit CAN und Ethernet war. Gerhard hat jetzt das BPi gewählt, weil es noch preisgünstiger ist. Für den CAN Anschluß benötigst du bei beiden Boards einen Transceiver. Da ist für dich die Frage, ob es eine kommerzielle Lösung gibt und sein muß oder ob du auch basteln kannst bzw. das jemand für dich machen kann. Und bei der Software ist die Frage, ob du ein fertiges SD Karten Image brauchst oder dir das selbst zusammenstellen kannst. Wobei Gerhard meine Software auch in sein Image integriert hat. Es wäre sicherlich kein Problem, auch seine Software in mein Image zu integrieren.

Tschüß
Michael

[st-oldie]

Hallo Martin,

Zitat von Frankenbahn

---

Zitat von bertr2d2

---

Riecht nach Strings, die ein Byte zu kurz (fehlendes Byte für Null Terminierung ?) angelegt worden sind ...

---

Ich bin zwar kein Linux-Entwickler und seit 15 Jahren entwickle ich gar nichts mehr, aber mir sieht das aus der Ferne auch genau nach diesem Problem aus.

---

Ich würde mich nicht zu sehr nur auf fehlenden Platz für das Nullbyte fokussieren. Eignetlich sollte ich solche Anfängerfehler nicht mehr machen. Uneigentlich kann es natürlich dennoch passieren. Ich lege ja auch diverse Puffer an, um z.B. die CFG Daten der MS2 "aufzusammeln", Strukturen mit Infos über Loks, Magnetartikel, ... zu speichern. Da gibt es genug Raum, wo ein Puffer möglicherweise zu klein sein kann.

Zitat von Frankenbahn

---

Führt zu extrem schwer zu findenden Fehlern, die sich ganz boshaft auswirken.
Gerade auf dem Stack hat das oft dazu geführt, dass das Lowbyte der Rücksprungadresse mit 0 überschrieben wurde und der Code danach nur ungefähr an der richtigen Stelle fortgesetzt wurde

---

Oh ja, da kann ich auch ein Lied von singen. Wobei zu kleine Puffer auf dem Stack eigentlich sich eigentlich leichter finden lassen dürften. Und da auch mein System das Fehlverhalten zeigen sollte.

Zitat von Frankenbahn

---

Blöderweise konnte man das im Debugger immer nicht feststellen, weil der Compiler im Debug-Modus Füllbytes eingefügt hatte.

---

Bei meinem Letzten Arbeitgeber hatte wir deshalb die Debugversion immer mit einer Debugspeicherverwaltung übersetzt. Die hat diese Extrabytes mit einem Prüfmuster überschrieben und damit solche Fehler erkannt.

Zitat von Frankenbahn

---

Viel Erfolg bei der Fehlersuche

---

Danke.

Tschüß
Michael

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

ich habe Deine Mail erhalten und die Libs "scanner" und "inipars" erneuert. Das Ergebnis (wie zu erwarten war) ist unverändert: "mrzentrale" stürtzt nach einigen Sekunden ab.

---

Das war zu erwarten. Der Bugfix in inipars würde nur ein Fehlverhalten beheben, wenn ich weitere Datentypen unterstüze. Der Bug in scanner hat keine Auswirkungen.

Zitat von bertr2d2

---

Ich habe gdb auf dem BPi installiert und kann den Fehler jetzt reproduzieren und die Stelle lokalisieren.

Hier der Output von GDB:

1
2
3
4
5
6
7
8
9
 

...
request lokinfo 0 >335 105-3 DB< from 1
FSM: new state 3
 
Program received signal SIGSEGV, Segmentation fault.
FsmDo (Data=0xb6ff0042, Data@entry=0xb6fff7b0, SignalNr=<optimized out>, 
SignalData=SignalData@entry=0xbefffc9c) at fsm_do.c:12
12	      FsmSetState(Data, NewState);
 
 

---

Das ist aber eine andere Stelle. Diesmal wurden alle Loknamen aufgesammelt und versucht, für jede Lok die Lokinfo abzufragen.

Zitat von bertr2d2

---

Die Stelle, wo das Programm aussteigt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 

SignalData=SignalData@entry=0xbefffc9c) at fsm_do.c:12
12         FsmSetState(Data, NewState);
######################
# fsm_do.c
 
#include "fsm.h"
 
void FsmDo(FsmStruct *Data, int SignalNr, void *SignalData)
{  int NewState;
    SignalFunctionsType SignalFunctions;
    StateFktType SignalFunction;
 
    SignalFunctions = FsmGetFunctions(Data)[FsmGetState(Data)];
    SignalFunction = SignalFunctions[SignalNr];
    NewState = SignalFunction(FsmGetPriv(Data), SignalData);
    if (NewState != STATE_NO_CHANGE)
       FsmSetState(Data, NewState);
}
 
 

---

Das ist erst mal komisch. Denn FsmSetState() ist ein Makro, das einen skalaren Wert in die Struktur schreibt, auf die "Data" zeigt. Damit das Probleme macht, müßte "Data" korrupt sein. Da aber der Aufruf der Funktion für die Transition SignalFunction() anscheinend richtig funktioniert hat, kann eigentlich "Data" nicht korrupt sein. Wenn "Data" plötzlich korrupt ist, müßte der Stack überschrieben sein. Dann hätte ich aber erwartet, daß auch der Rücksprung nach FsmDo() fehlschlägt. Kannst du mal den Wert von "Data" von vor und nach dem Aufruf von SignalFunction() anschauen?

Zitat von bertr2d2

---

Ein weitere Sache ist mir aufgefallen. Hier die letzten Frames auf dem CAN-Bus:

1
2
3
4
5
6
7
8
9
 

  (2016-01-04 09:41:13.339503)  can0  TX - -  00400300   [8]  6C 6F 6B 69 6E 66 6F 00
  (2016-01-04 09:41:13.340075)  can0  TX - -  00400300   [8]  33 33 35 20 31 30 35 2D  | 335 105- |
  (2016-01-04 09:41:13.340700)  can0  TX - -  00400300   [8]  33 20 44 00 00 00 00 00  | 3 D      |
  (2016-01-04 09:41:13.341393)  can0  RX - -  00410300   [8]  33 20 44 00 00 00 00 00
  (2016-01-04 09:41:13.341907)  can0  RX - -  00420300   [6]  00 00 00 10 F3 A3
  (2016-01-04 09:41:13.342472)  can0  RX - -  00420300   [8]  5B 6C 6F 6B 6F 6D 6F 74
  (2016-01-04 09:41:13.343051)  can0  RX - -  00420300   [8]  69 76 65 5D 0A 20 20 20
 
 

Die Kennung der Lok ist "335 105-3 DB" aber das "B" ist verschluckt. Das muss kein Problem darstellen - komisch ist es aber.

---

Das ist komisch und sollte ein Problem darstellen. Die beiden CAN Frames mit dem Loknamen dürften die Anforderung der Lokinfo sein. Da der Lokname der Key in die Lokliste der MS2 ist, dürfte diese Anforderung kein Ergebnis liefern. In deinem Trace wird aber noch der richtige Name benutzt:

1
 

request lokinfo 0 >335 105-3 DB< from 1
 

Also muß da auf dem Weg von der Zentrale zum CAN etwas überschrieben worden sein. Da muß ich nochmals alle Funktionen überprüfen, die diese Daten übertragen ...

.. Hab es gefunden. Der Lokname wird komplett an den Client für die MS2 (mrms2) übertragen und belegt den Platz von 2 mal die Datenbytes eines CAN Frames plus abschließendes Nullbyte, also maximal 17 Bytes. Die Struktur zur Übertragung dieser Daten enthält aber nur Platz für einen kompletten CAN Frame, also 13 Bytes, da sie nur dafür ausgelegt war, einen einzelnen CAN Frame und keine anderen Daten zu übertragen.

Ich schicke dir heute Nachmittag mal einen Bugfix. Jetzt werde ich erst mal Mittag machen.

Gut, daß du auf einem anderen System testest. Ich wundere mich schon etwas, daß dieser Fehler bei mir nicht zu einem Crash geführt hat. Aber da die Struktur dynamisch angelegt wird, spielt natürlich das Verhalten der Speicherverwaltung aus der C-Lib eine Rolle. Wenn die Granulartät groß genug ist, kann es sein daß noch "Extrabytes" hinter dem angelegten Puffer frei sind und der Fehler nicht auftritt. Du hast ja eine andere C-Lib in deinem System? Auch die Länge der verwendeten Namen spielt eine Rolle. Bleiben die immer kleiner als 13 Bytes, tritt der Fehler auch nicht auf. Erst wenn man an das Limit geht, wird über das Ende des Puffers geschrieben.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Hallo Gerd,

Zitat von bertr2d2

---

Ich habe gdb auf dem BPi installiert und kann den Fehler jetzt reproduzieren und die Stelle lokalisieren.

Hier der Output von GDB:

1
2
3
4
5
6
7
8
9
 

...
request lokinfo 0 >335 105-3 DB< from 1
FSM: new state 3
 
Program received signal SIGSEGV, Segmentation fault.
FsmDo (Data=0xb6ff0042, Data@entry=0xb6fff7b0, SignalNr=<optimized out>, 
SignalData=SignalData@entry=0xbefffc9c) at fsm_do.c:12
12	      FsmSetState(Data, NewState);
 
 

---

Das ist aber eine andere Stelle. Diesmal wurden alle Loknamen aufgesammelt und versucht, für jede Lok die Lokinfo abzufragen.
...
Das ist erst mal komisch. Denn FsmSetState() ist ein Makro, das einen skalaren Wert in die Struktur schreibt, auf die "Data" zeigt. Damit das Probleme macht, müßte "Data" korrupt sein. Da aber der Aufruf der Funktion für die Transition SignalFunction() anscheinend richtig funktioniert hat, kann eigentlich "Data" nicht korrupt sein. Wenn "Data" plötzlich korrupt ist, müßte der Stack überschrieben sein. Dann hätte ich aber erwartet, daß auch der Rücksprung nach FsmDo() fehlschlägt. Kannst du mal den Wert von "Data" von vor und nach dem Aufruf von SignalFunction() anschauen?

---

Hier die Änderung:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 

#include "fsm.h"
 
void FsmDo(FsmStruct *Data, int SignalNr, void *SignalData)
{  int NewState;
    SignalFunctionsType SignalFunctions;
    StateFktType SignalFunction;
 
    SignalFunctions = FsmGetFunctions(Data)[FsmGetState(Data)];
    SignalFunction = SignalFunctions[SignalNr];
    printf("%s : before SignalFunction : 0x%08Xn", __func__, (int)Data);
    NewState = SignalFunction(FsmGetPriv(Data), SignalData);
    printf("%s : after  SignalFunction : 0x%08Xn", __func__, (int)Data);
    if (NewState != STATE_NO_CHANGE)
       FsmSetState(Data, NewState);
}
 
 

und der Output:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 

FsmDo : before SignalFunction : 0xB6F177E0
FSM: new state 2
FsmDo : after  SignalFunction : 0xB6F177E0
add client socket 4
wait for 4 fd, max 10 s
select liefert 1
read new comand frame from socket 13
FsmDo : before SignalFunction : 0xB6F177E0
FSM: evaluate lokname cfg
[lok]
    .name=335 105-3 DB
     [lok]
    .name=
[numloks]
        .wert=1
        ardvers=anew paragraph lok in lok cfg
lok paragraph in lok cfg
new value name=335 105-3 DB in lok cfg
lok name 0 in lok cfg
new paragraph lok in lok cfg
lok paragraph in lok cfg
new value name= in lok cfg
lok name 1 in lok cfg
new paragraph numloks in lok cfg
numloks paragraph in lok cfg
new value wert=1 in lok cfg
number of loks in lok cfg
number of loks in lok cfg is 1
end of lok cfg
request lokinfo 0 >335 105-3 DB< from 1
FSM: new state 3
FsmDo : after  SignalFunction : 0xB6F10042
Segmentation fault
 
 

Volltreffer, der Zeiger ist verbogen

Zitat von st-oldie

---

Gut, daß du auf einem anderen System testest. Ich wundere mich schon etwas, daß dieser Fehler bei mir nicht zu einem Crash geführt hat. Aber da die Struktur dynamisch angelegt wird, spielt natürlich das Verhalten der Speicherverwaltung aus der C-Lib eine Rolle. Wenn die Granulartät groß genug ist, kann es sein daß noch "Extrabytes" hinter dem angelegten Puffer frei sind und der Fehler nicht auftritt. Du hast ja eine andere C-Lib in deinem System? Auch die Länge der verwendeten Namen spielt eine Rolle. Bleiben die immer kleiner als 13 Bytes, tritt der Fehler auch nicht auf. Erst wenn man an das Limit geht, wird über das Ende des Puffers geschrieben.

---

Das BPi Image basiert auf OpenWRT Designated Driver (Trunk). Seit dieser Version wird musl als libc verwendet:
http://www.musl-libc.org/

Gruß

Gerd

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

Ein weitere Sache ist mir aufgefallen. Hier die letzten Frames auf dem CAN-Bus:

1
2
3
4
5
6
7
8
9
 

  (2016-01-04 09:41:13.339503)  can0  TX - -  00400300   [8]  6C 6F 6B 69 6E 66 6F 00
  (2016-01-04 09:41:13.340075)  can0  TX - -  00400300   [8]  33 33 35 20 31 30 35 2D  | 335 105- |
  (2016-01-04 09:41:13.340700)  can0  TX - -  00400300   [8]  33 20 44 00 00 00 00 00  | 3 D      |
  (2016-01-04 09:41:13.341393)  can0  RX - -  00410300   [8]  33 20 44 00 00 00 00 00
  (2016-01-04 09:41:13.341907)  can0  RX - -  00420300   [6]  00 00 00 10 F3 A3
  (2016-01-04 09:41:13.342472)  can0  RX - -  00420300   [8]  5B 6C 6F 6B 6F 6D 6F 74
  (2016-01-04 09:41:13.343051)  can0  RX - -  00420300   [8]  69 76 65 5D 0A 20 20 20
 
 

Die Kennung der Lok ist "335 105-3 DB" aber das "B" ist verschluckt. Das muss kein Problem darstellen - komisch ist es aber.

---

So, ich hab jetzt einen Patch gemacht, der das Problem des zu kleinen Puffers löst. Es waren im Gegensatz zu meiner vorherigen Mail sogar nur Platz für die 8 Datenbytes eines CAN Frames. Übertragen wurden aber maximal 17 Byte. Ich bin mit meinen Namen in der MS2 damit auch über diese Grenze hinausgekommen. Aber wenn die Granularität der Speicherverwaltung entsprechend groß ist, muß der Fehler nicht auffallen. Du könntest für einen Test mal die Headerdatei der mr_ipc Lib im mrsystem Verzeichnis patchen:

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

diff -Nru a/mr_ipc.h b/mr_ipc.h
--- a/mr_ipc.h	2015-05-08 00:38:19.000000000 +0200
+++ b/mr_ipc.h	2016-01-04 14:38:48.000000000 +0100
@@ -18,7 +18,7 @@
 
 typedef struct {
    unsigned char Dlc;
-   unsigned char Data[MR_CS2_NUM_CAN_BYTES];
+   unsigned char Data[2 * MR_CS2_NUM_CAN_BYTES + 1];
 } RawDatas;
 
 typedef struct {
 

Damit könnte auch der Absturz behoben sein, denn der war direkt nach dem Versenden dieses Puffers.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Hallo Gerd,
So, ich hab jetzt einen Patch gemacht, der das Problem des zu kleinen Puffers löst. Es waren im Gegensatz zu meiner vorherigen Mail sogar nur Platz für die 8 Datenbytes eines CAN Frames. Übertragen wurden aber maximal 17 Byte. Ich bin mit meinen Namen in der MS2 damit auch über diese Grenze hinausgekommen. Aber wenn die Granularität der Speicherverwaltung entsprechend groß ist, muß der Fehler nicht auffallen. Du könntest für einen Test mal die Headerdatei der mr_ipc Lib im mrsystem Verzeichnis patchen:

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

diff -Nru a/mr_ipc.h b/mr_ipc.h
--- a/mr_ipc.h	2015-05-08 00:38:19.000000000 +0200
+++ b/mr_ipc.h	2016-01-04 14:38:48.000000000 +0100
@@ -18,7 +18,7 @@
 
 typedef struct {
    unsigned char Dlc;
-   unsigned char Data[MR_CS2_NUM_CAN_BYTES];
+   unsigned char Data[2 * MR_CS2_NUM_CAN_BYTES + 1];
 } RawDatas;
 
 typedef struct {
 

Damit könnte auch der Absturz behoben sein, denn der war direkt nach dem Versenden dieses Puffers.

---

mit der Änderung kommt es schon vorher zum Crash:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 

ZentraleInit
load Gleisbild Pages
read geraet.vrs
new paragraph geraet in geraet.vrs
geraet paragraph in geraet.vrs
new value version= in lok cfg
neuer version Eintrag
new value minor=1 in lok cfg
minor version
new value geraet= in lok cfg
neuer geraet Eintrag
new value sernum=1 in lok cfg
serial number
new value hardvers=OpenWRT,3 in lok cfg
hardware version
end of geraet.vrs
ready for incoming comands
add client socket 4
wait for 4 fd, max 10 s
select liefert 1
read new comand frame from socket 6
FsmDo : before SignalFunction : 0xB6FFF7E0
FSM: answer ping
FSM: new state -1
FsmDo : after  SignalFunction : 0xB6FFF7E0
add client socket 4
wait for 4 fd, max 10 s
select liefert 1
read new comand frame from socket 20540
 
Program received signal SIGSEGV, Segmentation fault.
FsmDo (Data=Data@entry=0xb6fff7e0, SignalNr=20541, 
SignalData=0xbefffc9c,
     SignalData@entry=0xbefffc94) at fsm_do.c:9
9	   SignalFunction = SignalFunctions[SignalNr];
 
 

Gruß

Gerd

[Rainald Adamski]

Hallo Michael,

besten Dank für Deine schnelle und ausführliche Antwort.

Das mit der Fehlersuche habe ich erst später registriert. Sorry, daß ich da hineingeplatzt bin.
Aber da Du geantwortet hast, will ich die offenen Punkte noch kurz kommentieren.

Das Steuerungsprogramm (geplant ist iTrain) soll die Verwaltung und Steuerung übernehmen, MS 2 nur als Slave.
Löten ist kein Problem es denn SMD, da tue ich mich schwer.
Mit Kompilation und Linux habe ich so gut wie keine Erfahrung, könnte mir aber da Hilfe organisieren.

Kurz zusammengefaßt was ich suche ist ein Interface - Steuerungs-SW ala CS, Ecos etc benötige ich nicht - zwischen PC und Moba was DCC, MM und Mfx kann.
Ich schau mir mal den anderen Thread an, vielleicht werde ich ja dort noch fündig.

Nochmals danke.

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

mit der Änderung kommt es schon vorher zum Crash:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 

ZentraleInit
load Gleisbild Pages
read geraet.vrs
new paragraph geraet in geraet.vrs
geraet paragraph in geraet.vrs
new value version= in lok cfg
neuer version Eintrag
new value minor=1 in lok cfg
minor version
new value geraet= in lok cfg
neuer geraet Eintrag
new value sernum=1 in lok cfg
serial number
new value hardvers=OpenWRT,3 in lok cfg
hardware version
end of geraet.vrs
ready for incoming comands
add client socket 4
wait for 4 fd, max 10 s
select liefert 1
read new comand frame from socket 6
FsmDo : before SignalFunction : 0xB6FFF7E0
FSM: answer ping
FSM: new state -1
FsmDo : after  SignalFunction : 0xB6FFF7E0
add client socket 4
wait for 4 fd, max 10 s
select liefert 1
read new comand frame from socket 20540
 
Program received signal SIGSEGV, Segmentation fault.
FsmDo (Data=Data@entry=0xb6fff7e0, SignalNr=20541, 
SignalData=0xbefffc9c,
     SignalData@entry=0xbefffc94) at fsm_do.c:9
9	   SignalFunction = SignalFunctions[SignalNr];
 
 

---

Ich krieg langsam die Krise!!!!

Aber einer geht noch: hast du auch alle Binaries neu gebuildet? Ich hab in den Makefiles der einzelnen Daemonen keine Abhängigkeit zu den Libraries im libs Verzeichnis. Das war mir dann zuviel. Wenn man die API der Libs wie auch z.B. die verwendeten Strukturen ändert, muß man die ganzen Daemonen neu compilieren. Bei interen Änderungen reicht neu linken. Da der Absturz beim Zugriff auf diese Struktur stattfindet, könnte es daran liegen.

Tschüß
Michael

[st-oldie]

Hallo Rainald,

Zitat von Rainald Adamski

---

Das Steuerungsprogramm (geplant ist iTrain) soll die Verwaltung und Steuerung übernehmen, MS 2 nur als Slave.
Löten ist kein Problem es denn SMD, da tue ich mich schwer.
Mit Kompilation und Linux habe ich so gut wie keine Erfahrung, könnte mir aber da Hilfe organisieren.

Kurz zusammengefaßt was ich suche ist ein Interface - Steuerungs-SW ala CS, Ecos etc benötige ich nicht - zwischen PC und Moba was DCC, MM und Mfx kann.
Ich schau mir mal den anderen Thread an, vielleicht werde ich ja dort noch fündig.

---

Ich denke, dann ist die Lösung von Gerhard (zumindest von der Software her) für dich passender. Solltest du statt dem von ihm verwendeten BPi lieber das BBB nehmen wollen, kann ich auch sein CAN2UDP in mein Image integrieren.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Ich krieg langsam die Krise!!!!

Aber einer geht noch: hast du auch alle Binaries neu gebuildet? Ich hab in den Makefiles der einzelnen Daemonen keine Abhängigkeit zu den Libraries im libs Verzeichnis. Das war mir dann zuviel. Wenn man die API der Libs wie auch z.B. die verwendeten Strukturen ändert, muß man die ganzen Daemonen neu compilieren. Bei interen Änderungen reicht neu linken. Da der Absturz beim Zugriff auf diese Struktur stattfindet, könnte es daran liegen.

---

Kaum macht man es richtig und schon geht es

Ich habe vergessen, die anderen Daemons zu stoppen und die neuen zu verwenden. Und siehe da, es läuft jetzt - ähm - zumindest stürtzt es nicht mehr ab.

Sollte Kevin das hier lesen - jetzt kannste testen: Image und Bin liegen bereit (siehe anderem Thread).

Gruß

Gerd

PS: Danke Dir, Michael, für die Geduld

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

Kaum macht man es richtig und schon geht es

---

Ja, das stelle ich auch immer wieder fest.

Zitat von bertr2d2

---

Ich habe vergessen, die anderen Daemons zu stoppen und die neuen zu verwenden. Und siehe da, es läuft jetzt - ähm - zumindest stürtzt es nicht mehr ab.

---

Ups. War es im Eifer des Gefechts etwas hektisch geworden? Prima. Das ist mal eine gute Nachricht. Ja, dann kann man jetzt ja mal mit der Funktionalität rumspielen.

Ich hab noch eine Änderung vor und bin gerade an etwas dran. Mal sehen, ob Kevin noch andere Fehler findet. Dann kann ich anschließend mal wieder ein Päckchen zum Publizieren zusammenstellen.

Ich hab beim Rumspielen mit den geänderten *.cs2 Datein in der Doku einen Hinweis und durch die korrupte Datenbank festgestellt, daß der Lokname der Index in die Lokliste der MS2 ist. Ich hab aber die ID benutzt. Das wollte ich noch anpassen.

Ich hatte einen Kollegen mal wegen Tipps für Webconfig gefragt, da er in unserer Firma auch die Webconfig erstellt. Ich wollte aber auf JavaScript verzichten. Eigentlich hatte er keine Erfahrung mit PHP. Aber er hat mir über die Feiertage mal eben schnell ein PHP Script als universelles Konfigscript erstellt. Damit kann ich über Konfigdateien die Felder vorgeben, die Werte werden aus einer Konfigdatei gelesen und dort wieder geschrieben und anschließend ein Sehllscript aufgerufen. Damit kann ich dann die veränderten Werte noch weiter bearbeiten oder speichern. Wie z.B. DHCP ein- oder aussschalten.

Zitat von bertr2d2

---

PS: Danke Dir, Michael, für die Geduld

---

Naja, eigentlich muß ich dir für deine Arbeit danken. Du hast ja schon einige Energie in die Tests gesteckt. Ich bin als quasi in deiner Bierschuld

Tschüß
Michael

[Rainald Adamski]

Hallo Michael,

vielen Dank für Dein Angebot. Ich habe mich mal durch den anderen Thread gekämpft. Mir scheint, wie Du bereits vermutest, daß das die für mich bessere Lösung ist. Ich werde dort mal meine Vorstellung posten und hören was die Kollegen sagen.

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Hallo Gerd,

Ups. War es im Eifer des Gefechts etwas hektisch geworden? Prima. Das ist mal eine gute Nachricht. Ja, dann kann man jetzt ja mal mit der Funktionalität rumspielen.

Ich hab noch eine Änderung vor und bin gerade an etwas dran. Mal sehen, ob Kevin noch andere Fehler findet. Dann kann ich anschließend mal wieder ein Päckchen zum Publizieren zusammenstellen.

---

bevor Du Dir die Arbeit machst, ein neues Päckchen zu schnüren, solltest Du Dir noch eine Sache anschauen. IMHO hast Du noch ein veritables Speicherleck in mrcs2eth. Laut valgrind (Testumgebung: AMD64 mit gilbc):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 

destroy mrcs2eth
==28638==
==28638== HEAP SUMMARY:
==28638==     in use at exit: 6,432 bytes in 239 blocks
==28638==   total heap usage: 293 allocs, 54 frees, 12,075 bytes allocated
==28638==
==28638== 768 (24 direct, 744 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 4
==28638==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28638==    by 0x408035: IniParsCreate (ip_create.c:8)
==28638==    by 0x407541: ConfigCreate (cfg_create.c:16)
==28638==    by 0x4013E9: main (main.c:43)
==28638==
==28638== 5,664 bytes in 236 blocks are definitely lost in loss record 4 of 4
==28638==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28638==    by 0x409645: MengeCreateIter (menge_citer.c:10)
==28638==    by 0x401DC9: ProcessSystemData (cs2eth.c:227)
==28638==    by 0x401F1A: HandleSystemData (cs2eth.c:269)
==28638==    by 0x40298A: Cs2ethRun (cs2eth.c:488)
==28638==    by 0x40173F: main (main.c:123)
==28638==
==28638== LEAK SUMMARY:
==28638==    definitely lost: 5,688 bytes in 237 blocks
==28638==    indirectly lost: 744 bytes in 2 blocks
==28638==      possibly lost: 0 bytes in 0 blocks
==28638==    still reachable: 0 bytes in 0 blocks
==28638==         suppressed: 0 bytes in 0 blocks
==28638==
==28638== For counts of detected and suppressed errors, rerun with: -v
==28638== Use --track-origins=yes to see where uninitialised values come from
==28638== ERROR SUMMARY: 1137 errors from 9 contexts (suppressed: 2 from 2)
 
 

Der zweite Block mit den 5.664 Bytes wächst auch an. In einem anderen Test (lief ein paar Minuten) habe ich da auch schon über 20KByte gesehen.

Zitat

---

Ich bin als quasi in deiner Bierschuld

---

Nehme aber nur "Barzahlung" an

Gruß

Gerd

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

bevor Du Dir die Arbeit machst, ein neues Päckchen zu schnüren, solltest Du Dir noch eine Sache anschauen. IMHO hast Du noch ein veritables Speicherleck in mrcs2eth. Laut valgrind (Testumgebung: AMD64 mit gilbc):

---

Das dauert noch etwas. Ich hab gerade mal etwas mit der Webconfig basierend auf dem PHP Script meines Kollegen rumgespielt.

Zitat von bertr2d2

---

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

destroy mrcs2eth
==28638==
==28638== HEAP SUMMARY:
==28638==     in use at exit: 6,432 bytes in 239 blocks
==28638==   total heap usage: 293 allocs, 54 frees, 12,075 bytes allocated
==28638==
==28638== 768 (24 direct, 744 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 4
==28638==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28638==    by 0x408035: IniParsCreate (ip_create.c:8)
==28638==    by 0x407541: ConfigCreate (cfg_create.c:16)
==28638==    by 0x4013E9: main (main.c:43)
 
 

---

Nicht so schön, aber das scheint ja nur einmalig zu sein. Das ist ja Speicher, der beim Create angelegt wird und beim Destroy, also beim Beenden freigegeben werden soll. Ist also zumindest kein Problem.

Zitat von bertr2d2

---

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 

==28638==
==28638== 5,664 bytes in 236 blocks are definitely lost in loss record 4 of 4
==28638==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28638==    by 0x409645: MengeCreateIter (menge_citer.c:10)
==28638==    by 0x401DC9: ProcessSystemData (cs2eth.c:227)
==28638==    by 0x401F1A: HandleSystemData (cs2eth.c:269)
==28638==    by 0x40298A: Cs2ethRun (cs2eth.c:488)
==28638==    by 0x40173F: main (main.c:123)
==28638==
==28638== LEAK SUMMARY:
==28638==    definitely lost: 5,688 bytes in 237 blocks
==28638==    indirectly lost: 744 bytes in 2 blocks
==28638==      possibly lost: 0 bytes in 0 blocks
==28638==    still reachable: 0 bytes in 0 blocks
==28638==         suppressed: 0 bytes in 0 blocks
==28638==
==28638== For counts of detected and suppressed errors, rerun with: -v
==28638== Use --track-origins=yes to see where uninitialised values come from
==28638== ERROR SUMMARY: 1137 errors from 9 contexts (suppressed: 2 from 2)
 
 

Der zweite Block mit den 5.664 Bytes wächst auch an. In einem anderen Test (lief ein paar Minuten) habe ich da auch schon über 20KByte gesehen.

---

Das klingt nicht so schön. Ist das die drehscheibe oder die mrcs2eth, die die CAN Nachrichten verteilen? Dann wird der Iterator nicht richtig zerstört. Das ist kritisch, da das ja dann bei jeder CAN Message auftritt.

Zitat von bertr2d2

---

Zitat von st-oldie

---

Ich bin als quasi in deiner Bierschuld

---

Nehme aber nur "Barzahlung" an

---

Welche Bar bevorzugst du denn

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Hallo Gerd,

Zitat von bertr2d2

---

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 

==28638==
==28638== 5,664 bytes in 236 blocks are definitely lost in loss record 4 of 4
==28638==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28638==    by 0x409645: MengeCreateIter (menge_citer.c:10)
==28638==    by 0x401DC9: ProcessSystemData (cs2eth.c:227)
==28638==    by 0x401F1A: HandleSystemData (cs2eth.c:269)
==28638==    by 0x40298A: Cs2ethRun (cs2eth.c:488)
==28638==    by 0x40173F: main (main.c:123)
==28638==
==28638== LEAK SUMMARY:
==28638==    definitely lost: 5,688 bytes in 237 blocks
==28638==    indirectly lost: 744 bytes in 2 blocks
==28638==      possibly lost: 0 bytes in 0 blocks
==28638==    still reachable: 0 bytes in 0 blocks
==28638==         suppressed: 0 bytes in 0 blocks
==28638==
==28638== For counts of detected and suppressed errors, rerun with: -v
==28638== Use --track-origins=yes to see where uninitialised values come from
==28638== ERROR SUMMARY: 1137 errors from 9 contexts (suppressed: 2 from 2)
 
 

Der zweite Block mit den 5.664 Bytes wächst auch an. In einem anderen Test (lief ein paar Minuten) habe ich da auch schon über 20KByte gesehen.

---

Das klingt nicht so schön. Ist das die drehscheibe oder die mrcs2eth, die die CAN Nachrichten verteilen? Dann wird der Iterator nicht richtig zerstört. Das ist kritisch, da das ja dann bei jeder CAN Message auftritt.

---

Wer die Nachricht verteilt, weiss ich nicht. Zumindest tritt der Fehler im mrcs2eth auf, bzw valgrind beobachtet hier deas Speicherloch.

Ich hab weiter getestet und noch ein Paar Unzulänglichkeiten gefunden.

1. Deine Software reagiert mit 10 Sekunden Verögerung auf den CAN-Ping:

1
2
3
4
5
6
7
8
9
 

#### BPi mit musl
09:02:41.997441 IP 192.168.0.9.15730 > 255.255.255.255.15731: UDP, length 13
09:02:52.008793 IP 192.168.0.159.15731 > 192.168.0.9.15730: UDP, length 13
 
#### AMD64 mit glibc
09:17:07.076143 IP 192.168.0.221.15730 > 255.255.255.255.15731: UDP,length 13
09:17:17.089790 IP 192.168.0.9.15731 > 192.168.0.221.15730: UDP, length13
 
 

Ist das so gewollt ? CS2.exe meldet jedenfalls, das keine CS2 gefunden wurde.
Nach diesen 10 Sekunden lädt CS2.exe dann aber doch die Files.

2. Zumindest beim BPi (mit musl) meldet CS2.exe CRC Fehler. Das müsste hier durch gefixt werden:

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

--- a/mrsystem/src/libs/mr_can/crc.c
+++ b/mrsystem/src/libs/mr_can/crc.c
@@ -109,7 +109,7 @@ static unsigned short CRCCCITT(unsigned char *data, 
unsigned int length, unsigne
 
  unsigned short MrCs2CalcCrc(unsigned char *data, unsigned int length)
  {
-   CRCCCITT(data, length, 0xffff);
+   return CRCCCITT(data, length, 0xffff);
  }
 
  #endif
 
 

Konnte es leider noch nicht testen.

Gruß

Gerd

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

Zitat von st-oldie

---

Das klingt nicht so schön. Ist das die drehscheibe oder die mrcs2eth, die die CAN Nachrichten verteilen? Dann wird der Iterator nicht richtig zerstört. Das ist kritisch, da das ja dann bei jeder CAN Message auftritt.

---

Wer die Nachricht verteilt, weiss ich nicht. Zumindest tritt der Fehler im mrcs2eth auf, bzw valgrind beobachtet hier deas Speicherloch.

---

Dann wird es auch mrcs2eth sein. Da wird die CAN Nachriucht an alle Ethernet Clients verteilt.

Zitat von bertr2d2

---

1. Deine Software reagiert mit 10 Sekunden Verögerung auf den CAN-Ping:
Ist das so gewollt ? CS2.exe meldet jedenfalls, das keine CS2 gefunden wurde.
Nach diesen 10 Sekunden lädt CS2.exe dann aber doch die Files.

---

Ja. Wobei das keine festen 10 Sekunden sind. Meine Software wartet zuerst auf die MS2 um dann die Loks abzufragen. Das geht erst, wenn die MS2 selbst pingt. Wenn ich vorher die Loks abfrage, hatte sich bei mir die MS2 aufgehängt. Und danach ist die mrzentrale bereit, auch Anforderungen von außen zu befriedigen. Es scheint aber auch der Timeout für eine Antwort im cs2.exe sehr knapp zu sein. Es kann also sein, daß der Ping nicht schnell genug beantwortet wird und die cs2.exe dehalb keine CS2 findet. Hier im Forum gab es auch schon Berichte, daß die cs2.exe auch eine reale CS2 nicht sofort gefunden hat.

Zitat von bertr2d2

---

2. Zumindest beim BPi (mit musl) meldet CS2.exe CRC Fehler. Das müsste hier durch gefixt werden:

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

--- a/mrsystem/src/libs/mr_can/crc.c
+++ b/mrsystem/src/libs/mr_can/crc.c
@@ -109,7 +109,7 @@ static unsigned short CRCCCITT(unsigned char *data, 
unsigned int length, unsigne
 
  unsigned short MrCs2CalcCrc(unsigned char *data, unsigned int length)
  {
-   CRCCCITT(data, length, 0xffff);
+   return CRCCCITT(data, length, 0xffff);
  }
 
  #endif
 
 

Konnte es leider noch nicht testen.

---

Läuft nicht weg

Tschüß
Michael

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

2. Zumindest beim BPi (mit musl) meldet CS2.exe CRC Fehler. Das müsste hier durch gefixt werden:

---

Was aber dann auch bedeutet, daß die Software von Märklin die CRC nicht überprüft.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Hallo Gerd,

Zitat von bertr2d2

---

2. Zumindest beim BPi (mit musl) meldet CS2.exe CRC Fehler. Das müsste hier durch gefixt werden:

---

Was aber dann auch bedeutet, daß die Software von Märklin die CRC nicht überprüft.

---

Doch. Tut sie. Merkwuerdigerweise braucht die glibc den Patch nicht (habs gerade probiert) - musl schon. Ich habs mit meinem 'get-cs-config' Tool verifiziert.
Vielleicht liegt bei glibc trotz fehlender "return"-Anweisung die CRC-Summe genau an der richtigen Stelle auf dem Stack, bei musl aber nicht.
Das es bei Dir auf dem BBB klappt ist anscheinend nur Zufall.

Gruß

Gerd

[bertr2d2]

Hallo Nochmal,

Zitat von st-oldie

---

Zitat von bertr2d2

---

1. Deine Software reagiert mit 10 Sekunden Verögerung auf den CAN-Ping:
Ist das so gewollt ? CS2.exe meldet jedenfalls, das keine CS2 gefunden wurde.
Nach diesen 10 Sekunden lädt CS2.exe dann aber doch die Files.

---

Ja. Wobei das keine festen 10 Sekunden sind. Meine Software wartet zuerst auf die MS2 um dann die Loks abzufragen. Das geht erst, wenn die MS2 selbst pingt. Wenn ich vorher die Loks abfrage, hatte sich bei mir die MS2 aufgehängt. Und danach ist die mrzentrale bereit, auch Anforderungen von außen zu befriedigen. Es scheint aber auch der Timeout für eine Antwort im cs2.exe sehr knapp zu sein. Es kann also sein, daß der Ping nicht schnell genug beantwortet wird und die cs2.exe dehalb keine CS2 findet. Hier im Forum gab es auch schon Berichte, daß die cs2.exe auch eine reale CS2 nicht sofort gefunden hat.

---

Ich meine, das ich den Effekt (CS2.exe meldet "kein Master gefunden") aber auch gesehen habe, wenn MS2 und Gleisbox schon lange ihre Daten miteinander ausgetauscht haben. Könntest Du in der FSM das nicht einbauen ?: MS2 ready - antworte auf Ping sofort.

So wird es jedenfalls viele Leute verwirren.

Gruß

Gerd

[Schmalspurbahn]

Sehr interessantes Projekt! Kann man mit dieser Lösung und er cs2.exe die mfx-Decoder über einen PC programmieren? Die CS2 hat dazu ja ein Programmiergleis, was macht die CS2.exe, wenn man darüber einen mfx-Decoder programmieren oder gar ein Soundprojekt updaten möchte?

[st-oldie]

Hi Gerd,

Zitat von bertr2d2

---

Doch. Tut sie. Merkwuerdigerweise braucht die glibc den Patch nicht (habs gerade probiert) - musl schon. Ich habs mit meinem 'get-cs-config' Tool verifiziert.
Vielleicht liegt bei glibc trotz fehlender "return"-Anweisung die CRC-Summe genau an der richtigen Stelle auf dem Stack, bei musl aber nicht.
Das es bei Dir auf dem BBB klappt ist anscheinend nur Zufall.

---

Ich weiß nicht, ob der Returnwert auf dem Stack oder nicht eher in einem Prozessorregister (wie beim 68k) zurückgegeben wird. So viel "Low-Level" Erfahrung mit ARM hab ich noch nicht. Ich vermute, in einem Register. Die von MrCs2CalcCrc() aufgerufene Funktion CRCCCITT() gibt ja schon die CRC zurück. Da nach dem Aufruf von CRCCCITT() nichts mehr gemahct wird außer Stack aufräumen, hat wohl dadurch das Register für den Rückgabewert den richtigen Wert.

Tschüß
Michael

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

Ich meine, das ich den Effekt (CS2.exe meldet "kein Master gefunden") aber auch gesehen habe, wenn MS2 und Gleisbox schon lange ihre Daten miteinander ausgetauscht haben. Könntest Du in der FSM das nicht einbauen ?: MS2 ready - antworte auf Ping sofort.

---

Das ist doch schon so umgesetzt, meine Software antwortet in diesem Fall sofort. Siehe in staes.c die Funktion HandlePing(), da siehst du, das sofort eine Antwort generiert und versendet wird. Da hab ich keine Wartezeit. Wie schon in der anderen Mail stand, ist der Timeout in der cs2.exe zu klein. Die sendet einen Ping und die Zeit, innerhalb der eine CS2 antworten muß, ist sehr knapp bemessen. Es haben schon Leute berichtet, daß die cs2.exe eine reale CS2 nicht sofort gefunden hat.

Zitat von bertr2d2

---

So wird es jedenfalls viele Leute verwirren.

---

Kann ich mir vorstellen. Nur müßte in diesem Fall Märklin den Timeout für eine Antwort mal etwas weniger hart an der Grenze einstellen.

Tschüß
Michael

[st-oldie]

Hi,

Zitat von Schmalspurbahn

---

Sehr interessantes Projekt! Kann man mit dieser Lösung und er cs2.exe die mfx-Decoder über einen PC programmieren? Die CS2 hat dazu ja ein Programmiergleis, was macht die CS2.exe, wenn man darüber einen mfx-Decoder programmieren oder gar ein Soundprojekt updaten möchte?

---

Das hab ich noch nicht versucht. In meiner Lösung läuft die cs2.exe als Slave. Kann die cs2.exe als Slave auch mfx Decoder programmieren? Da ich Alle CAN Nachrichten, die ich selbst nicht auswerte, 1:1 durchreiche und bei allen anderen wieder die ursprüngliche Nachricht weiterleite, kann es funktionieren.

Tschüß
Michael

[bertr2d2]

Hallo,

Zitat von Schmalspurbahn

---

Sehr interessantes Projekt! Kann man mit dieser Lösung und er cs2.exe die mfx-Decoder über einen PC programmieren? Die CS2 hat dazu ja ein Programmiergleis, was macht die CS2.exe, wenn man darüber einen mfx-Decoder programmieren oder gar ein Soundprojekt updaten möchte?

---

zumindest kann man mit BPi/Gleisbox +can2lan die Lok-Parameter auslesen und beschreiben. Sounds weiss ich nicht - Firmware-Update Lok-Deckoder anscheinend aber nicht (habe ich nur kurz getestet).

Gruß

Gerd