PnP Sensor+Actor System (PnPSA)
State of the art
While working and measuring with sensors in university's tool machine area,
I miss development towards digital measurement and handy, interchangeable and easy-to-use devices.
Even in 2012, the measurement technician has to deal with analog multi-channel data acquisition systems.
Frequently, analog voltage (± 10 V) is used for representation of the measured value,
besides those listed in
this document.
Here is a summary:
Why it's so hard to move toward complete digitalization:
- Extremely different speed requirements (eg, accelerometer vs. thermosensor)
- Very different accuracy requirements (often inversely proportional to speed)
- Problems with correlated time line
- Slow sensors with client-side clocked A/D conversion: latency
- Fast sensors with sensor-sode clocked (blockwise) A/D conversion and data loggers:
latency
and synchronity of sampling times
- Wiring and cabling Standard
- Cost (for the multiple A/D converters)
Today's scenario
Measurement is performed with a confusing amount of cables, connectors, adapters, tools and equipment,
not to mention the weird software.
Suppose you want to measure a mechanical force with a strain-gauge load cell,
you need a couple of devices as shown in the picture.
For simplicity and cost-efficiency, I would use a
NI USB DAQ device „NI USB-6008“
containing the
ADS7870 chip.
Despite the low performance of 12 bit accuracy and 10 kSa/s overall sample rate,
this device is USB bus powered and therefore easy to use.
With a
self-made signal conditioner containing a DC/DC converter
to get power from „NI USB-6008“ device, no extra power supply is needed,
and the overall design is capable for in-field measurements.
However, some efford is needed to get this, and you have to calibrate all!
Too much to do for a routine job.
Moreover, a software must be built using LabVIEW
(that's easy) and calibrated
(that's a bit more complicated).
Tools
- Screwdriver to connect wires
- Multimeter to check voltages and connections, for troubleshooting
- A mass unit to check whether the force sensor works properly
Every modern human outside who wants to measure a mechanical force
thinks that such constellation is easily available and ready to use.
Power is sorced from the (even more lightweight) netbook.
This is not available nowadays!
But it should be. And is expected by non-professionals.
Suppose you want to measure
mechanical force (strain-gauge load cell) and
temperature (Pt100).
For a cartoon picture too confusing, I decided to draw a block diagram for the devices needed.
So suppose you have a „NI USB-6008“ for analog-digital conversion.
You need
two different signal conditioners,
for industrial application always with its own power supply and calibration issues.
Probably a better, faster A/D converter is necessary;
at least all the National Instruments devices need extra power too.
With a suitable and modular system like
HBM
Spider8,
MGCplus,
QuantumX
or
NI
cDAQ-9172,
it's easier to handle,
but still you have to solder some wires and plugs, and the overall cost is overwhelming.
Extra Power is also needed, and as all devices are made for mains supply, the power consumption is not suited for in-field battery powering.
No one of those systems are powerable by a notebook.
Things get worse when you already have a “smart” sensor with digital output, like
Micro-Epsilon µε optoNCDT2200.
This Laser Triangulation Sensor outputs distances (± 10 mm) with 15 bit resolution (< 1 µm)
at pretty fast 10 kSa/s.
A PC built-in serial interface with its maximum 115.2 kBaud is too slow.
So you need a special
adapter for connecting.
For USB as
Do-It-Yourself device
to keep costs in bounds.
The next problem is to prevent drifting of another A/D converter, i.e.
synchronization. You need an extra
Sync Wire. Really!
But this imposes
three assumptions:
- A sync output
- A piece of cable (you have to solder plugs yourself, there is no standard!)
- A sync input for the next A/D converter
- Good luck that voltages etc. are the same, e.g. TTL level,
otherwise, you have to create some convertion circuitry and its power supply
The second sensor (here a strain-gauge load cell) works as before,
with signal conditioner.
Moreover, some sort of a start trigger is needed (depending on latency and demands),
so you may need another sync cable, not shown in the picture.
If you have two “smart” sensors with no synchronization between,
you must do it later by resampling in software if necessary.
Note that resampling is not measuring but interpolating values where no values were.
Same applies for AC measurements (e.g. sound pressure, modal analysis) per sound card.
A digital solution is needed!
Thow away analog interfacing! Take advantages of a fully digitized solution!
I would prefer using USB. Advantages:
- Good awareness, cables and hubs available at low cost
- no extra amplifier needed (every computer has USB, but not
CAN)
- Integrated, well-defined and simple power supply concept,
no need for large-range-voltage-input DC/DC converters on sensor side
(contrary to FireWire,
PoE)
- Availability of power supply even on notebooks, netbooks, etc. (in opposite to FireWire, Ethernet)
- Relatively low power output of the PC / hub (max. 2.5 W, 3.0-super speed: 4.5 W) enforces energy-efficient sensors
- Large range of available transmission rates for expensive (fast) and cheap (slow) sensors (compared to Ethernet and FireWire)
- No batteries (as in wireless solutions) for long-life sensors without constant care expenses
(such as the regular battery replacement or charging of too-short-living rechargeable batteries)
- Very flexible cable (especially at low speed, no shielding required)
- Solving problem of mutual synchronization provided in USB standard by SOF (start-of-frame, 1 kHz and 8 kHz)
- Decimal-based operating frequencies (12 MHz based) and sampling frequencies (contrary to uneven FireWire clock of 24.576 MHz)
- Large range of inexpensive microcontroller makes total sensor increasingly cost-attractive
- High-quality A/D converters are becoming cheaper, smaller and more energy-efficient
- Practice has shown that rather well-known consumer solutions go to industry than vice versa (eg, Ethernet, RS232)
- Host-centric USB system is easier to manage and understand (compared to FireWire, Ethernet)
- PnP and isochronous data transfer is already built-in (as opposed to Ethernet)
- Wireless option available with WUSB
Why USB and not FireWire, Ethernet/EtherCat, Fieldbus or CAN
should be now clear.
Disadvantages and their workarounds
- Missing standard for sensors and actors (more than built-in TEDS is needed)
- This is the objective of this reseach project!
- No software available for measuring on multiple USB devices with full synchronization
- The evaluation software is to be written to show how it works.
- No lockable USB connectors
- There are manufacturers of lockable USB connectors.
- 127 (devices + HUBs) maximum, 5 m per Segment maximum
- So-called “Concentrators” work like hubs but in a higher OSI layer.
These fully real-time devices make the downstream sensors to appear as one multi-channel sensor to the upstream port.
For high-reliable measurement, such a device should be always used to prevent bad effects of current operating systems to USB performance.
- Missing electrical isulation (potential separation)
- The sensors should be potential-free (i.e. non-metallic or insulated).
However, ground loops, dreaded in analog cabling, are not so problematic with USB.
- Latency (mostly when using Windows)
- Using a concentrator eliminates the latency problem.
However, connecting sensors to different host controllers may not work
due to possibly different SOF clock.
(Concentrators offer a sync solution.)
- Wiring (some users wish wireless solutions)
- Maximum cabling length: 35 m
- The PnPSA standard roots on USB but allows other transportation media such as FireWire or EtherCAT.
Using transportation media with built-in synchronization omits the cumbersome sync wires,
otherwise, sync wires are needed.
- Sync wires?
- Only needed when some other technology than USB is used!
Already invented?
Yes, there are some fully-digitized, PnP-able solutions,
but every vendor makes his own, and it's never interchangeable:
- Dallas DS1820: Temperature sensor with
One-Wire interface
The bus concept with long unique serial numbers is very smart solved but data rate is too slow for general use
- I²C bus,
SMBus:
Cannot handle two same chips, no PnP
- SPI,
SSC,
LPC:
For very short distances only (10 cm), no PnP
- RS422,
DMX,
RS485,
CAN,
Modbus,
Profibus:
No PnP but true buses and sometimes capable for real-time operation
- RS232: Avaliable at every PC (with USB-RS232 converter), PnP available(!),
but only seen for modems and mice, should be supported!, it's frequently used
- Parallelport: Avaliable at every PC (with USB-Printer converter),
PnP available, fast, bi-directional: outdated
- DDE: No PnP, but known Data transfer protocol, should be supported!, it's frequently used
- OLE: (unknown)
- Sockets (Ethernet, TCP/IP, WLAN): No PnP, no kein data transfer protocol;
der hohe Stromverbrauch von WLAN-Geräten erspart nicht das Strippenziehen!, should be supported!
- Bluetooth: hat IMHO PnP, but no data transfer protocol, should be supported!
- ZigBee: (unknown), should be supported!
- HART,
WirelessHART, IEC61158: Kein PnP, viel zu langsam
- DCF77
or similar national time references;
GPS:
Sub-Standard for synchronization
- Precision Time Protocol
for IP based local networks (mostly Ethernet, WLAN, EtherCAT)
- FireWire: Almost-USB?, should be supported!
- Audio and Video: This is measurement equipment too!
Think on thermographic cameras, high-ppeed cameras for crash-tests, microphones for modal analysis …
Should be supported.
- Hausbus (EIB, FreeBus):
No PnP, very slow, smart power supply, only 2 wires, large distance
- OPC
a software interface for Windows, merely for industrial automation
- Interface A,
a self-description for sensors in semiconductor production (SEMI Group), so it's PnP, but without synchronization
- DIAS bus
Hurdles
Technicians don't use USB
To be translated
Foresee (what to implement)
- Cheap and expensive! Einfache Sachen wie Temperatursensoren für die Wohnung
sollten genauso bezahlbar sein wie bei 100 MHz abtastende Stromwandler für die
Halbleiter-Plasmaindustrie, trotz gleichen (USB-)Steckers und gleicher USB-Geräteklasse.
Für den Profi-Einsatz wäre ein robustes Steckverbindersystem zu überlegen,
welches nicht unbedingt USB-kompatibel sein muss.
Mir schwebt da ein 10-poliger LEMO/ODU-Stecker vor.
Das System sollte auf Verlängerungskabel(!) aufbauen (also keine
verschiedenen Stecker für Host und Device).
Eingebaute Kodierwiderstände (etwa 100 kΩ pro Meter Kabel)
dienen zum Prüfen der maximalen Kabellänge (5 m) auf der Device-Seite.
Außer bei USB 3.0 seien nur 5 Pins vorhanden und belegt.
Zwei Kontakte (Speisespannung und Masse) sind voreilend.
- Immer mit Einheit!
Schluss mit dem manuellen Erstellen praxisgerechter Achsenbeschriftungen.
LabVIEW bietet beim Datentyp „Signal“ (Waveform) sowie bei Gleitkommazahlen
eine Einheit an, eine Darstellung in Graphen ist damit jedoch kurioserweise
nicht möglich.
- Nicht nur Messwert, sondern auch
Messunsicherheit
und Jitter!
Eine völlig neue (überfällige?) Herangehensweise, die die Messwertverarbeitung
und Fehlerabsicherung revolutioniert.
Anwendungssoftware wie LabVIEW müsste dahin gehend erweitert werden.
Beispielsweise sollte der Datentyp „Signal“ (Waveform)
ein Standardattribut „NI_Deviation“ mitführen,
welche absolute und relative Messabweichung beinhaltet.
Die Graph-Darstellung sollte den Toleranzbereich als entsprechend
breite Linie darstellen.
Das gilt sinnentsprechend auch für den Jitter, die Varianz der Abtastzeitpunkte.
Da Messungen des öfteren mit nicht ganz synchron laufenden Uhren
gemacht werden (sicherlich auch künftig),
ist eine Angabe der Unsicherheit der Startzeit
sinnvoll für eine nachträgliche Korrelierung verschiedener Messreihen.
Siehe auch: GUM.
- Absicherung von Kalibrierdaten mittels
Public-Key-Verfahren
(verhindert zuverlässig Piraterie teurer, zertifizierter Sensoren,
erzwingt Einhaltung von Kalibrier-Intervallen)
- Vorsetzbare analoge Sensortechnik mit wahlweiser Abspeicherung zugehöriger Kalibrierdaten
in einem nichtflüchtigen Speicher des PnP-Sensors und/oder des Computers.
Beispiel: Vor einem
PnP-Differenzdrucksensor
(Einheit Pa) wird ein Strömungshindernis angeordnet
und anhand der Druckdifferenz der Massenstrom
(Einheit kg/s) gemessen.
Bei Abspeicherung im Differenzdrucksensor formt dieses Gebilde
einen neuen PnP-Sensor
(vorteilhaft wenn's eine konstruktive Einheit ist, etwa ein Rohrstück),
bei Abspeicherung im Mess-PC nicht
(wenn's keine konstruktive Einheit ist).
- Jeder Sensor sollte dringend eine Erkennungs-LED
oder sonstige optische Anzeige besitzen,
die immer dann blinkt, wenn der Anwender diesen in irgendeiner Form ausgewählt
(selektiert, fokussiert) hat.
Das ist notwendig, um bei einem Gewirr gleicher
Sensoren sicher zu stellen, dass man den richtigen ausgewählt hat.
Zusätzlich zu einer seriennummern-basierten Grund-Unterscheidung.
- Nicht nur Sensoren, sondern auch Aktoren!
- Externe Synchronisation und deren Takt-Distribution!
- Unterstützung konfigurierbarer Sensoren (Bereichsumschaltung; Universalmessgeräte)
sowohl von Hand (sensorseitig) als auch vom PC (hostseitig)
- Hinreichend sinnvolle Zusammenarbeit mit herkömmlicher, analoger und/oder nicht-synchroner Messtechnik (hierzu zählt auch DDE)!
- PnP-Unterstützung auch für USB-Datenlogger und sonstiger Aufnehmer mit Signalverzögerung!
- Dual-Mode-Sensorik mit alternativem Anschluss, bspw. Hausbus oder Kfz-Bus
(Ideenspender: Seriell + PS/2 + USB-Mäuse)
- Unterstützung von dezentraler Messwerterfassung im Anzeigeprogramm!
- Entwicklung eines Speicher-Formats mit Bilddaten-Erfassung
Lange Zeit habe ich Text-Dateiformate favorisiert.
Die Flut an Informationen ist jedoch heutzutage nicht mehr menschenlesbar
und Binärformate hinreichend standardisiert, so dass ich mehr und mehr
zu einem Binärformat tendiere.
Womöglich als Erweiterung zum
TDMS-Dateiformat.
Es wird schließlich beides unterstützt.
Target
- Ein Sensoranzeigeprogramm läuft und stellt Messwerte dar, zeichnet permanent auf (was kostet Festplattenplatz heute und künftig?)
- Ein weiterer PnP-Sensor wird angesteckt
- Das Anzeigeprogramm fügt automatisch diesen Sensor in das Diagramm und die Anzeige ein
- Ein PnP-Sensor wird abgezogen
- Der Graf des Sensors bleibt stehen, die Digitalanzeige verschwindet, alles andere zeichnet weiter auf
- Einer der laufenden PnP-Sensoren ist ein Multimeter mit Messbereichsumschaltung von Hand.
Es wird von 20 V auf 200 V Messbereich umgeschaltet:
Die Anzeigesoftware reagiert mit einer Aktualisierung der Messunsicherheit (bspw. Breite der Linie)
- Es wird von Spannung auf Strom umgeschaltet:
Die Anzeigesoftware beendet den Spannungsgrafen und startet einen Strom-Grafen,
etwa als ob ein Sensor abgezogen und ein anderer angesteckt worden wäre;
nur Skalierung und Digitalanzeige bleiben an der gleichen Stelle (via Kanal-ID o.ä.)
- Das Programm speichert alle (oder auswählbare) Kanäle für die gesamte Messzeit mit der jeweils nötigen Abtastrate,
also Beschleunigungssensoren bspw. mit 10 kSa/s und Temperatursensoren mit 2 Sa/s
Plug-And-Play eben!
Implementation
Preparations
Im Vorfeld sollte folgendes abgeklopft werden:
- Vorhandene Standards mit gleichem/ähnlichen Ziel (speziell TEDS)
- Zusammenarbeit mit usb.org zur Erstellung einer neuen USB-Geräteklasse
- Zusammenarbeit mit National Instruments zur Erstellung eines Plugins für den Measurement und Automation Explorer
- Zusammenarbeit mit National Instruments: LabVIEW zur Erweiterung des Signal-Datentyps zur Mitführung der Messunsicherheit (bspw. via Tag)
und einer Signaldarstellungskomponente mit Darstellung der Messunsicherheit und Einheit
- Erweiterung der LabVIEW-Signalverarbeitungskomponenten (Addition, Mittelwert, RMS usw.) zur Verarbeitung dieser Messunsicherheit
gemäß Fehlerfortpflanzungsgesetzen
- Erstellung eines Dateiformats (binär, kompakt) für die Ablage synchronisierter und nicht-synchronisierter Messergebnisse
- Keine Zusammenarbeit mit AMS (ich habe jBEAM gesehen, das reicht!!)
- Kein Aufsetzen auf USB-TMC (Test&Measurement Class): Diese bietet überhaupt kein PnP
- Deskriptorsystem für Zusammenarbeit mit herkömmlicher, analoger und/oder nicht-synchroner Messtechnik
- Das Anzeigeprogramm muss mit kurzzeitigen (=interpolieren, Einzel-Samples)
und langen (=aussetzen, mehrere Samples) Sensor-Ausfällen zurechtkommen, wie in der Wettermesstechnik üblich
A roadmap
- Erstellung des PnP-Sensorsystems anhand von neuen Deskriptoren:
- Sensoren dürfen, nach ihrer Wahl, linearisierte und/oder nicht-linearisierte Werte liefern
- Reduktion der Datenanfalls auf ein Minimum; Vorbild: HID (Human Interface Device, USB-Geräteklasse)
- Sensoren müssen eine physikalische Einheit liefern; Vorbild: HID
- Sensoren müssen Genauigkeitsangaben liefern:
- konstant oder formelmäßig per Deskriptor
- pro Messwert
- pro Messwert-Bündel bei schnelleren Geräten
- Änderungsmitteilung am Messwert (bspw. Leistungsmessung bei sich änderndem, sehr kleinen Leistungsfaktor)
- Mehrsprachigkeit im Deskriptor
- Mehrsprachigkeit via Wörterbuch-Tags
- Einschluss bereits vorhandener, aber spezieller PnP- und Nicht-PnP-Sensortechnik
- USB-HID
- USB-Audio (bspw. Schallpegelmessung, Modalanalyse mit Impulshammer)
- USB-Messkarten (sofern Interface offengelegt)
- Nicht-USB-Systeme
- Nicht-PnP-Systeme
- Implementation von Referenz-Sensoren
- Bereits verfügbare digitale (wertdiskrete) Sensoren (erspart A/D-Wandler)
- Temperatur- und Feuchtesensor (auf Basis Sensirion SHT21), etwa 10 Sa/s max.
- Differenzdrucksensor (auf Basis Sensirion SDP610), bis 1 kSa/s
- Drehwinkelgeber (typ. 10 kSa/s)
- Analoge Sensoren
- Kraftsensor mit Dehnmessstreifen-Brücke (bspw. 2 kN Zug + Druck), 1 kSa/s
- Temperatursensor auf Basis von Pt100, etwa 100 Sa/s max.
- Stromzange (bis 1 MSa/s)
- Implementation einer Referenz-Software (ohne oder mit LabVIEW, ähnlich einem Oszilloskop-Programm)
- Implementation eines Konzentrators
- Nachweis der Funktionsfähigkeit des Ensembles unter verschiedenen Umgebungen
- Aktor-Implementation
- Vermarktung?
A tree view to PnPSA
- PnP-Sensor/Aktorsystem mit Deskriptor-System
- Native (standardmäßig vorhanden und Referenzimplementation)
- USB
- (neu zu erstellende) PnP-Klasse
- HID-Klasse (für langsame Sensorik ≪ 125 Sa/s)
- Embedded (vorhanden, erweiterbar, ggf. gegenüber „Nativ“ hinterherhinkend, teilweise Konfiguration [Non-PnP] erforderlich)
- Seriell (nur mit PnP)
- FireWire
- Bluetooth, ZigBee
- NI Measurement&Automation Explorer?
- USB Audio
- Using available bus-alike infrastructure (später vorhanden oder vom Anwender nachzuliefern, fallweise Konfiguration [wegen Non-PnP] erforderlich)
- Ethernet
- DDE, OLE
- One-Wire
- Using single-device drivers (vom Anwender oder Gerätehersteller nachzuliefern)
- GPIB, SICL, USB-TMC
- Alles, was noch nicht aufgelistet ist
Why I and here?
You may wonder why this project should be part of tool-machine profession.
But a young electronics engineeer cannot see the problems within machine measurement …
My references:
- Kontakthandschuh (Umgang mit USB, Mikrocontroller, C++, Datenformat-Interpretation, Windows-Programmierung)
- BootSelektor (Umgang mit Ethernet, TCP/IP, Webserver mit CGI, Mikrocontroller, C++)
- RS422 (Umgang mit Hochgeschwindigkeits-Digital-Sensor und LabVIEW)
- Analoges Sensoranschluss-Konzept (Schaffung eines evolutionären, weil auf HBM basierenden, Werkstandards)
- Laborautomatisierung (Windows-Programmierung, C++, Pascal, Schnittstellen-Kommunikation, DDE)
- Kenntnisse über Zeichenkodierung und Internationalisierung (kyrillisch, chinesisch/japanisch, arabisch, thailändisch)