CAN (Controller Area Network) wurde 1986 von Bosch entwickelt um Kabelbäume leichter und effizienter zu gestallten. Das Bussystem ist also prädestiniert dafür in einem 3D Drucker zur Verkabelung eingesetzt zu werden. Die Vorteile liegen klar auf der Hand:
Im 3D Druck Bereich setzen sich vermehrt die Head Boards durch. Also kleine Platinen die alle Funktionen des Druckkopfs steuern und regeln können und direkt am Durckkopf angebracht sind. Diese Boards können fast alle mittels CAN angebunden werden. Im besten Fall reduziert dies die Kabel in der Schleppkette zum Kopf auf 4 (2x Strom, 2x CAN Bus).
Das folgende Dokument beschreibt die Einrichtung von CAN am Raspberry PI, zeigt verschiedene Anschlussvarianten auf und gibt zudem tiefergreifende Informationen (auch zur Fehlersuche).
Hinweis: Klipper unterstützt CAN Bus derzeit nur auf STM32 Controllern. Und dann auch nur wenn die Controller CAN Support mitbringen.
Die Doku enthält doch ziemlich viel Detail Informationen die evtl. nicht jeden interessieren. Darum hier ein Quickstart für Eilige … Die Anleitung basiert auf folgender Hardware:
sudo apt update && sudo apt -y upgrade && sudo apt install -y git can-utils ack-grep silversearcher-ag hexedit sudoku tcpdump iptraf mc wavemon
sudo raspi-config
→ 3 Interface Options → P4 SPI → Enable YESsudo nano /boot/config.txt
dtparam=spi=on
folgendes einfügen dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000
sudo nano /etc/network/interfaces.d/can0
auto can0 iface can0 can static bitrate 500000 up ifconfig $IFACE txqueuelen 128
sudo reboot
cd ~/klipper
make clean && make menuconfig
Communication interface (CAN bus (on PD0/PD1))
. Und drauf achten das die Geschwindigkeit mit der Raspberry Config überein stimmt: (500000) CAN bus speed
. Speichern ….make -j4
out/klipper.bin
auf das Board flashen~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Ein CAN Bus ist im Grunde immer gleich aufgebaut. Es gibt zwei Leitungen die zur Datenübertragung genutzt werden : CAN L(ow) und CAN H(igh). An die beiden Busleitungen werden dann die Knoten / Teilnehmer angeschlossen. Jeder der Knoten (und das könnte z.B. ein Drucker Board sein) hängt über einen Transceiver mit am CAN Bus. Am Anfang und am Ende des CAN Bus ist jeweils ein 120Ω Widerstand platziert. Diese sind für Signalterminierung zuständig und verhindern Reflektionen (und damit Störungen) auf dem CAN Bus.
Aus dem Schaubild ergeben sich daraus schon einige Dinge die man beachten sollte:
Die meisten Themen werden aber noch im Detail erklärt.
Die CAN Bus Leitung verbindet alle Teilnehmer des CAN Bus miteinander. Bei der Länge ist das aus 3D Drucker Sicht unkritisch - denn selbst mit 500kBit/Sec kann die Buslänge immer noch ca. 100m betragen. Grundsätzlich kann man aber sagen - je länger das Kabel, desto geringer die Übertragungsgeschwindigkeit. Prinzipiell sollten sich also auch mehrere Drucker mit einem CAN Bus betreiben lassen. Im Netz gibt es diverse Übersichten was die Maximallänge angeht. Aber ganz grob schaut das immer so aus:
Baud-Rate | Buslänge |
---|---|
1 MBit/s | < 20 m* |
500 kBit/s | < 100 m |
250 kBit/s | < 250 m |
125 kBit/s | < 500 m |
50 kBit/s | < 1000 m |
20 kBit/s | < 2500 m |
10 kBit/s | < 5000 m |
Angaben zum Thema Stub (siehe Schaubild oben) bzw. Stichleitungen findet man nur spärlich. Grundsätzlich sollte man solche Stichleitungen vermeiden denn sie führen zu Signalreflektionen (= Störungen). Ein grober Anhaltswert wären ca. 0,5m bei 500kBit/s. Aber wenn eben möglich sollte der CAN Bus wie an einer Perlenkette aufgebaut werden, also von Gerät zu Gerät verbunden. Nur so ist eine saubere Terminierung sichergestellt.
Grundsätzlich sollten die Kabel bei CAN verdrillt sein. Bei guten Kabeln sind die Paare auch zusätzlich geschirmt. Schirmung ist bei den kurzen Distanzen im Drucker aber eher weniger notwendig. Der Querschnitt sollte ebenfalls nicht zu gering sein um den Leitungswiderstand klein zu halten.
Buslänge [m] | Widerstand [mΩ/m] | Querschnitt [mm²] |
---|---|---|
0 - 40 | 70 | 0,25 - 0,34 |
40 - 300 | < 60 | 0,34 - 0,60 |
300 | < 40 | 0,50 - 0,60 |
600 - 1000 | < 26 | 0,75 - 0,80 |
Für einen 3D Drucker sollte also für die CAN Leitungen 0,25mm² Leitung reichen. Bei den stromführenden Leitungen sieht das etwas anders aus …
Wer noch Strom zum Kopf führen will sollte das vorher mal grob überschlagen. Gehen wir mal von 24V aus und ca. 60W Heizpatrone. Dazu kommen vielleicht nochmal 0,5A an Strom für die Elektronik. Dann bedeutet das wir müssen ca. 60W/24V = 2,5A + 0,5A = ~3A zum Kopf transportieren. Gehen wir weiter davon aus das im Drucker ca. 3m Kabel lieben (und das wäre schon arg lang) dann hat ein Kabel mit 0,5mm² Querschnitt überschlagen ca. 0,11Ω an Leitungswiderstand. Damit lässt sich dann der Spannungsabfall berechnen … U = R*I = 0,11Ω * 3,0A = 0,33V. Am Kopf kommen also von den 24V ca. 23,7V an. Das passt
→ http://www.e-formel.info/elektrotechnik/leitungswiderstand.html
Für den Druckkopf sollte man 4*0,5mm² Leitung verwenden. Zudem sollte das Kabel Schleppkettentauglich sein sonst ist es nach kurzer Bewegung schnell hin. Da es die Igus Kabel nicht an jeder Ecke gibt kann man auch einfach etwas dickere nehmen. Bei Voelkner gibt es z.B. Igus-CF9.10.04 - also 4×1,0mm². Das passt dann locker und ist auch nur ca. 6mm im Durchmesser.
Passende Leitungen gibt es von IGUS:
0.5mm² → https://www.igus.de/product/CF9?artnr=CF9.05.04
0.75mm² → https://www.igus.de/product/CF9?artnr=CF9.07.04
2 x 0,5mm² → https://www.voelkner.de/products/71738/Igus-CF9.05.02-Schleppkettenleitung-Chainflex-CF-2-x-0.50mm-Blau-Meterware.html
4 x 1mm² → https://www.voelkner.de/products/71853/Igus-CF9.10.04-Schleppkettenleitung-Chainflex-CF-4G-1mm-Blau-Meterware.html
Bei der Verkabelung vom CAN Bus ist darauf zu achten das die Anschlüsse richtig verbunden werden. Der BUS hat immer eine Leitung für CAN L(ow) und eine für CAN H(igh). Das ist auf den Boards oft mit H / L oder CH / CL oder eben CANL / CANH beschriftet. Dabei gilt … Gleiches mit Gleichem verbinden
Beispiel mit dem Waveshare Board und dem BTT 42 Kopf Board:
H geht auf CAN-H und L geht auf CAN-L.
Es gibt Boards wo der CAN Anschluss mit Tx, Rx oder T, R gekennzeichnet ist. Manchmal findet sich auch die Bezeichnung CAN Tx und CAN Rx. Hier ist Vorsicht geboten denn diesen Anschlüssen fehlt oft der CAN Transceiver. Ein Paradebeispiel ist hier (leider) das Spider Board.
Wie man sieht werden die Pins mit RX und TX bezeichnet - das ist noch kein CAN Anschluss! Hier fehlt der Transceiver der die TX, RX Signale in CAN H und CAN L wandelt. Ein passender Adapter findet sich bei Ebay oder Amazon - einfach nach CAN Transceiver suchen.
Aber Obacht : Hier muss auf die Spannung geachtet werden. Das Spider Board liefert an seinem CAN Anschluss 5V. Viele CAN Transceiver bei Ebay nutzen aber den SN65HVD230 Chip und der arbeitet mit 3,3V ! Also genau drauf achten was man kauft. Faustregel: Suche nach TJA1050 CAN Transceiver liefert 5V Typen, Suche nach SN65HVD230 CAN Transceiver liefert 3,3V Typen
Der Anschluss der Transceiver ist dann trivial. 4 Leitungen gehen vom Board zum CAN Transceiver und der wird mit 2 Leitungen an den CAN Bus angeschlossen (auch hier auf L / H achten !).
Wie im Schaubild oben zu sehen ist muss der CAN Bus am Ende mit jeweils einem 120Ω Widerstand terminiert werden. Wenn diese Endwiderstände nicht vorhanden sind kommt es auf dem Bus zu Signalreflektionen und damit früher oder später zu Störungen. Man muss allerdings aufpassen wo und wie viele Widerstände “aktiv” am Bus hängen. Denn viele Boards bringen die Möglichkeit mit diese 120Ω zu aktivieren. Auf einigen Boards (wie z.B. die billigen eBay CAN Transceiver) lässt sich der Widerstand auch gar nicht deaktivieren (mittels Jumper).
Deshalb immer 2x hinschauen wo sich am BUS Kabel Widerstände befinden. Die Widerstände sollten immer am Ende des Kabels sein. Bei einem Drucker ist das oft direkt vorgegeben. Es gibt einen Buskoppler am Raspberry PI und ein Drucker Board z.B. am Druckkopf. Beide haben in der Regel einen 120Ω Widerstand direkt verbaut und der BUS ist damit sauber terminiert. Hängen aber mehrere Teilnehmer am CAN Bus kann das durchaus ein Thema werden.
Wer sich unsicher bezüglich der korrekten Terminierung ist kann dies mit einem Digitalmultimeter (Ohm Messung) prüfen. Dazu alle Elektronik erstmal stromlos machen! Dann kann man mit dem Ohmmeter den Widerstand zwischen der L und H CAN Leitung messen. Dabei sollte das Messgerät ~60Ω anzeigen (Das Ergebnis von 120Ω parallel zu 120Ω). Ist das Ergebnis kleiner ist garantiert ein Widerstand zu viel aktiv am Bus. Misst man hingegen 120Ω fehlt ein Widerstand - bei unendlich Ω fehlen beide
Der CAN Transceiver stellt die Verbindung dar zwischen den CAN Daten die geschrieben und gelesen werden sollen und dem physikalischem CAN BUS. Er “übersetzt” sozusagen die Daten in passende Bussignale. Von diesen Transceivern (= Gerät was lesen und schreiben kann) gibt es eine ganze Menge, jedoch sind sie sich alle ziemlich ähnlich - meist kleine 8 pinnige ICs. Hier eine kleine Übersicht :
In einem Punkt unterscheiden sich die ICs aber deutlich und das ist die Versorgungsspannung. Viele der Transceiver brauchen 5V um zu funktionieren, wenige kommen mit 3,3V klar. Es hängt immer von der Schaltung ab wo ein CAN Transceiver eingesetzt wird. Bei einem Spider Board liefert das Board 5V als Versorgung. hier können also nur die Vcc 5,0V Typen verwendet werden. Am Raspberry Pi will man hingegen lieber einen 3,3V Typen verwenden. Denn der ganze Raspberry Pi arbeitet mit 3,3V Pegeln. Gerade wenn man den Transceiver selber verbaut sollte man hier Obacht walten lassen
Die Bus Pegel bei einem CAN Bus sind - unabhängig von der Transceiver Versorgung - immer gleich.
Wenn sich der CAN-Bus im Ruhezustand befindet, führen beide Leitungen 2,5 V. Wenn Datenbits übertragen werden, geht die CAN High-Leitung auf 3,75V und die CAN-Low-Leitung auf 1,25V, wodurch eine 2,5V-Differenz zwischen den Leitungen entsteht.
Wie schon vorher erwähnt gibt es Boards mit und ohne CAN Transceiver. Ohne Transceiver funktioniert das Board am CAN Bus nicht! Hier hilft nur ein Blick in den Schalplan ob ein extra Transceiver benötigt wird oder nicht.
Beispiel Spider Board
Die Pins gehen direkt an den Controller und sind mit Tx / Rx beschriftet. Hier muss der Transceiver ergänzt werden!
Beispiel Octopus Board
Hier ist ein MCP2542 Transceiver verbaut und rechts sind die Anschlüsse auch mit CAN_H / CAN_L beschriftet. Hier ist alles vorhanden für CAN.
Faustregel
sind die Pins nicht mit CAN H / CAN L (oder H / L) beschriftet braucht es in der Regel einen extra Transceiver!
Bei einem CAN Bus ist es wichtig das alle Bus Teilnehmer die gleiche Geschwindigkeit benutzen. Sonst können Bus Teilnehmer nicht gefunden bzw. verwendet werden.
Also immer drauf achten das die Geschwindigkeit am Raspberry Pi …
mit der in der Klipper Firmware übereinstimmt !
Zu guter Letzt noch ein sehr kontrovers diskutiertes Thema beim CAN Bus. Muss ich die Masse der CAN Bus Teilnehmer miteinander verbinden? Grundsätzlich kann man sagen - nein. Auf dem CAN Bus werden die Daten differentiell übertragen woraus sich eine Spannungsdifferenz ergibt die ausgewertet werden kann. Als Beispiel dafür mein Testaufbau:
Der PI (links) ist über das Waveshare HAT nur mit 2 Strippen mit dem Drucker Board verbunden (über den Transceiver unten mittig im Bild). Es gibt keine direkte Masseverbindung bei den Boards. Funktionieren tut das tadellos
ABER
In der realen Welt teilen sich PI und Drucker Board eh schon die gleiche Masse durch das Netzteil. Also ist es im 3D Drucker Umfeld irrelevant.
Prinzipiell sorgt eine CAN Masse dafür das die CAN Pegel zwischen den Boards nicht zu große Differenzen aufweisen. Das kann bei sehr störbehafteten Umgebungen zu Problemen führen. Aber wie schon erwähnt haben wir im Drucker eh eine gemeinsame Masse und das Thema ist damit abgehakt.
Letztlich gibt es da nicht sehr viel zu tun…
sudo apt update && sudo apt -y upgrade && sudo apt install -y git ack-grep silversearcher-ag tcpdump can-utils python3-can
sudo raspi-config
→ 3 Interface Options → P4 SPI → Enable YESsudo nano /etc/network/interfaces.d/can0
auto can0 iface can0 can static bitrate 500000 up ifconfig $IFACE txqueuelen 128
Alle weiteren nötigen Schritte werden bei den Buskopplern erklärt. Wenn auch die eingerichtet sind empfiehlt sich ein Reboot sudo reboot
Hinweis : Werden keine CAN Boards gefunden sollte man die Bitrate hier mit 250000 versuchen. Dann müssen natürlich auch alle Firmware Versionen neu kompiliert werden mit der Geschwindigkeit. Hier kann schlechtes Kabel einem schwer in die Suppe spucken …
Also Buskoppler werden hier die Geräte gemeint welche den Raspberry PI (oder jeden anderen SBC) in die Lage versetzen mit einem CAN Bus zu kommunizieren.
Grundsätzlich gibt es da 3 Typen:
Die USB Typen sollen (laut Klipper Doku) stabiler laufen vor allem wenn mehrere CAN Boards angeschlossen werden. Die SPI Typen erzeugen wohl höhere CPU Last am PI. Auf der anderen Seite sind SPI Typen günstiger, leichter zu beschaffen und einfacher in der Handhabung als USB Typen. Die Klipper Entwicklern nutzen wohl auch eher das Waveshare HAT was ein SPI Buskloppler ist. Ganz so verkehrt kann das also nicht sein Hier muss man sicher noch etwas probieren und testen …
Der Bridge Mode ist derzeit in der experimentellen Phase. Ob er in den Hauptzweig von Klipper aufgenommen wird muss sich noch zeigen.
In dieser Klipper Doku finden sich dazu weitere Informationen:
The MCP2515 is a very common SPI connected CAN bus chip. It is a pretty bad options since it has very small buffers on chip and creates a lot of CPU load on the Raspberry Pi, and has a tendency to drop packet. It is not recomended if you use more than 1 or 2 boards or if you plan to use the accelerometer. You have to run the CAN bus at 250kbits/s or possibly 500kbits/s. An older Pi, or a Pi Zero will not work reliably, it has to be a Pi3 or Pi4 or better.
Hier finden sich auch noch weitere Infos zu dem Performance Problem → https://www.beyondlogic.org/adding-can-controller-area-network-to-the-raspberry-pi/
Im Grunde ein schönes Board. Es hat einen SN65HVD230 Transceiver verbaut und ist somit schon mal 3,3V kompatibel mit dem Raspberry Pi. Aber leider hat es auch einen Nachteil - es hat zusätzlich noch einen RS485 Anschluss. Und dieser belegt auch noch den seriellen Port des Raspberry Pi. Das ist arg unpraktisch wenn das Haupt Drucker Board seriell mit dem PI verbunden ist.
sudo nano /boot/config.txt
dtparam=spi=on
folgendes einfügen dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000
Dieser Umbau ist nur dann nötig wenn man den seriellen Port am Raspberry PI verwenden möchte. Wer das Drucker Board über USB betreibt müsste hier nichts tun. Grundsätzlich brauche ich den RS485 Part aber so oder so nicht. Also kann auch alles vom Board runter was unnötig Strom frisst ….
Nach dem “Umbau” …
Läuft tadellos, aber die Garantieansprüche sind dann auch dahin
Die Tests funktionieren nur wenn der PI eingerichtet wurde, das Waveshare HAT eingerichtet ist und der Raspberry Rebootet wurde !
Siehe Wiki → https://www.waveshare.com/wiki/2-CH_CAN_HAT
Siehe Wiki → https://www.waveshare.com/wiki/2-CH_CAN_HAT → Testing
Bei Ebay, Amazon und Co. gibt es für wenige Euro ebenfalls Buskoppler. Diese sind aber nicht als HAT konzipiert sondern einfach als kleine Extraplatine. Die Boards haben nur einen Nachteil wenn man sie mit einem Raspberry PI verwenden will - 5V Versorgung. Der verbaute Transceiver braucht in der Regel 5V Versorgungsspannung. Und das macht ihn ohne weiteres nicht verwendbar für den Raspberry PI. Der gleich folgende Hack beschreibt wie das dennoch klappt
sudo nano /boot/config.txt
dtparam=spi=on
folgendes einfügen dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000
Achtung : ocillator muss passen !
Auf dem Board ist ein Bauteil mit silberner Kappe. Das ist der Quarz für den MCP2515 Chip. Da ist eine Nummer aufgedruckt, entweder 8.000 (oscillator=8000000) oder 12.000 (oscillator=12000000). Je nachdem muss bei oscillator der passende Wert eingetragen werden!
Tja leider hat die Platine den falschen Transceiver verbaut. Also bleibt nix anderes als den Transceiver zu tauschen. So einen 8 Pinner kann man noch ganz gut von Hand auslöten. Bei Ebay sucht man sich eine Platine mit SN65HVD230 Chip. Den lötet man dann einfach um und fertig. Die Chips sind pinkompatibel.
Alternativ kann man sich auch den Chip bei Reichelt oder Aliexpress bestellen.
Siehe dazu auch hier → https://www.beyondlogic.org/adding-can-controller-area-network-to-the-raspberry-pi/
Die Tests funktionieren nur wenn der PI eingerichtet wurde, das Waveshare HAT eingerichtet ist und der Raspberry Rebootet wurde !
candleLight ist ein Projekt auf GitHub und stellt eine Firmware für diverse USB <> CAN Adapter bereit. Die Firmware “übersetzt” also den CAN Bus in ein USB Gerät. Mangels Hardware konnte das noch nicht getestet werden.
Wer eine Alternative zum BTT Adapter sucht sollte auf Aliexpress nach “CANable” suchen. Da finden sich für ~25€ passende USB Adapter die mit candleLight funktionieren.
Dann gibt es da noch die U2C Boards von BIGTREETECH in zwei Versionen. Die V1.1 hat lediglich noch ein paar mehr Anschlussmöglichkeiten als die V1.0 Version. Technisch sind die aber identisch. Auch diese Boards nutzen die candleLight Firmware. Ansonsten werden die sehr ähnlich eingerichtet wie die SPI Buskoppler. Der Unterschied besteht lediglich darin das kein extra Interface erzeugt werden muss.
Das Board wird später noch genauer getestet - ist aber noch in der Post
Inzwischen gibt es eine ganze Reihe an Drucker Boards die mit CAN betrieben werden können. Die folgende Liste ist auch sicher unvollständig, sollte aber ein paar nützliche Hinweise liefern für das ein oder andere Board
Das FYSETC Spider Board ist in allen Versionen CAN kompatibel. es hat allerdings keinen CAN Transceiver mit auf der Platine. Auf dem Board findet sich nur ein 4poliger Anschluss für CAN:
Von Links nach Rechts sind die Anschlüsse Masse, Rx, Tx, 5V. Der CAN Bus liegt auch auf dem EXP1 Anschluss und teilt sich die Pins mit dem Display. Wer also ein Display betreibt ist hier bei CAN leider aus dem Rennen.
Damit das Board überhaupt am CAN Bus funktioniert muss ein Transceiver nachgerüstet werden. Auf jeden Fall einen 5V Typen verwenden!
So wäre der dann zu verkabeln. Ganz Links am Transceiver würde dann CAN L und CAN H angeschlossen. Und auch hier Obacht bei den Endwiderständen des CAN Bus! Bei dem Adapter im Bild ist der fest verlötet.
Folgende Einstellungen sind zu treffen:
Wenn ein Bootloader verwendet wird muss der natürlich hier berücksichtigt werden. Die CAN bus speed muss auch zu den Einstellungen am Raspberry Pi passen.
Zum Flashen der Firmware nutzt man am einfachsten das Tool dfu-util in der Linux Konsole.
dfu-util -R -a 0 -s 0x08000000:leave -D out/klipper.bin
Das BTT Octopus (Pro) Board hat den Vorteil das bereit ein CAN Transceiver verbaut ist. Genaugenommen ein MCP2542 Transceiver. Der CAN Bus kann also direkt an die Pins CAN_H und CAN_L angeschlossen werden. CAN wird beim Octopus über eine RJ45 Buchse verbunden:
Der CAN Bus ist auf die mittleren beiden Pins der RJ45 Buchse gelegt.
Folgende Einstellungen sind zu treffen:
Wenn ein Bootloader verwendet wird muss der natürlich hier berücksichtigt werden. Die CAN bus speed muss auch zu den Einstellungen am Raspberry Pi passen.
Zum Flashen der Firmware nutzt man am einfachsten das Tool dfu-util in der Linux Konsole.
dfu-util -R -a 0 -s 0x08000000:leave -D out/klipper.bin
Die EBB Boards sind Erweiterungen für den Druckkopf. Sie werden an den Extrudermotor geschraubt und können alle Kopffunktionen bis hin zum Licht übernehmen. EBB36 ist die Variante für NEMA14 Stepper, EBB42 die für NEMA17. Die Boards sind bei Ebay und Aliexpress für ~20-50€ zu bekommen - je nach Ausstattung.
Handbuch, Doku und Schaltplan → https://github.com/bigtreetech/EBB
Folgende Einstellungen sind zu treffen:
Einen Bootloader braucht man hier nicht installieren da kein SD Slot vorhanden ist.
Zum Flashen der Firmware nutzt man am einfachsten das Tool dfu-util in der Linux Konsole.
dfu-util -R -a 0 -s 0x08000000:leave -D out/klipper.bin
Hier gibt das Gleiche wie bei Version V1.0. Der Unterschied ist nur ein anderer Prozessor.
Achtung: Wenn man das Board in den Boot Modus (DFU) versetzt um eine neue Firmware zu flashen wird kurzzeitig das Hotend geheizt! Das liegt an der Art und Weise der Controller Initialisierung. Im Zweifel das Hotend kurz abklemmen für ein Update!
Folgende Einstellungen sind zu treffen:
Einen Bootloader braucht man hier nicht installieren da kein SD Slot vorhanden ist.
Zum Flashen der Firmware nutzt man am einfachsten das Tool dfu-util in der Linux Konsole.
dfu-util -R -a 0 -s 0x08000000:leave -D out/klipper.bin
Das scheinen mir doch ziemliche Clone von den BTT Boards EBB36 / EBB42 zu sein. Insofern gilt bei denen auch das Gleiche bezüglich Firmware und Anschluss.
Hier gibt es noch weitere Infos:
http://mellow.klipper.cn/?spm=a2g0o.detail.1000023.17.31063265qOYbBR#/board/fly_sht36_42/
Das Huvud Board war wohl eines der ersten CAN Boards für den Druck Kopf. Es gibt inzwischen diverse Versionen und Stände von diesem Board. Das größte Problem ist die Verfügbarkeit - es ist kaum mal irgendwo zu bekommen.
Folgende Einstellungen sind zu treffen:
Weitere Infos zum Flashen finden sich hier:
https://github.com/bondus/KlipperToolboard/blob/master/doc/klipper.md
Ein weiteres Board mit CAN. Allerdings noch nie in der Hand gehabt oder gesehen. Deswegen hier nur der Verweis auf die Webseite für weitere Infos.
Auch Board Eigenbauten sind mit Klipper möglich. Hier können alle Controller verwendet werden die einen CAN Bus mitbringen. Zu erkennen ist das immer daran das unter dem Cummunication Interface CAN ausgewählt werden kann.
In diesem Fall ist das ein STM32F103 der u.a. auch auf dem Blue Pill Board verbaut wird.
Um eine Eigenkonstruktion an CAN zu betreiben muss natürlich ein Transceiver her. Hier ist wieder auf die 3,3V bzw. 5V Variante zu achten - was natürlich von dem verwendeten Controller abhängt.
So ein Board könnte man z.B. zur LED Beleuchtung hernehmen. Aber grundsätzlich kann man mit so einem Board alles steuern und Regeln was Klipper so anzubieten hat. Wer da Inspirationen braucht sollte sich mal den Schaltpan der BTT Kopfboards ansehen. Der sitzt der Controller auch drauf
Die Konfiguration von Klipper mit einem CAN Board unterscheidet sich nur in einem Punkt - die canbus_uuid. Boards die nicht über CAN betrieben werden nutzten einen seriellen Port für die Kommunikation mit dem Raspberry PI:
[mcu] restart_method : command serial : /dev/ttyAMA0
Wir CAN verwendet ändert sich nur die serial Zeile zu canbus_uuid:
[mcu] restart_method : command canbus_uuid : 5b5a812a7283
Bleibt noch die Frage wie man an die UUID ran kommt. Dafür gibt es Klipper Python Script
sudo systemctl stop klipper.service
sudo systemctl start klipper.service
Kommt hier die Meldung Total 0 uuids found
wurde kein Board am CAN Bus gefunden. Das kann leider eine ganze Menge an Gründen haben:
canbus_query.py
Skript ist auch eher von launischer Natur. Es findet die Boards teilweise nicht obwohl sie mit Klipper funktionieren. Also vor canbus_query.py immer erst den Klipper Dienst stoppen die Boards resetten!Wer hier hängt sollte sich das Kapitel Fehlersuche mal genauer durchlesen.
Nachdem am Anfang schon ein “einfaches” Beispiel mit einem CAN Bus Board war kommt hier ein Beispiel mit 2 CAN Boards. Das Beispiel setzt praktisch das Schaubild vom Anfang um. Wir haben also folgende Komponenten:
Betrachtet wird nur der Teil bis die Boards in und mit Klipper funktionieren. Die Konfiguration ist hier nicht Bestandteil - sollte aber normalerweise auch kein Problem darstellen.
Wie der Raspberry PI eingerichtet werden muss steht in diesem Kapitel.
Wie ein Spider Board mit Firmware geflasht wird steht in diesem Kapitel.
Wie ein BTT Board mit Firmware geflasht wird steht in diesem Kapitel.
Wie schon oben im Schaubild zu sehen ist werden alle 3 BUS Teilnehmer wie an einer Perlenschnur miteinander verbunden.
(1) ist der CAN Bus. Das schlimmste Kabel was man verwenden kann, aber so findet man Fehler Es ist aber wie beschrieben von CAN Device zu CAN Device einfach durchgeschliffen.
(2) ist der Transceiver für das Spider Board.
Viel mehr ist es nicht. Man sollte nur peinlichst drauf achten das jeweils CAN_L an CAN_L ist und gleiches für CAN_H.
Die Busteilnehmer muss man suchen, weil man die UUIDs für die Konfiguration in Klipper braucht. Das Kommando dazu lautet folgendermaßen:
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Als Ergebnis müsste dann eine Ausgabe wie diese kommen:
Welches Board nun zu welcher UUID gehört kann man mit dieser Ausgabe nicht ermitteln. Hier hilft nur raten oder die Boards einzeln am CAN Bus anschließen und auslesen.
Problematisch ist das canbus_query.py
Skript bei der Benutzung. Es gibt Situationen wo die UUIDs nicht angezeigt werden und das obwohl die Boards definitiv funktionieren. Deswegen folgendermaßen vorgehen:
sudo systemctl stop klipper.service
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Wer hier hängt sollte sich das Kapitel Fehlersuche mal genauer durchlesen.
Bleibt noch die printer.cfg mit passenden Einträgen zu versehen. Hier ist für einen ersten Test nur die Minimal Konfig abgebildet:
Wie schon vorher beschrieben gibt es hier keinen Eintrag für serial.
Nach einem Restart von MainSail sollte dann das Ergebnis so aussehen:
(1) ist das Spider Board (zu erkennen an den 180MHz)
(2) ist das BTT EBB42 Kopf Board
Es gibt seit kurzer Zeit einen neuen Modus für CAN fähige STM32 Boards - den Bridge Mode. Dabei kann man sich am Raspberry PI das extra CAN HAT ersparen. Die Aufgabe übernimmt ein Stückchen Software in der Drucker Board Klipperfirmware. Das schaut dann in etwa so aus:
Auch wenn dieser neue Modus erstmal sehr interessant klingt, bringt er doch ein paar Einschränkungen mit sich:
make menuconfig
sind relevant. sudo ip link set up can0
wieder reaktivieren, jedoch gibt es dafür derzeit noch keinen Automatismus. Wer das zur Zeit testen möchte muss den git Branch “work-usbcan-20220608” verwenden. Den bekommt man so:
cd ~/klipper
git checkout work-usbcan-20220608
git checkout master
Könnte einen spannende Sache werden, denn es erspart das CAN Interface am Raspberry PI. Allerdings sollte man warten bis diese Funktion in den Hauptzweig von Klipper eingefügt wurde. Derzeit ist es eher ein experimentelles Feature mit Potential
Es gibt seit einiger Zeit ein sehr interessantes Projekt namens “CanBoot”. CanBoot ist ein alternativer Bootloader für STM32 Controller. Er ermöglicht das Flashen von Klipper über den CAN Bus. Es muss also weder ein USB- oder serielles Kabel angeschlossen werden, noch muss ein Jumper gesetzt oder eine SD Karte eingesteckt werden. Finden kann man dieses Wunderwerk der Entwicklung hier: https://github.com/Arksine/CanBoot
Hinweis: In den vorherigen Kapiteln wurde immer beim Flashen auf einen Bootloader verzichtet. Damit CanBoot aber funktionieren kann sind ein paar zusätzliche Schritte nötig. Der Bootloader muss zuerst geflasht werden wie jede andere Firmware auch. Erst danach kommt man in den Genuss die Klipper Firmware über CAN aufzuspielen.
Um CanBoot zu nutzen muss zunächst einmal der Code geladen werden:
cd ~
git clone https://github.com/Arksine/CanBoot
cd CanBoot
Dann muss der Controller konfiguriert werden - ähnlich wie beim Klipper kompilierern:
make menuconfig
make
Hinweis: Nur es nochmals klar darzustellen - auch wenn es so aussieht ist das nicht Klipper! Es ist ein Bootloader um später Klipper über CAN flashen zu können.
Wichtig: Es ist zwingend erforderlich sich den Punkt “Application start offset” zu merken. Wenn später Klipper kompiliert wird muss das als Bootloader Offset angegeben werden! Sonst würde nämlich der frisch installierte CanBoot Bootloader wieder überschrieben.
Der nächste Schrott besteht dann darin den frisch kompilierten Bootloader auf das Drucker Board zu flashen. Für diesen Test ist das ein EBB46 V1.0 Board. Aber das sollte mit allen anderen STM32 Controllern ganz genauso funktionieren.
dfu-util -R -a 0 -s 0x08000000:mass-erase:force -D out/canboot.bin
Nachdem das Board nun den CanBoot Bootloader installiert hat muss es am CAN Bus auch gefunden werden. Dazu gibt es ein extra Python Script im CanBoot Verzeichnis flash_can.py
.
Alternativ geht die Board suche auch mittels canbus_query.py
sudo systemctl stop klipper.service
sudo systemctl start klipper.service
Bleibt noch der letzte Schritt - Klipper über CAN zu flashen.
cd ~/klipper/scripts/
make
zum Kompilieren der klipper Firmwarecd ~/CanBoot
python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u <uuid>
python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 539892be834d
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Found canbus_uuid=539892be834d, Application: Klipper
Das tolle an diesem Bootloader ist, dass man am Drucker Board nichts mehr machen muss wenn er einmal aufgespielt ist. Also keinen Taster drücken für DFU Mode, keine SD Karte, nichts. Einfach nur erneut das Flash Skript aufrufen mit der neuen Klipper Firmware und alles geht wie von Zauberhand. Eine enorme Vereinfachung für den Flashvorgang
Wie schon etwas weiter oben im Text aufgezeigt, kann es eine ganze Reihe an Gründen / Problemen geben warum der CAN Bus nicht sauber funktioniert. Dafür im Folgenden ein paar praktische Tipps zur Fehlersuche …
https://github.com/Esoterical/voron_canbus/tree/main/troubleshooting
CAN Bus falsch verdrahtet
Auch wenn der CAN Bus nur 2 Leitungen benötigt muss auf die Verdrahtung geachtet werden. CAN L gehört immer an CAN L, CAN H immer an CAN H. Das gilt für alle Geräte am CAN Bus!
CAN Bus ohne die 120Ω Widerstände am Ende der Busleitung
Am Ende des CAN Bus muss jeweils ein 120Ω Widerstand für die Terminierung vorhanden sein. Diese beiden Widerstände hängen am *äußersten Ende der Busleitung* jeweils zwischen CAN L und CAN H. Prüfen kann man die Widerstände mit einem Ohmmeter. Wenn die Hardware (= der Drucker) komplett stromfrei ist, einfach zwischen CAN L und CAN H den Widerstand messen:
CAN Bus Speed ist zu schnell für das Kabel / schlechtes Kabel
Für den CAN Bus sollte im Bestfall gedrilltes Kabel verwendet werden. Auch die Dicke der Adern sollte nicht zu gering sein. Sind diese Kriterien nicht erfüllt kann es vorkommen das der CAN Bus nicht sauber funktioniert. Geräte werden dann z.B. nicht sauber oder nur sporadisch erkannt. In einem solchen Fall sollte man die Busgeschwindigkeit herunter setzen auf 250000 Bit/s (oder auch noch tiefer wenn nötig - siehe dazu Tabelle am Textanfang).
Einstellen kann man die Bus Geschwindigkeit in der Datei /etc/network/interfaces.d/can0
→ bitrate
Achtung: Wenn die Busgeschwindigkeit angepasst wird muss auch jder Busteilnehmer mit einer neuen Firmware geflasht werden (CAN bus speed)!
Kein Transceiver auf dem Board bzw. keiner extra angeschlossen
Einige Boards haben keinen Transceiver verbaut - wie z.B. das Spider Board. Hier muss ein extra Transceiver angeschlossen werden der auch zur Spannungsversorgung des Boards passen muss. Hier sollte man ggf. im Schaltplan des Boards nachsehen ob ein Transceiver verbaut ist.
Faustregel: Sind die CAN Pins auf dem Board nicht mit CAN H, CAN L sondern eher mit Tx, Rx beschriftet fehlt in der Regel der Transceiver!
SPI nicht aktiviert
Damit die SPI basierten Buskoppler funktionieren muss auf dem Raspberry PI die SPI Schnittstelle eingeschaltet werden. Das geht über sudo raspi-config
→ 3 interface Options → P4 SPI. Nach dem einschalten den PI einmal durchbooten. Äußern kann sich das dann in der Meldung mcp251x spi0.0 **can0: bus-off**
wenn man den Befehl dmesg |grep '251\|can\|spi'
absetzt.
SPI mcp251x funktioniert nicht
Fast alle SPI basierten Buskoppler basieren auf dem Chip mcp251x. Damit dieser sauber funktioniert muss er in der Konfiguration vom PI eingerichtet werden. Siehe dazu die Buskoppler Infos. Wenn der Chip sauber läuft liefert der Befehl dmesg |grep '251\|can\|spi'
in etwa folgende Ausgabe:
Firmware falsch oder nicht korrekt aufgespielt (oder gar nicht aufgespielt)
Es sollte natürlich sichergestellt sein das die richtige Firmware für das Board eingerichtet und kompiliert wurde. Tückisch kann dabei ein vorhandener Bootloader sein (Stichwort Bootloader offset) oder eine falsch eingestellte CPU und / oder Clock Reference. Hier also genau auf die richtigen Einstellungen achten.
Manchmal kann es auch helfen vor dem Schreiben der Firmware den Flash Speicher zu löschen. Dann ist der Aufruf von dfu-util leicht anders.
Anstatt wie sonst üblich mit leave
dfu-util -R -a 0 -s 0x08000000:leave -D <FIRMWARE FILE>
wird jetzt mass-erase:force verwendet
dfu-util -R -a 0 -s 0x08000000:mass-erase:force -D <FIRMWARE FILE>
Firmware ohne CAN Support kompiliert
Essentiell beim Kompilieren neuer Klipper Firmware ist natürlich der CAn Support. Dazu das richtige Communication interface auswählen. Hier besonders auf die verwendeten Controller Pins achten. Zur Not im Schaltplan des Boards nachsehen welche Pins genau für CAN reserviert wurden.
Tools finden keine CAN Geräte
Es kommt vor das canbus_query.py wie auch flash_can.py keine CAN Geräte am Bus finden. Hier ist es mitunter sinnvoll mal die Reset Taste der Druckerboards zu drücken und die Suche zu wiederholen. Zudem ist es ratsam vor der Nutzung dieser Tools den Klipper Dienst zu stoppen:
sudo systemctl stop klipper.service
Das stellt sicher das keine Software die Kommunikation mit dem Drucker Board stört. Abschließend den Klipper dienst natürlich wieder starten:
sudo systemctl start klipper.service
CAN Anschluss am PI läuft nicht sauber
Wenn der CAN Bus am PI nicht verfügbar ist, oder nicht korrekt läuft liegt das zu 99% an einer falschen Konfiguration:
/etc/network/interfaces.d/can0
fehlerhaft oder nicht vorhanden
Prüfen kann man das mittels dmesg |grep '251\|can\|spi'
(siehe oben unter Fehlersuche → Hardware)
Falsche txqueuelen in /etc/network/interfaces.d/can0
Es wird in manchen Dokus empfohlen die txqueuelen in der Datei /etc/network/interfaces.d/can0
zu erhöhen (teilweise auf 1024). Das hat bei meinen Tests nicht immer geklappt. Teilweise war das can0 Interface im Raspberry PI dann down und somit der CAN Bus nicht funktional. Standard ist jedenfalls 128.
Die txqueuelen kann auch im Betrieb (bis zum nächsten Reboot) neu gesetzt werden:
sudo ifconfig can0 up txqueuelen 1000
oder alternativ
sudo ip link set txqueuelen 1000 can0
Könnte für Tests manchmal ganz hilfreich sein …
can0 Interface down
Es ist immer eine gute Idee den Status des can0 interfaces zu prüfen. Das geht recht einfach mittels ip a
:
In diesem Fall ist das can0 Interface UP = betriebsbereit. Und hier funktioniert es auch mit 1024 für die txqueuelen.
Sollte das can0 Interface mal auf DOWN stehen kann man versuchen es mittels
sudo ip link set up can0
wiederzubeleben. Möchte man das Interface (wozu auch immer) abstellen geht das mittels
sudo ip link set down can0
Interface auf UP setzen mit bitrate
sudo ip link set can0 up type can bitrate 500000
Bitrate testweise umsetzen
sudo ip link set can0 type can bitrate 125000
Es gibt unter Linux (und Klipper) eine ganze reihe an Tools, um den CAN Bus zu untersuchen.
Klipper - canbus_query.py
Das Skript canbus_query.py listet alle Klipper und CanBoot Geräte am CAN Bus auf. Das ist dann von Nöten wenn die UUIDs für die Klipper Konfig ermittelt werden müssen. Ganz nebenbei zeigt es aber auch recht simple ob die Geräte am Bus funktionell sind.
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Die Ausgabe ist dann folgendermaßen:
Achtung: canbus_query.py ist ein eher “launisches” Tool. Manchmal werden keine Boards gefunden wenngleich sie funktional am Bus hängen.
Beste Vorgehensweise
sudo systemctl stop klipper.service
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
sudo systemctl start klipper.service
Klipper - console.py
ein weiteres Klipper Skript ist console.py. Es ist nur schwer in Dokumentationen zu finden, aber im Grunde sollte es jeder kennen. Es stellt eine Verbindung zum Drucker Board her und zeigt die Kommunikation an. Damit kann man nicht nur testen ob das Board sauber mit der Klipper Firmware arbeitet. Damit lässt sich auch schnell die Firmware Version auslesen. Anmerkung am Rande … Das Tool funktioniert auch mit seriellen Verbindungen.
Beste Vorgehensweise
sudo systemctl stop klipper.service
~/klippy-env/bin/python ~/klipper/klippy/console.py -c can0 <CAN_UUID>
sudo systemctl start klipper.service
CanBoot - flash_can.py
Das nächste interessante Skript stammt vom CanBoot Projekt. Es kann ebenfalls alle CAN Geräte am Bus finden.
Beste Vorgehensweise
sudo systemctl stop klipper.service
~/CanBoot/scripts/flash_can.py -i can0 -q
sudo systemctl start klipper.service
Linux - can-utils
sudo apt-get install can-utils
sudo cansniffer can0
Linux - tcpdump
sudo apt-get install tcpdump
sudo tcpdump -i can0