Ofensteuerung

• 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

• 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

• 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

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⚓

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.

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:

Schaltplan
Schalttafel
Verdrahtung

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!

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

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)

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

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.

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.

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!).

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.