Ofensteuerung

Von einer „alten“ Ofensteuerung (zum Sintern von Keramik) hin zu einer „neuen großen“ und einer „kleinen“ Steuerung. Alle Steuerungen regeln die Temperatur, fahren eine vorgegebene Temperaturkurve ab rund steuern digitale Ausgänge für Gase und Pumpen.

Wie so üblich wurde zunächst aus dem Matschklumpen eine strukturierte Software geschaffen, dann wurde die Hardware strukturiert — und weil das doch recht schwierig ist — eine Miniausgabe davon erstellt.

„Alte“ Ofensteuerung

Ofentemperaturregelung mit Rezeptsteuerung (über Stunden) und Steuerung von 8 digitalen Ausgängen (Relais).

Features der LabVIEW-Software

• Heiz- und Abkühlkurve vorgebbar
• Steuerungsmöglichkeit der Ausgänge nach Zeit und/oder nach erreichter Ofentemperatur, überlappende Steuerbereiche werden unterstützt und dabei stets der Treffer mit der kleinsten Zeitspanne bevorzugt. Tristate-LEDs für gezieltes Ein- und Ausschalten bei überlappenden Ereignissen
• Startzeitpunkt vorgebbar
• Messung und Protokollierung von 3 Temperaturen und 3 Drücken
• Merkt sich alles in der Systemregistrierung, sogar Plotfarben
• Eingebauter einfacher Webserver (Single-Thread) zur Fernüberwachung
• Rezept-Im- und -Export als kommaseparierte Liste, XML oder JSON

Features des Ofens

• Volumen schätzungsweise 20 × 20 × 20 cm³
• Temperaturbereich 25..1100 °C
• Gaszufuhr und Abpumpen möglich
• 3 Temperatur- und 3 Drucksensoren
• Externer Watchdog gegen Software-Ausfall
• Gassensor gegen Lecks:
  • Ausgangspunkt ABUS-Rauchmelder RM10 (Partikelzähler); 9-V-Block herausgerupft und Batteriefach mit Elektronik gefüllt
  • Standard-Schaltkreis MC145012 und zur Auswertung seltsamer (und unnötiger) chinesischer Levelshifter
  • MiCS5524 Kohlenmonoxid-Gassensor dazugebastelt
  • Noch ein rundes 4-poliges Pyrometer MLX90614KSF mit der Aufschrift „aaa5414D14“ dazugebastelt, mit I²C-Businterface
  • Am Arduino ein Industrie-DS18B20 zur Außentemperaturmessung am Ofen, bis 125 °C

Probleme

• Bluescreen nach Stunden: IRQL_NOT_LESS_OR_EQUAL in usbser.sys. Workaround: Arduino abstecken. Er ist funktionslos und liefert nur die unausgewerteten Werte für die Spannung vom Gassensor und die Ofen-Außentemperatur. Das Watchdog-Relais tut nichts (ist nicht angeschlossen).
  Richtiger Workaround: Schnittstelle lesen auf „synchron“ umstellen!
  Gemachter Workaround: COM-Portzugriff via Win32-Funktionen (verringert Abhängigkeit von VISA)
• Mess- und Steuerungstechnik zu teuer für Duplikation; Absturzgefahr. Mein Vorschlag:
  • Arduino Leonardo headless, also ohne Display, Software mit kompletter Rezeptabarbeitung, evtl. automatische Fortsetzung mit EEPROM-Zustand
  • 4-Thermoelemente-Shield, etwa jenes
  • 8-Relais-Karte, etwa das hier
  • Eigenes Shield für Drucksensoren, Gassensor, Schwingungspaketsteuerung, Strommessung (im wesentlichen nur passive Bauelemente)
  • Oder komplett eigene problemangepasste Platine mit ATmega328 oder ATmega32U4
  • Überwachung und Logging mit Windows-PC und LabVIEW-Software, später C++-Software

Neukonstruktion Rauchmelder mit USB

Um „immer mal“ einen Rauchmelder für die Platzierung in Ofennähe parat zu haben, ist es zweckmäßig, diesen mit einem jedermann bekannten USB-Stecker zu versehen und mit HID+WebUSB auszurüsten. Die Geizhalsversion verwendet nicht Arduino, sondern PIC16F1455.

Die Bereitstellung der Betriebsspannung für den Rauchmelder geschieht über eine Spannungsverdopplerschaltung, dessen Rechteckgenerator ein Ausgang des Mikrocontrollers ist. Das bidirektionale Pin 7 des Melders dient zur Abgabe akustischer Warnungen bei Übertemperatur und Gas, d.h. auch ohne Rauch. Über USB und eine Webseite können die Messwerte abgelesen und Alarm-Grenzwerte eingestellt werden. An Stelle der LED kann auch ein Relais sitzen, welches den Rauchmelder zusätzlich zum Frostwächter macht. In dieser Schaltung dient die LED nur als Hilfe zum Erstellen der Firmware.

R6 ist unbedingt erforderlich, damit der Urlader überhaupt einen Power-On-Reset erkennt (und zur Anwendungsfirmware springt). Verwendet wurde der Urlader bootCDC-lvp.hex. Für den Spannungsverdoppler ist C3 unbedingt ein keramischer Kondensator; für die 47 kHz müssen es 470 nF sein. Bei höherer Taktfrequenz geht auch weniger. Hingegen C4 muss ein ziemlich großer Elko sein, weil der Rauchmelder beim Unterspannungs-Test ziemlich reichlich Strom zieht und dann (bei Spannungseinbruch) der Piepser nervtötend alle 1 min piepsen würde. Bei einigen Rauchmeldern ist D1 und C4 bereits enthalten. Solange der Urlader „läuft“ und der Spannungsverdoppler nicht arbeitet, piept der Rauchmelder alle 1 min.

• Firmware (unfertig)
• Zugriff via WebUSB (unfertig)

Erste Schritte

„Große“ Steuerbox

Schaltplan.

Von einem Arduino wurde Abstand genommen, da unvorteilhaft: Frisst Platz, muss für Self-Power-Betrieb frisiert werden, teuer. Stattdessen wurde ein ATmega32U4-Chip vorgesehen. Es wurden Bestückungsvarianten freigehalten für:

Ofensteuerungs-Äpp (Silberbox).

231006: Die Äpp und die Firmware wurde auf 32-Bit-Zeistempel mit Millisekunden-Auflösung aufgebohrt. Ziel ist eine Betriebsdauer > 18 h. Sie liegt nun bei 49 Tagen. Die Änderungen sind erheblich, unter anderem weil das Eingabe-Element <input type="time"> nicht für über 24 h funktioniert. (Es ist nur für Uhrzeiten gemacht.)

231010: Die beiden DIL-Schalter der Steuerbox, die schon lange als 2 Tasten verlängert herausgeführt wurden, sind nun in eine extra Box gewandert. Zur Erinnerung, die beiden Knöpfe haben folgende Funktion:

• Grün = HWB/PE2 = Start / Stopp / Fortsetzen(?) des Programmablaufs
• Rot = Reset = Rücksetzen des Mikrocontrollers und damit Stopp + Zurückspulen des Programmablaufs
• Rot + Grün (dabei erst Rot, dann Grün loslassen) = Verbleib im Urlader des Mikrocontrollers, zum Firmware-Update mittels make flash

Damit erwiesen sich die DIL-Schalter als weitere Fehlkonstruktion der Silberbox, 2 Taster + 1 Anschluss zum Verlängern sind einfach besser. Neben dem vergessenen ISP-Anschluss und der Huddelei mit dem Thermoelement-Wandler.

Überlegungen zur A/D-Wandlung

Der Vorteiler 128 ergibt sich aus der Forderung, den A/D-Wandler mit 50..200 kHz zu takten. Der Teiler 13 ergibt sich bei kontinuierlicher A/D-Umsetzung. Somit liegt die Summenabtastrate bei etwa 10 kHz. Die Messstellen mit der höchsten effektiven Abtastrate sind die LEM-Stromwandler, um die Kurvenform des Stroms beim Phasenanschnitt zu erfassen. Schnelle A/D-Wandlung wird auch benötigt für Beschleunigungs- und Kraftmesszellen, die am INA126 angeschlossen sind. Temperaturmessungen sowie Gasdruck sind hingegen nur langsam erforderlich. Dabei läuft die Temperaturmessung für Thermoelemente am A/D-Wandler des ATmega32U4 vorbei und wird parallel dazu im MAX31855 abgewickelt.

Wie man sieht ergeben sich Fünfergruppen mit folgenden Abtastzeiten und -frequenzen:

Ergibt eine Gesamtpuffergröße von 4×100 + 4×20 + 5×4 = 500 Samples = 1000 Bytes, bei Doppelpufferung 2000 Bytes, was die RAM-Kapazität des Mikrocontrollers schon „ganz gut ausfüllt“. Dabei diktiert der A/D-Wandler die Abholrate von 52 ms entsprechend ≈ 19 Hz und damit die Aktualisierungsrate der Weboberfläche.

Die Nettodatenrate allein für die A/D-Daten entspricht genau der Summenabtastrate von ≈ 10 kSa/s, somit ≈ 20 kByte/s. Für USB kein Problem.

Nutzung der 6 freien Bits

Um den RAM-Verbrauch zu senken kann man den Datenstrom des 10-Bit-A/D-Wandlers auch ohne Arrayzuordnung zum PC leiten. Damit das Javascript-Programm die Werte auseinanderklamüsern kann, werden die 5 MSB zur späteren Zuordnung genutzt:

Das letzte freie Bit wird für das Vorzeichen (bei INA126) benötigt. Eine Entscheidung wird noch gefällt.

Einbau

3 Jahre nach Entwicklung und Bestückung erfolgte nun endlich die Inbetriebnahme am realen Ofen. Die Umgebungsschaltung, bei der diese Ofensteuerung eingebettet ist, sieht so aus:

Dabei ergaben sich folgende Probleme:

• Die gemessene Temperatur des Ofens liegt 20 K zu tief.
• Die gemessene Temperatur zappelt stark und springt beim Start der Ofensteuerung um etwa 10 K nach oben.
• Starkes Überschwingen der Regelung und Ursachenforschung machen die Anzeige der internen Regelparameter erforderlich. ✔️
• Die hochgesteckten Ziele mit Strom- und Kurvenformanzeige mussten pragmatisch wegen Termindruck fallengelassen werden, und die Firmware wurde kurzerhand in Ofen3 umbenannt. ✔️
• Die Steuerung per WebUSB ist nunmehr die gleiche wie bei der Steuerung in der Plastebox: Nur 8 statt 16 Relais können gesteuert werden sowie viele weitere Einschränkungen und Vereinfachungen.
• Der Ofen löste den Fehlerstrom-Schutzschalter 40 mA (= Personenschutz) aus. Daher wurde die Umgebungsschaltung umverdrahtet und der Ofen, aber auch die Pumpe und die Entrauchung laufen über einen gesonderten Fehlerstrom-Schutzschalter mit 300 mA (= Geräteschutz). ✔️

Um den Berührschutz bei geöffnetem Ofendeckel zu gewährleisten wäre der Einsatz eines Deckelkontaktes sinnvoll, der das Schütz betätigt. Um dafür Kleinspannung verwenden zu können, Ersatz des Schützes durch eins mit 12 V= Spulenspannung. Es wurden entsprechende Beschriftungen zur Handlungsanweisung angebracht.

Es ist noch angedacht, das HID-Interface unter LabVIEW anzusprechen, um die gewohnte Benutzeroberfläche weiter nutzen zu können. Das bisherige LabVIEW-Programm, die Relaiskarte, ein USB-Hub, ein USB-Seriell-Wandler, eine NI-USB-Messkarte, ein NI-USB-Termoelement-Konverter und eine Menge Starkstrom-Installationsmaterial wurden obsolet: Hinter der Steuertafel sieht es nun richtig aufgeräumt aus!

Mini-Ofensteuerung

Gewissermaßen als Starthilfe für die „große“ Ofensteuerung soll „mal eben schnell“ eine universelle Heizprozess-Steuerung ohne Gassteuerung implementiert werden. Es genügt 1 Thermoelement und 1 Heizungsrelais. Letzteres war bereits in einer Steuerkiste mitsamt 24-V-Netzteil vorhanden. Hinzugefügt wurde ein Arduino Pro Micro von ebay, ein (gefundener) Schaltregler für 5 V (ein MC34063 hätte es für die wenigen mA auch getan) und ein Thermoelement-Modul mit MAX6675. Für das 24-V-Relais und 6 digitale 24-V-Ausgänge der Renner ULN2003.

Gesteuert wird der beliebige Ofen per Schwingungspaketsteuerung (allerdings mit mechanischem statt Festkörperrelais) mit 1..4 s Periodendauer, um die Kontakte zu schonen. Zum Festlegen der Regelungsparameter und der gewünschten Temperaturkurve sowie Prozessdauer wird ein PC mit Windows-Programm via USB angeschlossen. Start/Stopp sowie der Heizvorgang an sich läuft unabhängig mit oder ohne PC. Da kein Raspberry verbaut wurde, ist das Ganze sehr zuverlässig auch bei Stromausfällen.

Die gesamte USB-Kommunikation basiert auf der HID-Geräteklasse. So wird kein Treiber benötigt. Die Firmware arbeitet ausschließlich mit Integerzahlen und kommt ohne Flash fressende printf()/scanf() aus. Nein, die Firmware baut nicht aufs Arduino-Framework auf! Sondern macht alles selber.

Der letzte Schrei ist nun die Erweiterung der Firmware um ein WebUSB-Interface und eine Äpp, die im Browser läuft. Geeignete Browser sind derzeit Google Chrome und Microsoft Edge.

Ofensteuerungs-Äpp (Plastebox)

Ausfall 220609: Keine USB-Konnektivität. Ursache: USB-Micro-Buchse nochmals von Platine abgerissen, wohl heftig am Kabel gezogen. Reparatur: Diesmal USB-Kabel direkt an den 22-Ohm-Widerständen, am Masseanschluss und an der Sicherung angelötet sowie mit Zugentlastung versehen. Sollte halten, macht jedoch den Pro Micro schwerer austauschbar.

Dateiliste

Computer-Algebra

Geometrie-Routinen zur Plotdarstellung sowie zum Maus-Treffertest. Da Drag-und-Drop im Plot nur bei weniger als 100 sichtbaren Punkten funktionieren sollte, sollten nur Grafen (Punktlisten) untersucht werden, die bei aktuellem Zoom auf eine derart reduzierte Punktzahl kommen.

Maus in Punktnähe

Trivial: r = |mousepos - pointpos| = √(mouse.x-point.x)² + (mouse.y-point.y)², in Javascript Math.hypot(mouse.x-point.x,mouse.y-point.y)

Maus in Streckennähe

Nicht so trivial: Sei A = Streckenanfang, B = Streckenende, C = Mausposition:
B -= A, C -= A, r = |B|, also B.x-=A.x; B.y-=A.y; C.x-=A.x; C.y-=A.y; let r=Math.hypot(B.x,B.y);
Distanz zur (unendlichen) Geraden: (B.x*C.y - B.y*C.x)/r
Längsanteil zur Strecke, 0 = Anfang, 1 = Ende, <0 = davor, >1 = dahinter: (B.x*C.x + B.y*C.y)/(r*r)

Temperatur-Logger

Preiswerte Temperaturaufnehmer, die das MCPS (??) und die teure und schwerfällige Yokogawa-Kiste ersetzen. Für USB, treiberlos, etwa 8-kanalig, je 2 Exemplare.

Da sich

• Thermoelemente,
• Thermowiderstände und
• digitale Sensoren

Für Thermoelemente

Steckbrief: 2 Exemplare 8-Kanal-Temperaturlogger für Thermoelemente Typ K, Abtastrate 1 Sa/s/Kanal, Logdauer mehrere Tage; PC-Unterstützung. Daher genügt ein USB-Interface, das Messdaten direkt (ohne zu puffern) zum PC durchreicht. Irgendein Programm (WebUSB = JavaScript, LabVIEW, C++, Python, Matlab …) nimmt die Daten entgegen und speichert als .csv oder (vielleicht besser) Matlab-Matrix (.mat).

Angedachte Realisierung: MAX31855 mit 4051-Analogsignalschalter und irgendein 3,3-V-USB-Mikrocontroller. Dabei genügt ein ATtiny44 mit V-USB und 3,3-V-LDO, typischerweise LP2950-33.

Tatsächliche Realisierung: Wenn Datenlogger in Matlab, dann muss es eine serielle Schnittstelle sein (gähn 🥱). Also Full-Speed, kein V-USB. Also PIC16F1454. Das Loggen (ohne Zeitstempel) ginge dann mit einer simplen Kommandozeile: copy com8 Dateiname.csv, Linux 🐈 /dev/ttyS0 > Dateiname.csv oder so ähnlich. Eine Verwandt­schaft besteht mit dem Frequenzmesser zur Durchflussmessung. Der Mikro­controller generiert an einem freien Ausgang eine Wechsel­spannung zur Bereit­stellung einer negativen Hilfs­spannung für den Analog­multiplexer. Mal sehen ob dieser dadurch besser funktioniert. Die LED D1 ist vor allem zum Debuggen, da das Pin 8 = RC2 nicht frei verfügbar ist sondern vom SPI als serieller Datenausgang in Beschlag ist.

Hier kommt das (bereits herumliegende) Hammond-Flanschgehäuse 1590AFL (93×39 mm) zum Einsatz, welches um 9 mm heruntergefräst wird: Gesamthöhe nun 22 mm. Die UNC-Gewinde müssen dazu etwas nachgeschnitten werden, damit die Schrauben noch passen.

Der seltsame Spannungsregler IC4 = LDCL015-33 wurde in einer alten Messe­muster­verpackung gefunden und „musste mal weg“. Er ist pinkompatibel zum bekannteren MIC5219.

Pufferung: Da der eingebaute USB-Seriell-Konverter „weiß“, wann Daten abgeholt werden und wann nicht, kann der Mikrocontroller die bis dahin noch nicht abgeholten Daten in einen (Flash-)Ringpuffer ablegen und „en bloc“ liefern (= sich auskotzen). Das vermeidet Lücken im Protokoll durch Windows-Reboots. Weiterhin kann durch ein (wie auch immer geartetes) Abfrage­kommando zwischen ASCII- und Binär­ausgabe umgeschaltet werden — sowie die gesamte Historie abgefragt werden. Zudem erscheint das Einstellen der Summen­abtast­rate sinnvoll.

8-Thermoelemente-Äpp

Stolpersteine

• PIC-Assembler ist voller Stolpersteine! Aber der C-Compiler ist auch nicht gerade Luxus. Die wichtigsten:
  • Mit banksel aufpassen! Lieber einmal zuviel verwenden, Platz ist hier reichlich.
  • Subtraktionsbefehle, sowohl subwf als auch sublw sind teuflisch!
    • subwf reg,w entspricht w = reg - w (invertiert w) und c = reg >= w
    • subwf reg,f entspricht reg -= w und (genauso) c = reg >= w
    • sublw k entspricht w = k - w (invertiert w, daher ist sublw 0 eine Negation) und c = k >= w
    • Will man eine Konstante von w subtrahieren, nehme man gefälligst addlw -k!
    Und das Übertragsflag ist genau verkehrtherum. Daher die eigenen Makros skpb skpnb brb brnb.
  Dass weder gpasm noch mpasmx automatisch banksel und pagesel generieren und Sprünge anpassen (bra durch goto ersetzen) ist ein Armutszeugnis für die Assembler, wobei gpasm durch seine gigantische Größe (über 5 Megabyte mit DLL, ohne Include-Dateien!) unangenehm auffällt und mpasmx mit dem Popup-Fenster nervt. Nirgends ist irpc implementiert. Die Makroverarbeitung in der LST-Datei ist unpraktisch: Wünschenswert wäre die Kombination keine Makroexpansion aber trotzdem Kodeausgabe.
• Da der MAX31855 (anscheinend, laut Datenblatt) asynchron wandelt muss man nach dem Umschalten des Analogmultiplexers zwei Umsetzzeiten warten. Da diese mit max. 100 ms angegeben ist, kommt man so auf eine Summenabtastzeit von 100 ms × 2 × 8 = 1,6 s. Daher musste die Summenabtastrate von ursprünglich angedachten 1 Hz auf 0,5 Hz (für alle 8 Eingänge) verringert werden. Vielleicht mache ich noch einen 4-Kanal-Modus mit 1 Hz Summenabtastrate.
• Schade dass die PIC beim Timer1 sowohl keinen CTC-Modus anbietet als auch keinen atomaren Zugriff auf das Zählregister realisiert, wie man das vom AVR gewöhnt ist. So ist die Software-CTC nicht ganz exakt (Zählimpulse können flöten gehen); die Variante mit dem Softwareteiler an Timer2 (von 100 kHz herunterteilend) ist exakt aber schiebt alle 120 Befehlstakte eine ISR ein. Alternativ bietet sich das Zählen von USB-SOF an.
• Das ChipSelect-Signal hätte man vielleicht auch von RC2 = SDO herleiten können. Es stellt das Bit 7 des Schieberegisters dar. Da aber dann nicht klar ist, ob es mit dem letzten Bit (als Sonderfall) Low bleibt, ist es doch besser, dass da nur die unkritische LED angeschlossen ist.
• Mit GUIDs und WebUSB-Deskriptoren herumhantieren erleichtete jene Webseite erheblich.
• Mit der Kombination CDC + WebUSB (in dieser Reihenfolge) kommt Edge unter Windows 11 nicht klar. Das Vertauschen der Reihenfolge (also WebUSB + CDC) brachte die Lösung. Unter Ubuntu funktioniert's trotzdem erstmal nicht. CDC mit irgendetwas zu kombinieren erfordert ohnehin einen seltsamen zusätzlichen Deskriptor, der IMHO erst ab Windows 8 verstanden wird. Jedenfalls nicht mit Windows98, Windows 2000 und Windows XP. Aber solche Altsysteme sind in der Uni ausgestorben bzw. ausgetrieben worden. Wenn's partout laufen muss, geht's dann halt nur seriell, und man muss auf WebUSB verzichten.
• WebSerial ist bei Chrome, Edge und Opera (jeweils nur Desktop) verfügbar und macht WebUSB prinzipiell obsolet.
• 230703: EMV-bedingte Abstürze (?) der seriellen Verbindung werden auf Verdacht mit R5 bekämpft.

Dasselbe für Pt100

So einfach ist das nicht! Weil man bei Thermowiderständen besser mit einem Vierdrahtanschluss arbeitet sind diese Sensoren deutlich umständlicher zu handhaben. Pt100 ist ohnehin old-school, wenn möglich sollte man zu Pt1000 (1 kΩ bei 20 °C) umschwenken, weniger Eigenerwärmung, geringerer Stromverbrauch. Diese gibt es in klitzekleinen SMD-Gehäusen, aber man darf sie nicht (wie Dehnmessstreifen) starr aufkleben, da sie sonst einen parasitären Dehnmessstreifen-Effekt zeigen.

Dafür gibt es den maßgeschneiderten Chip MAX31865. Diesen gibt es entweder einzeln im QFN20-Gehäuse mit (IMHO) 0,65 mm Pitch oder als Arduino-Baustein mitsamt Pegelwandler und Spannungsregler. Auch wenn die Lochraster-Verdrahtung irre aufwändig ist, bleibe ich auch diesmal dem Lochraster treu und verwende das Arduino-Teil von Ebay. Diesmal müssen vier Analogmultiplexer 74HC4051 vorgeschaltet werden. Das praktische Konzept mit dem superbilligen Mikrocontroller PIC16F1454 (mit Urlader vorprogrammiert) wird beibehalten.

Hier kommt das Hammond-Flanschgehäuse 1590BFL (112×60 mm) zum Einsatz, welches um 9 mm heruntergefräst wird: Gesamthöhe nun 22 mm. Die UNC-Gewinde müssen dazu etwas nachgeschnitten werden, damit die Schrauben noch passen.

Einfacher für DS18B20

Für einen Temperaturbereich von -55 .. +125 °C tun's auch die viel leichter anwendbaren DS18B20 (parallelschaltbare Temperatursensoren mit A/D-Wandler und OneWire-Interface im TO92-Gehäuse), wenn das Gehäuse klein genug ist. Das ist hier der Fall. Das praktische Konzept mit dem superbilligen Mikrocontroller PIC16F1454 (mit Urlader vorprogrammiert) wird beibehalten.

An den beiden Schraubklemmsteckern können zwei Gruppen von DS18B20 angeschlossen werden, oder mit einer Firmware-Modifikation kann an einem von beiden ein Schaltsignal, bspw. bei Übertemperatur, ausgegeben werden.

Hier kommt das (bereits herumliegende) Hammond-Flanschgehäuse 1590LBFL (51×51 mm) zum Einsatz, welches um 9 mm heruntergefräst wird: Gesamthöhe nun 22 mm. Die UNC-Gewinde müssen dazu etwas nachgeschnitten werden, damit die Schrauben noch passen. Der quadratische Gehäusedeckel kann mitsamt Schaltung um 90° zu den Flanschen gedreht werden, wenn das zum Einbau besser passt.

Eine eventuelle Verpolung der Temperatursensoren wird dadurch erkannt, dass bei Busruhe ein Kurzschluss nach Masse besteht. Dieser wird als solcher erkannt, bevor das betreffende Portpin zum Ausgang umgeschaltet wird. Damit bleibt der Strom vom 4,7-kΩ-Pullup mit 1 mA so klein, dass nichts kaputt geht.

Es ist durchaus eine gute Idee, von den DS18B20 nicht allzu viele parallel zu schalten, da diese nur bei Busruhe (sicher) die Temperatur messen und dafür bei maximaler Auflösung eine knappe Sekunde (!) benötigen.

Wenn man sich umsieht, werden üblicherweise Sensoren mit DS18B20 mit drei Anschlüssen angeboten und (anscheinend) angeschlossen. Dabei verliert man den Verpolungsschutz und gewinnt:

• Ein Ready-Signal wenn Konversion beendet,
• Funktionssicherheit im Temperaturbereich 100…125 °C.

Kamera

Was macht man mit einer ESP32-CAM? Abgesehen von der Verwendung der unveränderten Anwendungssoftware, der WLAN-Kamera (für die Anwendung im Heimnetz) möglicherweise mit „Knipsfunktion“ auf die Mikro-SD-Karte fallen mir immerhin zwei Anwendungsfälle ein, die einen erheblichen Eingriff in die Firmware erfordern:

• WLAN-Kamera für einen Versuchsstand in der Laborhalle (eben einen Brennofen) zur Beobachtung aus der Ferne (Büro oder Home-Office). Dazu muss sich die Kamera in die universitäts­eigene Infra­struktur (eduroam) oder ähnlich einwählen können. Weiterhin ist die Übertragung der Videodaten per WebSocket angeraten; die einbettende Webseite kann vom Webserver der Universität kommen. Als Extra kann die Kamera einen Alarm bei erheblicher Änderung des Bildes melden (Feuer oder Diebstahl).
• Lokale Positionsbestimmung eines Modellfahrzeugs anhand von Sichtmarken. Hier kommen ArUco-Marker 6×6 in Betracht. Die Firmware macht in diesem Fall Bilderkennung und meldet die vergleichsweise geringe Datenmenge an gefundenen Koordinaten per serielle Schnittstelle an den Hauptrechner. Der Hauptrechner braucht wesentlich weniger Rechenleistung und kann ein beliebter, Energie sparender 8-Bit-Typ sein. Mehrere Kameras sind dann kaum ein Problem, und das Verfahren merzt das Problem des ESP32 aus, zu wenig Ein/Ausgänge zu haben.

Ressourcen über hardwarenahe Programmierung sind dünn gesät. ESP32 Bare Metal vielleicht, der Installationsaufwand ist trotzdem riesig. Leider hat sich Espressif auf CMake und Python als zwanghafte Teile der Entwicklungsumgebung festgenagelt, was mich als Makefile-Auskenner elend ausbremst. Für mich ist ESP32 erst dann „Bare Metal“ wenn nur noch gcc und make und ein Flashprogramm (als Echse) nötig sind.

eduroam-Webcam

Entfällt! Genau dafür gibt es das WLAN tuc-special, bei der man den Zugang bei bekannter Ethernet-ID beim URZ beantragt. Damit verhält sich das Universitäts-WLAN etwa so wie ein heimisches.

Trotzdem wäre es hilfreich, den Datenstrom auf WebSocket auszugeben und die feilgebotene Webseite aufzuhübschen. Es wäre nicht schlecht, wenn eine Client-Webseite mehrere derartige Webcams beobachten kann.

Der Videostream erscheint als MJPEG auf http://host:81/stream. Sobald man diesen angestoßen hat. Leider ist das Bild (warum auch immer) kleiner als die ausgewählte Kameraauflösung, sodass die Kamera nicht so recht bewertet werden kann. Auch handelt es sich mit MJPEG nicht um ein modernes Videostream-Format, welches man in den HTML5-<video>-Tag packen kann. Aber es ist bereits eine erhebliche Softwareleistung des ESP32-CAM, jedes Bild als JPEG zu komprimieren.

Nach einiger Fummelei entstand dieses Kamera-Projekt im Arduino 2.0.1. Dieses generiert keine Webseite sondern nur den Kamera-Stream als MJPEG. Wiederum nur für 1 Client. Es wird kein PSRAM erkannt. Da ist ein 8-beiniger APS6404L-3SQR (8 MByte via SPI/QSPI) drauf. Die Adresse des WLAN-Routers wird beim Hochlauf oder bei Verbindungsproblem via serielle Schnittstelle erfragt, wobei ein (für Arduino viel zu schicker und unnützer) Zeileneditor zum Einsatz kommt. Idealerweise lässt man auf der seriellen Schnittstelle ein PuTTY laufen. Wie gewünscht werden die WLAN-Zugangsdaten abgespeichert.

Die Kamera ist einsetzbar, läuft aber noch ohne Konfigurationsmöglichkeit (Auflösung + Framerate) und - noch schlimmer - mit angezogener Handbremse (kein PSRAM) und auf halber Kraft (ohne zweite CPU). Für den Zugriff auf tuc-special muss man sich im gleichen Subnetz befinden.

Ich habe etwas durcheinandergeworfen: Einerseits gibt es die (zuerst getestete) Kamera-Äpp, die so elend plump zu bedienen ist, und dann gibt es den reinen VideoBilder-Stream-Generator. Beide Äpps liefern mangels (erkanntem) PSRAM ein zu kleines Bild. Obendrein werde ich von dem Umstand ausgebremst, dass der Firmware-Download mit dem heimischen Dell-Notebook mittendrin versagt. Wacklige Versorgungsspannung? Auf Arbeit funktioniert das mit den dortigen Barebones einwandfrei.

Heute zum Nikolaustag 2022 geht endlich der PSRAM: Nachdem ich das ganze Arduino-Geraffel nochmal unter Windows installiert habe (weil das Linux neuerdings dazu tendiert, immer häufiger abzustürzen und kaum eine Stunde(!) durchhält), gab es weitere Tools-Menüpunkte, u.a. die das Debug-Level und die Flash-Aufteilung betreffen. Ob es daran liegt oder nicht, ich konnte die (meine) Quelle damit übersetzen, flashen, und voilà, es meldet PSRAM vorhanden (juhu) und volle Bildgröße! Angezogene Handbremse gelöst, jetzt noch den zweiten Topf aktivieren und (v.a. für die Bilderkennung) nutzen. Kamera-Konfiguration fehlt auch noch.

Daraufhin habe ich mich mal in das Thema Multicast eingelesen. Einerseits muss die URZ-Infrastruktur (hier: tuc-special) Multicast zulassen. IPv4 oder IPv6 erscheint egal, IPv4 erscheint einfacher. Wie man's für IPv4 in C programmiert steht da auf deutsch beschrieben. Es ist aber zu befürchten, dass man dazu einiges in den Espressif-Sourcen anpassen/einbauen muss, damit das klappt. Interessant ist auch, wie Multicast im Ethernet funktioniert. Leider sieht es auf der Browserseite mau aus, weil per JavaScript kein UDP empfangen werden kann. Schade. Der gängige Umweg dafür ist ein Python-Hilfsprogramm, das die UDP-Pakete in WebSocket eines lokalen Webservers umpackt; das kann dann per JavaScript weiterverarbeitet werden. In jedem Fall muss das Konzept mit dem HTTP-Header aufgegeben werden, da sich Clients (hier: Videobetrachter) jederzeit einhängen können dürfen und eine Modifikation der Bildgröße und Bildrate alle Teilnehmer betrifft (logisch!).

ArUco-Finder

Bisher kommt dafür ein Raspberry Pi mit Weitwinkel-Kamera zum Einsatz. Aber mit dem Raspberry auf einem Fahrzeug fangen die Probleme an:

• Bootet viel zu lange, langes Warten auf Einsatzbereitschaft
• Möglicher Datenverlust (Crash der Mikro-SD-Karte) beim Bordspannungsausfall, teure und Platz fressende USV erforderlich
• Viel zu energiehungrig, frisst 0,6 A, dazu das WLAN-6-Modul weitere 0,4 A.

Hinzu kommt, dass der Raspberry dazu verleitet, vorhandene Software zur Bildverarbeitung unverändert zu nutzen — und dann reinzufallen, etwa mit Genauigkeits- und Latenzproblemen. Besser ist es stets, jeglicher Software auf den Grund zu gehen, noch besser, sie neu zu schreiben: Github ist nicht mehr als eine Softwaremüllhalde. Zur Bewältigung der Datenmenge durchaus in Assembler.

Für ArUco-Erkennung gibt es bereits diese Lösung in JavaScript.