Fräse

Aller Anfang 06/2022⚓

Auftrag: Beides zusammenbringen; notwendige Kabel und Stecker beschaffen; am besten mit MACH4 in Betrieb nehmen.

Dokumentation:

Schrittmotor
Anschlussbelegung Steckverbinder
3D-Druckteile in SolidEdge 17 Academic Version erstellt

Da sich die passenden M23-Kupplungen nur mit schier endlosen Lieferzeiten liefern lassen (30 Wochen!!) wurden diese kurzerhand durch SubD-Buchsen in ISEL-Belegung ersetzt. Vorläufig gehen die Schalter auf Masse. Die Endschalter öffnen beim Erreichen des Endes! Nur die Z-Achse hat eine Bremse (Elektromagnet). Die SubD-Buchsen befinden sich in einfachen 3D-gedruckten Adaptern.


Motorspule 1A	1
		6	Bremse
Motorspule 1B	2
		7	Endschalter motorfern ES2
Motorspule 2A	3
		8	0 V, gemeinsamer Anschluss der Endschalter
Motorspule 2B	4
		9	Endschalter motornah (Referenz) ES1
Bremse (Isel: +24 V)	5

Wieder zurück 10/2024⚓

Nachdem sich eine Reihe von Maschinenbauern daran abgeeichelt und alles nur verschlimmbessert hat (viele nutzlose 3D-Druckteile) steht das Problem nun wieder vor mir. Die Box ist weg. Es soll zu einer Holzfräse werden. (Doch nicht etwa für Schwibbogen-Zubehör?) Mit einer benutzbaren CNC-Steuerung.

MACH4 oder auch jede andere kostenpflichtige(!) Steueungsoberfläche für Windows ist vom Tisch. Juhu! Es soll nur G-Code fressen können.
Das extra gekaufte Steuerungsgerät CSMIO/IP-S (600 € oder mehr) ist ebenfalls für die Katz! Na endlich! Der Ethernetanschluss macht eh' nur Probleme.
Inzwischen kenne ich mich etwas grbl aus. Beim benachbarten Maschinenbau ist es auf einem Arduino Uno im Einsatz bei einer kleineren Demo-Fräse. Nutzlose Arduinos liegen massenhaft als Fehlkauf herum.

Schlachtplan⚓

✅ Rekapitulation des Aufbaus
✅ Untersuchung der Bremse der Z-Achse
✅ Probeinbetriebnahme mit grbl auf Arduino Uno und putty
✅ Ansteuerungshardware für Bremse und Endstufen-Freigabe (fliegend zur Erprobung)
✅ Ansteuerungshardware für Fräse = Spindelmotor
✅ Software-Anpassung grbl für Endschalter, Bremse, Spindelmotor
✅ Untersuchung 24-V-Lauffähigkeit: Doch 48 V
❌ Software-Anpassung grbl für ATmega32U4 in Ofensteuerbox (diese enthält bereits Endstufen für 230V~ und Bremse, allerdings nur für max. 24 V) → Es bleibt beim Arduino Uno.
Windows-Bedienoberfläche (mit DDE für Parallelprojekt Radarsensor)
Eingabegeräte Handrad, 3D-Joystick (= Joystick mit zusätzlicher Z-Achse)

Weiter⚓

grbl kennenlernen: Das ist eine Open-Spource-Lösung für ATmega328 und passt dass es pufft und kracht geradeso in die 30 freien KByte Flash des Controllers hinein (aber nur mit avr-gcc 5.3.0), wobei der Uno ~~2 KByte für seinen seriellen Catarina-Urlader~~ 0,5 KByte für den unbenannten Urlader wegschnappt. Es ist die Ausgangssoftware für alle 3D-Drucker. grbl verarbeitet G-Code, der vom PC über die serielle Schnittstelle „eingeströmt“ (per XON/XOFF-Protokoll gedrosselt) kommt, kann Geraden- und Kreisinterpolation machen sowie Geradenstücke nahtlos zusammensetzen. Die Ausgabe sind STEP- und DIR-Signale für die gängigen chinesischen (Mikro-)Schrittmotor-Endstufen. Mit beachtlichen 30 kHz Schrittfrequenz. (Meine alte machte nur 8 kHz, auf einem ATmega8, aber dafür auch Mehrfachschritte einer Mikroschritt-Endstufe.) Ist für genau 3 Achsen und 3 Endschalter — sowie 1 PWM-Ausgang zur Geschwindigkeitsvorgabe der Werkzeugspindel. Kommandos zur Handbedienung (Jog) sind ebenfalls implementiert aber dürftig dokumentiert. Einigermaßen verständlicher C-Quelltext. Leider überhaupt kein C++, dadurch unschön strukturiert: Alles im globalen Namensraum.

Die Bremse der Z-Achse macht deutlich hörbare Klickgeräusche und hat folgende gemessene Eigenschaften:

Freilaufdiode (Si, nicht Schottky) eingebaut, daher unbedingt Polarität beachten!
Spulenwiderstand 60 Ω, ergäbe 400 mA Strom bei 24 V und 9,6 W!
Anzug/Lösen: 11 V 180 mA (Spulenanzugstrom), wäre 2 W
Lösen/Anziehen: 0,8 V 13 mA (Spulenhaltestrom) bei 11 mW

Daher ist es am besten, die Bremse mit einer Stromkontrolle zu betreiben, um die Eigenerwärmung der Z-Achse zu minimieren.

Der Freigabeeingang der Schrittmotortreiber ist ein Disable-Eingang! Ohne Beschaltung schluckt dieser 0,5 A bei 24 V (bei maximal eingestelltem Schrittmotor-Spulenstrom). Mit 5 V 30 mA.

Schlachtplan:

✅ GRBL-Software verkleinern: ausreichend erledigt
✅ Alle sechs Endschalter auf PC0..PC5: erledigt. Entprellung in Hardware: erledigt, R/C-Glied 5,6 kΩ / 15 nF Richtungsabhängige Endschalter-Abfrage in Software: Erledigt. Referenzfahrt $H: Erledigt
❌ Timer1 freimachen für Phasenanschnitt: Geht nicht! grbl-Stepper erfordert (anscheinend) 16 Bit. Stattdessen wurde Timer0 frei gemacht: Erledigt. Umstellung Timer1: Statt CTC nun fortlaufende Compare-Ereignisse, um diesen auch als Echtzeituhr nutzen zu können. Beginn des Software-Umbaus auf Idle-Workhorse-Modell.
✅ Endstufen-Abschaltausgang auf PB4, um Input Capture frei zu halten. Für Phasenanschnitt. Erledigt. Wurde rückgebaut, Input Capture in Software. Pullup-Widerstand 240 Ω hält Endstufen abgeschaltet während Reset. Zu testen!
✅ PWM-Ausgang für Bremse bereitstellen: OC2A = PB3. Entfällt für Spindel. Schaltung mit Optokoppler und Bipolartransistor. Erledigt. PWM-Frequenz ca. 240 Hz. Kein hörbares Geräusch. Minimum-Tastverhältnis viel höher als berechnet: Transistorschalt- oder (wahrscheinlicher) Eisenverluste.
✅ Maschine ausmessen und ausreizen: erledigt, Arbeitsvolumen nur 500 × 500 × 200 mm³, fährt alle 3 Achsen mit 5 m/min = 83 mm/s.
✅ Not-Aus an Reset-Eingang: erledigt
XON/XOFF-Streaming und OOB-Datenbehandlung auf ATmega16U2: Erledigt
Alternatives WebUSB-Interface mit angepassten USB-Endpoints: Erledigt, ASCII/Binär-Konvertierung für gcode auf ATmega16U2: entfällt
✅ Phasenanschnitt-Schaltung: Fertig Schaltplan faktisch gleich mit jenem oben rechts. Bestückt mit russischen Triacs ТСTS106-10, Optotriacs MOC3073, Nulldurchgangsdetektor-Optokoppler PC817.
Phasenanschnitt- oder Schwingungspaketsteuerung in Software: Im Test
✅ Gehäuse: Vorhandes, von Werkstatt gefertigtes Plexiglasteil aufgegriffen und vollendet. Vorhandene 3D-Druckteile verwendet. Neue 3D-Druckteile:

Steckdose vorn (weiß)
Wannenstecker-Kapsel (schwarz)
Gehäuse für Phasenanschnittsteuerung
Steckdose innen (schwarz)
Unnötig: ATmega16U2 und ATmega32U4-Urlader so ändern dass die Baudrate fest 1 MBaud ist: Einfach(?) alle Zugriffe auf UBRR(H|L) wegpatchen.
✅ Triac-Steuerung geht:
- M3 S1000 = Spindel ein
- M5 = Spindel aus
- M10 oder M7 = Staubsauger (Steckdose vorn) ein
- M11 oder M9 = Staubsauger aus
Bei fehlendem oder fehlerhaftem Nulldurchgangssignal wird einfach der Optotriac voll (digital) durchgesteuert.

Hoppla!

Der ATmega16U2 hat sehr wenige Endpoints.
Der CDC-Interrupt-Endpoint sendet nur dann Daten, wenn sich an den Modemstatusleitungen RI, DCD oder DSR etwas ändert oder Break detektiert wird. * Das ist für einfache PIC-Programmiergeräte wichtig.
CDC funktioniert auch ohne da jemals Daten zu senden.
CDC funktioniert auch wenn man diesen Endpoint auf einen nicht vorhandenen legt, bspw. EP7.

… unter Windows 10, aber nicht unter Windows 7! Verdammt! Das macht sich bösartigerweise erst beim Lesen von Daten bemerkbar, da kommt nie eine Antwort zurück, und avrdude versagt.

Zumal lässt Windows 7 nicht die Kombination von CDC mit irgendeiner anderen USB-Klasse zu, es geht einfach nicht.

Die Moral von der unendlichen Geschichte: CDC so lassen wie's ist! Und die verfügbaren 176 Byte Endpoint-RAM so aufteilen:

EP0 = Control Out/In (32 Byte)
EP2 = Interrupt In (16 Byte)
EP3 = Bulk In (32 Byte doppelt gepuffert)
EP4 = Bulk Out (32 Byte doppelt gepuffert)

Das Problem mit CDC allein bleibt allerdings, dass bei GCode-Streaming keine Urgent-Daten an der Warteschlange „vorbeifahren“ können. Für die Windows-Funktion TrannmitCommChar() hat man bei der Definition der CDC-Klasse „vergessen“ einen entsprechenden Control-Transfer dafür festzulegen. Dadurch ist während des Streamings das Abbrechen oder ein Override nur mit deutlichem Zeitverzug möglich.

Die Lösung ist das Umschalten zwischen 2 USB-Deskriptorsätzen mit „Magic Strings“ #1*␊ zu WebSerial bzw. #2*␊ zu WebUSB — jeweils in einem 4-Byte-USB-Block. Ein Update von grbl-isel ist nur in der Stellung WebSerial möglich. Und ein Betrieb am Smartphone nur in der Stellung WebUSB. Zudem springt #0*␊ zum ubaboot-Urlader und erlaubt ein Firmware-Update ohne Reset-Aktivierung.

grbl und Synchronisation: Ein Armutszeugnis!⚓

Gegrübelt habe ich einige Zeit, wie beim aktuellen Firmware-Stand das Streaming von g-code vonstatten gehen soll, ohne Pufferüberläufe. Ich bin davon ausgegangen, dass man der Fräse einfach mit

ZeilennummernUmbruch

copy /b gcodefile.gcode com9

die abzuarbeitenden Schritte aus dem CAM-Postprozessor überträgt und sich eine wie-auch-immer-geartete Synchronisationslogik um die Drosselung der Übertragung kümmert, damit keine Pufferüberläufe auftreten.

Da gcode 7-Bit-ASCII ist, bietet sich zur Synchronisation das XON/XOFF-Protokoll an.

Unter Windows lässt sich XON/XOFF zur Synchronisation zwar aktivieren, die Wirkung verpufft jedoch durch den relativ großen Puffer des USB-Seriell-Konverters. Das heißt, ehe XOFF beim Empfänger ankommt müssen sämtliche noch gepufferten Sendedaten raus, oder es wird erst nach einer Zeitüberschreitung gesendet, da der Konverter vermeiden will, lauter 1-Byte-Pakete zu senden. Dabei bietet USB selbst einen Synchronisierungsmechanismus an: Bei USB drohen schlicht keine Pufferüberläufe: Kann ein USB-Device keine Daten entgegennehmen, antwortet es auf das OUT-Paket mit NAK. Und kann der USB-Host keine Daten entgegennehmen, sendet er keine IN-Tokens.

Gängige, zumeist in Python geschriebene „G-Code-Sender“ gehen den folgenden oder ähnlichen Umweg:

Senden den G-Code zeilenweise
Fügen Abfragebefehle für die Maschinenposition ein
Zählen die gemeldeten Abfragen, um den Füllstand der Warteschlangen abzuschätzen
Drosseln das Aussenden weiterer G-Code-Zeilen, einen begrenzten Vorlauf einhaltend

Das hat zur Folge, dass die Maschine, je nach USB-Seriell-Konverter, gelegentlich auf Geschwindigkeit 0 herunterfährt oder hängen bleibt. Ein Irrweg!

Die richtige Lösung ist demnach XON/XOFF auf dem USB-Seriell-Konverter! Leider sieht der CDC-Standard (IMHO) keine Lösung dafür vor. Daher fallen Arduino-Uno-Nachbauten aus China mit generischem USB-Seriell-Konverter-Chip heraus. Hinreichend originale Unos mit ATmega16U2 als USB-Seriell-Konverter lassen sich jedoch umprogrammieren, um XON/XOFF permanent zu aktivieren. Eine ausführliche Erläuterung ist auf Github, lässt jedoch außer Acht, den ATmega16U2 umzuprogrammieren. FTDI FT232 wiederum basiert nicht auf CDC sondern verwendet einen eigenen Treiber, der offenbar XON/XOFF korrekt umsetzt.

ATmega16U2-Firmware ohne LUFA!!! Drei Geräte: HID, WebUSB, CDC. Mit LandingPage. Zurzeit nur CDC und WebUSB funktionstüchtig. Eine LandingPage gibt's nur bei WebUSB. Die String-Deskriptoren sind im EEPROM und können später mal mit SetDescriptor(0,7,wValue,-,wLength) vom Anwender angepasst werden. Die Firmware verwendet eine richtungsweisende Von-Neumannisierung von RAM, EEPROM und Flash.

Für Nachnutzer In den Arduino Uno ist 3× Software zu „brennen“:

512 Byte Urlader und Fuses für den ATmega16U2 via ISP-Anschluss und geeignetem ISP-Programmiergerät: ubaboot

# Im Makefile Programmiergerät und ggf. Chiptyp (16u2, 8u2, 90usb16, 90usb8) einstellen.
c:\Users\Dein Name\avr\uba>make program

Derzeit namenloser USB-Seriell-Konverter für den ATmega16U2 via USB und Reset via ISP-Anschluss (Pin 5 und Pin 6 kurz verbinden): Firmware. Dieser beinhaltet das XON/XOFF-Protokoll für Baudraten > 115200 (so fixiert erforderlich damit avrdude noch funktioniert) sowie WebUSB. Ändern Sie ggf. die String-Deskriptoren auf Ihren Namen („Verkäufer“) und Ihre Fräse (Produkt), denn diese werden (browserabhänging) von Ihrem Browser angezeigt! Es wäre unsinnig, hier „Arduino“ anzeigen zu lassen.
```
# Nichts einstellen aber uba.exe muss im Pfad liegen.
c:\Users\Dein Name\avr\grbl-isel\m16u2>make flash
```

Mein modifiziertes grbl-isel via USB, ohne weitere Vorkehrungen, also jederzeit: Firmware

# Im Makefile COM-Port einstellen. Chiptyp fest ATmega328P
c:\Users\Dein Name\avr\grbl-isel>make flash

Hat man einen werksfrischen ATmega328P, muss man diesen vorher mit OptiBoot betanken:

512 Byte Urlader und Fuses für den ATmega328 via ISP-Anschluss und geeignetem ISP-Programmiergerät: Hex-Datei ohne Fuses.

# Prüfen ob OptiBoot bereits drauf ist:
c:\Users\Dein Name\avr>avrdude -c avrisp2 -p m328p -qq -U hfuse:r:-:h
0xde	# Richtig. Falsch wäre bspw. 0xd9 als Werksvorgabe.
# Urlader ersetzen, ohne Makefile:
avrdude -c avrisp2 -p m328p -U flash:w:optiboot_atmega328.hex -U lfuse:w:0xff:m -U hfuse:w:0xde:m -U efuse:w:0xfd:m -U lock:w:0xef:m

Gegenüber dem originalen grbl ist die Verdrahtung und ggf. die Maschine zu ändern!

Es werden sechs Öffner als Endschalter benötigt und an A0..A5 angeschlossen. Die Endschalter fungieren dabei als Achsen-Präsenzdetektor: Einer von beiden muss geschlossen sein. Referenzfahrten sind faktisch unnötig, und die Achsen werden niemals an ihren Endanschlägen gequält.
Der 230-V-Fräsmotor (Universalmotor) muss über eine Phasenanschnittsteuerung mit Nulldurchgangsdetektor betrieben werden, falls vorhanden. Dazu ändert sich die Funktion der Anschlüsse D9..D12. D13 (LED) ist noch frei zum Debuggen.
An D11 (PWM-Ausgang) ist die Bremse via Darlington-Transistorstufe anzuschließen, falls vorhanden.

Diese Software ist für Arduino Unos mit einem anderen USB-Seriell-Konverterchip als dem ATmega16U2 nicht geeignet! Als einfaches Indiz schaue man auf den Quarz: Der richtige Chip braucht 16 MHz, die ungeeigneten Chips brauchen 12 MHz.

Das Problem mit dem avrdude löste sich durch Anwendung des altmodischen avr-size -C: Der ATmega16U2 hat ja nur ein halbes Kilobyte RAM und war schlicht zu voll! Und modernere avr-size bemerken das nicht, weil sie keine Füllgradausgabe haben: Benutzerunfreundlichkeit von GNU-Software at its best!

Das XON/XOFF-Protokoll funktioniert nun endlich korrekt, und das sogar mit 2 MBaud. Entscheidend war ① die Empfangs-ISR mit Tail-Chaining auszustatten und ② das XOFF nicht via Interrupt sondern direkt aus der Empfangs-ISR zu senden.

Bei dieser Gelegenheit habe ich den Quarz des ATmega16U2 samt RC-Beschaltung ausgebaut und lasse den Mikrocontroller fortan vom ATmega328P mit einem kurzen Verbindungsdraht von ATmega328P XTAL2 nach ATmega16U2 XTAL1 takten. Dazu müssen oder zumindest sollten die Fuses der beiden Controller folgendermaßen geändert werden:

avrdude -c avrisp2 -p m328p -U lfuse:w:0xf7:m	# Full swing crystal oscillator
avrdude -c avrisp2 -p m16u2 -U lfuse:w:0xe0:m	# External clock

Ich habe die Durchsteck-Quarze für mein Projekt avrpp benötigt. Richtiger ist die Taktspeisung in die andere Richtung. So bekommt man 1 weiteres Pin des ATmega328P frei. Mit dem SMD-Resonator CS T CE 16M0 V 5 3 konnte ich nichts anfangen. (USB Full-Speed fordert ≤2,5 ‰ Toleranz, deshalb wohl der Extra-Quarz!) Erstaunlich: Vermeintliche „Quarze“ mit 3 Anschlüssen sind auch 2025 stets Keramikresonatoren! Niemand scheint Quarze mit integrierten Ballastkondensatoren zu verkaufen.

Bedienoberfläche⚓

Herrjemine, bevor ich irgendwas brauchbares in die Finger bekomme, lieber gleich als Offline-Webanwendung programmieren.

Äpp

Die Webanwendung unterstützt sowohl WebSerial (nur auf PCs) als auch WebUSB (auf Smartphones die einzige Option). Sie funktioniert mit allen modernen Browsern außer Firefox!

Verbleibende Bugs⚓

Zurzeit hängt es noch an folgenden Punkten:

Der ATmega328 bleibt beim Jogging manchmal hängen. Dieser Fehler ist auch beim Original-Binärimage vorhanden! Leider ist der eigenständige Betrieb der Achsen nicht vorgesehen, was Jogging eher problematisch macht.
Während des GCode-Streamings ist das Pausieren, Abbrechen oder Override nur mit erheblichem Zeitverzug möglich. Ursache ist ein auf XON/XOFF setzendes Streaming (was einwandfrei funktioniert) und die fehlende Möglichkeit mit CDC, Urgent-Daten an den vollen Warteschlangen vorbeizuschleusen. Wie auf einer gesonderten Überholspur. Mit WebUSB funktioniert das, das beißt sich jedoch mit avrdude.

Siehe auch: