ControllerTools

Controller-Tools

Die Controller-Tools sind kleine Linux-Programme, mit denen die Controller getestet werden können. Alle Programme sprechen das serielle Device direkt an. Meistens ist das /dev/ttyS0, kann aber auch im Falle eines USB2SER-Dongles /dev/ttyUSB0 heißen. Alle Tools geben die Meldungen im Klartext aus, soweit die Meldungen dem Kommunikationsprotokoll entsprechen.

canprog

Mit diesem Tool werden alle Controller mit neuer Firmware geflasht. Das Flashen geschieht über den CAN-Bootlader der CAN-Knoten. Das CAN-Gateway kann auf diesem Wege nicht geflasht werden. Die Firmware muss im üblichen Hex-Format vorliegen.

Aufruf:

./canprog <device> <hexfile>

canprog greift nur schreibend auf das serielle Device zu.

receive

Das Tool receive ist fast das wichtigste Tool. Es gibt alle über RS232 empfangenen Nachrichten im Klartext aus. Bei Verwendung der Tools canprog, ping, reset und setid macht es Sinn das Tool receive in einer weiteren Konsole mitlaufen zu lassen.

Aufruf:

./receive <device>

receive greift nur lesend auf das serielle Device zu.

ping

Mit dem ping-Tool wird jede Sekunde eine PING-Message via Broadcast versendet. Alle CAN-Knoten müssen demnach mit einem PING/MSG_OK antworten.

Aufruf:

./ping <device>

ping greift nur schreibend auf das serielle Device zu.

reset

Mit dem reset-Tool wird via Broadcast ein Reset aller CAN-Knoten veranlasst.

Aufruf:

./reset <device>

reset greift nur schreibend auf das serielle Device zu.

qrybuf

Mit dem qrybuf-Tool fragt alle CAN-Knoten nach den Füllständen ihrer CAN-Buffer ab.

Aufruf:

./qrybuf <device>

qrybuf greift nur schreibend auf das serielle Device zu.

qryerr

Mit dem qryerr-Tool fragt alle CAN-Knoten nach den CAN-Fehlerzählern ab. Es erfolgen pro CAN-Knoten drei Antwortmeldungen.

Aufruf:

./qryerr <device>

qryerr greift nur schreibend auf das serielle Device zu.

setid

Mit dem setid-Tool wird die Controller-ID umprogrammiert. Dabei muss beim zu programmierenden Controller der ID-Taster gedrückt gehalten werden. Alle Controller, deren ID-Taster nicht gedrückt werden, antworten mit einem SET_ID/MSG_ID_CHANGE_DISABLED. Wenn der ID-Taster gedrückt wird, die neue ID aber der alten ID ist, bleibt die gespeicherte Konfiguration erhalten und der Controller antwortet mit SET_ID/MSG_ID_NOT_CHANGED. Wird die ID geändert, wird eine vorhandene Konfiguration gelöscht und der Controller antwortet mit SET_ID/MSG_OK. Danach wird ein Reset durchgeführt.

Aufruf:

./setid <device> <id>

setid greift nur schreibend auf das serielle Device zu.

gwsim

gwsim ist ein Tool, mit dem die Stellwerks-Software getestet werden kann. Dazu müssen zwei Rechner mit einem Nullmodem-Kabel verbunden werden. Auf dem einem Rechner läuft die Stellwerks-Software, auf dem anderen läuft gwsim. gwsim nimmt alle CAN-Frames entgegen und antwortet mit einem MSG_OK. Dadurch sollte die Stellwerks-Software in einem fehlerfreiem Modus funktionieren. Die eingehenden und ausgehenden CAN-Frames werden auf der Konsole mitgeloggt.

Aufruf:

./gwsim <device>

gwsim greift lesend und schreibend auf das serielle Device zu.

config

config programmiert eine Testkonfiguration in den Controller mit der ID 2040. Dazu gehören zwei neue Weichen, zwei alte Weichen, vier Gleisabschnitte und ein Einfahrsignal kombiniert mit einem Vorsignal, ein Vorsignal und ein Gleissperrsignal verteilt an zwei Lichtsignalmodule.

Folgende Konfiguration wird vorgesehen:

Unitnumber	Typ	Bemerkung
2020	Weiche ohne Endabschaltung	Weichenmodul
2021	Weiche ohne Endabschaltung	Weichenmodul
2019	Weiche mit Endabschaltung	Weichenmodul
2001	Weiche mit Endabschaltung	Weichenmodul
100	Einfahrsignal	Lichtsignalmodul 3
101	Vorsignal	Lichtsignalmodul 3
102	Vorsignal	Lichtsignalmodul 2
103	Gleissperrsignal	Lichtsignalmodul 2
201	Gleisabschnitt	Gleismodul
202	Gleisabschnitt	Gleismodul
203	Gleisabschnitt	Gleismodul
204	Gleisabschnitt	Gleismodul

Aufruf:

./config <device>

switch

switch testet die vier Weichen des Controllers mit der ID 2040. Diese werden zweimal jeweil nach links und nach rechts geschaltet.

Aufruf:

./switch <device>

signal

signal testet ein Einfahrsignal mit kombinierten Vorsignal am Controller mit der ID 2040. Alle Kombinationen werden rotierend und fortlaufend durchprobiert. Dazu gehört auch ein Testmuster (alle LEDs an) und alle LEDs aus.

Aufruf:

./signal <device>

rail

rail testet das Gleismodul am Controller mit der ID 2040. Alle vier angeschlossenen Gleisabschnitte werden zyklisch ein- und wieder ausgeschaltet. Dabei wird intern ein Zähler hochgezählt. Die ersten vier Bits repräsentieren jeweils einen Gleisabschnitt. So wird der erste Gleisabschnitt mit jedem Zyklus ein- und wieder ausgemacht, der zweite Abschnitt erst mit jedem zweiten, der dritte Abschnitt mit jedem vierten Zyklus, usw. Ein Zyklus dauert zwei Sekunden.

Aufruf:

./rail <device>

occupation

occupation fragt alle zwei Sekunden die Gleisbesetztanzeige eines Gleismoduls am Controller mit der ID 2040 ab.

Aufruf:

./occupation <device>

send

Mit dem send-Tool können beliebige CAN-Frames gesendet werden. Es wird eine Ziel-ID übergeben, danach kommen beliebig viele Datenbytes. Die Datenbytes dürfen dezimal und hexadezimal angegeben werden. Hexadezimale Datenbytes müssen ein 0x vor dem Datenbyte haben.

Aufruf:

./send <device> <id> {bytes}

send greift nur schreibend auf das serielle Device zu.

Logging-Ausgaben

Ausgehende Kommandos haben in etwa folgendes Ausgabe Format:

1215148970 # ID=0000:0000 len=1 stat=00 # PING # 0xbb >
1215148971 # ID=0000:0000 len=1 stat=00 # PING # 0xbb >

Zeitstempel|ID <Standard-ID>:<Extended-ID>|len=<Datenfeldlänge>|stat=<Status>|Kommando <ggf. weitere Datenbbytes>|Prüfsumme der seriellen Übertragung|Richtung

Bedeutung:

Zeitstempel	Zeit der Sekunden seit dem 01.01.1970
Standard-ID	Die 11-bittige CAN-Standard-ID, entspricht der Controller-ID
Extended-ID	Der 16-bittige Anteil der CAN-Extended-ID, entspricht der Unitnumber
Datenfeldlänge	Mindestens 1, da das Kommandobyte Pflicht ist.
Status	0x00 bei Standard Data Frames, 0x40 bei Extended Data Frames
Kommando	Das eigentliche Kommando. Dazu kommen ggf. ergänzende Datenbytes.
Prüfsumme	Die Prüfsumme für die Übertragung über RS232
Richtung	> steht für Senden, < steht für Empfangen

Eingehende Antworten haben folgendes Format:

1215718180 # ID=07ff:0007 len=6 stat=51 # PING         MSG_OK               0007:0000 # 0x00  6632 <
1215718181 # ID=07ff:0007 len=6 stat=51 # PING         MSG_OK               0007:0000 # 0x00  6633 <

Zeitstempel|ID=<Std-ID>:<Ext-ID>|len=<Datenfeldlänge>|stat=<Status>|Kommando|Antwort-Code|<ggf. weitere Datenbbytes>|Prüfsumme der seriellen Übertragung|lfd. Frame-Nummer|Richtung

Bedeutung:

Zeitstempel	Zeit der Sekunden seit dem 01.01.1970
Standard-ID	Die 11-bittige CAN-Standard-ID, entspricht der Gateway-ID 0x7ff
Extended-ID	Der 16-bittige Anteil der CAN-Extended-ID, der sendenden Controller-ID
Datenfeldlänge	Mindestens 6, da das Kommandobyte, der Antwortcode, die Absende-ID (Controller-ID und Unitnumber) Pflicht ist.
Status	0x00 bei Standard Data Frames, 0x20 bei Extended Data Frames, 0x40 steht für Empfang in Buffer 0, 0x80 in Buffer 1, die ersten drei Bits zeigen die Filterregel an, auf die das Frame passte
Kommando	Das eigentliche Kommando
Antwort-Code	Der Antwort-Code
<Standard-ID>	Die Controller-ID des Absenders.
<Extended-ID>	Die Unitnumber des Absenders
weitere Datenbytes	Es ist noch Platz für zwei zusätzliche Bytes.
Prüfsumme	Die Prüfsumme für die Übertragung über RS232
Richtung	> steht für Senden, < steht für Empfangen