Cand: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
(19 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{ProjektInfoBox | {{ProjektInfoBox | ||
|name | |name=Cand | ||
|status | |status=stable | ||
|description=Labor-CANBus EIA-232 zu TCP Gateway Dienst | |||
|description = | |author=[[Benutzer:Theodor|Joerg]], [[Benutzer:Tixiv|Tixiv]], [[Benutzer:Asklepios|Asklepios]] | ||
|author | |version=1.0 | ||
|platform=GNU/Linux | |||
|version | |license=? | ||
|download=[https://das-labor.org/svn/microcontroller/src-atmel/automatization2.0/cand SVN] [http://das-labor.org/trac/browser/microcontroller/src-atmel/automatization2.0/cand browse] | |||
|platform | |tags=Software, | ||
|license | |update= | ||
|download | |||
}} | }} | ||
Der Cand[y] ist der Daemon der auf unserem Intranet-Server läuft und die vom [[CAN|CAN-Bus]] ankommenden Nachrichten verarbeiten kann. Urspruenglich war er nur als zentrale Instanz fuer lapcontrol gedacht. Lapcontrol ist dabei die Clientsoftware die von jedem Rechner aus gestartet werden kann und via tcp/ip eine Verbindung zum Cand aufbaut. | |||
Das auf der EIA-232 Schnittstelle gesprochene Protokoll ist auf der Seite des [[CAN-Gateway|CAN-Gateway]] dokumentiert. | |||
= Netzaufbau = | |||
Genau genommen sieht es so aus, dass cand ein uart-tcp gateway ist. Damit fuegt er sich in die Struktur wie folgt ein: | |||
{{CANstructure}} | |||
= start des cand = | = start des cand = | ||
Cand wird auf | Cand wird auf weblab mit | ||
start cand | start cand | ||
gestartet resp mit | gestartet resp mit | ||
Zeile 49: | Zeile 49: | ||
Die uebergebenen Werte kommen alle als Hexwerte rein. Also z.b. '0xde' '0xeb' | Die uebergebenen Werte kommen alle als Hexwerte rein. Also z.b. '0xde' '0xeb' | ||
= uart = | = uart = | ||
Der cand läuft in der aktuellen Version mit '''115200''' baud. | Der cand läuft in der aktuellen Version mit '''115200''' baud. Der CAN-Bus selbst laeuft mit 100000Bps. Die LAP-Pakete werden direkt an den Gateway gesendet. CAN-Pakete auf dem Bus sind dabei maximal 128Bit lang. Es ergibt sich 100000/16=6250 Bytes pro sekunde auf dem Canbus. In der Praxis liegt die reale CAN-Datenrate aufgrund von CAN Interframe Spaces und Bit-Stuffing etwas darunter. | ||
= listen = | = listen = | ||
Der cand hört per default auf den Port 2342. | Der cand hört per default auf den Port 2342. | ||
= CAND-TCP Protokoll = | |||
Der CAND verwendet ein einfaches Protokoll, welches CAN-Frames übertragen kann. Es ist auf dem über die EIA-232 Schnittstelle gesprochenen Protokoll des [[CAN-Gateway|CAN-Gateway]] aufgebaut. Es sind lediglich len und type vertauscht (CAND-TCP sendet len vor type, das Gateway-Protokoll umgekehrt) und enthält keine CRC16-Summe mehr. Weiterhin muss nicht jede implementierung alle Kommandos an das Gateway oder von diesem weiterleiten. Momentan gilt als gesichert, dass Pakete mit dem Kommando 0x11 immer weiter geleitet werden. Andere können aus gründen der Sicherheit und Bus-Stabilität ignoriert werden. | |||
{| |{{prettytable}} | |||
! colspan="4" | CAND-TCP Protokoll | |||
|- | |||
| colspan="4" | <pre style="border:0"> | |||
+-------------+--------------+-------------------+ | |||
| uint8_t len | uint8_t type | uint8_t[] payload | | |||
+-------------+--------------+-------------------+ | |||
</pre> | |||
|- | |||
! Feld !! Bedeutung !! Datentyp !! Länge (Bytes) | |||
|- | |||
| len || Payload-Länge || unsigned byte || 1 | |||
|- | |||
| type || Payload-Typ || unsigned byte || 1 | |||
|- | |||
| payload || Daten || unsigned byte array || 0-18 | |||
|} | |||
* Maximale Gesamtlänge: 20 Bytes | |||
{| | {{prettytable}} | |||
! colspan="3" | LAP-Paket Typen | |||
|- | |||
! Paketname !! Hex-Value !! Bemerkung | |||
|- | |||
| LAP_RESET || 0x00 || | |||
|- | |||
| LAP_CAN_SETFILTER || 0x10 || | |||
|- | |||
| LAP_CAN_PKT || 0x11 || Einbetten von CAN-Paketen | |||
|- | |||
| LAP_CAN_SETMODE || 0x12 || | |||
|- | |||
| LAP_CAN_ERROR || 0x13 || | |||
|- | |||
| LAP_CAN_NOTIFY_RESET || 0x14 || | |||
|- | |||
| LAP_RS232_PING_GATEWAY || 0x15 || | |||
|} | |||
= source = | = source = | ||
http://das-labor.org/trac/browser/microcontroller/src-atmel/automatization2.0/cand | * http://das-labor.org/trac/browser/microcontroller/src-atmel/automatization2.0/cand | ||
http://das-labor.org/trac/browser/microcontroller/src-atmel/automatization2.0/labcontrol | * http://das-labor.org/trac/browser/microcontroller/src-atmel/automatization2.0/labcontrol | ||
[[Kategorie:Automatisierung]] | [[Kategorie:Automatisierung]] | ||
[[Kategorie:Infrastruktur]] | [[Kategorie:Infrastruktur]] |
Aktuelle Version vom 7. Februar 2020, 00:37 Uhr
Cand Release status: stable [box doku] | |
---|---|
Description | Labor-CANBus EIA-232 zu TCP Gateway Dienst |
Author(s) | Joerg, Tixiv, Asklepios |
Last Version | 1.0 () |
Platform | GNU/Linux |
License | ? |
Download | SVN browse |
Der Cand[y] ist der Daemon der auf unserem Intranet-Server läuft und die vom CAN-Bus ankommenden Nachrichten verarbeiten kann. Urspruenglich war er nur als zentrale Instanz fuer lapcontrol gedacht. Lapcontrol ist dabei die Clientsoftware die von jedem Rechner aus gestartet werden kann und via tcp/ip eine Verbindung zum Cand aufbaut.
Das auf der EIA-232 Schnittstelle gesprochene Protokoll ist auf der Seite des CAN-Gateway dokumentiert.
Netzaufbau[Bearbeiten | Quelltext bearbeiten]
Genau genommen sieht es so aus, dass cand ein uart-tcp gateway ist. Damit fuegt er sich in die Struktur wie folgt ein:
+----------------+ +-------------------+ +------------+ +---------------------+ | CAN-Device <-|-> CAN-Bus <-|-> CAN-Gateway <-|-> EIA-232 <-|-> Cand <-|-> tcp/ip <-|-> lapcontrol + UI | +----------------+ +-------------------+ +------------+ +---------------------+
start des cand[Bearbeiten | Quelltext bearbeiten]
Cand wird auf weblab mit
start cand
gestartet resp mit
stop cand
gestoppt. Es ist davon abzuraten den cand von hand zu starten, da er unter einem spez benutzer laeuft der unter anderem schreibenden zugriff auf /var/log/cand hat. Aus sicherheitsgruenden sollte der cand auch nicht als benutzer root gestartet werden, was durch die start/stop-scripte sicher gestellt ist. Daher die obenstehenden commands nur als root ausfuehren
logging[Bearbeiten | Quelltext bearbeiten]
Der cand loggt alles was auf dem Canbus (eigentlich ja auf der uart) passiert mit. Diese Datei befindet sich unter /var/log/cand/cand.log. Sie sollte einmal in der Woche von logrotate rotiert werden. Sie kann mit unter recht gross werden, wenn Geraete ueber den can-bus ein neues image erhalten.
scripting[Bearbeiten | Quelltext bearbeiten]
Es ist moeglich den cand auf spez. events des can-bus reagieren zu lassen. Dafuer ist unter /etc/cand/ die datei cand.scripts gedacht. Diese hat ein recht eigenwilliges Format da hier kurz am beispiel der Uhrzeitanzeige des Laufschriftborgs beschrieben ist. Die beschreibende Zeile ist
0x24:0x30 0x00:0x30 0x01 -> /etc/cand/timeserv.sh
Das liesst sich wie folgt:
src_addr:src_port dst_addr:dst_port data_length -> command_to_call
wenn also ein packet auf dem bus ankommt, das die entsprechenden eigenschaften hat (src/dst/payloadlength) wird das entsprechenden Command ausgefuehrt. Diese command bekommt dabei als ARGV die daten mit. Ein entsprechendes Script saehe dann z.b. so aus:
#!/bin/bash DATALENGHT=$1 FIRSTDATABYTE=$2 SECONDDATABYTE=$3 ... LASTDATABYTE=$n #entspricht n=$DATALENGTH+1 max(n)=9
Die uebergebenen Werte kommen alle als Hexwerte rein. Also z.b. '0xde' '0xeb'
uart[Bearbeiten | Quelltext bearbeiten]
Der cand läuft in der aktuellen Version mit 115200 baud. Der CAN-Bus selbst laeuft mit 100000Bps. Die LAP-Pakete werden direkt an den Gateway gesendet. CAN-Pakete auf dem Bus sind dabei maximal 128Bit lang. Es ergibt sich 100000/16=6250 Bytes pro sekunde auf dem Canbus. In der Praxis liegt die reale CAN-Datenrate aufgrund von CAN Interframe Spaces und Bit-Stuffing etwas darunter.
listen[Bearbeiten | Quelltext bearbeiten]
Der cand hört per default auf den Port 2342.
CAND-TCP Protokoll[Bearbeiten | Quelltext bearbeiten]
Der CAND verwendet ein einfaches Protokoll, welches CAN-Frames übertragen kann. Es ist auf dem über die EIA-232 Schnittstelle gesprochenen Protokoll des CAN-Gateway aufgebaut. Es sind lediglich len und type vertauscht (CAND-TCP sendet len vor type, das Gateway-Protokoll umgekehrt) und enthält keine CRC16-Summe mehr. Weiterhin muss nicht jede implementierung alle Kommandos an das Gateway oder von diesem weiterleiten. Momentan gilt als gesichert, dass Pakete mit dem Kommando 0x11 immer weiter geleitet werden. Andere können aus gründen der Sicherheit und Bus-Stabilität ignoriert werden.
CAND-TCP Protokoll | |||
---|---|---|---|
+-------------+--------------+-------------------+ | uint8_t len | uint8_t type | uint8_t[] payload | +-------------+--------------+-------------------+ | |||
Feld | Bedeutung | Datentyp | Länge (Bytes) |
len | Payload-Länge | unsigned byte | 1 |
type | Payload-Typ | unsigned byte | 1 |
payload | Daten | unsigned byte array | 0-18 |
- Maximale Gesamtlänge: 20 Bytes
LAP-Paket Typen | ||
---|---|---|
Paketname | Hex-Value | Bemerkung |
LAP_RESET | 0x00 | |
LAP_CAN_SETFILTER | 0x10 | |
LAP_CAN_PKT | 0x11 | Einbetten von CAN-Paketen |
LAP_CAN_SETMODE | 0x12 | |
LAP_CAN_ERROR | 0x13 | |
LAP_CAN_NOTIFY_RESET | 0x14 | |
LAP_RS232_PING_GATEWAY | 0x15 |