ich habe mal eine Frage: kann man die CC-Schnitte mit Befehlen eigentlich überlasten? Und was meldet sie in so einem Fall?
Vorab mein Setup:
- Gleisbox
- Mobile Station 2
- CC-Schnitte 2.1
- Raspi B2 1GByte
- Rocrail
- Selbstgeschriebene Clients für Rocrail
Hintergrund der Frage: Ab und zu (häufiger mit "Befehlslast" schaltet mein System scheinbar grundlos auf STOP, zumindest zeigen mir meine Clients den Empfang von STOP-Befehlen von Rocrail an. In den Logfiles steht tatsächlich, das RocRail ein STOP von der Gleisbox bzw. über die CC-Schnitte bekommen hat.
Nur, dann müsste doch eigentlich
* Der Strom wegbleiben (die Loks fahren weiter)
* an der MS2 dick und fett "ROT" leuchten
Tuts aber nicht. Klar, die Box ist nämlich gar nicht abgeschaltet bzw. Offline, sonder läuft.
Die Rocrailies haben gemeint, der Grund könne wg einer Überlastung sein. Die CC-Schnitte hätte eine Pufferüberlauf und melde Überlastung.
Das kann ich mir aber nicht vorstellen, denn die Schnitte ist ja mit 50 Kbit/s angebunden - da ist viel Platz.
Zudem kommt die Meldung auch, wenn man das Ding einfach mal ne Weile liegen lässt und nichts tut.
Ich habe mal den Verkehr auf der Serielle Schnittstelle, an der die CC-Schnitte hängt, mitgeschnitten - vielleicht jemand ein Idee?
In dem Verkehr gegen Ende ist auch ein Stopbefehl zu finden, der von mir durch Fehlbedienung ausgelöst wurde. Vielleicht sieht jemand etwas, das ich übersehen habe?
Beiträge: 2257 Ort: in der Lampe Eingetreten: 03.06.10 Status: Offline
Eingetragen am 10.07.2015 09:03
Hallo Martin,
der Datenverkehr ist recht unleserlich, Blöcke in 13 Byte lassen sich da wesentlich besser lesen.
Ist aber auch egal. Die Schnitte solte es eigentlich nicht sein, denn sie kann keine Daten, Meldungen oder was auch immer erzeugen. Sie übersetzt nur zwischen den Welten, mehr nicht.
Überlast kann ich mir auch eher nicht vorstellen, da doppelt so schnell wie der CAN.
Aber ich kenne dieses Problem, da war es ein Systemteilnehmer, der eine falsche Antwort sendete. War ich in dem Fall selber
Du muss mal schauen welche Geräte Kennung diese Meldung sendet, vielleicht hilft das weiter.
danke für die Antwort. Ich glaube auch nicht, das die Schnitte an Überlast leiden könnte ... gerade auch wg. dem Tempo der Schnittstelle. Zumindest diese Meinung sehe ich jetzt bestätigt. Der Systemteilnehmer dürfte wohl die Gleisbox sein ... aber ich finde es schon komisch, das Rocrail nur an meine Rocrailclients was ausgibt, aber selbst in RocView nichts anzeigt.
Wg. den 13er-Blöcken: sorry.
Eine Frage: ich sehe immer Byte 12 und 13 mit den Werten 19
00 0B 83 28 05 00 00 00 18 01 E8 19 19
00 09 83 28 06 00 00 00 18 00 00 19 19
00 0D 83 28 06 00 00 00 18 00 00 19 19
Sind das "Schlusszeichen"? Ich habe in der Märklin-Doku nicht so recht was gefunden, das dem ähnelt (oder ich habs schlicht übersehen).
Oder vielleicht habe ich den falschen Blickwinkel ...
Aufgezeichnet habe ich die Bytes übrigens durch ein nettes Tool unter Linux: jpnevulator. Das klemmt sich schön in die serielle Schnittstelle rein. Mal so nebenbei.
Ah ja, noch eine Frage: kann die Gleisbox eine Art Pufferüberlauf haben oder bekommen und meldet so etwas auf dem Bus? Ich habe einen Befehl gesehen, der "Überlast" anzeigt, verorte den aber eher in "zuviele Loks auf dem Gleis".
Muss das mal stur weiterloggen - irgendwann werde ich wohl ein Schema erkennen.
Beiträge: 2257 Ort: in der Lampe Eingetreten: 03.06.10 Status: Offline
Eingetragen am 11.07.2015 10:09
Hallo Martin,
was Rocrail macht kann ich nicht beurteilen, damit komme ich nicht wirklich klar. Ist einfach nicht meine Software.
Wenn Du dir die Docu der Schnitte mal genauer anschaust, wirst Du die Lösung zur 19 am Ende finden. Es sind laut DLC nur 5 oder 6 Byte zu übertragen, der rest wird aufgefüllt und ist nicht zu beachten. Steht auch in der Märklin Docu, da ist es nur dann 0x00.
Wenn Du mit den Meldungen arbeiten wilst, muss Du sie schon in Bits umwandeln und dann nach der Märklin Beschreibung betrachten.
Wenn der Bus zu voll wird, hängt sich die MS2 schon mal auf ob das die Box auch macht weiß ich nicht.
Und traue diesen COM Sniffern nicht wirklich! Bei der Windows Version hatte ich da so meine Probleme, vorallem laufen die Programme dahinter dann unrund. Ich nutze nur noch Hardware-Analyser oder zwei Schnitten.
Thorsten schrieb:
was Rocrail macht kann ich nicht beurteilen, damit komme ich nicht wirklich klar. Ist einfach nicht meine Software.
:-) Ich missbrauche den Server zum Weichenschalten und Handregler-Befehl-entgegennehmen. Alles andere wird nicht genutzt. Und Automatik finden meinen Söhne langweilig ... na ja: ich auch ;-)
Im Ernst: ich bin drauf und dran, das ganze unter einen Debugger zu legen, den Code lese ich jetzt schon im Single Step ;-)
Mal sehen ...
Quote
Wenn Du dir die Docu der Schnitte mal genauer anschaust, wirst Du die Lösung zur 19 am Ende finden. Es sind laut DLC nur 5 oder 6 Byte zu übertragen, der rest wird aufgefüllt und ist nicht zu beachten. Steht auch in der Märklin Docu, da ist es nur dann 0x00.
Ist schon richtig, danke für den Hinweis auf die DLC. Aber konstant immer 0x19? Und zwar von der Gleisbox über die Schnitte zur Anlage? Klar, es kann alles nach DLC-Length lt. Doku ignoriert werden. aber der "krumme" Wert sieht schon eigenartig auch, oder auch willkürlich. Die anderen Felder der CAN-Message habe ich jetzt so lala verstanden.
Quote
Wenn der Bus zu voll wird, hängt sich die MS2 schon mal auf ob das die Box auch macht weiß ich nicht.
Ist mir noch nicht passiert. Und wirklich voll wird der Bus bei mir nicht, gerade auch, wenn man die Anlage einfach hochfährt und nichts tut - da kommt nämlich dann auch irgendwann die STOP-Meldung ... mir ist nur noch nicht das Schema dahinter klar.
Ich nehme mir die kommenden Tage mal viel Zeit und starte ein Dauerlogging auf verschiedenen Kanälen.
Quote
Und traue diesen COM Sniffern nicht wirklich! Bei der Windows Version hatte ich da so meine Probleme, vorallem laufen die Programme dahinter dann unrund. Ich nutze nur noch Hardware-Analyser oder zwei Schnitten.
Glaube ich Dir sofort! Allein, mir fehlt die Ausrüstung - dann mit Krücken. ;-)
Ich teste das Zeug nur unter Linux, gibt es nette Schrauben zum drehen (mal abgesehen davon, das ich das alles auf einem Raspi Zwo laufen lasse, dessen Ports ich auch noch unter Bytes setzen muss - vielleicht mag der ja ned so recht).
Beiträge: 2257 Ort: in der Lampe Eingetreten: 03.06.10 Status: Offline
Eingetragen am 14.07.2015 10:17
Hallo Martin,
wie sieht dann genau die Stopmeldung aus? Was ist genau davor?
Wenn Du DLC nicht beachtest, kannst Du manches nicht mal unterscheiden, dann wundert mich das nicht.
Wer sagt Dir, dass die 0x19 von der Gleisbox über die Schnitte zur Anlage geht?
Lese Dir das mal genau durch, was das mit den 13Byte aufsich hat.
Du siehst mit dem Sniffer die RS232 Daten, aber nicht das, was auf dem CAN wirklich läuft! Hier brauchst Du einen echten CANanalyser.
zwischen meiner Software und der Schnitte hängt Rocrail im Grunde nur als "Übersetzer" zu CAN hin. Wenn also Rocrail von der Schnitte über die Gleisbox und MS2 ein "echtes" Stopsignal bekommt, sendet die Software per "Broadcast" an alle Clients (SRCP, meine Software, mobile Geräte, RocView ...) einen Stop-Befehl (XML-formatiert). Soweit so gut.
Allerdings - und das ist auffallend - kommt solch ein Stopbefehl auch mal, ohne explizit von der MS2 ausgelöst zu werden. Das ist nachvollziehbar bei Lasterzeugung durch meine Software (z. B. ständiger Befehl "Richtungswechsel", man kann aber auch einfach mal ein paar Minuten warten - und Plop: die XML-Message kommt von RocRail an alle.
Die einzige Software, die aber darauf reagiert, ist meine Software (genau genommen jede Software von mir), weswegen ich auch vermute, Rocrail addressiert nur meine offenen TCP-IP-Channels, ohne das zu sagen (oder ich habs nicht gesehen).
Ach ja, und interessanterweise kommt diese "selbsterzeugte" Message nicht über die Gleisbox zurück an die MS2, mit anderen Worten: kein STOP auf CAN-Ebene, also kein STOP an den Rocrail-Treiber ...
Ich habe selbstverständlich schon bei den Rocrailies gefragt, die ziemlich schnell auf die Schnitte verwiesen haben ... ich bin Informatiker, und kann das spätestens mit diesem Thread hier ausschliessen (und deren Argumente haben mir auch nicht so recht eingeleuchtet, wenn ich auch die Hilfsbereitschaft zu schätzen weiß).
Also stimmt etwas nicht am CAN-Treiber mcs2 von RocRail - das ist dann mein nächstes Untersuchungs-Opfer.
Argl, C++ debuggen ...
Seufz, im nächsten Leben steuert meine Software vielleicht die Schnitte direkt per CAN an ... hm ... das hätte allerdings auch einen Charme ... ... Gibt es CAN-Libs für Java?
Quote
Wer sagt Dir, dass die 0x19 von der Gleisbox über die Schnitte zur Anlage geht?
Hatte ich auch nicht. Und das glaube ich auch nicht. Mein Mitschnitt scheint mir "outgoing" zu sein, also von Rocrail kommend. Aber auch dann sind die 0x19 komisch. Aber da die Bytes ignoriert werden, ist das im Grunde nur ein Schönheitsfehler.
Quote
Lese Dir das mal genau durch, was das mit den 13Byte aufsich hat
Habe ich gestern abend. Und deshalb konnte ich auch die Bytes dekodieren.
Manchmal braucht man einen Stuppser ...
Quote
Du siehst mit dem Sniffer die RS232 Daten, aber nicht das, was auf dem CAN wirklich läuft! Hier brauchst Du einen echten CANanalyser.
Richtig - aber ich sehe auch, was Rocrail bekommt bzw. was von Rocrail kommt. Vom CAN-Bus gehe ich mal naiv aus: das passt schon so. Ich tippe auf eine Unverträglichkeit von RocRail (vielleicht die ARM-Plattform? Der Test mit Intel ist schon vorbereitet), die noch keiner mitbekommen hat ... vielleicht sollte ich doch auf den CAN-Bus direkt schreiben.
Viele Grüsse aus München und Danke für Deine Zeit!
Eingetragen am 09.07.2015 23:56
schaltet mein System scheinbar grundlos auf STOP, zumindest zeigen mir meine Clients den Empfang von STOP-Befehlen von Rocrail an. In den Logfiles steht tatsächlich, das RocRail ein STOP von der Gleisbox bzw. über die CC-Schnitte bekommen hat.
v6.01.13 © 2003-2005