Das Windows-Programm „radariq“ besteht konzeptionell aus einem Hauptfenster sowie bis zu 8 „Satelliten“-Dialogfenstern, welche während des Programmbetriebs geöffnet bleiben und wahlfrei angeordnet werden können. Einige dieser Fenster können in der Größe verändert werden. Dieses Konzept ist freizügiger und leichter umzusetzen als „dockable“ Fenster. Alle Fensterpositionen und -größen werden in der Systemregistrierung gespeichert. Steht keine Maus zur Verfügung kann der Fokus zwischen den Fenstern mit F6 oder Strg+Tab gewechselt werden.
Steht die NC-Maschine zur Verfügung, wird deren Schnittstelle uns Baudrate mit dem Menüpunkt „NC — Einstellung“ festgelegt und mit dem Knopf „Verbinden“ aktiviert. Mit dem Menüpunkt „NC — Handbedienung“, im entsprechenden Dialog lassen sich die Achsen mit den Pfeiltasten sowie BildAuf/BildAb im „Jog“ bewegen. Mit den Zifferntasten wird die Jog-Geschwindigkeit eingestellt, Shift+1..9 gilt dann für die Z-Achse.
Sobald eines der drei Editfelder fokussiert ist, ist die Tastensteuerung unwirksam! Hingegen kann eine Zielposition eingegeben werden, die nach 0,5 s Eingabepause angefahren wird.
Das Terminalfenster erlaubt eine Direkteingabe von gcode-Befehlen und grbl-Befehlen. Die Firmware liefert eine Kurzhilfe bei Eingabe von $.
Die Taste 0 löst ein Reset am ATmega328P aus (huch!). Das bewirkt das Nullsetzen der Werkzeugkoordinaten. (Dafür gibt es keinen gcode-Befehl und auch (noch) keinen grbl-Befehl.)
Der Sensor wird mit dem Menüpunkt „Sensor — Reach-Schnittstelle“ konfiguriert, wobei 921600 Baud höchst empfehlenswert ist und die Close-Source-Firmware seit Mai 2024 nur noch mit 1024 Abtastwerten funktioniert. Weniger wäre besser weil dann die Blockrate steigt (das war früher so).
Das Signal wird im oberen Diagramm dargestellt. Typisch ist ein unbrauchbares Einschwingen im ersten Drittel, das sehr gut auswertbare Stück in der Mitte sowie ein ebenfalls brauchbares Stück mit verringerter Amplitude am Ende. Wenn man den Abstand verändert, sieht man, dass sich das Signal verändert, das wie ist jedoch auf den ersten Blick nicht auszumachen.
Mit dem Ankreuzfeld (Checkmark) „Merken“ werden 32 Proben des Block-Signals gemittelt und danach (als 2 KByte) abgespeichert. Zum Ende der Anlernphase verschwindet die Markierung bei „Merken“. Das sollte verwendet werden, wenn der Sensor keinen Reflektor „sieht“! Mit dem Ankreuzfeld „Subtrahieren“ wird das Angelernte subtrahiert. Die Wirkung der Subtraktion lässt nach einiger Zeit nach, sodass nach etwa 1 h erneut angelernt werden sollte.
Um das Gezappel am Anfang zu unterdrücken und Abschneidefehler für die nachfolgende Fouriertransformation zu vermeiden kann der Signalverlauf mit einem „Hann-Fenster“ versehen werden. Aktuell ist es ein (sehr ähnlich aussehendes) Blackman-Fenster.
Mit dem Ankeuzfeld „Visualisierung“ kann die Anzeige zu- oder abgeschaltet werden, letzteres um Rechenleistung zu schonen.
Der erste Ansatz war, im Amplitudenspektrum nach der Fouriertransformation des komplexen Eingangssignals das Maximum zu suchen und davon eine Phasenauswertung zu machen.
Das erwies sich jedoch als unbrauchbar, eine feste Linie L zu verwenden ist völlig ausreichend, und das Q-Signal kann einfach um 1024/4/L Abtastwerte nach links verschoben dem I-Signal hinzugefügt werden. Für das kurze Rohr ist L = 6 am besten.
Daher genügt schließlich ein „Direktmischempfänger“ (= Goertzel-Algorithmus?) in Software zur Signalauswertung. Ohne Fouriertransformation, ohne FFT. Damit wäre selbst ein popeliger 8-Bit-Mikrocontroller des Arduino Uno noch unterfordert. Könnte der Radarsensor auch selber machen…
Sobald im Menüpunkt „Sensor — FFT-Amplitudenspektrum“ ein Ankreuzfeld nach einem Spektrum verlangt, schaltet sie Software in den aufwändigeren FFT-Modus um, um das Spektrum anzuzeigen. Bis zu zwei Spektren können zwecks Gegenüberstellung berechnet und angezeigt werden.
Beim Menüpunkt „Sensor — Phasendetektor“ kann man die auszuwertende Spektrallinie auswählen — oder wie früher das Maximum suchen lassen. Die Anzeige der Phase als Umlaufzeiger macht die Funktion als auch die Empfindlichkeit deutlich.
Schließlich gibt es eine Funktion zur automatisierten Zweipunktkalbrierung zwischen Sensorsignal („akkumulierte“ Phase) und Wegstrecke der Z-Achse. Hier erweist sich die geringe Aktualisierungsrate der grbl-Software als Pferdefuß: Diese ergibt eine deutliche Treppenfunktion in Y-t-Digramm des Hauptfensters.
Erscheint im Logfenster „Phasensprung größer als ±90°“ ist die Verfahrgeschwindigkeit recht hoch, und die Gefahr „übersehener“ Phasenumläufe steigt. Es ist als Warnung zu verstehen. Weichen daraufhin der Weg der Z-Achse der Messmaschine und das Ergebnis vom Sensor um Vielfache des Umlaufweges ab, war's ein „übersehener Phasenumlauf“. Diese Art von Fehler zu vermeiden war das Ziel des gesamten Forschungsprojekts!
Die zeitkritischen Berechnungen laufen allesamt in einem Worker-Thread.
Mit dem Hauptprogramm wird lediglich via statische Variablen sowie (hauptsächlich)
PostMessage()
kommuniziert.
Ebenfalls im Worker-Thread läuft die Abfrage der seriellen Schnittstelle,
nebenläufig durch asynchrone Aufrufe von ReadFile()
bzw. WriteFile()
mittels einer OVERLAPPED
-Struktur:
Vor der Berechnung erhält der Sensor bereits den nächsten Befehl zur Messung,
und während der Berechnung kann der Sensor bereits Daten über die (vergleichsweise lahme)
RS485-Schnittstelle senden.
Vermutlich macht der Konverter das Problem, die Empfangspause zu groĂźzĂĽgig abzuwarten
um das USB-Paket abzuschlieĂźen (= dem PC zu senden),
auf das der Worker-Thread bereits „sehnsüchtig“
mit WaitForSingleObject()
wartet.
Vermutlich läuft die Windows-Software in der ANSI-Version ab Windows 98.
Getestet wurde auf Windows 10 auf einem eher langsamen Barebone-Rechner; sogar der heimische, ĂĽber 10 Jahre alte DELL-Laptop ist schneller.
Als Compiler dienten MS Visual Studio 6 mit Windows2003-DDK
sowie MS Visual Studio 2008 fĂĽr die 64-Bit-Version.
Bei allen(!) Compilern stehen keine brauchbaren C++-Templates zur VerfĂĽgung,
daher wurden std::vector
, std::array
,
std::uniq_ptr
und std::shared_ptr
nachprogrammiert,
hier vom Standard abweichend fĂĽr eine noexcept
-Umgebung.
(Das hat man im C++-Standard schlicht „vergessen“.)
Es bestehen keine Abhängigkeiten zu externen DLLs!
Die Verlagerung aller Zeichenketten in eine Ressourcendatei erlaubt die mehrsprachige Auslegung des Programms. Zurzeit ist es mehr deutsch als englisch.
Das Auswerteprogramm wurde zunächst in Python und denglisch geschrieben. Die Auswertung war vermutlich richtig, aber weil keine grafische Anzeige möglich ist und eine Rechenlastverteilung mittels Threads unklar bleibt, blieb das Funktionsvertrauen im Dunkeln. Aus jetziger Sicht hätte man's vielleicht mit Phyton-Qt hinbekommen. Aber der Aufwand wäre dann kaum geringer als beim Windows-Programm, bei großer Abhängigkeit von Software von Drittanbietern.
Aus jetziger Sicht wäre eine Lösung in LabVIEW zielführend gewesen, da es eine schnelle und bequeme Signal-Plotdarstellung mitbringt. Aber noch mehr als mit Python handelt man sich Portabilitätsprobleme ein, und für Firmen ist LabVIEW unbezahlbar.
Die HĂĽrde unter Matlab und WolframAlpha ist der Zugang zur seriellen Schnittstelle und der Bau eines Benutzerinterfaces.
Wurde zunächst nicht anvisiert wegen:
Wäre im Nachhinein keine schlechte Lösung. Die fehlende Typisierung von JavaScript macht das Debuggen zum Alptraum.