shacan ist ein Projekt welches sich damit beschäftigt Shackinfrastruktur und was uns sonst noch einfällt über einen CAN-Bus zu vernetzen. Die Idee enstand aus dem Projekt Heizungsregler, für die eh eine Verkabelung benötigt wird die dann auch gleich so ausgelegt werden kann, dass weitere $Dinge die Infrastruktur mitnutzen kann. Für die Wahl von CAN sprachen folgende Dinge:
Vom Rechenzentrum aus werden ein (oder zwei) Leitungen durch die Kabelkanäle des shack verlegt. Die Leitungen haben 8 Adern, belegt mit CAN-High, CAN-Low, 3x24V, 3xGND. Stichleitungen sind nur für wenige Meter und auch nur wenige im Gesamtsystem erlaubt. Diese sollten aber ohnehin selten nötig sein. Ggf. kann man eine Stichleitung auch als mit je zwei mal CAN-Low und CAN-High auslegen (und um mit 8 Adern auszukommen durch den Stich einfach nur 2x24V und 2xGND durchgeben) und somit die Gesamtleitung kreisförmig halten.
Die Leitungen sind Ethernetkabel mit folgender Belegung:
Draht | Bedeutung |
---|---|
Grün-weiß | CAN-High |
Grün | CAN-Low |
Blau, Blau-weiß, orange-weiß | Ground |
braun, braun-weiß, orange | 24V |
Das CAN-GPIO (CAN General Purpose I/O) Board bietet eine Reihe Pins, die über CAN gesetzt, bzw. ausgelesen werden können. Hardwaretechnisch handelt es sich im wesentlichen um eine Platine mit CAN Controller, CAN transceiver und einem ATTiny4313 controller dessen Pins nach außen geführt sind. Außerdem sind die Boards mit einem Schaltregler ausgestattet, der die 24V auf 5V herunterregelt und einem Linearregler der zusätzlich noch 3V zur Verfügung stellt. Die Spannungsversorgung wurde darauf ausgelegt die hohe Spitzenlast der Heizungsregler handhaben zu können (siehe Projektseite der Heizungsregler).
An jede Außenwandsäule wird eine solche CAN-GPIO-Platine angebracht. (Dies entspricht übrigens pro zwei Heizkörper ein CAN-GPIO-Board).
Im Gegensatz zu IP, welches meist eine Unicast-Kommunikation zwischen einem Sender und einem Empfänger darstellt gibt es bei CAN nur Broadcasts mit einer Objekt-ID (11 bit oder 29 bit) und bis zu 8 Byte Nutzlast. Es sollte kein Problem sein grundsätzlich nur 29 bit „extended ids“ zu verwenden.
Durch CAN's Collision-Resolution-Verfahren gewinnt bei einer Kollision immer die Nachricht mit der kleinsten Object-ID. Daher sollten die ersten zwei Bit der Objekt-ID die Wichtigkeit der Nachricht wiederspiegeln:
Bit 0 und 1 | Wichtigkeit |
---|---|
00 | Besonders hohe Dringlichkeit (Rauchmelder,…) |
01 | Daten mit starker Echtzeitrelevanz (Lichtschalter,…) |
10 | Daten mit untergeordneter Echtzeitrelevanz (Heizungsregler,…) |
11 | Daten ohne Echtzeitrelevanz |
Die restlichen 27 bit könnten dann eigentlich total frei gewählt werden und irgendwo könnten dann große Tabelle stehen wer welche ID hat. Stattdessen lieber mal ein Schema für den shack:
Die ID der Platine kann man ebenfalls systematisieren:
Hier dann der komplette Aufbau der Object-ID:
Format | RFU | Wichtigkeit | Z-Achse | Y-Achse | X-Achse | Nummeriert | Funktion |
---|---|---|---|---|---|---|---|
Bin | 000 | II | ZZZZ | YYYY | XXXX | NNNN | FFFF FFFF |
Hex | 0-7 | I | Z | Y | X | N | FF |
Wie man sieht, kann man das dann im HEX-Format super lesen .
Ein Arduino-Ethernet mit angeschlossenem CAN Controller und CAN transceiver sorgt zusammen mit dem shacan-VServer für die Verbindung des CAN und des Ethernets. Der Arduino sollte ausschließlich vom shacan-VServer angesteuert werden. Um Nachrichten zu versenden oder zu Empfangen sollte der shacan-VServer verwendet werden.
http://shacan.shack - coming soon
Über das UDP Interface können einfache Befehle an den shacan-VServer gesendet werden. Ein UDP-Befehl besteht aus:
Der Inhalt eines UDP Segements sieht so aus:
<Command> [Argumentname[=Argumentwert] [Argumentname2[=Argumentwert2]] …] [$Binärdaten]
Bisher lautet der einzige Befehl „eth2can“ und dieser nimmt eine CAN Nachricht entgegen und speist sie ins CAN-Netz ein. Die zu übertragenen Daten können entweder binär oder ascii-basiert als Parameter spezifiziert werden. Die zur Verfügung stehenden Parameter sind:
Beispiel:
eth2can id=42 srr=0 rtr=0 ide=1 data=0x123400
Dies würde eine „normale“ Nachricht mit der extendedId 42 und 3 Byte Daten (erstes Byte 0x12, zweites Byte 0x34, drittes Byte 0x00) ins CAN einspeisen.
Alternativ können die Daten binär angegeben werden, in folgendem Format:
eth2can $<4 byte id><1 byte srr><1 byte rtr><1 byte ide><1 byte Anzahl Datenbytes><0..8 Datenbytes>
Wenn sowohl Parameter als auch Binärdaten angegeben werden, werden die Parameter ignoriert.