Testing on Schallberts Blog

CNC Tuning #3

Schallbert — Sat, 04 May 2024 00:00:00 +0000

Dies ist der letzte Teil meiner Reihe über die Optimierung der Fertigungszeit auf CNC-Fräsmaschinen. Er konzentriert sich auf den Pfadinterpreter der CNC-Steuersoftware.

Der Pfadinterpreter der Steuersoftware ist dafür zuständig, die Anweisungen aus dem G-Code zu lesen und in Maschinenbewegungen zu übersetzen. Soll beispielsweise G01 X100 Y200 Z-2.0 F2000 S18000 ausgeführt werden, so muss der Pfadinterpreter die akuelle Position der Maschine kennen und einen Fräsvektor erzeugen, der zur gewünschten Position mit den vorgegebenen Parametern zeigt.

Hierbei muss der Interpreter die kinematischen Parameter der Maschine berücksichtigen: Mit welcher Rampe auf Zielgeschwindigkeit F1000 beschleunigt wird ob der gewünschte Vorschub überhaupt zulässig ist, und ab welchem Punkt wieder gebremst werden muss um den Zielpunkt exakt zu erreichen. Die so gewonnenen Daten werden schließlich in eine Schrittfolge für die drei Schrittmotoren übersetzt, in einen Pufferspeicher geladen und schließlich in Echtzeit an die Motorendstufen ausgegeben.

Schritt 3: Optimierung des Pfadinterpreters

Viele Steuersoftware-Anbieter haben integrierte Fräspfadfilter programmiert, welche mittels Kommando G64 oder per Menü zu konfigurieren sind. Ich verlinke hier mal ein paar Beispiele verschiedener Hersteller, wo für spezifische Details nachgelesen werden kann:

Die Kunst ist nun, eine Konfiguration passend zum Fräsjob und der Maschinenkinematik zu finden. Es geht hier immer um einen Kompromiss zwischen Fertigungsgeschwindigkeit und Bahntoleranz. Soll also mit hohem Vorschub gefahren werden, werden eigentlich spitze Kanten verrundet, verbundene Liniensegmente in einem Toleranzband angefahren oder Pfade so vereinfacht, dass außerhalb der von der Maschine erreichbaren Beschleunigung befindliche Pfadpunkte nicht angefahren werden.

Grundlagen: Was ist “Look Ahead Feed”?

Hiermit ist gemeint, dass der Pfadinterpreter der Steuersoftware sich während des Ausführens einer Fräsoperation - z.B. G01 X* Y* (lineare Bewegung Punkt zu Punkt) - bereits die nächste(n) Operation(en) anschaut und herausfindet, ob und wie stark zwischen den Operationen abgebremst und wieder beschleunigt werden muss bzw. direkt durchgefahren werden kann. Die Physik dahinter erkläre ich im Artikel zum CNC-Setup.

Hierdurch kann teils massiv Zeit gespart werden, der Fräsvorgang wird flüssiger und die Maschine erfährt geringere Belastungen. Zusätzlich zur Vermeidung von Beschleunigungs- und Bremsvorgängen kann mittels Parameter G64 eingestellt werden, ob und wie Fräspfadfilter die geplante Trajektorie verändern dürfen, um weiter auf höhere Bahngeschwindigkeiten zu optimieren.

Ideal im Gravurbetrieb

Im Gravurbetrieb kann man sich solche Optionen hervorragend zu Nutze machen: Höhere Toleranzen sind hier meist OK, und leicht verrundete Kanten oft akzeptabel. Bei 3D-Gravuren dauert das Fräsen durch die vielen Pfade lang, und hier ist besonders viel Zeit herauszuholen.

Da ich Eding CNC benutze, kann ich nur für Parameter dieser Steuerung Tipps geben. Nun aber ab ins Detail zur Erklärung der Einstellungen!

Fräspfadtoleranz `G64 P*`

Dieser Parameter gibt der Steuersoftware die allgemeine Toleranz der Pfadgenauigkeit vor.

Ich habe meine Maschine so eingestellt, dass sie im Gravurbetrieb Abweichungen vom vorgegebenen Fräspfad von bis zu LAF blending tolerance = 0.3mm zulässt. Alternativ kann die Konfiguration per Kommando G64 P0.3 erfolgen. Im Bild habe ich skizziert, wie sich eine solche Einstellung in der Praxis auswirken kann: Der Fräspfad (weiß) besteht aus G01-Liniensegmenten. Die Toleranz ist mit Hilfe von Kreisen eingezeichnet. Der Pfadinterpreter der Steuersoftware kann nun eigenständig Kreissegmente so definieren, dass innerhalb der Toleranz eine möglichst hohe Bahngeschwindigkeit erreicht wird.

Die so ermittelte Bahn (türkis) ähnelt einer Spline-Kurve. Zu beachten ist hier, dass sämtliche Linien von dieser Einstellung betroffen sein können - auch solche, die strenge Toleranzanforderungen haben. Ist dies nicht gewünscht, so sollte hier ein kleinerer Wert verwendet werden.

Pfadverrundung `G64 R*`

Treffen zwei Liniensegmente im Winkel von bis zu LAF full speed blending angle threshold = 12° aufeinander, wird die Maschine ohne abzubremsen versuchen, dem Winkel genau zu folgen. Bei größeren Winkeln wird mit reduzierter Geschwindigkeit mit per G64 P* definierter Toleranz gefahren. Diese Konfiguration wird mit G64 R12 programmiert.

Die Werte hier sind mit großer Vorsicht einzustellen, weil sie zu Beschleunigungsspitzen auf der Maschine führen. Große Werte können Schrittverluste und höheren Verschleiß der CNC-Fräse verursachen. Dafür werden Bahngeschwindigkeit und Genauigkeit optimal gehalten.

Pfadverrundung bei reduziertem Vorschub `G64 S* D*`

Diese Konfiguration gibt der Steuersoftware die Möglichkeit, Kanten bis zum eingestellten Toleranzwert zu verrunden: LAF reduced speed path smoothing delta = 0.001mm. In Kombination mit der Verrundung muss der Winkel eingestellt werden, bis zu dem diese Verrundung durchgeführt werden soll: LAF reduced speed path smoothing angle threshold = 0°.

Programmiert wird diese Funktion am Besten in Kombination mit der Pfadverrundung bei vollem Vorschub als G64 R* S* D*. Der Vorteil hierbei ist, dass Liniensegmenten wie im Bild gezeigt sehr genau gefolgt wird, und die Kanten gleichzeitig aber fein justierbar abgerundet werden. Bis zum über R definierten Winkel wird sogar mit vollem Vorschub dem Pfad exakt gefolgt.

Werden bei S sehr große Winkel eingestellt, so findet entsprechend D auch eine stärkere Verrundung statt. Überschreitet der im Fräsprogramm vorgegebene Winkel jedoch den konfigurierten Wert, so fällt der Algorithmus auf die für P hinterlegten Werte bzw. in den exakten Pfadfolgemodus zurück.

Pfadvereinfachung `G64 Q*`

Enthält die G-Code Datei zahlreiche, sehr kurze Liniensegmente (wie sie oft bei der Erstellung von Pfaden aus Bilddateien entstehen), kann diese Funktion durch Vereinfachen der Fräspfade Abhilfe schaffen. Dabei gibt die Zahl hinter dem Parameter die Toleranz an, bis zu der Liniensegmente zu einer Linie verschmolzen werden.

Diese Einstellung entlastet den Pufferspeicher der Maschine und erhöht gleichzeitig die mittlere Bahngeschwindigkeit. Für den Gravurbetrieb halte ich diese Einstellung insbesondere für interessant, wenn mit “verrauschten” Daten gearbeitet wird und im CAD nicht die Möglichkeit bestand, die Anzahl der Pfade zu reduzieren.

Beschleunigungsfilter `G64 F*`

Mittels diesen Parameters können die durch Look Ahead Feed möglicherweise erzeugten Beschleunigungsspitzen abgemildert werden. Der minimal einzustellende Wert ergibt sich durch den Quotienten aus gewähltem Vorschub für die Operation und maximaler Geschwindigkeit der Maschine.

Beispiel: Fmin = Foperate / Fg00, bei Fg00 = 12000mm/min und Foperate = 5000mmm/min ist Fmin = 0.42

Also wird bei Vorschub von 5000mm/min die maximal mögliche Beschleunigung der Maschine abgerufen und Kurvenradien so eingestellt, dass sie bei konstanter Bahngeschwindigkeit gefahren werden. Alle Werte größer gleich Fmin = 1 sind inherent sicher, unabhängig vom gewählten Vorschub.

Dieser Parameter wurde entwickelt für die Bearbeitung von elastischen Materialien wie Gummi oder Kork, wo eine konstante Vorschubgeschwindigkeit extrem wichtig und die Bahntreue eher zweitrangig ist. Der Parameter wird in Kombination mit G64 R* verwendet. Die folgende Programmierung für das obige Beispiel würde die volle Kapazität der Maschine abrufen: G64 R120 F0.42, wobei mit F5000 gefahren wird, F12000 der Maximalvorschub der Maschine ist und spitze Winkel bis 120° ohne abzubremsen gefahren werden sollen.

Wende ich diese Werte auf meine Maschine an, entsteht das nebenstehende Bild. Hier soll ein Rechteck mit 25 x 100mm Kantenlänge gefertigt werden. Weiß ist wieder die Zieltrajektorie dargestellt. Die türkise Kurve zeigt die durch die Programmierung des Beschleunigungsfilters gefahrene Kurve mit konstanter Bahngeschwindigkeit. Je geringer der Vorschub im Verhältnis zum Maximalvorschub und je höher die Beschleunigung der Maschine eingestellt ist, desto kleiner wird der notwendige Radius.

Für den Gravurbetrieb und das Fräsen fester Materialien wird dieser Parameter meiner Erfahrung nach jedoch nicht verwendet.

Meine Konfiguration für die Hobbyline 4530

Ich habe im Gravurbetrieb viel mit den verschiedenen LAF-Parametern herumgespielt und eine Menge Rohlinge als Lehrgeld “verbraucht”. Die kürzesten Fertigunszeiten erhielt ich bei vorheriger Optimierung der kinematischen Parameter mit folgender Konfiguration:

G64 Q0.3 R12 D0.3 S120

Damit sage ich der Maschine folgendes:

“Verwende den Pfadvorschau-Algorithmus und versuche, kurze Liniensegmente unter 0.3mm Länge zu verschmelzen. Versuche, den Vorschub bei einem Winkel zweier Streckenabschnitte von bis zu 12° nicht herunterzuregeln. Bei größeren Winkeln bis 120° kann statt einem exakten Nachfahren mit bis zu r=0.3mm verrundet werden. Bei noch größeren Winkeln ist dem vorgegebenen Pfad zu folgen und, falls erforderlich, bis zum Stillstand abzubremsen.”

Fazit

Da mich die Parameteroptimierung für den Gravurbetrieb ziemlich weit vom Parametersatz für den normalen Fräsbetrieb weggebracht haben, habe ich mein Steuerprogramm einfach ein zweites Mal installiert.

Dort konnte ich dann Geschwindigkeit, Achsbeschleunigung und Pfadparametrierung getrennt festlegen. Nun habe ich das Beste beider Welten auf einer Maschine zur Verfügung:

Einen sehr genauen, weich operierenden Fräsbetrieb mit folgenden Parametern:

Fmax XY 12000mm/min
Fmax Z 4800mm/min
Amax X 1000mm/s²
Amax Y 1000mm/s²
Amax Z 1000mm/s²
G64 P0.1 R6

Und über die andere Verknüpfung einen überaus flinken Gravurbetrieb:

Fmax XY 12000mm/min
Fmax Z 4800mm/min
Amax X 4000mm/s²
Amax Y 3200mm/s²
Amax Z 1600mm/s²
G64 Q0.3 R12 D0.3 S120

Und wo ist der Beweis?

Das eingebettete Video zeigt dasselbe Gravurprojekt mit vier verschiedenen Optimierungsstufen:

oben links: Herstellerkonfiguration der Maschine, Standard-Fräspfade aus CAD/CAM
oben rechts: Geschwindigkeit und Beschleunigung auf Fräsbetrieb erhöht
unten links: Look Ahead feed eingeschaltet G64 P0.3, Fräspfade im CAM optimiert
unten rechts: Optimiert für Gravurbetrieb wie oben beschrieben, CAM Flyover auf 2mm reduziert und Leerfahrten minimiert

CNC-Tuning für den Gravurbetrieb

CNC Tuning #2

Schallbert — Sat, 27 Apr 2024 00:00:00 +0000

Dies ist der zweite Teil meiner Reihe über die Optimierung der Fertigungszeit auf CNC-Fräsmaschinen. Er konzentriert sich auf die kinematischen Maschinenparameter für den Gravurbetrieb.

Schritt 2: Tuning der kinematischen Parameter der CNC

Die theoretischen Grundlagen habe ich im Artikel zur CNC-Steuerungskonfiguration ausführlich erläutert. Meine Probleme damit und zugehörige Lösungen habe ich nach vielen Tests und Rücksprache mit dem Hersteller im Fazit zu einem Jahr CNC-Betrieb festgehalten. Die folgenden Abschnitte wenden die obigen Erkenntnisse auf eine Demonstrationsmaschine an, die ich mir habe leihen können.

Verfahrgeschwindigkeit im Eilgang

Für die Demomaschine konnte ich die Geschwindigkeit im Eilgang von den vorgeschlagenen Fxy = 4m/min und Fz = 2.4m/min auf Fxy = 12m/min und Fz = 4.8m/min erhöhen. Setze ich alle drei Achsen gleichzeitig in Bewegung, erhalte ich durch Steigung der Kugelgewindespindeln und Mikroschrittkonfiguration (8 pro Vollschritt) der Motoren eine kombinierte Schrittfrequenz von 96kHz, was unter der maximalen Schrittfrequenz von 125kHz der Steuerung liegt.

Beschleunigung im Eilgang

Die Herstellerangaben empfehlen hier aXY = 300mm/s² und aZ = 200mm/s².

Ich habe die Beschleunigung in mehreren Schritten hochgesetzt und bin in einer ersten Runde bei aXY = 1000mm/s² und aZ = 400mm/s² gelandet. Diese Werte sind für diese kleine und leichte Maschine mit nur 30x45x14cm Verfahrweg nach meiner Erfahrung für den Normalbetrieb ohne Weiteres möglich. Sie erhöhen die Fertigungsgeschwindigkeit stark, denn jeder Richtungswechsel, auch die im Materialeingriff bei G01, G02, G03, werden nun um Faktor 3 bzw. 2.5 schneller ausgeführt.

So habe ich die Maschine oft betrieben und auch auf der Messe bin ich mit diesen Werten stabil und sicher gefahren. Das folgende Video zeigt die Fräse im Gravurbetrieb mit den angegebenen Werten.

CNC-Tuning: Vorschau

Danach jedoch wollte ich wissen, wie weit ich es treiben kann. Getreu dem vorher beschriebenen Motto

“Wer die Grenze nicht überschreitet, weiß nicht, wo sie liegt”

habe ich erst einmal geprüft, wie sich massive Schrittverluste bei dieser Maschine anhören. Also habe ich eine Achse mit einem Holzbalken blockiert und bin vorsichtig dagegen gefahren:

Your browser does not support the video tag.

Massive step loss soundcheck

Das deutlich vernehmbare Rattern entsteht wenn der Motorhochlauf zwar klappt, in Richtung Zielgeschwindigkeit aber diverse Vollschritte verloren gehen. Wird der Rotor bereits bei Anlauf des Motors “verloren”, so fiept der Motor nur noch, ohne die Achse überhaupt in Bewegung zu setzen. Verliert der Motor nur wenige Schritte, befindet sich aber auf Zielgeschwindigkeit, so gibt es einen rauen und unter Umständen kratzenden Ton.

Ich habe für das Experiment die X-Achse gewählt, weil sie sich am einfachsten blockieren lässt. Des Weiteren habe ich sie in X+-Richtung blockiert. Begründung: diese Maschine besitzt kein professionelles Festlager zur Aufnahme von Druck- und Zugkräften der Kugelumlaufspindel. Stattdessen werden Druckkräfte in Richtung Schrittmotor sicher von einem auf der Spindel montierten Flansch abgefangen, der gegen in der Portalwange befindliche Kugellager drückt.

Zugkräfte hingegen werden hauptsächlich von den Motorlagern aufgenommen - da wollte ich kein Risiko eingehen. Nun ist also das Geräusch bei plötzlichem und ruckartigen Schrittverlust bekannt - das Übertakten kann beginnen!

Meine Vorgehensweise:

Die Beschleunigung einer Achse der Maschine verdoppeln
Die betreffende Achse umher joggen, dabei auf merkwürdige Geräusche achten und die Achsbewegung beobachten
Vorige Schritte wiederholen, bis massive Schrittverluste auftreten
Beschleunigung auf den Mittelwert zwischen “klappt” und “klappt nicht” zurückfahren
Den vorigen Schritt solange wiederholen, bis die Maschine sauber fährt
Alle Schritte auch für die anderen Achsen durchführen

So bin ich schließlich bei für eine solche Hobbymaschine unglaublichen aXY = 4000mm/s², aZ = 1600mm/s² gelandet. Dies liegt nun eine Größenordnung über den empfohlenen Werten.

Die kleine Fräse scheint auch hier stabil zu laufen und die gefertigten Gravuren sehen gut aus. Allerdings konnte ich mir nicht vorstellen, dass ich Schrittmotoren, Treiberstufen und Netzteil noch innerhalb ihrer Spezifikation betreibe. Daher habe ich gemessen.

Elektrische Messwerte

Das Netzteil ist mit 3.7A bei 36V angegeben. Ich darf diesen Wert also in der Summe weder im Eilgang G00 noch im Materialeingriff dauerhaft überschreiten. Wie oben erklärt, ist der Eilgang im Gravurbetrieb durch die geringeren Fräskräfte maßgeblich, sodass ich besonderes Augenmerk auf das Verfahren mehrerer Achsen gleichzeitig legen muss.

Die Motoren können je einen Dauerstrom von 3.0A verkraften, limitieren mir hier also nichts. In den elektrischen Tests schaue ich lediglich, ob ich mit der Energieaufnahme des Systems im Rahmen bleibe.

Messaufbau

Ich schließe das aus diesem Artikel bekannte Multimeter direkt am Ausgang des Netzteils an und nehme Spannung und Strom auf. Für das Experiment simuliere ich die Fertigung der oben im Video verlinkten Gravur und führe in zwei Durchläufen zuerst eine zeitlich grob aufgelöste Leistungsfaktoranalyse (2Hz) durch, gefolgt von einer fein aufgelösten Stromermittlung mit 20kHz.

Ergebnisse

Im obigen Bild sind Spannung, Strom, Wirk- und Blindleistung aufgetragen. Zu erkennen ist, dass die Blindleistung (grün) immer dann kurze Spitzen zeigt, wenn mehrere Achsen gleichzeitig in den Eilgang beschleunigen. Die Leistungsaufnahme einer Achse im Eingriff G01/G02/G03, blau beträgt im Schnitt etwa 45W und ist ähnlich hoch wie bei der Konstantfahrt im Eilgang.

Das Netzteil ist in der Lage, die Spannung (orange) ziemlich konstant zu halten und knickt selbst unter Volllast nur um knapp 0.2V ein. Einzig der Stromwert sah mir etwas zu glatt aus. Ich vermutete an dieser Stelle, dass die zeitliche Auflösung zu gering ist und beschloss, das Experiment mit Konzentration auf den Strom zu wiederholen.

Und tatsächlich. Die höhere zeitliche Auflösung zeigt, dass die Stromaufnahme bei Beschleunigung mehrerer Achsen Spitzen zeigt, die über den bereits bekannten Werten liegt.

Hier stechen Bewegungen auf der Y-Achse, welche das gesamte Portal in Bewegung setzen muss, besonders heraus. Und zwar genau dann, wenn die anderen Achsen noch in Bewegung sind oder gerade gehalten haben. Dies hängt mit den Schrittmotortreibern zusammen. Sie betreiben die Motoren nämlich noch etwa 0.5s nach Anhalten bei vollem Strom weiter. Die dadurch entstehende Überlagerung lässt die Spitzen noch dramatischer aussehen.

Benchmark Spitzenlast

Na dann treiben wir es mal auf die Spitze mit einem Beschleunigungs-Benchmark. Wird das Netzteil auch bei voller Last unter Beschleunigung aller Motoren gleichzeitig die Ausgangsspannung halten können?

Um dies zu testen, habe ich einen G-Code geschrieben, der alle Achsen gleichzeitig auf Höchstgeschwindigkeit beschleunigen und dann wieder abbremsen lässt. Anschließend wird unter gleichen Bedingungen zum Ausgangspunkt zurückgefahren und das Ganze wiederholt.

Auf diese Weise kann ich herausfinden, ob das Netzteil genügend Reserven hat, um Lastspitzen abzufangen und gleichzeitig schauen, ob die Motoren bereits im größeren Maße Schritte verlieren. Im Mittel liegt hier die aufgebrachte Leistung bei 95W und die Versorgungsspannung sinkt um 0.28V auf 35.72V ab. Dabei muss das Netzteil in der Spitze 5.14A abgeben, was knapp 40% über Nennstrom liegt.

Your browser does not support the video tag.

Benchmark

Hört man ganz genau hin, so klingt die Maschine direkt zu Beginn des Benchmarks etwas rau, fängt sich dann aber. So können auch Schrittverluste klingen. Es ist daher sehr wichtig, die Maschine mit allen Sinnen zu überwachen.

Mechanische Prüfung

Nun zur letzten Prüfung: Ich gebe beim Eilgang-Benchmark zusätzlich Last auf die Achsen, indem ich während des Programmablaufes mit meinem Arm an der jeweiligen Achse ziehe. Die Achsen Z und X laufen stabil weiter. Bei der Portalachse Y merke ich jedoch, dass die Maschine nun anders klingt. Irgendwie rau, als würde man mit mit einer Raspel leicht über eine Holzplatte ziehen.

Lege ich eine große Last an, so fährt der Schrittmotor auf dieser Achse nicht mal mehr an, sondern fiept nur noch. Er kann den Pulsen der Endstufe nicht mehr folgen. Ich reduziere nun also die Beschleunigung schrittweise, bis der Motor die Portalachse auch unter mittlerer Last wiederholbar und ohne hörbare Schrittverluste beschleunigen kann. Hier lande ich am Ende bei immer noch flinken [aX = 4000mm/s² aY = 3200mm/s² aZ = 1600mm/s²].

In einem letzten Schritt führe ich nach fünfmaliger Wiederholung des Benchmarks eine weitere Referenzfahrt durch und schaue mir die Logs der Steuersoftware an. Alle Achsen sind nun unauffällig hinsichtlich Schrittverlusten.

Appelle zum CNC-Tuning

Bitte geht beim Tuning eurer Maschine behutsam vor. Lernt sie richtig kennen, bevor ihr damit beginnt. Hört genau hin und optimiert Achse für Achse nacheinander. Nehmt euch Zeit für Tests, Prüfungen und Experimente.

Selbst wenn ihr eine sehr ähnliche Maschine wie meine besitzt, machen andere Abmessungen bereits einen riesigen Unterschied hinsichtlich Steifigkeit und damit auch möglicher Verfahrgeschwindigkeit bzw. Beschleunigung. Sogar Wartungszustand, leichtgängigere Wellen, andere Führungen o.Ä. können dazu führen, dass ihr am Ende mit anderen Werten fahrt als ich.

Es wird kein Profi-Equipment benötigt, um die Grenzen der Maschine auszuloten. Nicht einmal eine Messuhr, da Schrittverluste auch mit Hilfe der Referenzschalter hinreichend genau bestimmt werden können.

Alles was ich durch die elektrischen Messungen oben festgestellt habe, ist, dass der Hersteller bei der Auslegung der Maschine sauber gearbeitet hat und keine Komponente unterdimensioniert ist. Im Gegenteil, diese Maschine ist für die Übertaktung bestens geeignet.

Und nun weiter zum letzten Teil 3: Pfadinterpreter optimieren.

CNC Tuning #1

Schallbert — Sat, 20 Apr 2024 00:00:00 +0000

Dies ist der erste Teil meiner Reihe über die Optimierung der Fertigungszeit auf CNC-Fräsmaschinen. Er konzentriert sich auf den Einsatz von CAD- und CAM-Werkzeugen zur Erzeugung effizienteren G-Codes.

Es gibt diverse Maßnahmen zur Reduktion der Fertigungszeit mit einer CNC-Maschine. Erstmal jedoch sollte beleuchtet werden, warum so etwas gewünscht ist und welche möglichen Nachteile sich hierdurch ergeben.

Warum überhaupt?

Aus kaufmännischer Sicht sorgen geringere Fertigungszeiten für einen höheren Teiledurchsatz und ermöglichen damit einen höheren Umsatz in einer gegebenen Zeitspanne. Zudem ist die Investition der Maschine schneller amortisiert.

Als Hobbyist sind kürzere Fertigungszeiten vor allem dann interessant, wenn das Ziel die Herstellung sehr komplexer Geometrien oder die 3D-Fertigung ist. Hier können Fräszeiten durchaus mehrere Stunden betragen und die möglichen Einsparungen sind folglich besonders groß.

Bei mir steht wie auch in der Lehre der wissenschaftliche Gedanke im Vordergrund: Ich will herauszufinden, wo die Grenze der Maschine liegt. Ich möchte wissen, warum sie dort liegt. Ich werde versuchen, sie stabil innerhalb ihrer Grenzen zu betreiben. Dabei ist der Verschleiß unter Kontrolle zu halten.

Um diese Grenze jedoch genau zu kennen, muss sie zuerst übertreten werden. Woher sonst soll ich wissen, wo sie sich befindet?

Was sind mögliche Nachteile?

Bestimmte Komponenten einer “übertakteten” Maschine könnten schneller als üblich verschleißen. Dazu zählen etwa Netzteile und Motor-Endstufen, die höhere transiente Ströme verkraften müssen. Lager und Führungen werden durch höhere Beschleunigungen stärker beansprucht. Umlaufspindeln und Maschinenrahmen müssen die dadurch resultierenden, stärkeren und schneller wechselnden Kräfte und Vibrationen aufnehmen und können früher Ermüdungserscheinungen oder sich lösende Verbindungen aufweisen.

Bei der Ermittlung der Grenzen kann die Maschine im Extremfall sogar beschädigt werden: Mit hoher Wahrscheinlichkeit treten jenseits der Grenze Schrittverluste¹ auf. Das ist zwar im Testbetrieb nicht weiter problematisch. Doch stimmt die angenommene Position dann nicht mehr mit der tatsächlichen Position überein und es besteht das Risiko des “Crashes” - wenn nicht mit Bedacht vorgegangen wird. Hier noch ein ziemlich gutes Youtube-Video von gammaflow zum Thema Schrittverluste vermeiden.

Werden die Fräsbahnen im CAD oder CAM zugunsten kürzerer Fertigungszeiten verändert, so kann dies außerdem negative Auswirkungen auf Schnitt-, Kanten- und Oberflächenqualität haben.

Bei der Optimierung des Pfadinterpreters der Steuersoftware ist ebenfalls ein Kompromiss einzugehen: Höhere Fertigungsgeschwindigkeit wird hier mit geringerer Genauigkeit und/oder höherem Maschinenverschleiß eingekauft.

Welche Maßnahmen werden nicht diskutiert?

Nicht betrachten werde ich hier die Optimierung von Vorschub F und Drehzahl S des gewählten Fräsers im Eingriff. Diese Parameter hängen vom zu bearbeitendem Material, der Fräsergeometrie, den Fähigkeiten der Maschine und dem Mut des Bedienpersonals ab, sodass ich keine allgemein gültigen Tunings vorschlagen kann.

Einen anderen, großen Einflussfaktor muss ich hier ebenfalls ausklammern: Die Bearbeitungsstrategie des CAM-Programms bezogen auf Eilgänge. Mein CAM-Programm lässt mich da nicht besonders tief eingreifen, sodass ich für die Optimierung der letzten paar Prozent Fertigungszeit stets von Hand im G-Code arbeiten muss, was entsprechend fehleranfällig ist.

Tuning in drei Schritten

Bei meiner Optimierung bin ich in drei Schritten vorgegangen, die allerdings unabhängig voneinander umgesetzt werden können. Jeder Schritt hat mir hierbei deutlich spürbare Verbesserungen gebracht. Dieser Artikel konzentriert sich aus mehreren Gründen auf den Gravurbetrieb:

Gravuren erlauben meist größere Toleranzen als andere Betriebsarten. Dadurch kann stärker verrundet werden, was zu geringeren Beschleunigungen führt. Dies ermöglicht im Mittel größere Vorschübe
Die zu erwartenden Fräskräfte sind geringer: Keine Durchfräsungen, kaum Energieeinsatz bei der Spanverdrängung, kleineres Spanvolumen als bei Schaftfräsern
Dadurch kann die Maschine näher an ihren mechanischen und elektrischen Grenzen betrieben werden
Durch im Schnitt größere G-Code Dateien mehr Optimierungspotential

Schritt 1: Besserer G-Code

Dieser Abschnitt folgt dem Credo Garbage in, Garbage out. Will heißen: Wenn mein G-Code schon schlecht ist, kann die Maschine niemals optimale Fertigungszeiten erreichen. Was zeichnet also “schlechten” G-Code in Bezug auf Fertigungszeit aus?

übermäßig komplex und lang, möglicherweise Dateigröße im Megabyte-Bereich
extrem viele Stützpunkte und eine Menge kurzer Liniensegmente
Einen Haufen “Leerfahrten” im Eilgang auf XY mit hochgezogener Z-Achse
Viele Rückzüge der Z-Achse auf Sicherheitshöhe
Häufige Wartezeiten der Maschine (Spindelhochlauf, Kühlmittelpumpe, Controller-Puffer voll)
Übermäßiges Feinstschlichten auch bei B-Oberflächen

Aber wie soll ich meinen G-Code vereinfachen?

Kurze Frage, lange Antwort: Es fängt im CAD an und hört möglicherweise im CAM nicht auf.

Beispiel CAD

Nehmen wir an, wir möchten eine Schrift fräsen. Unser CAD-Programm hat auch einen Haufen toller Schriftarten dazu. Wir erzeugen nun eine DXF-Datei für’s CAM. Im CAM dann sehen wir plötzlich beim Hineinzoomen, dass alle Buchstaben aus sehr kurzen Liniensegmenten bestehen statt aus Kreissegmenten oder Splines. Die Folge: Das CAM wird G01-Bewegungen, also “Linear Moves” bzw. eine Aneinanderreihung von Strecken erzeugen.

Die verbundenen Strecken machen sehr viele Richtungswechsel der Maschine erforderlich. Folglich muss sie vor dem Verbindungspunkt ständig abbremsen und danach wieder beschleunigen. Die Maschine kann also nicht mit konstanter Geschwindigkeit fahren, denn das würde eine unendliche Beschleunigung am Knickpunkt erfordern.

Für dieses Problem gibt es Lösungen, die im Idealfall gemeinsam angewendet werden:

Im CAD-Programm einstellen, dass wann immer möglich Splines oder Kurven statt Liniensegmenten erstellt werden sollen
Vereinfachung der Zeichnung durch Reduktion der Stützstellen
Vermehrte Nutzung von Radien und Splines an Kanten, Vermeidung von Winkeln

In meinem Falle war die erste Option nicht verfügbar, sodass ich nun ein anderes Programm für die Gravur von Schriften verwende als für meine üblichen Zeichnungen. Dadurch kann ich Schrift jetzt in Linien- und Bogensegmenten ausdrücken. Die dafür erforderliche Fräszeit halbiert sich und gleichzeitig kommt der G-Code mit weniger Zeilen aus. Außerdem wird die Schrift runder und hält sich sogar noch genauer an die anfangs gewählte Schriftart.

Gute Beispiele für die Vereinfachung von Pfaden durch Reduktion von Stützpunkten liefern Gimp und Inkscape - für Inkscape habe ich das sogar bereits meinem Artikel zum Thema Bild-zu-Pfad-Konversion gezeigt. Mit ein paar wenigen Klicks erhält man auf Kosten der Genauigkeit Zeichnungsdaten, die teils deutlich schneller zu fertigen sind.

Da ein Schaftfräser sowieso keine Tasche mit r=0 in den Ecken fertigen kann, habe ich mir angewöhnt, sämtliche Ecken und Kanten im CAD abzurunden. Nicht nur liegen so hergestellte Teile besser in der Hand, sie sind außerdem schneller zu fertigen - die Zeitersparnis summiert sich, besonders auf langsamen und trägen Maschinen.

Beispiel CAM

Im CAM kann ich durch vermehrte Verwendung von Anfahrpunkten und Rampen ein wenig Zeit sparen. Ich lege sie zumeist an das kürzeste Liniensegment und spare so einen Brems/Beschleunigungsvorgang. Bei der Eintauchart ist der Vorteil von “Rampe” gegenüber “Helix”, dass sämtliche Wege des Fräsers Nutzwege sind und ich ohne zusätzliche Achsbeschleunigungen durchfahren kann. Je nach Rampensteigung allerdings verlängert sich der Fräspfad, da Überlappungen entstehen.

Einen viel größeren Effekt auf die Fertigungszeit hat die kluge Auswahl von Räumzustellungen und -strategien für Taschen passend zu Material, Fräser und gewünschter Oberflächengüte. So erzeugt Wirbelfräsen (Trochoidalfräsen²) in vielen Fällen längere Dateien und kostet auf der Maschine mehr Zeit als der klassische “Rasenmäher”, welcher die Tasche bloß abzeilt. Für die Räumzustellung wähle ich bei Materialien wie Holz und Acrylglas gern große Werte über 60% - es sei denn, der Boden der Tasche muss besonders hohen Qualitätsansprüchen genügen.

Für Gravuren ist es meiner Meinung nach oft am Schnellsten, auf einen Räumgang mit einem zweiten Fräser zu verzichten und wenn möglich einen Gravurfräser mit abgeflachter Spitze - ähnlich derer für meine Tests mit Dibond - zu verwenden. Dieser benötigt zum Räumen zwar länger; das kann ich durch gesteigerte Gravurtiefe und eine recht breite Abflachung von 1.5mm aber kompensieren. Ich verwende bei einem solchen Fräser eine Räumzustellung in XY von 1mm. Übrig bleibt schließlich der Zeitvorteil durch weniger Werkzeugwechsel.

Aber wie soll ich die Leerfahrten reduzieren?

Endlich mal ein paar knackig-kurze Antworten:

Geringere Rückzugshöhe in Z (ich verwende 5mm aber 2mm würde bei mir wahrscheinlich auch funktionieren)
Optimierung der Frässtrategie im CAM auf “minimale Wege”
Bei Nesting: Darauf achten, dass die Geometrie möglichst nicht Zeile für Zeile, sondern Teil für Teil gefertigt wird.
Im Zweifel Optimierung der Strategie im G-Code von Hand. Lohnt sich dann, wenn das CAM-Programm nicht gut genug arbeiten kann und viele Gleichteile zu fertigen sind

Und wo ist das Problem mit Rückzügen der Z-Achse?

Rückzüge finden vor allem im Gravurbetrieb sehr häufig statt
der Zeitverlust summiert sich
Beim Wiedereingriff wird meist nicht im Eilgang sondern mit für den Fräser vorgesehener Geschwindigkeit mit G01 auf das Material gefahren

Eine Verbesserung kann hier eine gute Planung der Fräsreihenfolge im CAM bringen. Möglichst viele Sektionen sollten verbunden und ohne Absetzen des Fräsers gefertigt werden. Im CAM sollte für Rückzug und Wiedereinfahrt in Z der Eilgang verwendet werden.

Wie reduziere ich Wartezeiten?

Mit Kühlschmierstoffschaltvorgängen, Wechsel der Spindeldrehzahl oder des Werkzeugs sind Wartezeiten verbunden, die meist leicht zu reduzieren sind:

Kühlschmierstoffförderung durchlaufen lassen während des Programmablaufes
die Verwendung möglichst weniger Werkzeuge bei gleichbleibender Drehzahl für ein Produkt
Anschläge verwenden, um die Maschinenbeschickung zu vereinfachen und Nullpunkte nicht immer wieder neu setzen zu müssen
Wird die Maschine mit komplett verschiedenen parametern für Gravur- und Fräsbetrieb gefahren, empfiehlt sich die doppelte Installation der Steuersoftware mit jeweils passenden Parametersätzen. Dadurch entfällt das ständige Ändern der Konfiguration.

Weiter geht es in Teil 2: Kinematische Parameter hochdrehen.

Schrittverluste treten dann auf, wenn die Achse eines Schrittmotors nicht mehr synchron mit der durch die Steuerung vorgegebenen Schrittfolge dreht, sondern weniger bzw. mehr Schritte zurücklegt als vorgegeben. Fast immer ist die Ursache eines Schrittverlustes in einer unzureichenden Auslegung des Systems (z.B. zu geringe oder instabile Versorgungsspannung, zu schwache oder nicht an den Motor angepasste Endstufen) oder einer Überlastung des Schrittmotors zu finden. Selten jedoch können Schrittverluste Symptome von Defekten sein wie Lagerfraß, Windungsschluss oder durchschlagene Pufferkondensatoren. ↩︎
Das Trochoidalfräsen ist keine schlechte Praxis. Es hat andere Stärken, ist im Gravurrbetrieb aber nur selten von Nutzen. ↩︎

Hardware Test

Schallbert — Sun, 23 Apr 2023 00:00:00 +0000

Ein neuer Antrieb

Kürzlich habe ich Zerspanobert ein Spindel-Upgrade gegönnt. Ich bin jetzt auf eine Drehstrom-Asynchronmaschine umgestiegen, welche mit einem 24V-Lüfter fremdgekühlt wird. Für den Betrieb im benötigten Drehzahlbereich musste ich in einen Frequenzumrichter investieren, der in meinem Falle wie beim vorigen Fräsmotor auch über ein analoges 0-10V Signal gesteuert wird. Aus Sicht der CNC ist die neue Spindel bis auf eine Ausnahme identisch mit der alten: Der Frequenzumrichter kann nun ein “Not-Aus” Signal erzeugen und an die Steuerung melden, z.B. wenn die Drehzahl ungeplant abfällt, zu lange ein Überlastzustand auftritt etc.

Wie man sich vorstellen kann ist das neue Subsystem rund um die Spindel deutlich komplizierter als das alte.

Warum extra Tests?

Mit höherer Systemkomplexität erhöht sich auch das Risiko für Fehlfunktionen. Es sind eine Menge mehr elektrischer, elektronischer und mechanischer Bauteile verbaut als bei meinem Fräsmotor, die selbst Defekte aufweisen oder bei falscher Verdrahtung selbst in Rauch aufgehen können. Da ich als Systemdesigner selbst nur ein Mensch bin der Fehler macht, wäre es nicht besonders schlau, das System irgendwie zusammenzustecken und dann direkt auszuprobieren.

Während ich die Verdrahtung erstellte, überlegte ich mir also, wie ich das System effizient testen könne, ohne etwas zu zerstören.

Teststrategie

Ich habe die unterschiedlichen Testbereiche von meiner Arbeit in der Softwareindustrie geborgt. Sie passen hier denke ich recht gut hinein:

Unit: Ein Test, der das Verhalten einer Komponente des Systems isoliert überprüft. Alle externen Einflüsse wurden entweder entfernt oder durch Komponenten ersetzt, auf die im Test selbst problemlos zugegriffen werden kann. Beispiel: Prüfe, ob der Lüfter bei Anlegen seiner Betriebsspannung wie erwartet im richtigen Drehsinn anläuft.
Integration: Diese Tests prüfen das Zusammenspiel verschiedener Komponenten, welche gemeinsam eine Funktion abbilden. Beispiel: Überprüfe, ob die Luftkühlung der Spindel auch nach Abschalten derselben für eine bestimmte Zeit nachläuft.
Subsystem: Verifiziert die korrekte Interaktion aller Komponenten eines Subsystems. Beispiel: Die Spindeldrehzahl kann über eine analoge Spannung am Eingang des Frequenzumrichters verändert werden.
System (End2End): Diese Tests werden aus Kundensicht ausgeführt und durchlaufen das komplette System. Beispiel: Wenn ich den Not-Aus an der CNC betätige, muss der Frequenzumrichter die Spindel umgehend sicher zum Stillstand bringen.

Teste früh

Aus meiner Erfahrung macht es Sinn, die Tests zum frühestmöglichen Zeitpunkt durchzuführen. Nachdem die Spindel geliefert worden war, konnte ich auf diese Weise sofort nachvollziehen, ob alle Lager leichtgängig sind, ob der Lüfter funktioniert und ob der elektrische Widerstand der Statorwicklungen im erwarteten Bereich liegt. Alle diese Tests waren durchführbar noch bevor ich mit dem Bau des Schaltschranks überhaupt begonnen hatte.

Your browser does not support the video tag.

Unit test: Lüfter

Die schnell und einfach durchführbaren Unit Tests können einen Haufen Zeit sparen, denn diese Fehlerquellen kann man später bei der Inbetriebnahme direkt ausschließen. Und findet man doch etwas so früh, kann man sich direkt um Ersatz kümmern und hält nicht den Einrichtbetrieb auf.

Teste “von unten nach oben”

Bei den vier Testebenen versuche ich, so viel wie möglich mit einfachen und schnellen Unit Tests abzudecken. Was hier noch nicht geht, wird jeweils auf der nächsthöheren Ebene abgearbeitet und so weiter. Am Ende möchte ich nur ein paar Wenige Tests aus Kundensicht durchführen, da diese meist einen größeren Aufwand für Vor- und Nachbereitung benötigen und außerdem zumeist nicht genau in der Lage sind, den Fehler zu lokalisieren.

Dies deckt sich mit dem Konzept der Testpyramide, welche in der Softwareentwicklung des Öfteren herangezogen wird.

Testplan

Für meine privaten Hobbyprojekte schreibe ich üblicherweise keinen Testplan. Meine Systeme sind meist deutlich einfacher als dieses. Außerdem benötigen nur die wenigsten potentiell gefährliche Niederspannung wie in diesem Fall.

Um das System besser zu visualisieren habe ich mal einen groben Schaltplan mit allen Komponenten sowie relevanten Ein- und Ausgängen gezeichnet.

Von diesem Bild habe ich einen Testplan abgeleitet. Hierbei habe ich versucht, die Interaktionen jeder Komponente mit jeder anderen abzudecken und wenn möglich versucht, dem Komponententest den Vorrang zu geben.

Your browser does not support the video tag.

Unit test: Stromversorgung +24V OK

Hier überprüfe ich die Versorgungsspannung für den 24V-Lüfter

Your browser does not support the video tag.

Unit test: Abfallverzögerung

Mit diesem Test stelle ich sicher, dass die Konfiguration der Anzugs- und Abfallverzögerung wie gewünscht funktioniert. Für den Test habe ich kürzere Zeiten gewählt als später im produktiven Betrieb.

Your browser does not support the video tag.

Integrationstest: FU Inbetriebnahme

Hier prüfe ich, ob der Frequenzumrichter die Spindel mit der korrekten Drehrichtung und mit unterschiedlichen Drehzahlen betreiben kann.

Ausführung der Tests

Es gibt natürlich noch viele weitere hardwarebasierte Tests die ich oben nicht erwähnt habe. Dinge wie “ist die Spindel korrekt mit der Z-Achse ausgerichtet?” “Habe ich alle Schrauben mit dem vorgeschriebenen Drehmoment angezogen?” “Sind alle Stecker angeschlossen und verriegelt?”

Bevor ich nach dem Umbau also das erste mal wieder Späne mache, habe ich den Testplan komplett abgearbeitet und tatsächlich ein Problem auf Systemebene entdeckt: Ich habe den Analogausgang zur Vorgabe der Spindeldrehzahl falsch verdrahtet, sodass andere Pins das Signal führten als geplant. Dies führte dazu, dass sich die Spindel trotz Freigabe nicht starten ließ, obwohl die CNC “Spindel läuft” ausgab.

Dank der vorausgehenden Tests am Frequenzumrichter (“Reacts to speed command”) habe ich nur Minuten benötigt um den Fehler zu finden und zu beheben - denn ich wusste, am FU liegt’s nicht.

Dokumente

Falls Sie planen, eine Frequenzumrichtergesteuerte Motorspindel an Ihrer Maschine einzusetzen, können Sie sich meinen Testplan kostenlos herunterladen. In case you plan on adding a VFD-controlled spindle motor to your machine, please find my full test plan below.

VFD-controlled spindle motor test plan

Aber bitte betrachten Sie diesen Plan mehr als Unterstützung denn als vollumfängliche Prüfung und beachten Sie vor allem die üblichen Warnhinweise:

⚠️ Warnung vor gefährlicher Spannung ⚠️

Dieses System sollte nur von Profis konstruiert, zusammengebaut, angepasst, in Betrieb genommen und schließlich fachgerecht geprüft werden. In diesem Falle meine ich mit “Profi” jemanden, der eine abgeschlossene Berufsausbildung zum Elektriker oder Elektroniker, optimalerweise in der Fachrichtung Anlagenbau/Betriebstechnik sowie Erfahrung im Umgang mit Industrieelektronik vorzuweisen hat. Vermeiden Sie insbesondere, unter Spannung stehende Teile zu berühren oder an einer der Komponenten zu arbeiten, bevor der Frequenzumrichter nach dem Abschalten genügend Zeit hatte, seine Pufferkondensatoren zu entladen.

GoogleTest Demo

Schallbert — Mon, 01 Jan 0001 00:00:00 +0000

Projekt-Steckbrief

Schwierigkeitsgrad: Mittel 3/5
Kosten: 0€
Zeitaufwand: ~2h

Motivation

Es ist schön, bei der Entwicklung komplexerer Projekte ein leistungsfähiges Unit-Test-Framework zur Hand zu haben, das viel Zeit bei der Fehlersuche spart (vor allem das On-Target-Debugging in der Embedded-Welt kann sehr zeitaufwändig sein), die Codequalität verbessert und möglicherweise den Einblick in APIs und Architektur für andere verbessert.

Die Welt der “embedded controller”

Traditionell waren Mikrocontroller auf der Speicherseite begrenzt. In der Vergangenheit hatten sie weder viel RAM noch PROGMEM, also war mein meist in schlankem C geschrieben und die Konfiguration fand in Listen von #define statt, die nicht viel Rechenzeit kosten, weil der Präprozessor die Arbeit machen würde und nicht der µC zur Laufzeit. Meine Unit-Tests waren immer an die Hardware gebunden, auf der sie liefen - nehmen Sie Unity als bekanntes Beispiel - aber jetzt wollte ich etwas Neues ausprobieren: Code objektorientiert schreiben und die Geschäftslogik unabhängig von der Hardware testen lassen. Ich wählte das GoogleTest-Framework und wollte eine nahtlose Integration in meinen Workflow mit VScode und dessen Erweiterung PlatformIO erreichen.

Hierfür blieb bis vor kurzem nur der Weg, GoogleTest per GNU Compiler Collection parallel zu betreiben und durch PlatformIO ansteuern zu lassen. Neuerdings allerdings lässt sich GoogleTest als PlatformIO Library direkt nutzen. Daher gehe ich hier auf beide Wege ein.

GoogleTest direkt in PlatformIO verwenden

Hier gestaltet sich die Installation besonders einfach:

Mein Github-Repository PlatformIO-gTestgMock klonen.
Im Repository-Ordner ein Konsolenfenster öffnen und per git checkout googletest-native auf den entsprechenden Branch wechseln.
Den Anweisungen in der README-Datei des Repository folgen und das Setup ausprobieren.

So sieht es aus, wenn die Tests erfolgreich durchgeführt wurden:

GoogleTest per GCC einsetzen

Die benötigte Software kann man selbst (auch auf einem Windows¹ Rechner) installieren, um mit GoogleTest starten zu können.

MinGW herunterladen und installieren

Siehe diesen Thread im Forum von PlatformIO, wenn es Fragen zu den folgenden Schritten gibt.

Unix-Benutzer: bis hier die Schritte überspringen, denn wahrscheinlich werden nur die libpthreadgc-Bibliotheken zusätzlich benötigt. Prüfen Sie das Vorhandensein aller Bibliotheken (aber lassen Sie das Präfix mingw32- weg) und installieren ggf. fehlende nach. Stellen Sie sicher, dass die PATH-Variable korrekt gesetzt ist.
Windows-Benutzer:

Laden Sie MinGW herunter, z.B. von Sourceforge
Installieren Sie durch Ausführen von mingw-get-setup.exe. Wenn Sie grafische Benutzeroberflächen mögen, lassen Sie das entsprechende Kästchen angekreuzt. Ich empfehle nicht, das Installationsverzeichnis zu ändern. Wenn Sie das doch tun, müssen Sie sich sich den neuen Pfad merken.

MinGW konfigurieren

Damit GoogleTest läuft, müssen zusätzliche Pakete installiert werden:
- mingw32-gcc-g++
- mingw32-libmingwex
- mingw32-libmingwex-dll
- mingw32-libmingwex-dev
- mingw32-libpthreadgc-dll
- mingw32-libpthreadgc-dev
Um diese zu installieren,
- Wenn Sie die GUI verwenden: Suchen Sie die Bibliotheken unter “MinGW Standard Libraries” und fügen Sie sie nacheinander hinzu/aktivieren/installieren Sie sie.
- Benutzer des Kommandozeilen-Interpreters: Geben Sie mingw-get install ein und fügen Sie dann den Paketnamen hinzu. Wenn Sie eine Fehlermeldung erhalten, die besagt, dass einige der Pakete bereits existieren, umso besser.
Jetzt müssen Sie den Ordner “bin” von MinGW zu Ihren Systempfadvariablen hinzufügen, damit PlatformIO sie später finden kann. Wenn Sie ihn nicht von Hand modifiziert haben, sollte er C:\MinGW\bin lauten.
- GUI-Fans: folgen Sie dieser Anleitung
- CLI: Geben Sie set PATH=%PATH%;C:\MinGW\bin ein und überprüfen Sie, ob es mit echo %PATH:;=&echo.% funktioniert.

Glückwunsch! Sie haben MinGW installiert, die Umgebungsvariablen so gesetzt, dass es von Drittanwendungen leichter gefunden wird, und es für die Zusammenarbeit mit GoogleTest konfiguriert.

PlatformIO konfigurieren

Nachdem die Variable PATH gesetzt ist, muss VScode neu gestartet werden.
Damit PlatformIO korrekt mit dem gerade installierten Compiler verbunden wird, muss die native Umgebung verwendet werden. Dort befindet sich der Compiler mit allen benötigten Umgebungsvariablen. Öffnen Sie ein PlatformIO-Terminal in einem Ihrer Projekte und geben Sie pio platform install native ein.
Zwei Möglichkeiten:

A) Befolgen dieser Anleitung unter Verwendung meines Beispielprojektes wie unten beschrieben. Dann kann der nächste Abschnitt getrost übersprungen werden, da dieses Projekt vorkonfiguriert ist. Sie können nach Belieben damit herumspielen denn Sie verfügen von Anfang an über grundlegende Hardware-Abstraktionsschnittstellen.
B) Nehmen Sie Ihr eigenes Projekt und ändern Sie dessen Platformio.ini so, dass GoogleTest ausgeführt werden kann.

Dies sollten Sie zu Ihrer Platformio.ini hinzufügen:

[env:desktop]
platform = native
build_flags = 
	-std=gnu++11 # use installed GNU C++11 compiler.
	-pthread # found in gtest documentation
lib_deps = 
	googletest # Will automatically load latest googletest lib
lib_ignore = 
 src # most main.cpp's directly access the hardware. 
 # Can be removed if your project is different.
 #
 # PLUS: Any files that contain bare-metal hardware commands 
 # (e.g. digitalWrite), g++ won't have the headers or specialized compiler knowledge!
lib_compat_mode = off # Must-have for external stuff like gtest!

Erklärung: Für die Umgebung Desktop (= Computer ohne Microcontroller) wird der native Compiler verwendet, d.h. GCC/G++, der oben in der Anleitung installiert und für den die PATH-Variable festgelegt wurde. GoogleTest verwendet den C++11-Standard und Threading, der zu den Build-Flags hinzugefügt werden muss. Der Build von der googletest Bibliothek ab. Es werden alle Dateien/Ordner ignoriert, die Quell- oder Headerdateien mit hardwarebezogenen Befehlen oder Headern enthalten. Der Bibliothekskompatibilitätsmodus muss ausgeschaltet sein, damit der Library Dependency Finder googletest einbeziehen kann.

(Optional) Falls Sie lieber GUI-Schaltflächen verwenden als eine Zeile in die Konsole zu tippen um die Tests zu starten, erstellen Sie eine benutzerdefinierte Konfiguration.

Tests ausführen

Für einen schnelleren Einstieg kann mein Beispiel-Repository geklont werden (den main branch verwenden). Es enthält alle notwendigen Elemente, um zu prüfen, ob gTest und gMock korrekt funktionieren. So kann man direkt nachvollziehen, ob die Installation erfolgreich war.

Entpacken Sie die Zip-Datei bzw. verwenden Sie SSH, um das Repository zu klonen.
Öffnen Sie die Startseite der PlatformIO-Erweiterung, klicken Sie auf “Open Project”, und wählen Sie den Ordner aus.
Um die Unittests auszuführen, öffnen Sie ein PlatformIO-Terminal und geben Sie pio test -vvv -e desktop -f test_desktop ein. (-vvv = wortreich -e = Umgebung, -f = Filter). Die Parameter sind erforderlich, weil die Tests nur auf der “Desktop”-Umgebung lauffähig sind, nicht aber auf dem Microcontroller.
Nach einiger Zeit sollte die unten dargestellte Meldung angezeigt werden.

Super! Unit-Tests innerhalb von PlatformIO wurden gebaut und ausgeführt!

Tipps und Tricks

Zu beachten ist, dass der Ordner PlatformIO_gTestgMock/.pio/build/desktop nun eine ausführbare Datei namens program.exe enthält. Wird sie über die Kommandozeile ausgeführt, sollte das selbe Ergebnis wie in der obigen Abbildung herauskommen. Dies kann nützlich sein, wenn Tests nicht nur fehlschlagen, sondern das ganze Programm bei der Ausführung abstürzt. Zum Debuggen der Tests ist das auch hilfreich, da die CLI von PlatformIO dazu neigt, sich aufzuhängen. Man hat hier auch leichten Zugang zum Stracktrace - das sprengt den Rahmen dieser Übung aber bei Weitem.

Ab diesem Punkt

können Sie weiterlesen, um den Inhalt des Repositorys und die Funktionsweise von GoogleTest besser zu verstehen
Sie könnten das Schreiben von Tests üben, indem Sie weitere Fälle hinzufügen, z. B. um zu überprüfen, ob der Zustand “LOW” korrekt durchlaufen wird.
Sie könnten auch die Interfaces dieser Grundbausteine verbessern, z. B. durch Hinzufügen der Funktion analogRead() zur Hardware-Abstraktionsschicht
Sie könnten Ihr eigenes Projekt darauf aufbauen, die Hardware-Abhängigkeiten sauber ausschalten und es so einfach auf verschiedene Hardware-Geräte und Hersteller portieren
Oder Sie beschäftigen sich weiter mit diesen anderen genialen Dingen, die Sie in die Tat umsetzen wollten, bevor Sie von diesem Tutorial abgelenkt wurden.

Repository-Inhalte erklärt

Die folgenden Abschnitte behandeln die meisten Dateien im Repository und erklären, was sie im Detail tun. Die implementierte Geschäftslogik ist minimal und sollte als Beispielcode betrachtet werden. Ein reales Projekt, das alle auf dieser Seite dargestellten Muster verwendet, ist auf meiner Tonuino-Seite zu finden.

Schnittstelle der Hardware-Abstraktionsschicht

Schauen wir uns das Interface und seine Struktur genauer an.

// hal_if.h
namespace hardwareAbstraction {

// Hardware Abstraction Layer Interface class
class Hal_IF
{
public:
 virtual ~Hal_IF() = default;

 virtual bool digitalRead(uint8_t pinId) const = 0;
 virtual void digitalWrite(uint8_t pinId, bool value) const = 0;
};

} // hardwareAbstraction

Die Klasse Hal_IF hat zwei Methoden, die beide virtuell sind. Das bedeutet, dass eine Client-Klasse, die diese Schnittstelle verwendet, die Methode aufrufen kann und somit “automatisch” an die konkrete Implementierung der Methode weitergeleitet wird. Das = 0; macht diese Methoden rein virtuell, so dass das Überschreiben dieser Methoden durch eine abgeleitete Klasse nicht optional sondern vorgeschrieben ist. Das ist genau das, was wir hier wollen, denn wenn diese Methode nicht überschrieben würde, hätte sie kein Verhalten. Zu beachten ist, dass der Destruktor einer Schnittstellenklasse fast immer virtuell sein sollte.

LoopInOut

Die zu testende Logik. Sie greift nicht direkt auf die Ein-/Ausgabe-Hardware des µC zu, sondern auf die Variable m_hal, die eine Implementierung der Schnittstelle Hal_IF ist. Sie wird bei der Objekterzeugung per Referenz (gekennzeichnet durch das & bei der Typdeklaration) an die Klasse übergeben².

// loopInToOut.h

class LoopInToOut
{
public:
 LoopInToOut(hardwareAbstraction::Hal_IF& hal): m_hal(hal){};
 ~LoopInToOut() = default;

 bool loopThrough(uint8_t inPin, uint8_t outPin);

private:
 hardwareAbstraction::Hal_IF& m_hal;
};

Dies ermöglicht die eigentliche Magie von gMock: Da der Client-Code mit einer Schnittstelle arbeitet, kann ich die “echte” Implementierung (des Hardware-Zugriffs) zur µC-Laufzeit übergeben, aber für den Test kann ich eine “Modell”-Implementierung übergeben, über die ich zum Zeitpunkt der Ausführung des Tests die Kontrolle habe.

// loopInToOut.cpp

bool LoopInToOut::loopThrough(uint8_t inPin, uint8_t outPin)
{
 bool input = m_hal.digitalRead(inPin);

 m_hal.digitalWrite(outPin, input);
 return input;
}

loopThrough() ist wiederum sehr einfach. Sie liest den Zustand des Eingangspins und ordnet ihn dem Ausgangspin zu. Sie gibt den Zustand des Eingangspins an den Aufrufer zurück.

Modellierte Hardwareabstraktion (mock hal)

GoogleTest verwendet Makros, um Verhalten zu definieren. Die Mock-Klasse leitet sich ebenfalls von der Schnittstelle ab und stellt lediglich die Deklarationen der Schnittstellenmethoden bereit, die sie überschreibt. Es ist noch kein Verhalten festgelegt.

// hal_mock.h

class Hal_mock : public hardwareAbstraction::Hal_IF
{
public:
 MOCK_METHOD(bool, digitalRead, (uint8_t pinId), (const, override));
 MOCK_METHOD(void, digitalWrite, (uint8_t pinId, bool value), (const, override));
};

Die Testvorrichtung (test fixture)

Die Testvorrichtung enthält gemeinsame Daten und Verhaltensweisen für alle Testfälle innerhalb einer Testsuite. Name der Testsuite = Klassenname. Genau dieser Name muss in den Tests, die zu dieser Suite gehören sollen, wiederverwendet werden.

// unittest_loopInToOut.cpp
class loopInToOut_Test : public ::testing::Test
{
protected:
 virtual void SetUp()
 {
 m_loopInToOut = new LoopInToOut(hal_mock);
 }

 virtual void TearDown()
 {
 delete m_loopInToOut;
 }

 NiceMock<Hal_mock> hal_mock{};
 LoopInToOut* m_loopInToOut{nullptr};
};

Jeder Test verfügt also über einige vorbereitete Daten, die er verwenden kann: Die zu testende Klasse wird als Zeiger mit einer modellierten (Mock) Implementierung ihrer Abhängigkeit eingerichtet.

Der eigentliche Test

Der Test wird durch das Makro TEST_F definiert, was soviel bedeutet wie “Test mit Fixture”, das eine Testsuite und Testnamen erwartet. Das Makro ON_CALL ist ein Befehl an gMock, der der modellierten Klasse vorgibt, wie sie sich zu verhalten hat, wenn digitalRead(_) mit einer beliebigen Eingabe (Unterstrich = beliebig) aufgerufen wird: die Methode soll standardmäßig true zurückgeben.

// unittest_loopInToOut.cpp

TEST_F(loopInToOut_Test, loop_inputHigh_writesCorrectOutputHigh)
{
 ON_CALL(hal_mock, digitalRead(_)).WillByDefault(Return(true));

 EXPECT_CALL(hal_mock, digitalWrite(2, true));

 m_loopInToOut->loopThrough(1, 2);
}

Dann wird eine “Erwartung” an die nachgebildete Klasse formuliert, die besagt, dass digitalWrite mit Eingabewerten von (2, true) aufgerufen wird, die ebenfalls auf Korrektheit geprüft werden.

Die letzte Anweisung ruft die echte Implementierung auf, so dass die Erwartungen überprüft werden können.

Implementierung des Hardwareverhaltens

Da main.cpp auf die Hardware zugreift, muss es dafür eine Art Schnittstellenimplementierung geben.

// hal.h
class Hal : public Hal_IF
{
public:
 Hal() = default;
 ~Hal() = default;

 bool digitalRead(uint8_t pinId) const override;
 void digitalWrite(uint8_t pinId, bool value) const override;
};

Hier leitet Hal sich von Hal_IF ab und überschreibt alle seine Methoden.

// hal.cpp
#include "Arduino.h"

#include "hal.h"

namespace hardwareAbstraction{

bool Hal::digitalRead(uint8_t pinId) const
{
 return digitalRead(pinId);
}

void Hal::digitalWrite(uint8_t pinId, bool value) const
{
 digitalWrite(pinId, value);
}

Man erkennt, dass nur diese Quelldatei tatsächlich die Arduino.h für den Zugriff auf die Hardware einbindet. Die Abhängigkeit von den Hardware-Funktionen ist also sehr begrenzt und in Schnittstellen-Implementierungen gekapselt, die durch die Programmstruktur ausgewählt werden können. Während die main.cpp für das Zielgerät also ein Objekt der obigen Implementierung erzeugt, wird der Test stattdessen ein Mock übergeben.

Gtest Schlüsselkonzepte

Googles offizielle Webseite über Googletest kann sehr helfen, nicht nur für den Einstieg³. Das gmock Cookbook ist ein hervorragender Leitfaden, den ich im Laufe der Monate benutzt habe, als meine Tests immer komplexer und schwieriger zu schreiben wurden, und das gmock Cheat Sheet hilft, wenn man den Überblick verloren hat, wie ein Test für dieses oder jenes spezielle Problem zu schreiben ist.

Dependency Injection

Dependency Injection ist die grundlegende Mechanik, verstanden werden muss, damit man gMock erfolgreich anwenden kann. Ich versuche es mal mit einem Bild zu verdeutlichen.

Kurzgesagt ist die Schnittstelle lediglich ein Platzhalter für die Implementierung der Abhängigkeit der Client-Klassen.

Zur Laufzeit, z.B. wenn der Host das Client-Objekt erzeugt, wird er die Implementierung der Abhängigkeit an den Client übergeben (d.h. injizieren), der dann jede seiner Methoden aufrufen kann, da ihre Signaturen zur Kompilierzeit aufgrund der vom Client verwendeten Schnittstelle bekannt sind.

Das Mock ist nun lediglich eine Implementierung der Schnittstelle, die für die Tests spezialisiert ist.
Die eigentliche Implementierung wird in allen anderen Kontexten verwendet, sie zeigt das “echte” Verhalten dieser Klasse.

Hardware-Abstraktionsschicht

Dies ist vielleicht einer der kniffligen Punkte bei der Arbeit mit eingebetteter Software. Irgendwann geht es um die Interaktion mit der Außenwelt, sei es mit GPIO-Pins (General Purpose Input Output), den Zugriff auf eines der unzähligen Hardware-Bussysteme wie I2C, UART, SPI, CAN zur Steuerung externer Hardware oder einfach die Nutzung von Systeminterna wie dem EEPROM - da fangen die Probleme an.

Gtest läuft auf dem GCC/G++ Compiler, der einfach nichts von dem weiß, was der spezialisierte Compiler des jeweiligen Chips weiß. Er würde nicht einmal die Header-Dateien verstehen. Nun gibt es zwei Möglichkeiten, dieses Problem zu umgehen:

“Fake Header” für jede µC-spezifische Implementierung schreiben, die von GCC/G++ verwendet werden können
Eine Schnittstelle für jede µC-spezifische Implementierung unter Verwendung einer (Hardware-)Abstraktionsschicht programmieren, so dass Ihre Produktionsumgebung die Chip-Hardware wie gewohnt verwendet, die Testumgebung aber stattdessen Mocks benutzt.

Der zweite Ansatz hat eine Reihe von Vorteilen:

Er ist sauber. Er zwingt einen dazu, keine Abstraktionsschichten zu zusammenzufassen die getrennt gehören.
Er ist einfach. Man kann die Geschäftslogik testen, ohne den µC zu programmieren! Es müssen nur die Eingänge gemockt und die Ausgänge abgefangen werden.
Er ist portabel. Wenn man die Implementierung Abstraktionsschicht austauscht, kann man sie auf einer anderen Controller-Familie oder sogar auf Chips eines anderen Herstellers auszuführen.

Nachteile

Hmm, wo Licht ist, muss es doch irgendwo auch Schatten geben. Meiner Meinung nach sind die Nachteile, wenn man alles ohne angeschlossene Hardware testen will:

Speicher. Sowohl ROM als auch RAM werden schneller voll, wenn eine große Anzahl von Klassen und vtables existieren.
Besitz. Die Injektion von Abhängigkeiten trennt den Besitz von der Nutzung eines Objekts, und man muss sich entscheiden, wie beides organisiert werden soll.
Bibliotheken von Drittanbietern können nicht einfach verwendet werden sondern benötigen Anpassung. Ein Interface-Header, eine Adapter-Implementierung und ein Mock für jede Bibliothek, die “chip-internals” verwendet, sind zu erstellen.
Komplexität. Da Objekte über eine Schnittstelle injiziert werden, muss jetzt Call-by-Reference oder Übergabe per Zeiger durchgeführt werden 😨. Ersteres ist zusätzlich eingeschränkt, da es nur für Konstruktorinjektion funktioniert, nicht für andere Arten (Methodeninjektion, Setterinjektion usw.).

Einige weitere Tipps

Alles “hinter” der Abstraktionsschicht sollte so einfach wie möglich gehalten werden: Diese Dinge können nur auf dem Zielgerät getestet und ausgeführt werden. Beispiel: Jede Methode führt nur einen Befehl aus (wie in meinem Beispielcode).
Verwendung einer Loader-Klasse oder eines Dependency Injection Container (Nicolas Croad) erleichtert die Arbeit, denn er enthält alle zu injizierenden Objekte und kann sie auf Anfrage übergeben.
Die oben genannten Nachteile sollten im Blick behalten werden. Bei kleineren Projekten lohnt sich dieser Aufwand wahrscheinlich nicht.
Manchmal macht es sogar Sinn, mehrere Ebenen Schnittstellen zu haben. Dieses Muster kann nicht nur für die direkte Interaktion mit der Hardware zu verwendet werden, sondern auch zwischen Softwaremodulen, die dann in einer höheren Granularität getestet werden können. Dies kann sogar schneller sein als ein großen Haufen Klassen zu haben, die nur über Mocks in der Hardware-Abstraktionsschicht kontrolliert werden können.

Schwieriges Thema!

Sie haben sich jetzt eine Pause verdient. Das waren viele Informationen, die Sie verarbeiten mussten. Nehmen Sie sich Zeit. Kontaktieren Sie mich gern auf der discussions Seite zu diesem Thema, wenn Sie das Gefühl haben, dass etwas fehlt, nicht korrekt dargestellt ist, verbessert werden sollte oder einfach genau das ist, was Sie jetzt brauchten.

Die Installation unter Linux ist einfacher, da gcc und g++ bereits vorinstalliert sind. Selbst wenn sie noch nicht die richtigen Pakete zur Unterstützung von GoogleTest enthalten, sind ihr Fehlermeldungen viel aussagekräftiger als die unter Windows, z.B. wenn Bibliotheken fehlen. 🙃 ↩︎
Dies wird auch Constructor Injection genannt, eine Unterart der Dependency Injection, die ein Mittel zur Erreichung der Inversion Of Control ist. Ich habe einige Links zu weiteren Informationen vorbereitet. Dies ist ein umfangreiches Thema, über das ganze Bücher geschrieben worden sind. ↩︎
Übrigens: die googletest-Seite ist auch statisch wie meine und verwendet ebenfalls Jekyll 👋 …gefällt sie Ihnen? Ich würde gern Ihre Meinung dazu auf meiner Diskussionsseite erfahren. ↩︎

QR-Codengrave

Schallbert — Mon, 01 Jan 0001 00:00:00 +0000

Projekt-Steckbrief

Schwierigkeitsgrad: Schwer 4/5
Kosten: 0€
Zeitaufwand: ~50h

Die Idee

Ein Freund bat mich, einen Bierdeckel für ihn anzufertigen. Ein eigenes Logo, ein paar Buchstaben. Nichts allzu Schweres. Auf der Rückseite wollte er einen QR-Code eingravieren lassen, der einen Link zu seiner Website enthält.

Ich habe also einen QR-Code mit einem Standard-Webtool erstellt und als .svg exportiert. Leider müsste ich in meinem CAM jedes einzelne Pixel anklicken und eine Carve-Action für dieses Pixel erstellen, was einige Minuten meiner Zeit für Auswahl-Klick-und-Parameter-Wähl-Prozeduren in Anspruch nehmen würde. Außerdem müsste ich einen Gravurstichel mit tiefenvariabler Gravur verwenden, um ein quadratisches Pixel zu erhalten, was viel mehr Bearbeitungszeit erfordert als eine runde Darstellung.

An diesem Punkt beschloss ich, viele, viele weitere Stunden meiner Zeit auf dieses Problem zu werfen und eine allgemeine Lösung für QR-Code-Gravuren zu entwickeln - eine Software namens QR-codengrave.

Erste Schritte

Spezifikation

Das, was ich mit dem Tool erreichen wollte:

Muss es können:

Texteingabe verarbeiten und in einen QR-Code konvertieren. Der Benutzer muss keine zusätzliche Konfiguration vornehmen.
Bietet die Option zur Verwaltung verschiedener CNC-Werkzeuge.
Ermöglicht Eingabe von Gravurparametern: Gravurtiefe, Eilgangbewegung im Job, Überflughöhe
Ermöglicht Eingaben für benutzerdefinierte XY0-Offsets für Werkstücke
Vektorisiert die Pixelausgabe des QR-Codes
Kann Pfade aus den Vektoren erstellen lassen, beginnt der Einfachheit halber mit einer Spirale nach innen
Übergabe der Pixellinien an ein Modul, das die Parameter des ausgewählten Werkzeugs verwendet, um Maschinenbahnen zu erstellen
Maschinenbahnen in G-Code konvertieren, der später von meiner Maschine interpretiert werden kann.
Gründliche Überprüfung der Algorithmen mit automatisierten Unit-Tests (bitte keine Abstürze in der realen Welt)
Bietet eine grafische Benutzeroberfläche, um die Parametereingabe so einfach wie möglich zu machen.

Optional

Eine Continuous-Integration-Pipeline sowohl für meine IDE als auch für Github-Aktionen erstellen
Eine Continuous-Deploy-Pipeline für meine IDE (PyInstaller) und Github-Aktionen (Artefakte, Releases) erstellen
Integrationstests für die GUI hinzufügen
Optimieren des Algorithmus zur Pfaderzeugung, da die “nach innen gerichtete Spirale” eine hohe Fertigungsqualität hat und schön anzusehen ist, aber nicht sehr effizient mit der Zeit umgeht.

Unbekannte

Zu Beginn dieses Projekts hatte ich einige offene Fragen und Risiken, die die Nutzbarkeit des Programms hätten einschränken oder sogar das gesamte Projekt undurchführbar machen können. Sie haben sich alle als falsch herausgestellt (zum Glück), aber dennoch sind hier die Risiken, die meine ganze Arbeit unbrauchbar hätten machen können:

Kameras lesen keine runden Punkt-als-Pixel-QR-Codes.
Der Kontrast, den meine Graviermaterialien bieten, ist zu gering, so dass das Lesen der Codes schlecht oder gar nicht funktioniert.
Die Bearbeitungszeit könnte sehr hoch sein, was das Projekt unwirtschaftlich machen würde.
Beschränkungen der Programmierwerkzeuge oder meiner Programmierfähigkeiten könnten die Entwicklungszeit so verlängern, dass es sich nicht lohnt, weitere Anstrengungen zu unternehmen.

Daher beschloss ich, Unit-Tests zusammen mit dem Code zu schreiben, um ein schnelles Feedback darüber zu erhalten, ob mein Code das leisten kann, was er soll. Außerdem habe ich die Funktionalität des Programms auf eine Gravurstrategie beschränkt und die GUI so gestaltet, dass sie nur eine Vorschau des QR-Codes anzeigt, nicht aber XY-Offsets oder anderen Schnickschnack.

Programmiersprache

Ich nahm einige Blätter Papier und notierte mir das Wesentliche.

Ein Modul soll sich um die Erstellung eines QR-Codes aus einer Texteingabe kümmern, ein anderes soll Vektoren und Pfade erzeugen, um diesen QR-Code zu gravieren, und eine GUI in der Mitte soll die Texteingabe, eine Bearbeitungsvorschau und Eingabemöglichkeiten für Fräswerkzeuge, Gravurparameter und Werkstückversätze enthalten.

Ich hatte ein paar Programmiersprachen zur Auswahl, die ich gut genug “spreche”:

C++ mit QT-Framework
Java
Python mit dem Tkinter-Framework

Ich entschied mich für die - meiner Meinung nach - einfachste Lösung, um so schnell wie möglich einen lauffähigen Prototyp zu haben: Python mit Tkinter. Ich kenne Tkinter von einem meiner früheren Projekte und obwohl es seine Einschränkungen hat, ist es immer noch leistungsstark genug und schnell zu verwenden.

Konzeptphase

Nach etwas Recherche fand ich eine ziemlich gute Open-Source-QR-Code-Bibliothek im Internet, die auch in Python verfügbar ist. Auf der Grundlage ihrer Ausgaben habe ich einen Vektorisierungsalgorithmus erstellt, der die QR-Code-Bibliothek abfragen kann, um die Werte der Pixel des QR-Codes in einer Scanzeile zurückzugeben:

 def _qr_bitstream_from_line(self, line):
 """Creates a bitstream from an input line of a QR-code data representation
 :param line: a QR-code data representation (line of bits within the QR-code)
 :returns bitstream: returns an array of bits reflecting the QR code's state at the respective
 point of the line."""
 bitstream = []
 if line.get_direction() == Direction.RIGHT:
 for x in range(line.get_p_start().x, line.get_p_end().x + 1):
 bitstream.append(self._qr.get_module(x, abs(line.get_p_start().y)))
 if line.get_direction() == Direction.LEFT:
 for x in range(line.get_p_start().x, line.get_p_end().x - 1, -1):
 bitstream.append(self._qr.get_module(x, abs(line.get_p_start().y)))
 if line.get_direction() == Direction.UP:
 for y in range(line.get_p_start().y, line.get_p_end().y + 1):
 bitstream.append(self._qr.get_module(line.get_p_start().x, abs(y)))
 if line.get_direction() == Direction.DOWN:
 for y in range(line.get_p_start().y, line.get_p_end().y - 1, -1):
 bitstream.append(self._qr.get_module(line.get_p_start().x, abs(y)))
 return bitstream

Dann musste ich aus diesen Linien Vektoren erstellen, so dass aufeinanderfolgende Pixel derselben Farbe zu einer Linie zusammengefügt werden konnten, die viel schneller herzustellen ist als einzelne Punkte:

 def _vectorize_bitstream(self, bitstream):
 """Creates a QrLineData object from an input bitstream
 :param bitstream: an array of bits = a line of the QR-code
 :returns line_vector: A list of QrLineData objects"""
 line_vector = []
 data = QrLineData(bitstream[0], True)
 for bit in range(1, len(bitstream)):
 if bitstream[bit] == data.get_state():
 data.add_length()
 else:
 line_vector.append(data)
 data = QrLineData(bitstream[bit])
 if not data.get_state():
 data.finalize()
 line_vector.append(data)

 return line_vector

Diese beiden Methoden würden nun von einer übergeordneten Methode aufgerufen werden, die einen spiralförmigen Pfad durch den QR-Code kennt. Meine erste GUI hatte nur drei Elemente: Ein Eingabefeld für den Text, der in einen QR-Code umgewandelt werden sollte, eine Schaltfläche, um den Algorithmus auszuführen, und eine Zeichenfläche, auf der der Gravurpfad des Algorithmus ausgegeben werden sollte.

Ich das Modul Turtle verwendet, um den vektorisierten QR-Code-Pfad zu zeichnen, ein Tool, das für Schülerinnen und Schüler geschrieben wurde, die sich in Programmiersprachen wie Python einarbeiten. Es ist zwar langsam, aber einfach einzurichten, so dass mir das für den Anfang genügte. Ich habe für’s Erste hart kodiert, um Zeit zu sparen, und meine Schleifen sind eher C-esk als pythonisch, aber egal.

 for vect in self._spiral_path[i].get_z_vector():
 if self._stop_draw:
 break
 length = vect.get_length()
 if vect.get_state():
 self.turtle.down()
 self.turtle.forward(self.pen_size * length)
 self.turtle.up()
 else:
 self.turtle.forward(self.pen_size * length)
 self.turtle.right(90)

Dieses sehr einfache Konzept sah für mich vielversprechend aus, aber ich musste ein paar Stunden daran feilen, weil meine anfängliche Ausgabe wie folgt aussah:

Your browser does not support the video tag.

QR-codengrave GUI test

Nach einer Weile konnte ich jedoch zuverlässig einen (21x21 Pixel) QR-Code auf den Bildschirm zeichnen und die Kamera meines Smartphones verwenden, um den Link zur Webseite zu erhalten. 🥳 Yeah!

Your browser does not support the video tag.

QR-codengrave Vektorerzeugung funktioniert

Unit-Tests

Die “Plattform”-Teile - Klassen vectorize_qr und machinify_vector - enthalten beide eine Menge überprüfbarer Berechnungen und Geschäftslogik. Deshalb sind meine Tests mit Pythons Standardmodul unittest schnell und einfach zu schreiben. In diesem Beispiel überprüfe ich, ob die von mir erstellte Linienklasse eine Länge (n+1 Stil) korrekt berechnet:

class TestLine(unittest.TestCase):

 def test_line_x_calculates_valid_length(self):
 line = Line(Point(0, 0), Point(5, 0))
 self.assertEqual(6, line.get_abs_length())

Aber es wurde schnell komplexer, als ich testen wollte, ob die Ausgabe der QR-Code-Generatorbibliothek in meinem Programm korrekt verarbeitet wird. Dazu musste ich die Bibliothek in meine zu testende Klasse einbinden, damit ich eine Mock-Implementierung einschleusen konnte, die dann im Test abgefragt wird.

Dieses Muster der Abhängigkeitsinjektion ist der Vorgehensweise in C++ sehr ähnlich, wo ich viel mehr Erfahrung habe (siehe ein Projekt hier oder ein anderes hier, zum Beispiel), nur dass in Python viel weniger Boilerplate-Code nötig ist, um dorthin zu gelangen. Ein paar Suchvorgänge im Internet und schon war der folgende Testfall geschrieben:

 def test_bitstream_qr_input_loop_xpos_correct(self):
 mock_qr = QrCode.encode_text("schallbert.de", QrCode.Ecc.MEDIUM)
 mock_qr.get_module = MagicMock()
 cam = VectorizeQr(mock_qr, 1)
 cam._qr_bitstream_from_line(self.test_line_x)
 mock_qr.get_module.assert_called_with(20, 0)

Ich injiziere die “echte” QrCode-Bibliothek, aber mit einer Mock-Methode, die für mich von Interesse ist, get_module(). In dem Test stelle ich sicher, dass die Methode mit den erwarteten Parametern aus meiner zu testenden Klasse aufgerufen wird.

Mit solchen Tests kann ich sichergehen, dass die Bausteine meines Algorithmus wie vorgesehen funktionieren und dass Regressionen schnell gefunden werden können.

Der lange Weg zum Produkt mit Minimalanforderungen

Beflügelt von diesem schnellen Erfolg, ging ich aufs Ganze. Vor der Implementierung des G-Code-Generators musste ich einen Werkzeugselektor entwerfen, da ich die Werkzeugeigenschaften zur Verfügung haben musste, bevor ich die Abmessungen und die Werkzeuggeschwindigkeit / den Vorschub für die QR-Code-Gravur einstellen konnte.

Nach einigen erfolglosen Versuchen im Hauptfenster entschied ich, dass das Werkzeugkonfigurationsfenster stattdessen ein Dialog sein sollte (den Tkinter Toplevel nennt), so dass die Werkzeugparameter eingegeben und nach Abschluss an die Haupt-GUI zurückgeschickt werden können. Ich habe den Dialog modal gemacht mit

 self._dialog.grab_set()

So hat er immer den Fokus, damit nicht mehrere Instanzen dieses Fensters gleichzeitig vorhanden sein können. Ich habe die konfigurierten Werkzeuge in einer nummerierten Liste gespeichert, so dass die Anwendung, sobald sie gefüttert wurde, die Liste zur Verfügung stellt, damit der Benutzer das gewünschte Werkzeug für den Job aus einem Dropdown-Menü auswählen kann.

In diesem Schritt musste ich zwei Dinge implementieren:

Überprüfungen für Wertetyp und -bereich
Ein Persistenzmodul, so dass die eingegebenen Tools einen Neustart der Anwendung überleben würden.

Überprüfungen von Wertetyp und -bereich

Dies könnte mit einem Ereignis-Auslöser innerhalb des Eingabefeld-Widgets wie folgt erreicht werden:

 reg = config_tool_frame.register(validate_number)
 tool_nr_entry.config(validate="key", validatecommand=(reg, '%P'))

Anschließend wird der eingegebene Wert an einen einfachen Validator übergeben, der lediglich versucht, den Eingabewert in einen Float-Wert umzuwandeln und False zurückgibt, wenn dies einen Fehler erzeugt,

def validate_number(entry):
 """Helper function that is used in validators to check
 that the entered keystroke is a number"""
 if entry == '':
 return True
 try:
 float(entry)
 return True
 except ValueError:
 return False

Eine Prüfung ob der Wert plausibel ist erfolgt erst, wenn die Schaltfläche “OK” gedrückt wird, um die eingegebenen Daten an die Anwendung weiterzuleiten. Bei Überschreitung des Bereichs würde ein Warn-Popup (Modul tkinter.messagebox) erscheinen, das auf das mögliche Problem hinweist.

Persistenz

Das Persistenzmodul war etwas schwieriger zu implementieren. Ich entschied mich dafür, ein Element zu erstellen, das C++-Kenner eine statische Klasse nennen würden, d.h. eine Klasse, die nicht instanziiert werden muss, um eine ihrer Methoden aufzurufen. Diese Klasse hat nur zwei Methoden namens load und save, die das tun, was ihr Name andeutet, indem sie Pythons pickle Modul zur Serialisierung von Objekten verwenden, die ich speichern wollte. In Python habe ich den Dekorator @classmethod verwendet, um die statische Natur dieser Klasse zu kennzeichnen.

So einfach kann die Serialisierung von Daten mit den richtigen Werkzeugen werden:

 with open(app_persistence_path, 'wb') as file:
 pickle.dump([cls._tool_list,
 cls._z_params,
 cls._xy0],
 file, protocol=2)

Als dies zuverlässig funktionierte, fügte ich ein Widget zur Konfiguration der Gravurparameter hinzu. Von Nachteil bei statischen Methoden ist, dass sie nur schlecht unit-testbar sind, weil Dependency Injection hier nicht funktioniert; sie sind ja instanzlos. Es bliebe mir nichts anderes üblich als “Fakes” zu schreiben, die im Testfalle die echte Speicher- bzw. Ladefunktion ersetzt.

Gravur-Parameter

Um den G-Code aus meinen QR-Code-Daten zu generieren, benötigte ich nicht nur Werkzeug- und Geschwindigkeits-/Vorschubdaten, sondern ich musste auch wissen, wie tief ich gravieren wollte, wie weit das Werkzeug bei Eilgängen über der Werkstückoberfläche schweben sollte und welche Sicherheitshöhe die CNC für die Rückkehr zum Ursprung oder zur Ausgangsposition verwenden sollte.

Es wird auf ähnliche Weise wie das Dialogfeld “Werkzeugkonfiguration” erstellt und verwendet dieselben Mechanismen zur Überprüfung von Typ und Bereich. Der einzige Unterschied besteht darin, dass er nicht über einen Klick auf eine Schaltfläche, sondern direkt über das zugehörige Textfeld gestartet wird, das den aktuellen Wert der Gravurparameter im Hauptfenster anzeigt.

Werkstück XY Nullpunktverschiebung

Der Konfigurationsdialog für den Werkstückversatz enthält einige Radiobuttons zur Auswahl der gängigsten Werkstückursprünge und eine benutzerdefinierte Option, mit der der Benutzer Werte für den X- und Y-Achsennullpunkt des Werkstücks eingeben kann. Eine Funktion im Hintergrund berechnet den erforderlichen Versatz relativ zum Startpunkt der Gravierspirale.

Normalerweise würde ich nicht wollen, dass die grafische Benutzeroberfläche Berechnungen durchführt oder viel Verzweigungslogik verwendet, da dies schwieriger zu verifizieren ist, weil die Test Fixtures damit größer und schwieriger zu warten werden. In diesem Fall habe ich mich jedoch entschieden, die Offset-Berechnung mit Hilfe einer Wertetabelle innerhalb des GUI-Moduls durchzuführen, um zu vermeiden, dass alle GUI-Module zur Plattform und zurück kommunizieren müssen (und das durch 4 Klassen hindurch).

 def _get_xy_offset(self, offset):
 """calculates an XY coordinate offset from a preset point, taking the selected tool diameter into account.
 :param offset the selected offset from the above enum class
 :returns a XY Point where XY0 is assumed for the engraving."""
 qr = self._qr_dimension
 d = self._tool_diameter
 offsets = {Offset.CENTER: Point((d - qr) / 2, (qr - d) / 2),
 Offset.TOPLEFT: Point(d / 2, -d / 2),
 Offset.TOPRIGHT: Point(d / 2 - qr, -d / 2),
 Offset.BOTTOMLEFT: Point(d / 2, qr - d / 2),
 Offset.BOTTOMRIGHT: Point(d / 2 - qr, qr - d / 2)
 }

 if offset in offsets:
 return offsets[offset]

Erstes Release V1.0

Die erste Version ist minimalistisch. Sie erfüllt ihren Zweck, hat aber noch einige Fehler (z.B. eine Fehlermeldung, wenn kein Werkzeug in der Auswahlliste ausgewählt ist) und Unzulänglichkeiten (z.B. ist das Zeichnen eines QR-Codes sehr langsam, beim erneuten Zeichnen kippt der QR-Code ein wenig usw.), aber sie sollte einfach funktionieren und dem Benutzer helfen, die schlimmsten Fehler auf seinem Weg zu vermeiden.

Ich habe die Ausführung auf meiner CNC-Maschine getestet und zumindest mein Handy ist in der Lage, zu einer Website zu navigieren, indem es einfach die Kamera auf das Werkstück hält 📱.

Automatisierte Integrationstests für die GUI: Frustrierende Arbeit

Als meine erste Version herauskam, wollte ich einige Tests für die grafische Benutzeroberfläche hinzufügen. Da ich es nicht geschafft habe, dort absolut keine Geschäftslogik zu haben, wollte ich zumindest Bereichsprüfungen sowie die Kommunikation mit der Plattform überprüfen, um sicherzustellen, dass alles wie vorgesehen funktioniert.

Aufgehängt in der Messagebox

Zu diesem Zweck schrieb ich einige Tests, die auf meinem lokalen Rechner liefen, mit dem Nachteil, dass, wenn der Test auf einen Warn- oder Fehlerdialog messagebox.showinfo / messagebox.showerror stieß, eine manuelle Benutzerinteraktion unbedingt erforderlich war, damit das Fenster geschlossen und der Test fortgesetzt werden konnte.

Ich habe keine einfache Möglichkeit gefunden, dieses Problem zu umgehen, da die Messagebox als unabhängiges Widget agiert, das nicht einfach manipuliert werden kann. Auch meine Versuche, einen Tastendruck als Seiteneffekt aus dem Test heraus auszulösen, waren nicht von Erfolg gekrönt (und wären am Ende wohl auch keine saubere Lösung gewesen).

Meine Lösung nach ein paar Stunden gemurmelten Fluchens ist, dass die Messagebox-Widgets in die GUI-Klassen injiziert werden, die sie verwenden:

@patch('src.gui.gui_tool_manage.GuiToolManager')
 def setUp(self, mock_guitoolmanager):
 tk.Tk() # required to have tk variables properly instantiated
 self.mock_guitoolmanager = mock_guitoolmanager
 self.mock_msg = MsgBox()
 self.mock_msg.showinfo = MagicMock()
 Persistence.set_mock_msgbox(self.mock_msg)
 self.config_tool = GuiConfigureTool(self.mock_guitoolmanager, self.mock_msg, {'padx': 5, 'pady': 5})

Auf diese Weise kann ich mock_msg in die Gui-Klasse werfen, so dass nicht die echte showinfo genommen wird, sondern das Mock weiß, ob er wie vorgesehen aufgerufen wurde. Ich könnte ihr zur Testvorrichtung hinzufügen, so dass mein Testcode selbst DRY bleiben könnte.

Es fügt dem Konstruktor mehr Argumente hinzu und delegiert die Instanziierung an eine Klasse höherer Ebene, aber die Verwendung innerhalb der zu testenden Klasse bleibt trivial. Im Einsatz unter Realbedingungen agiert die Schnittstelle wie ein Proxy, der dann die echte showinfo-Methode des Messagebox Objektes aufruft.

Probleme mit statischen Klassen

Da die Persistenzklasse, die ich oben erwähnt habe, statisch ist, d.h. keine Instanziierung erfordert, hatte ich das nächste Problem von Anfang an in meinen Code eingebaut: Ein Integrationstest würde nun versuchen, in eine tatsächliche “persistence.dat”-Datei zu schreiben, eine Abhängigkeit, die ich nicht haben wollte, insbesondere nicht in der kontinuierlichen Integration (CI) - denn dort würde das Programm die Rechte für das Schreiben auf Festplatte nicht besitzen.

Also habe ich Persistence in die Haupt-GUI-Datei verschoben, die nicht getestet werden würde, und folgte damit Steven Andersons großartigem Blogbeitrag. Die Haupt-GUI sollte ohnehin nur deklarativen Code enthalten, und die geladenen Daten werden dann in die Klassen kaskadiert, die sie verwenden, anstatt in die Persistenzklasse, die die eigentliche Lade-/Speicheroperation durchführt.

Zukünftige Versionen

Folgendes ist für spätere Releases geplant:

Die Zeichnungsgeschwindigkeit des QR-Codes muss erhöht werden
Grafikfehler (Skalierung, Kippen) und unscharfe Ränder des Zeichenbildschirms sollen behoben werden
CNC-Bahnen sollen optimiert werden, um die Fertigungszeit zu verringern
Fehlerbehebungen

Zumindest wenn es welche gibt; mal sehen, wie oft ich dieses Tool benutzen werde. Die Dinge, die mich am meisten stören, werden wahrscheinlich zuerst behoben werden.

Ach ja, noch etwas: Danke für’s Lesen des gesamten Artikels. Zur Belohnung gibt es eine Kopie QR-codengrave kostenlos zum Herunterladen. Es kann für den privaten Gebrauch gern verwendet werden. Falls Sie eine kommerzielle Nutzung planen, lassen Sie es mich bitte im Voraus wissen.

Tonuino - alternative Firmware

Schallbert — Mon, 01 Jan 0001 00:00:00 +0000

Projekt-Steckbrief

Difficulty: Experte 5/5
Kosten: 0€
Zeitaufwand: ~400h

Galerie

Die alternative Tonuino-Firmware im Einsatz.

NFC-Tags sind Vögel, die zum Abspielen ins Häuschen gesetzt werden

Anwendungsbeispiel mit Microcontroller unter Verwendung meiner ClickEncoder-Bibliothek

Anwendungsbeispiel mit Arduino in einem Gitarrenverstärker

Gesteuert wird der Player in diesem Fall mit drei Tasten.

In disem Projekt entstand eine Software für eine NFC-Tag gesteuerte Jukebox. Sie ist für das Arduino-Framework optimiert und verbindet die Hardware eines Mp3-Players (mit SD-Karte), ein NFC-Tag-Lesegerät und ein paar Bedienelemente.

Ein NFC-Tag wird mit einem Ordner auf der SD-Karte verknüpft, welcher Audiodateien enthält. Das Tag speichert auch Informationen über den gewünschten Wiedergabemodus für dieses Album, z. B. “Zufällig”. Sobald ein verknüpfter Tag in die Nähe der Jukebox gebracht wird, wird der konfigurierte Ordner im entsprechenden Wiedergabemodus abgespielt. Mit den Bedienelementen kann der Titel ausgewählt, die Lautstärke geändert und sogar durch ein Sprachmenü navigiert werden, was das Löschen, Verknüpfen und Konfigurieren eines Tags sowie Sperren/Entsperren der Eingabetasten ermöglicht.

Motivation

Idee und fantastische Umsetzung hatte ich auf Thorsten Voß’ blog gesehen. Es begann mit der Funktionalität (encoder support), die ich hinzufügen wollte. Leider war der ursprüngliche Code ein zusammenhängender Block mit mehreren tausend Zeilen Code und für mich schlechter Lesbarkeit, so dass es mir schwer fiel, meine Änderungen einzubringen.

Also habe ich den Code von Grund auf neu geschrieben, um eine bessere Struktur, Lesbarkeit, Wartbarkeit und Erweiterbarkeit zu erreichen. Parallel dazu las ich einige Bücher über objektorientiertes Design in C++, Clean Code und Software Design Patterns und wandte einige davon dort an, wo ich sie für geeignet hielt. Auf diese Weise konnte ich sowohl die Modularität als auch die Lesbarkeit des Codes verbessern und habe außerdem gelernt, wie man Code in einem “größeren” Projekt schreibt.

Schwierigkeiten

Dies war mein erstes eigenes C++-Projekt, und vielleicht war es für den Anfang ein wenig zu groß. All die für mich neuen Konzepte, das Schreiben an eine Schnittstelle, die erstmalige Verwendung von Platformio als IDE, die Verwendung des googletest unit test framework, die Einsatz von Coding Patterns wie [factory](https://www. oodesign.com/factory-pattern.html) oder Dependency Injection kostete mich Abend um Abend über fast ein Jahr, bis ich dieses Projekt schließlich fertigstellen konnte. Und es gibt immer noch etwas zu überarbeiten und zu verbessern.

Übersicht

Unit-Test-Suite mit über 250 Testfällen
Serielle Debug-Ausgabe konfigurierbar
Lose gekoppelte, objektorientierte Architektur in C++
Einzelne Module mit klaren Aufgaben, skalierbar und leicht zugänglich für zukünftige Funktionen
benutzerdefinierte Hardware-Abstraktionsschicht; der größte Teil des Codes sollte ohne Änderungen auf andere MCUs portierbar sein
eigenes Dependency Injection Framework (Loader Klasse)

Funktionen

Konfigurierbare Benutzereingabe (Tasten oder Encoder)
Auto-Poweroff, wenn für eine konfigurierbare Zeit keine Taste gedrückt wird
Einschalten durch Drücken der “Play”-Taste
Autoplay-Funktion
Status-Led-Funktion
Sperren/Entsperren der Benutzereingabe
Mehrere Wiedergabemodi [Album, Zufall, Speichern des Titelfortschritts, Nur ein Titel] pro Nfc-Tag verfügbar
Sprachmenüs zum Verknüpfen oder Löschen von Nfc-Tags
Optimiert für Batterieanwendungen (z.B. Powerbank) unter Verwendung von Ruhezuständen
Niedriger Stromverbrauch @5V: ~40mA im Leerlauf, ~75mA bei mittlerer Lautstärke
Konfigurationsdatei für Startlautstärke, Einschlaf-Timer etc.
Automatische Wiederherstellung bei Eingabeaufforderung, die niemand bedient
Sprachansagen für die häufigsten Fehlermeldungen

Nicht enthaltene Funktionen

Keine Erkennung des Ladezustands der Powerbank
Kein Konfigurationsmenü (Startlautstärke, Dauer des Einschlaf-Timers, Standby-Dauer usw.)
…

Dokumentation

Das Projekt ist für das Arduino Framework erstellt - getestet auf einem Arduino nano Board - unter Verwendung der PlatformIO IDE. Die folgenden Abschnitte zeigen das Design.

Projekt Modulübersicht

Ordnername in `/lib`	Zweck
Arduino	minimalistische hardwarenahe Implementierungen, nicht Unit-testbar
Arduino_HardwareAbstraction	Hardware-Abstraktion, um Portabilität und Testen zu ermöglichen
Config	Systemkonfigurationsparameter
Folder	Geschäftslogik für Wiedergabeliste und Wiedergabemodus
Loader	Dependency Injection Framework
MessageHandler	Systemnachrichten und Debug-Framework
Mp3	Mp3-Steuerung (Status, Ordner, Sprachausgabe, Anzeigen)
Nfc	Tag-Steuerung (Status, Lesen, Schreiben, Löschen)
PowerManager	Steuerung von Status-LED und Ruhezustand abhängig vom Systemstatus
Tonuino	Haupt-Task-Scheduler
UserInput	Verarbeitung von Tasten- oder Encoder-Eingaben
Utilities	Timer, Led-Steuerung, Pin-Steuerung
VoiceMenu	Geschäftslogik für das Menü Link / Löschen / Konfiguration

Verwendete externe Bibliotheken

Automatische Installation durch Platformios “Library Dependency Finder” beim erstem Kompiliervorgang

Klassendiagramme

Klassendiagramme wären zu viel nicht-automatisierte Arbeit gewesen. Stattdessen habe ich das hier vorbereitet:

Software-Modulübersicht

Sie sollte ein genaues Verständnis dafür vermitteln, wie die Softwaremodule zusammenwirken und welche APIs die Module anbieten.

Los geht’s!

Zuerst muss mein repository, geklont werden - entweder per git clone, Download als zip-Datei oder per https. Das README.md Dokument bietet einen leichten Einstieg. Ich empfehle die Verwendung von PlatformIO für dieses Projekt. In den folgenden Abschnitten sind die Teilfunktionen des Programms erläutert, und wie deren korrekte Funktion sichergestellt wird.

Testen

Unit-Tests

Unit-Tests wurden mit dem gtest C++ Unit-Test-Framework geschrieben. Sie befinden sich im Ordner test/desktop. Zu beachten ist, dass googletest die Installation von gcc mit einigen Bibliotheken voraussetzt. Die Anleitung dazu findet man in einem meiner anderen Projekte. Sobald diese Voraussetzungen erfüllt sind und ein einfacher ASSERT_TRUE(false);-Test mit der gtest-Umgebung erwartungsgemäß fehlschlägt, können die Unit-Tests des Projekts erstellt und mit pio test -e desktop -f desktop, in der PlatformIO CLI (Terminal) ausgeführt werden.

Akzeptanztests

Obwohl diese Tests automatisiert werden könnten, ist es viel einfacher, diese Tests von Hand durchzuführen, nachdem der Mikrocontroller programmiert und alle elektronischen Komponenten zusammengesteckt wurden. Jede Zeile in den folgenden Tabellen ist ein eigenständiger Testfall. Die Testsuiten (“Überschrift Name”) haben eine System Pre: Eigenschaft, die vor der Ausführung der einzelnen Testfälle wiederhergestellt werden muss. Wenn die Erwartungsklausel erfüllt ist, ist der Test BESTANDEN. Ich habe die Tests auf Englisch belassen, weil sie recht eng mit dem Code korrespondieren.

Switching ON

System Pre: System is OFF

Action	Expectation
press Play/Pause button	LED flashes slowly?
press Play/pause button	Welcome prompt plays?

Switching OFF

System Pre: System is ON

Action	Expectation
Playback on pause, no button input	System switches off after a time?
System shutdown	Farewell prompt plays?
System shutdown	LED switched off?

Play Help Prompt

System Pre: System is ON

Action	Expectation
Long press Play/Pause button	Help prompt plays?
Help prompt playing	Can be interrupted with any button press?

Behavior without Tag

System Pre: System is ON, no Tag present

Action	Expectation
press Play/Pause button	prompts “couldn’t find track” error?
press Next button	prompts “couldn’t find track” error?
press Prev button	prompts “couldn’t find track” error?
doubleclick Play/Pause button	Delete Menu prompt played?

Behavior with Tag

System Pre: System is ON, linked Tag available

Precondition	Action	Expectation
no Tag placed	place known Tag	starts Playback of correct Folder?
active playback	press Next button	plays next track?
active playback	press Next button	next track in accordance with selected playMode of Folder?
active playback	long press Next button	increases volume?
active playback	press Prev button	plays previous track?
active playback	press Prev button	previous track in accordance with selected playMode of Folder?
active playback	long press Prev button	decreases volume?
active playback	press Play/Pause button	pauses track?
paused playback	press Play/Pause button	resumes track?
active playback	doubleclick Play/Pause button	Lock prompt played?
active playback	doubleclick Play/Pause button	Playback resumes after Lock prompt played?
active playback	doubleclick Play/Pause button	locks button input?
locked button input	doubleclick Play/Pause button	Unlock prompt played?
locked button input	doubleclick Play/Pause button	Playback resumes after Unlock prompt played?
locked button input	doubleclick Play/Pause button	unlocks button input?
paused playback	doubleclick Play/Pause button	Playback resumes after Lock prompt played?

Behavior with unlinked Tag

System Pre: System is ON

Action	Expectation
place unlinked Tag	plays LinkMenu Prompt?
navigate through LinkMenu	plays Configuration Success Prompt?
place Tag again	plays linked folder?

Hardware

Materialliste

Ich habe versucht mit möglichst wenigen Einzelteilen auszukommen. Für ein Projekt dieser Größe ist die Liste denke ich recht kurz geblieben.

Menge	Artikel	Zweck
1	Arduino (z.B. Nano)	Gehirn
1	Dfplayer Mini Mp3 Player	Mund
1	Micro SD Karte	Speicher
1	MFRC522 Nfc-Leser	Psi-Sense
1	Bistabiles Relais 5V, z.B. HFE20	Kaffee - kein Schlaf
2	Dioden z.B. 1n4007	Venenklappe
1	PNP-Transistor z. B. BC327	Kaffeemaschinenschalter
2	Widerstände 1k	Blutstromaufbereiter
1	Widerstand 220	Blinkstärke dimmen
1	LED, Farbe nach Wahl	blinken
1	Powerbank/ 5V Versorgung	Lebensmittel
3	Drucktasten, z.B. Cherry MX Tasten	Drucksensoren
1	Lautsprecher, z.B. 5W@4Ohms	Stimmbänder
1	USB-A-Stecker	Strohhalm
1	Gehäuse	Körper

Zusätzliche Bauteile und Tipps

Überbrückungsdrähte, Platine, Buchsen und Verbrauchsmaterial nach eigenem Ermessen Wie beim “Original”-Projekt; alternativ einen Drehgeber anstelle der Drucktasten kaufen und das Projekt so konfigurieren, dass er statt der Taster ausgelesen wird. Da das System für den Batteriebetrieb optimiert ist, nehmen Sie ein bi-stabiles Relais oder einen JFET-Transistor (mit niedriger Gate-Spannung und niedrigem Source-Drain-Spannungsabfall) für die KeepAlive-Funktionalität, die den zusätzlichen Strom durch die ständig eingeschalteten Relaisspulen vermeidet. Eine billige Powerbank reicht für viele Stunden Betrieb. Alternativ können z.B. 3xAA-Batterien verwendet werden - allerdings macht der Dfmini-Player ordentlich Lärm, wenn die Spannung zu sehr einbricht. Er kann sogar bei wiederholten Neustarts durch Stromstöße zerstört werden, also Vorsicht bei nachlassender Akkuladung.

Testing on Schallberts Blog

CNC Tuning #3

Schritt 3: Optimierung des Pfadinterpreters

Grundlagen: Was ist “Look Ahead Feed”?

Ideal im Gravurbetrieb

Fräspfadtoleranz G64 P*

Pfadverrundung G64 R*

Pfadverrundung bei reduziertem Vorschub G64 S* D*

Pfadvereinfachung G64 Q*

Beschleunigungsfilter G64 F*

Meine Konfiguration für die Hobbyline 4530

Fazit

Und wo ist der Beweis?

CNC Tuning #2

Schritt 2: Tuning der kinematischen Parameter der CNC

Verfahrgeschwindigkeit im Eilgang

Beschleunigung im Eilgang

Elektrische Messwerte

Messaufbau

Ergebnisse

Benchmark Spitzenlast

Mechanische Prüfung

Appelle zum CNC-Tuning

CNC Tuning #1

Warum überhaupt?

Was sind mögliche Nachteile?

Welche Maßnahmen werden nicht diskutiert?

Tuning in drei Schritten

Schritt 1: Besserer G-Code

Aber wie soll ich meinen G-Code vereinfachen?

Beispiel CAD

Beispiel CAM

Aber wie soll ich die Leerfahrten reduzieren?

Und wo ist das Problem mit Rückzügen der Z-Achse?

Wie reduziere ich Wartezeiten?

Hardware Test

Ein neuer Antrieb

Warum extra Tests?

Teststrategie

Teste früh

Teste “von unten nach oben”

Testplan

Ausführung der Tests

Dokumente

GoogleTest Demo

Projekt-Steckbrief

Motivation

Die Welt der “embedded controller”

GoogleTest direkt in PlatformIO verwenden

GoogleTest per GCC einsetzen

MinGW herunterladen und installieren

MinGW konfigurieren

PlatformIO konfigurieren

Tests ausführen

Tipps und Tricks

Repository-Inhalte erklärt

Schnittstelle der Hardware-Abstraktionsschicht

LoopInOut

Modellierte Hardwareabstraktion (mock hal)

Die Testvorrichtung (test fixture)

Der eigentliche Test

Implementierung des Hardwareverhaltens

Gtest Schlüsselkonzepte

Dependency Injection

Hardware-Abstraktionsschicht

Nachteile

Einige weitere Tipps

Schwieriges Thema!

QR-Codengrave

Projekt-Steckbrief

Die Idee

Erste Schritte

Spezifikation

Unbekannte

Programmiersprache

Konzeptphase

Unit-Tests

Der lange Weg zum Produkt mit Minimalanforderungen

Überprüfungen von Wertetyp und -bereich

Persistenz

Fräspfadtoleranz `G64 P*`

Pfadverrundung `G64 R*`

Pfadverrundung bei reduziertem Vorschub `G64 S* D*`

Pfadvereinfachung `G64 Q*`

Beschleunigungsfilter `G64 F*`