Bestand: Portalmaschine, ca. 500 × 500 × 200, mit Schrittmotoren
und Endschaltern, von ISEL, ohne Stecker.
„Flachbetteinheit E18?“ —
Ein Link dazu.
Vorhandene Hardware für Schrittmotorsteuerung inklusive Box.
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
Motorspule 1B
Motorspule 2A
Motorspule 2B
Bremse (Isel: +24 V)
Bremse
Endschalter motorfern ES2
0 V, gemeinsamer Anschluss der Endschalter
Endschalter motornah (Referenz) ES1
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 etwasgrbl 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-gcc5.3.0),
wobei der Uno 2 KByte für seinen seriellen Catarina-Urlader0,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 G28: TODO
❌ 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: TODO
Alternatives WebUSB-Interface mit angepassten USB-Endpoints
und ASCII/Binär-Konvertierung für gcode auf ATmega16U2: TODO
✅ Phasenanschnitt-Schaltung: Fertig Schaltplan faktisch gleich mit
jenem oben rechts.
Bestückt mit russischen Triacs ТС106-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:
Nice to have: 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.
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
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.
ATmega16U4-Firmwareohne LUFA!!!
Drei Geräte: HID, WebUSB, CDC. Mit LandingPage.
Zurzeit nur CDC. Also ohne LandingPage. Für HID fehlt eh' noch ein Endpoint.
Das Problem mit dem avrdude löste sich durch Anwendung des altmodischen
avr-size -C: Der ATmega16U4 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 (1) die Empfangs-ISR mit Tail-Chaining auszustatten und
(2) das XOFF nicht via Interrupt sondern direkt aus der Empfangs-ISR zu senden.
Bedienoberfläche
Herrjemine, bevor ich irgendwas brauchbares in die Finger bekomme,
lieber gleich als Webanwendung programmieren.
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.
Äpp