Hallo Leser, beim immerwährenden Basteln an kleinen oder großen Werkzeugmaschinen bin ich (beim Projekt Ofensteuerung) zu dem Schluss gekommen, dass die Ausgestaltung des Mensch-Maschine-Interfaces (auch Benutzerschnittstelle oder HMI = Human Machine Interface im Fachenglisch) die größte Arbeit macht. Das Steuern der Maschinenseite (hier: Keramik-Brennofen, Fräsmaschine, Innenloch-Kreissäge, Drahtsäge, Waschmaschine für Wafer, VR-Simulator für Hammereinschläge usw.) ist vergleichsweise einfach.
Mein Mikrocontroller-Favorit ist derzeit ATmega32U4 oder, für mehr Rechenleistung, STM32F103 oder STM32F407. Dabei implementierte ich stets ein USB-Device mit WebUSB-Interface (= treiberloser Zugang für PCs UND Smartphones) sowie eine passende Webseite („Äpp“) auf dem Webserver der TU Chemnitz. Die Maschine benötigt eine hohe elektrische Leistung, daher ist das USB-Device in der Regel „self-powered“ und benötigt VBUS allenfalls zur Präsenzerkennung und zur Speisung des chip-internen Pullup-Widerstandes an D+. Die Äpp benutzt ausgiebig JavaScript und stellt Prozessparameter (bspw. Temperatur) als große, von Ferne ablesbare Zahlen sowie grafisch in einem Zeitdiagramm dar, ermöglicht alle Einstellungen und Programmierungen. Keine Webhostkommunikation (= läuft vom Cache) und keine Cookies. Maschinen-Einstellungen und Prozessabläufe werden im EEPROM oder Flash des Mikrocontrollers gespeichert, nicht im Local Storage der Äpp. Nur bei der Fräsmaschine kommt der G-Code von einer Datei hereingestreamt. Um das so nervige Problem von GRBL und der allfälligen Synchronisation kümmert sich USB von selbst: Der Verzicht auf altmodische Schnittstellen macht's möglich.
In vielen Fällen benötigt man ohne diese HMI allenfalls einen Startknopf. Dann geht der Ofen, die Waschmaschine oder die Drahtsäge einfach das zuletzt abgearbeitete Programm noch einmal durch. Bei Maschinen, die einen feinfühligen Jog-Modus benötigen, hängt am Mikrocontroller noch ein Inkrementalgeber sowie ggf. weitere analoge, quasianaloge oder digitale Eingabegeräte, bspw. ein Fußpedal.
So weit, so gut, das funktioniert alles prima seit Jahren. Ein Renner, der Schule machen sollte. Derzeit mit jeweils einem dazu abgestellten Windows-PC.
Beim Betrieb mit Smartphone stellt sich — abgesehen von der Bildschirmgröße und der notwendigen Umgestaltung der einen oder anderen Äpp — das Problem, dass man jenes auch aufladen können muss. Die gängige Lösung für Kommunikation UND Laden ist die Verwendung eines PCs. Das beißt sich allerdings mit WebUSB und Device-Only-USB-Geräten. Und dafür OTG implementieren erscheint mir zu aufwändig, falls das überhaupt funktioniert.
Die Rettung naht: USB-C! (Leider nicht für Uralt-Smartphones.) So wie ich herausgefunden habe, ist bei USB-C die Host-Device-Richtung von der Stromversorgungsrichtung entkoppelbar. Dazu muss das Smartphone als auch das USB-Device eine USB-C-Buchse haben und ein einigermaßen vollbeschaltetes USB-C-C-Kabel verwendet werden. Im Standardfall: USB-Device = Strom-Konsument muss CC1 und CC2 je mit einem Widerstand 5,1 kOhm nach GND beschaltet sein. Im Sonderfall: USB-Device = Strom-Lieferant muss CC1 mit einem lieferstromabhängigen Widerstand (im Bereich 10 kOhm) gegen VBUS beschaltet sein, um die Strom-Lieferfähigkeit mitsamt Stromstärke anzuzeigen. Mir genügen hierbei 5 V; Spannungsumschaltung ist nicht vorgesehen. CC2 ist entweder frei zu lassen oder — wenn vorhanden — mit Plus eines LiIon-Akkus direkt zu verbinden.
Ist das so richtig? Muss das USB-Device als Strom-Lieferant einen Schalter implementieren, der VBUS speist? Und wenn ja, wann ist dieser einzuschalten? Müssen Spannungspegel an CC1 und CC2 bspw. per A/D-Wandler gemessen werden? Wie geht ein Smartphone vor, um das Laden zu aktivieren?
Wäre das alles gelöst kann ein altes Smartphone an der Maschine verbleiben und seine Nutzungsperiode vor dem fälligen Recycling verlängern. Und es ist im Fehlerfall kinderleicht tauschbar, im Vergleich zu HMIs wie man sie von sonstigen Werkzeugmaschinen kennt.
Interessanterweise gibt es von der USB-C-Buchse eine 12-polige Version zu kaufen, die alle notwendigen Kontakte dafür herausführt und mit Lötkolben lötbar ist: Einreihige, nach Bestückung sichtbare und damit revisionierbare SMD-Kontakte. Diese reicht für alles außer USB jenseits 480 MBit/s. Also für alle Bastelprojekte dieser Art. Jaja, 0,5 mm Pitch ist schon arg eng, da kann man vom ATmega32U4 auch die QFN-Version nehmen: Hat den gleichen Pitch – aber ist nicht revisionierbar: Keine Stummelbeinchen und das olle PowerPad.
Jaja, viel Text. Bitte vor dem Kommentieren genau durchlesen.