ERCF Speedboard

ERCF Speedboard

Warum das alles?

Das ERCF Speedboard ist meine erste selbstgebaute Platine für meinen 3D-Drucker.

Motiviert hat mich das ERCF Easy Board ( https://github.com/Tircown/ERCF-easy-brd ). Im 3D Drucker selbst (ein Voron 2.4) habe ich als Mainboard das Fysetc Spider v1.1, welches ich vor kurzem von Klipper auf RepRap Firmware umgestellt habe. Es gab dafür keinen besonderen Grund, ich wollte es einfach mal ausprobieren. Allerdings habe ich dadurch die Möglichkeit verloren, mit dem ERCF Easy Brd zu kommunizieren. Natürlich ist das schade, aber auch eine neue Herausforderung.

All das hat dazu geführt, das ERCF Speedboard zu entwickeln.

Unterschiede zum Easy Board

  • Ein STM32F407 als Prozessor
  • MicroSD Kartenslot
  • CAN-Anschluss
  • UART Anschluss
  • ESP32 für WiFi

Bei der Größe habe ich versucht, die gleichen Maße der Platine einzuhalten… und es hat geklappt! Nur eines der drei M3 Löcher fehlt leider, aber das stört mich nicht.

Verbesserungspotential

Es gibt aber auch ein paar Verbesserungen, die man machen könnte. Zum Beispiel einen Buck-Konverter für die Spannungswandlung von 24V auf 5V. Momentan verwende ich dafür einen L7805 LDO. Dieser nimmt wenig Platz ein, wird aber sehr heiß.

Prototyp

Das Ganze habe ich natürlich schon ausprobiert und es funktioniert soweit. RepRapFirmware läuft ohne große Probleme auf dem STM32 Fork von Teamgloomy ( https://teamgloomy.github.io/ ). Hier habe ich mein Board im Code ergänzt, kompiliert und es funktioniert.

Das Board selbst habe ich bei JLCPCB herstellen lassen. Die finde ich super, weil man als kleiner Hobbybastler das Ganze auch gleich zu erschwinglichen Preisen löten lassen kann. Für meine beiden Prototypen habe ich mit allem drum und dran ca. 75€ bezahlt.

Prototyp

Verbindung zum 3D-Drucker

Leider unterstützt die Firmware den normalen CAN-Anschluss des STM32F407 nicht von Haus aus. Das Problem ist, dass der normale CAN nur bis zu 8 Byte Daten unterstützt. Daher verwendet die RepRapFirmware normalerweise CAN-FD, welches bis zu 64 Byte unterstützt, plus ein paar andere Features. Hier war mein erster Versuch, eine eigene Klasse für die CAN-Kommunikation zu schreiben, die die Daten dynamisch auf mehrere Pakete verteilen und am Ende wieder zusammensetzen kann. Nach ein paar Versuchen hat es funktioniert und ich konnte meine beiden Prototypen der Platine miteinander reden und sich gegenseitig steuern lassen. Die Performance war aber erwartungsgemäß nicht die beste. Ein zweiter Versuch war dann, das Ganze über UART zu machen. Das hat zu meiner Überraschung sogar besser funktioniert. Ist dann natürlich nicht für sehr lange Kabelstrecken geeignet, aber: was solls. Das Ganze habe ich dann in meinen Fork für das Fysetc Spider Mainboard portiert und so dann versucht die beiden Boards miteinander reden zu lassen, leider bisher ohne Erfolg. Das Spider Board stürzt mit der Firmware Version direkt ab, sobald CAN aktiviert wird. Meine Vermutung ist momentan, dass durch die zusätzlichen Tasks, die dann laufen, der RAM voll läuft. Hier ist nur ein STM32F446 verbaut, der statt 192KB nur 128KB RAM hat.