MIGAL.CO Sensorbox – Schweißdaten, mit denen Sie arbeiten können
Die MIGAL.CO Sensorbox misst, was im Lichtbogen wirklich passiert: Schweißstrom, Lichtbogenspannung, Drahtvorschub und Schutzgasdurchfluss – synchron, 5.000-mal pro Sekunde, an jeder MSG- oder WIG-Schweißanlage, unabhängig vom Hersteller. Sie wertet die Daten direkt auf dem Gerät aus und stellt sie über den Browser, industrielle Schnittstellen und unsere Software bereit.
- Prozesssignale auf einer Zeitbasis – Strom und Spannung, mit den optionalen Sensoren zusätzlich Drahtvorschub und Gasdurchfluss, in einem gemeinsamen, NTP-synchronisierten Zeitraster
- Arbeitet eigenständig – integriertes Web-Dashboard, Aufzeichnung auf microSD, kein PC und keine Cloud nötig
- Offene Schnittstellen – MQTT, OPC UA, Modbus TCP, REST und ein schneller UDP-Rohdatenstrom
- KI-Qualitätsüberwachung auf dem Gerät – Einlernen von Gutteilen, Ampelbewertung jeder Naht
- Herstellerunabhängig nachrüstbar – Anschluss an den Schweißstromkreis; optionale Sensoren für Drahtvorschub und Gasleitung
Wählen Sie Ihre Anwendung
Alle drei Ansichten beschreiben dieselbe Box – Hardware und Firmware sind identisch, nur die Software drumherum unterscheidet sich.
Produktion & Qualität
Wissen, wie jede Anlage schweißt – und es belegen
Sie müssen kein Lichtbogenphysiker sein, um die Sensorbox zu nutzen. Anschließen, Browser öffnen, und Sie sehen, was Ihre Anlagen tun. Mit RoboCenter laufen alle Sensorboxen und Schweißanlagen Ihres Werks auf einem Bildschirm zusammen – mit Historie und Berichten für Audits und Kunden.
Transparenz statt Bauchgefühl
Strom, Spannung, Drahtvorschub und Gasdurchfluss jeder Anlage – live und als Verlauf. Abweichungen werden sichtbar, bevor sie zu Ausschuss werden.
Nachweis für jedes Bauteil
Jeder Messwert hat einen Zeitstempel und lässt sich Auftrag, Bauteil oder Naht zuordnen. Ideal für Qualitätsdokumentation, Audits und Reklamationen.
Gas- und Drahtprobleme früh erkennen
Zu wenig Schutzgas, ein rutschender Drahtvorschub oder ein verschlissenes Kontaktrohr zeigen sich in den Daten – lange bevor man es der Naht ansieht.
Passt zu Ihren vorhandenen Anlagen
Herstellerunabhängig nachrüstbar: Die Sensorbox misst direkt im Schweißstromkreis. Ein Eingriff in die Stromquelle ist nicht nötig.
Kein IT-Projekt
Die Box arbeitet eigenständig mit eigenem Web-Dashboard. Die Daten bleiben in Ihrem Netzwerk – keine Cloud, kein Abo nötig.
Verbrauch auf einen Blick
Lichtbogenzeit, Energie, Draht- und Gasverbrauch je Anlage und Schicht – die Grundlage für Kalkulation und Effizienz.
An der Anlage: das integrierte Web-Dashboard
Jede Sensorbox hat eine eigene Weboberfläche – einfach die Adresse der Box im Browser auf PC, Tablet oder Smartphone öffnen. Eine Softwareinstallation ist nicht nötig.
- Live-Anzeige von Spannung, Strom, Leistung, Drahtvorschub und Gasdurchfluss sowie eine Statusübersicht, die auf einen Blick zeigt, ob alles in Ordnung ist
- Lichtbogenerkennung – die Box erkennt, wann geschweißt wird, und zeichnet nur auf, was zählt
- Lokale Aufzeichnung auf microSD-Karte (CSV, direkt in Excel lesbar), eine Datei pro Tag oder pro Sitzung – auch ohne Netzwerk
- Benutzerverwaltung mit den Rollen Administrator und Benutzer
- Firmware-Updates über den Browser – neue Funktionen ohne Servicebesuch
- Oberfläche auf Deutsch und Englisch
Für die ganze Fertigung: RoboCenter
RoboCenter führt alle Sensorboxen – und direkt angebundene Fronius-TPS/i-Schweißanlagen – in einer Browser-Anwendung auf Ihrem eigenen Server zusammen.
- Alle Anlagen auf einem Bildschirm: online, im Leerlauf oder beim Schweißen, mit Live-Werten
- Historie über Tage, Wochen und Monate, gespeichert in einer Zeitreihendatenbank
- Qualitätsampel je Anlage und Job auf Basis des eingelernten Referenzverhaltens
- PDF-Berichte für Audits und Kunden: Schweißzeit, Energie, Draht- und Gasverbrauch
- Läuft on-premises auf Ihrem eigenen Server – Ihre Daten bleiben in Ihrem Werk
In vier Schritten startklar
- MontierenSensorbox in der Nähe der Schweißanlage platzieren, Versorgung über 12-V-Netzteil oder PoE.
- AnschließenStromkabel in den Schweißstromkreis, Spannungsabgriff an Brenner und Werkstück, optional Draht- und Gassensor.
- VernetzenEthernet-Kabel einstecken und die Adresse der Box im Browser öffnen.
- ÜberwachenLive-Werte ansehen, SD-Aufzeichnung einschalten – oder die Box an RoboCenter, MES oder SPS anbinden.
Möchten Sie es an Ihrer Fertigungslinie sehen? Wir bringen gern eine Sensorbox an Ihre Schweißzelle und zeigen Ihnen live, wie Ihr Prozess aussieht.
Mehr als Überwachung gewünscht? Erfahren Sie, wie die Sensorbox Anomalien mit KI erkennt.
Qualitätssicherung mit KI
Die Box lernt, wie eine gute Naht aussieht
Ein erfahrener Schweißer hört, wenn der Lichtbogen falsch klingt. Die Sensorbox macht dasselbe – bei jeder Naht, in jeder Schicht. Sie zeigen ihr einige Gutteile; sie lernt das normale Verhalten und meldet ab dann jedes Bauteil, das abweicht. Alles läuft auf der Box selbst: kein PC, kein KI-Server, keine Cloud.
So funktioniert es
- Gutteile schweißenMindestens acht bekannt gute Bauteile schweißen. Die Box erkennt Bauteile und Nähte selbstständig am Lichtbogen.
- EinlernenFür jede Naht lernt die Box eine Referenz aus 305 Kennwerten pro Viertelsekunde – einschließlich der natürlichen Streuung.
- ÜberwachenJedes folgende Bauteil wird mit der Referenz verglichen. Ergebnis je Naht und je Bauteil: grün, gelb oder rot.
- ErklärenVerständliche Indikatoren zeigen, was anders ist: Spannung, Strom, Kurzschlüsse, Frequenzmuster, U/I-Zusammenspiel.
- VerbessernDer Bediener bestätigt oder verwirft Alarme. Fehlalarme machen das Modell toleranter – echte Fehler nie.
Teach-in direkt auf der Sensorbox
Das Teach-in ist Teil der Sensorbox-Firmware und wird vollständig über den Browser bedient. Es ist für Roboterzellen und Serienfertigung mit wiederkehrenden Bauteilen ausgelegt.
- Automatische Bauteil- und Nahterkennung aus dem Lichtbogensignal – keine zusätzlichen Signale vom Roboter nötig
- Ein Programm pro Bauteiltyp, ausgewählt über die Jobnummer von Robotersteuerung oder SPS (MQTT/REST)
- Ampel je Naht und je Bauteil; ein Bauteil wird auch dann verworfen, wenn eine Naht fehlt oder eine zusätzliche auftritt
- Fünf verständliche Indikatoren je Naht und die Abweichung von der Referenz in Prozent für Spannung, Strom und Kurzschlussfrequenz
- Trendwarnung, wenn der Prozess langsam driftet, z. B. durch Kontaktrohrverschleiß
- Ereignisliste mit Bediener-Rückmeldung (i. O./n. i. O.); das Modell wird erst nach einem Regressionstest gegen die Referenz aktualisiert
- Ergebnisse im Dashboard, über MQTT, OPC UA und Modbus TCP – und gespeichert auf der SD-Karte
Prozesslernen in RoboScope
Für lange oder sehr häufig wiederholte Nähte – z. B. Längsnähte an Schienen oder Rundnähte an Behältern – lässt sich das Modell auch am PC mit RoboScope trainieren:
- Autoencoder-Modell, trainiert aus einer 20-Sekunden-Aufnahme des guten Prozesses
- Empfindlichkeitsregler und zusätzliche harte Grenzwerte je Merkmal (z. B. Mindest-Gasdurchfluss)
- Annotation von Ereignissen als i. O./n. i. O. und mit Fehlerlabels wie „Spritzer“ oder „Gasverlust“ – das Modell lernt, bekannte Fehler zu benennen
- Latent-Space-Ansicht, um zu sehen, wie das Modell gute und schlechte Zustände trennt
- Auf die Sensorbox übertragen mit einem Klick – die Box überwacht danach selbstständig
Welcher Ansatz passt zu Ihnen?
| Teach-in auf der Sensorbox | Prozesslernen in RoboScope | |
|---|---|---|
| Typischer Einsatz | Roboterzellen, Serienbauteile mit mehreren Nähten | Lange oder stark wiederholte Nähte, Labor, Prozessentwicklung |
| Wo wird gelernt? | Auf der Box, bedient über den Browser | Am PC, danach Übertragung auf die Box |
| Was wird benötigt? | Mindestens 8 Gutteile | 20 s Aufnahme des guten Prozesses |
| Modell | Statistische Referenz je Naht (305 Merkmale); neuronales Autoencoder-Netz in Vorbereitung | Neuronales Autoencoder-Netz, optional Fehlerklassen |
| Ergebnis | Ampel je Naht und Bauteil, verständliche Indikatoren, Trendwarnung | Ampel mit Anomalie-Score, benannte Fehlerklassen nach Annotation |
| Im Betrieb | Läuft selbstständig auf der Sensorbox – kein PC, keine Cloud. Ergebnisse über Dashboard, MQTT, OPC UA, Modbus TCP. | |
Was das Signal verrät – und was nicht
Wir bleiben ehrlich: Die elektrischen Signale zeigen, ob der Prozess anders gelaufen ist. Ob im Schweißgut ein Fehler steckt, zeigt erst die Prüfung. Grundlage sind Literatur von 2001 bis 2025 und eigene Versuche:
Zuverlässig erkennbar
- Schutzgasverlust oder zu wenig Gas
- Probleme im Drahtvorschub, Drahtklemmer
- Falscher Kontaktrohrabstand, verschlissenes Kontaktrohr (Trend)
- Spritzer und Lichtbogenabrisse
- Spalt oder Kantenversatz, Durchbrand
- Falsche Streckenenergie, fehlende oder zusätzliche Nähte
- Indirekt: Poren infolge Gasverlust, fehlende Durchschweißung
Nicht aus dem Signal erkennbar
- Heiß- und Kaltrisse
- Einbrandkerben
- Schlackeneinschlüsse
- Flankenbindefehler
- Fehler, die das Lichtbogenverhalten nicht verändern
Die Sensorbox meldet, dass eine Naht anders ist und welche Prozessgröße abweicht. Um die Fehlerart zu benennen, braucht es annotierte Beispiele (RoboScope).
Zwei Prozesse vergleichen – mit KI-Befundbericht
Der Reiter Vergleich in RoboScope beantwortet die Frage „Was hat sich tatsächlich geändert?“ in Sekunden: zwei Aufnahmen laden, eine von zehn Vergleichsmethoden wählen (z. B. Tropfenfrequenz, Kurzschlussstatistik, Lichtbogenimpedanz, U/I-Phasendiagramm, Poincaré-Diagramm, Drahtvorschub-Schwankung) und einen verständlichen Bericht erzeugen.
RoboScope ermittelt mehr als 20 physikalische Kennwerte je Aufnahme, kommentiert jede Methode, ordnet die Methoden nach Signifikanz und nennt nur physikalisch relevante Abweichungen – ohne Spekulation über Ursachen. Typische Anwendungen: WPS-Validierung, Vergleich Roboter gegen Roboter, Wechsel der Drahtcharge, Schichtvergleich und Reklamationsanalyse.
Beispiel: KI-Vergleichsbericht (PDF)
KI-Vergleichsbericht – Beispiel (12 Seiten)Zwei Schweißungen mit zehn Methoden verglichen: KI-Kommentar je Methode, Kennwerte, Signifikanz-Rangfolge2 MB
0 Klicks im Betrieb
Jobnummer wählen, Ampel ablesen. Die Box entscheidet für jede Naht in Echtzeit.
Daten bleiben im Werk
Lernen und Bewerten laufen lokal auf der Box. Keine Cloud, kein externer KI-Dienst.
Erklärt statt nur zu alarmieren
Fünf verständliche Indikatoren zeigen, welche Prozessgröße abweicht – ein Ansatzpunkt für die Ursache.
Wird mit der Nutzung besser
Wenige Minuten Rückmeldung pro Schicht reduzieren Fehlalarme – echte Fehler weiten die Toleranz nie auf.
KI-Überwachung führen wir gemeinsam mit Ihnen ein. Wir wählen geeignete Nähte aus, führen das Teach-in an Ihrer Anlage durch, binden die Jobnummern Ihrer Robotersteuerung, SPS oder Ihres MES an und validieren die Ergebnisse in der laufenden Produktion.
Sprechen Sie uns an – gemeinsam klären wir, was KI-Überwachung für Ihre Bauteile leisten kann.
Forschung & Entwicklung
Rohdaten, offene Protokolle, volle Transparenz
Für Schweißlabore, Hochschulen und Prozessentwickler ist die Sensorbox ein offenes Messinstrument: synchrone 5-kHz-Rohdaten von Strom und Spannung, dokumentierte Protokolle, Kalibrierdaten in jedem Paket – und RoboScope für Analyse, Aufzeichnung und Export in offene Formate.
Messprinzip
Im Inneren arbeitet ein STM32H7-Dual-Core-Mikrocontroller mit klarer Aufgabenteilung: Der Cortex-M4 übernimmt die zeitkritische Messung, der Cortex-M7 die Merkmalsberechnung, Protokolle, den Webserver und die KI-Modelle. Beide Kerne tauschen Daten über OpenAMP/RPMsg aus – so bleibt die Messung auch unter Netzwerklast deterministisch.
- Strom und Spannung werden gleichzeitig mit 5 kHz je Kanal abgetastet, mit 16 Bit Auflösung und 16-fachem Hardware-Oversampling (DMA, Blöcke zu 256 Samples ≈ 51 ms)
- Strom über einen galvanisch getrennten Shunt-Sensor (2,5 mV/A) und Differenzverstärker – ±500 A dauerhaft, Spitzen bis ±1.000 A
- Spannung über eine differenzielle Eingangsstufe, Messbereich ±100 V, geschützt durch Varistor und TVS-Dioden
- Rauscharme Analogversorgung mit isolierten DC/DC-Wandlern und Ultra-Low-Noise-Linearreglern, Präzisions-Spannungsreferenz
- Drahtvorschub über Encoder, Gasdurchfluss über thermischen Massendurchflusssensor mit Korrekturfaktor für beliebige Gemische aus Ar, He, CO₂, O₂ und N₂
- Kalibrierbar: Nullpunkt, Verstärkung und Umfang des Encoder-Rads; die Kalibrierparameter werden in jedem Datenpaket mitgesendet
Berechnete Größen
Effektivwerte und Wirkleistung werden je Zeitfenster aus den Rohsamples berechnet. Die Wirkleistung ergibt sich Sample für Sample als Mittelwert von u·i – die einzig korrekte Methode für nicht sinusförmige Schweißsignale (vgl. ISO/TR 18491).
RMS-Spannung:
\[ U_{\mathrm{RMS}}=\sqrt{\frac{1}{N}\sum_{k=0}^{N-1} u[k]^2} \]
RMS-Strom:
\[ I_{\mathrm{RMS}}=\sqrt{\frac{1}{N}\sum_{k=0}^{N-1} i[k]^2} \]
Mittlere Wirkleistung:
\[ P=\frac{1}{N}\sum_{k=0}^{N-1}\big(u[k]\cdot i[k]\big) \]
305 Kennwerte pro Viertelsekunde
Bei 5 kHz erzeugt eine einzige Anlage rund 72 MB Rohdaten pro Stunde. Für Überwachung und KI übersetzt die Sensorbox jedes 256-ms-Fenster in 305 physikalisch aussagekräftige Merkmale – etwa 20 MB pro Tag:
| Gruppe | Merkmale |
|---|---|
| Grundwerte & Dynamik | Effektivwert, Mittelwert, Leistung, Änderungsrate von U und I |
| Verteilung | Standardabweichung, Schiefe, Kurtosis, Perzentile |
| Spektrum | Bandenergien von Strom und Spannung von 0 bis 1.500 Hz |
| Kurzschlüsse & Lichtbogen | Kurzschlussanteil, -frequenz und -dauer, Lichtbogenstatistik, Lichtbogenimpedanz |
| U/I-Kopplung | Korrelation von U und I, Spannungshistogramm, 16 × 16 U/I-Dichteraster |
Der Merkmalssatz ist in der Sensorbox und in RoboScope identisch – am PC trainierte Modelle laufen unverändert auf der Box.
Schnittstellen und Protokolle
| Schnittstelle | Inhalt | Typischer Einsatz |
|---|---|---|
| UDP-Rohdatenstrom | Ca. 20 Pakete pro Sekunde mit je 256 U/I-Samples, Zeitstempel, Sequenznummer, Status- und Kalibrier-Header | Oszilloskop, Spektralanalyse, eigene Auswertesoftware |
| MQTT 3.1.1 (TLS) | JSON-Telemetrie alle 0,1–5 s, lichtbogengesteuerter Modus, Ereignisse, Status; Jobnummern können empfangen werden | Datenbanken (z. B. InfluxDB), RoboCenter, Node-RED |
| OPC UA | Strom, Spannung, Leistung, Gasdurchfluss, Drahtgeschwindigkeit (ns=1) | SCADA, MES, IIoT-Plattformen |
| Modbus TCP | Holding-Register ab 1000 (Port 502) | SPS-Anbindung |
| REST / WebSocket | Konfiguration, Live-Werte, Teach-in, Signal Bauteilende | Integration in eigene Anwendungen |
| microSD / USB | CSV oder RoboScope-Rohdaten (RBS), als USB-Massenspeicher lesbar | Langzeitaufzeichnung, Feldeinsatz ohne Netzwerk |
Zeitbasis: SNTP/NTP mit batteriegepufferter Echtzeituhr; Diagnose-Flags (ADC-Überlauf, Encoder-Timeout, NTP-Sync, Kernverbindung) sind Teil jedes Datenpakets.
MQTT-Message
Die Sensorbox sendet ihre Mess- und Statusdaten in einem kompakten JSON(JavaScript Object Notation)-Format. Jede Nachricht entspricht einem zeitlich eindeutig zuordenbaren Snapshot des Schweißprozesses und enthält sowohl Prozesskennwerte als auch Systemzustände und Firmware-Versionen.
Zeit & Sequenz
→ Dient zur Synchronisation mit anderen Systemen (InfluxDB, Dashboard, RoboScope, MES).
→ Erlaubt das Erkennen von Aussetzern, Paketverlust oder Lücken in der Aufzeichnung.
Elektrische Kenngrößen
→ Diese Größen ermöglichen Last-/Energieanalyse, Prozessstabilitätsbewertung und Vergleich von Jobs/Parametern.
Draht & Gas
→ Basis für Prozessüberwachung (z. B. zu geringer Vorschub, Drahtstau, Fehlererkennung).
→ Wird bereits in der Sensorbox korrigiert, sodass der Anwender direkt einen praxisrelevanten Wert erhält.
→ Transparenz, wie stark Rohwerte aufgrund Kalibrierung/Umgebungseinfluss angepasst wurden.
Statusobjekt (Gesundheit & Diagnose)
Unter status werden wichtige Diagnoseflags als Booleans mitgeliefert:
→ Dadurch ist Remote-Diagnose möglich, ohne dass der Anwender direkt an die Hardware muss.
Firmware-Versionen (Traceability)
Beispiel:
{
"ts": "2026-01-21T10:15:23.123Z",
"seq": 4711,
"u_rms": 23.45,
"i_rms": 156.78,
"p_rms": 3680.2,
"wire_m_min": 8.50,
"gas_l_min": 12.30,
"gas_cf": 1.07,
"status": {
"openamp_ok": true,
"adc_overrun": false,
"encoder_timeout": false,
"ntp_synced": true
},
"fw": {
"m7": "1.0.3",
"m4": "1.0.3"
}
}UDP High-Speed Stream (Rohdatenpaket)
Für hochauflösende Analyse (Oszilloskop-Ansicht, Histogramme, Ereigniserkennung) sendet die Sensorbox zusätzlich zur JSON-Telemetrie einen binären/CSV-ähnlichen UDP-Datenstrom. Jedes UDP-Paket enthält einen Header mit Metadaten und danach einen Block von ADC-Rohsamples für Spannung und Strom.
1) Paket-Header (Metadaten)
→ Damit kann der Empfänger Daten sicher als „Sensorbox-Frame“ erkennen und Fehl- oder Fremdpakete verwerfen.
Zeitstempel in Millisekunden.
→ Ermöglicht zeitkorrekte Darstellung (z. B. Live-Trace), Logging und Synchronisation mit anderen Quellen.
Fortlaufende Sequenznummer.
→ Paketverluste oder Reihenfolgefehler (UDP!) werden sofort sichtbar.
Anzahl der Samples pro Kanal in diesem Paket.
→ Ein Paket ist ein „Datenblock“ (Frame) mit genau definiertem Umfang.
Aktueller Gasdurchfluss (l/min) als Meta-Info zum Sampleblock.
→ Praktisch, um Oszi-Daten direkt mit Prozessparametern zu verknüpfen.
Drahtvorschub (m/min) zum selben Zeitpunkt.
→ Kann 0 sein, wenn Draht steht oder ein Encoder-/Signalproblem vorliegt.
Bitmaske für Systemzustände/Fehlerflags (z. B. ADC Overrun, Encoder Timeout, OpenAMP OK, NTP Sync).
→ Diagnose ohne extra Abfrage – jedes Paket trägt seinen Gesundheitszustand mit.
Kalibrier-/Umrechnungsparameter
→ Damit kann der Empfänger Rohdaten zu physikalischen Größen umrechnen (oder bewusst Rohdaten speichern und später mit denselben Parametern rekonstruieren).
2) Sample-Daten (Payload)
Nach dem Header folgt eine Tabelle/Sequenz:
→ Der Empfänger kann daraus:
-
Oszilloskop-Traces (u(t), i(t)) erzeugen
-
RMS/Leistung/Arc-Stabilität berechnen
-
Peaks, Kurzschlüsse, Spritzerereignisse erkennen
-
Histogramme / Verteilungen erstellen (z. B. Stromverteilung pro Job)
Warum UDP?
UDP ist ideal für Live-Streaming großer Datenmengen:
-
sehr geringe Latenz
-
geringer Protokoll-Overhead
-
„best effort“ (Paketverlust möglich) → deshalb: seq im Header
Für robuste Speicherung/Backfill nutzt man meist parallel die „langsamen“ Telemetriekanäle (z. B. JSON via MQTT/HTTP), während UDP für die Echtzeit-Ansicht dient (RoboScope).
Beispiel eines Python-Codes zur Ausgabe des UDP-Streams im Terminal (Aufruf z.B. mit python3 udp_dump.py 9000:
#!/usr/bin/env python3
import argparse
import socket
import struct
import math
MAGIC_OSCI = 0x3143534F # "OSCI"
FLAG_STATUS = 0x0001
FLAG_CAL = 0x0002
BASE_HDR_FMT = "<IHHII" # magic, header_len, flags, seq, sample_cnt
BASE_HDR_LEN = struct.calcsize(BASE_HDR_FMT) # 16
def parse_packet(buf: bytes):
if len(buf) < BASE_HDR_LEN:
return None
magic, header_len, flags, seq, sample_cnt = struct.unpack_from(BASE_HDR_FMT, buf, 0)
if magic != MAGIC_OSCI:
return None
# Minimaler Header: base + ts + meta
if header_len < (BASE_HDR_LEN + 8 + 8) or header_len > len(buf):
return None
off = BASE_HDR_LEN
ts_ms, = struct.unpack_from("<Q", buf, off)
off += 8
gas_l_min, wire_m_min = struct.unpack_from("<ff", buf, off)
off += 8
status = None
if flags & FLAG_STATUS:
if off + 4 > header_len:
return None
status, = struct.unpack_from("<I", buf, off)
off += 4
# Default Cal (falls nicht mitgesendet)
u_gain = 1.0
u_offset = 0.0
i_gain = 1.0
i_offset = 0.0
if flags & FLAG_CAL:
if off + 16 > header_len:
return None
u_gain, u_offset, i_gain, i_offset = struct.unpack_from("<ffff", buf, off)
off += 16
# Payload beginnt bei header_len
payload_off = header_len
payload_bytes = len(buf) - payload_off
available_samples = min(sample_cnt, payload_bytes // 4)
return {
"ts_ms": ts_ms,
"seq": seq,
"sample_cnt": sample_cnt,
"available_samples": available_samples,
"gas_l_min": gas_l_min,
"wire_m_min": wire_m_min,
"flags": flags,
"status": status,
"u_gain": u_gain,
"u_offset": u_offset,
"i_gain": i_gain,
"i_offset": i_offset,
"payload_off": payload_off,
}
def main():
ap = argparse.ArgumentParser(description="Simple UDP dump for MIGAL.CO Sensorbox OSCI stream")
ap.add_argument("port", type=int, help="UDP port to listen on, e.g. 9000")
ap.add_argument("--bind", default="0.0.0.0", help="Bind address (default: 0.0.0.0)")
ap.add_argument("--n", type=int, default=16, help="How many samples to print (default: 16)")
ap.add_argument("--rms", action="store_true", help="Compute simple U_rms/I_rms/P_mean from printed samples")
args = ap.parse_args()
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((args.bind, args.port))
print(f"Listening on {args.bind}:{args.port} ... (Ctrl+C to stop)")
while True:
buf, addr = sock.recvfrom(65535)
info = parse_packet(buf)
if info is None:
# Unbekanntes Paket – leise ignorieren oder kurz melden:
continue
ts_ms = info["ts_ms"]
seq = info["seq"]
sc = info["sample_cnt"]
av = info["available_samples"]
gas = info["gas_l_min"]
wire = info["wire_m_min"]
flags = info["flags"]
status = info["status"]
u_gain = info["u_gain"]
u_offset = info["u_offset"]
i_gain = info["i_gain"]
i_offset = info["i_offset"]
print("\n" + "-" * 80)
print(f"from {addr[0]}:{addr[1]} ts_ms={ts_ms} seq={seq} samples={sc} (in packet: {av})")
print(f"gas_l_min={gas:.3f} wire_m_min={wire:.3f} flags=0x{flags:04x}", end="")
if status is not None:
print(f" status=0x{status:08x}")
else:
print()
if (flags & FLAG_CAL) != 0:
print(f"cal: u_gain={u_gain} u_offset={u_offset} i_gain={i_gain} i_offset={i_offset}")
# Samples ausgeben
nprint = min(args.n, av)
off = info["payload_off"]
u_vals = []
i_vals = []
for i in range(nprint):
w, = struct.unpack_from("<I", buf, off)
u_raw = w & 0xFFFF
i_raw = (w >> 16) & 0xFFFF
off += 4
# physikalisch (falls Gain/Offset gesetzt)
u = u_raw * u_gain + u_offset
cur = i_raw * i_gain + i_offset
u_vals.append(u)
i_vals.append(cur)
print(f"{i:4d}: u_raw={u_raw:5d} i_raw={i_raw:5d} u={u:.3f} i={cur:.3f}")
if args.rms and nprint > 0:
u2 = sum(x*x for x in u_vals) / nprint
i2 = sum(x*x for x in i_vals) / nprint
p = sum(u_vals[j] * i_vals[j] for j in range(nprint)) / nprint
print(f"-> U_rms={math.sqrt(u2):.3f} I_rms={math.sqrt(i2):.3f} P_mean={p:.3f} (über {nprint} Samples)")
if __name__ == "__main__":
main()
OPC UA Variable Nodes
Der Server exponiert 5 Read-Only Variablen im Namespace ns=1:
| Variable | NodeID | Typ | Einheit | Beschreibung |
|---|---|---|---|---|
| Strom | ns=1;i=6001 | Double | A | Effektivwert (RMS) |
| Spannung | ns=1;i=6002 | Double | V | Effektivwert (RMS) |
| Leistung | ns=1;i=6003 | Double | W | Momentanleistung |
| Gasfluss | ns=1;i=6004 | Double | l/min | Korrigierter Volumenstrom |
| Drahtgeschwindigkeit | ns=1;i=6005 | Double | m/min | Encoder-basiert |
Modbus TCP (SPS-Anbindung)
Modbus TCP ist ein weit verbreitetes Industrieprotokoll zur Kommunikation zwischen speicherprogrammierbaren Steuerungen (SPS) und Feldgeräten. Die Sensorbox stellt einen integrierten Modbus TCP Server bereit, über den eine SPS die wichtigsten Schweißprozessdaten direkt als Holding Registers lesen kann.
Diese Schnittstelle kann um beschreibbare Register erweitert werden, sodass eine SPS oder Robotersteuerung der Sensorbox aktiv Informationen übermitteln kann – etwa die aktuelle Schweißnaht-ID, Job-Nummer oder Programmnummer. So wird eine lückenlose Rückverfolgbarkeit und Qualitätsdokumentation jeder einzelnen Naht möglich.
Damit kann Ihre Robotersteuerung in Echtzeit mit der Sensorbox kommunizieren – die Grundlage für automatisierte Qualitätssicherung in der vernetzten Schweißfertigung.
Kontaktieren Sie uns – wir erarbeiten gemeinsam mit Ihnen die passende Anbindung an Ihre bestehende Automatisierungsinfrastruktur.
RoboScope – Analysesoftware für Windows und macOS
RoboScope empfängt den UDP-Rohdatenstrom und macht aus Signalen Erkenntnisse – live am Schweißplatz oder aus Aufnahmen.
- Oszilloskop mit Trigger, Zeitbasis 1–500 ms/div
- FFT (4.096 Punkte), Wasserfalldiagramm 0–2.500 Hz und 3D-Spektrum – Tropfenfrequenzen, Schwingungen und Störungen finden
- Histogramm, U/I-Kennlinie und U/I-Dichte-Heatmap – der elektrische Fingerabdruck des Prozesses
- Vergleich zweier Aufnahmen mit zehn Methoden und KI-Befundbericht
- Prozesslernen: KI-Modelle trainieren, annotieren und auf die Sensorbox übertragen
- Aufnahme & Wiedergabe mit Aufnahme-Gate (Drahtvorschub oder Strom)
- Export als PDF, ins offene Forschungsformat weldx und nach WPS-Maker 2 (.wpsx) inkl. Streckenenergie
Technische Daten
| Messgrößen | Schweißstrom, Lichtbogenspannung, Drahtvorschub, Schutzgasdurchfluss (synchron) |
| Abtastrate | 5 kHz je Kanal, U und I gleichzeitig, 16 Bit mit 16-fachem Oversampling |
| Spannungsmessung | ±100 V (AC, DC), differenzieller Eingang |
| Strommessung | ±500 A dauerhaft (AC, DC), Spitzen bis ±1.000 A, galvanisch getrennter Shunt-Sensor |
| Genauigkeit U / I | ±1 % vom Messwert ±0,2 V / ±1 % vom Messwert ±0,5 A |
| Drahtvorschub (optionaler Drahtsensor) | 0–20 m/min, Encoder-Auflösung 0,114 mm, 0,7 % bei 10 m/min |
| Drahtdurchmesser | 0,8–1,6 mm (größer auf Anfrage) |
| Gasdurchfluss (optionaler Gassensor) | 0,5–50 l/min, ±3 % vom Endwert, Korrektur für Ar/He/CO₂/O₂/N₂-Gemische |
| Prozessor | STM32H7 Dual-Core (Cortex-M7 480 MHz + Cortex-M4 240 MHz) |
| Netzwerk | Ethernet 10/100 Mbit/s, statische IP oder DHCP; WLAN-Modul (ESP32-C6) auf der Platine, Firmware-Unterstützung in Vorbereitung |
| Protokolle | MQTT 3.1.1 mit TLS, UDP-Rohdatenstrom, OPC UA, Modbus TCP, REST/JSON, WebSocket |
| Datenrate | MQTT: alle 0,1–5 s; UDP: ca. 20 Frames × 256 Samples pro Sekunde (= 5 kHz) |
| Weboberfläche | Integriert, browserbasiert, Deutsch/Englisch, Benutzerrollen, Firmware-Update über den Browser |
| Lokaler Speicher | microSD-Karte (CSV oder Rohdaten), USB-Massenspeicher |
| Zeitbasis | SNTP/NTP, batteriegepufferte Echtzeituhr |
| Versorgungsspannung | 9–12 V DC oder PoE (Adapter im Lieferumfang) |
| Abmessungen / Gewicht | 200 × 160 × 60 mm (L × B × H) / 1,1 kg |
| Schutzart / Umgebungstemperatur | IP20 / 0–40 °C |
Lieferumfang
- Sensorbox mit Anschlüssen für Ethernet, Spannungsversorgung und Sensoren; 12-V-Steckernetzteil und PoE-Adapter
- 3-poliger Kabelstecker für die Spannungsmessung mit 5 m verdrilltem Messkabel
Optional
- Drahtsensor (Encoder) mit 1,5 m Kabel und 5-poligem Stecker
- Gasdurchflusssensor mit 2 m Kabel und 7-poligem Stecker
- Softwarelizenzen: RoboScope (Windows/macOS) und RoboCenter
