Benutzer-Werkzeuge

Webseiten-Werkzeuge


project:shacan

shacan

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:

  • Hardware ist günstig verfügbar (CAN Controller MCP2515 = 1,55 Eur @ Reichelt, CAN transceiver MCP2551 = 0,98 Eur @ Reichelt, läuft beispielsweise zusammen mit einem ATTiny-CPU)
  • Geringer Stromverbrauch (schlimmstenfalls zieht der transceiver 75mA@5V für einen dominanten Pegel, durchschnittlicher Verbrauch deutlich unter 10mA)
  • CAN enthält bereits Verfahren zur Fehlererkennung und zur Auflösung von Kollisionen
  • CAN ist in dem Bereich auch von anderen bereits erprobt. –> Es gibt etwas community und libraries

Verkabelung

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

CAN-GPIO

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).

Object-ID

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:

  1. Zwei bit's for future use (beide 0).
  2. ID der empfangenden Platine bei „unicast“ (zum Beispiel Heizungsreglerbefehl), bzw, eine ID der sendenden Platine bei broadcast (zum Beispiel passive Sensoren). Diese id soll 16 bit lang sein.
  3. Dann 8 bit Identifizierung der Funktion auf der Platine.
  4. Dann kommt 1 bit „for future use“, immer 0.

Die ID der Platine kann man ebenfalls systematisieren:

  1. 4 bit Z-Achse (=Stockwerk, vorzeichenbehaftet, negativ = Keller)
  2. 4 bit Y-Achse
  3. 4 bit X-Achse
  4. 4 bit durchnummeriert.

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 :-).

  • Definition Z-Achse: 0 = Erdgeschoss, 1 = die Etage wo der shack bisher quasi ausschließlich ist,… 9=-1= Keller, 10=-2=Erste Bunkeretage (ggf. Bunker noch zu bauen),…
  • Definition X/Y-Achse: Tragende Säulen von der Treppenhausecke an zählen (TODO: Zählen wieviele Säulen das sind und ob man da auch mit 16 Möglichkeiten hinkommt ^^)
  • Definition Nummeriert/Funktion: Frei nach Schnauze

shacan-ethernet bridge

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.

shacan-VServer Webinterface

http://shacan.shack - coming soon

shacan-VServer UDP-Interface

Über das UDP Interface können einfache Befehle an den shacan-VServer gesendet werden. Ein UDP-Befehl besteht aus:

  • Einem Kommando (zwingend)
  • Argumenten (optional)
  • Binärdaten (optional)

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:

  • id (11 oder 29 bit integer (je nach ide flag))
  • srr (substitute remote request, boolean (0/1))
  • rtr (remote transmit request, boolean (0/1))
  • ide (extended id, boolean (0/1))
  • data (Nutzdaten, bis zu 8 Byte, binär (keine Leerzeichen erlaubt und die Nachricht darf nicht mit „0x“ anfangen), oder als eine große Hexzahl mit vorangestelltem „0x“)

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.

project/shacan.txt · Zuletzt geändert: 2017-06-21 17:19 von rixx