Ich liebe es meine diversen Messgeräte fernsteuern zu können. Und deshalb achte ich darauf, dass Neuanschaffungen eine entsprechende Schnittstelle bieten – RS232, LAN, WLAN oder USB. Der Industriestandard in puncto Kommunikationsprotokoll heißt SCPI und wird von den meisten meiner Geräte unterstützt. Wie das mit Standards aber oft so ist, hält sich die tatsächliche Standardisierung sehr in Grenzen und abgesehen von der Kommandostruktur unterscheiden sich die verschiedenen Gerät doch erheblich und v.a. billige Hersteller kochen da manchmal sehr ihr eigenes Süppchen. Und spätestens bei Features, die sehr gerätespezifisch sind muss der Hersteller sich eh was ausdenken. Und so bin ich gerade dabei, für meine diversen Geräte je eine Python Klasse zu schreiben, um die Steuerung zu vereinfachen und nicht jedes Mal in das SCPI Handbuch des Geräts schauen zu müssen und dann diese eher sperrigen Kommandos einzutippen. Dabei lerne ich gerade viel über die Instrumente, weil ich ja ihre diversen Funktionen alle umsetzen will. So zum Beispiel für mein Uni-T UDP3305S Netzteil, oder meine ET5410A+ Elektronische Last.

UDP3305S Labornetzteil

Im Großen und Ganzen klappt die Ansteuerung sehr gut.

Und wenn ich nun z.B. die Spannung auf 12V setzen möchte, dann geht das so:

SOURCE:VOLT 12

Und wenn ich wissen will, auf welchen Wert die Spannung eingestellt ist, dann schreibt man dies:

SOURCE:VOLT?

Aus Gründen, die ich auch nicht verstehe gibt es aber ein weiteres Kommando, das das selbe tut:

APPLY: 12V
APPLY? VOLT

So weit so einfach. Aber manchmal fragt man sich auch, ob das der Praktikant entworfen hat.

Kanalauswahl

Das Netzteil hat drei echte Kanäle und zwei virtuelle Kanäle:

1. Ch1 (0-30V, 5A)
2. Ch2 (0-30V, 5A)
3. Ch3 (0-6V, 3A)
4. SER : Dabei werden Ch1 und Ch2 in Serie geschaltet, so dass bis zu 60V zur Verfügung stehen
5. PARA: Hier sind Ch1 und Ch2 parallel geschaltet so dass wir bis zu 10A kriegen können.

Verwendet man nun die obigen Kommandos, dann beziehen diese sich auf den aktuell aktiven Kanal. Das ist nicht sehr elegant und deshalb ist es natürlich möglich, im Kommando den gewünschten Kanal explizit anzugeben. Leider ist die Syntax hier überraschend inkonsistent.

Sagen wir mal, wir wollen Kanal 2 auf 24V setzen, dann lauten die Befehle

APPLY CH2: 24V

oder

SOURCE2:VOLT 24

What?? Warum in aller Welt ist das so total unterschiedlich implementiert? Aber es wird noch besser. Stellen wir mal SER auf 9V:

APPLY SER: 9V

bzw.

SOURCE5:VOLT 9

Quizfrage: Wie lauten die Befehle im Falle von PAR? So:

APPLY PARA: 9V
SOURCE6:VOLT 9

D.h. die Kanal IDs sind so zugeordnet:

D.h. SOURCE4 gibt es nicht. Waaaaaaaaaaaaaaarum??? @§$%&#* Wer denkt sich denn sowas aus?

ET5410A+ Electronic Load

Aber es geht noch spaßiger. So bei meiner Last von EastTester. Zugegebenermaßen ist die preislich am unteren Ende angesiedelt. Und das merkt man bei der Firmware ziemlich. Erfahrungsgemäß ist das bei fernöstlichen Billiggeräten oft so, dass Software und Firmware weit hinter der Qualität der Hardware zurückbleiben, so auch hier. Mit dem Gerät an sich bin ich eigentlich für den Preis ganz zufrieden, aber die SCPI-Implementierung hat mich teilweise schon an den Rand der Verzweiflung gebracht.

Z.B. *IDN? – dieser Befehl soll laut Standard vier Felder liefern:

1. Hersteller
2. Modell
3. Seriennummer
4. Firmware version

Und was sagt meine Load?

ET5410A+ 09937662737 V1.00.2213.016 V1.00.2213.016

Hm. Hersteller Fehlanzeige, Reihenfolge anders und Feld 3 ist die Hardware revision. Und die Beschreibung im Handbuch stimmt nullkommanull damit überein:

Query returns <model>,<SN>,<software>,<NL>

Note <model> gives the machine model number as ET54XX,< SN> gives the serial number,<software> gives the software version number, and <hardware> gives the hardware version number.

What? Das ist ja schon in sich nicht konsistent...

Noch besser wird es bei dem baugleichen Gerät mit "Mustool" Branding:

XXXXXX   V1.01.2251.018 V1.06.2247.016

Kein Modell, und anstatt einer Seriennummer gibt es einen Space(!). Das macht es wirklich zum Vergnügen, das zu parsen und dennoch beide Geräte korrekt zu behandeln...

Die nächste Überraschung ist, dass die Load keinen *RST Befehl unterstützt. Warum zum Geier? So ein Geräte-Reset ist schon eine sehr nützliche Sache und bisher hatte absolut jedes Gerät, mit dem ich gespielt habe diese Kommando.

Und der dritte Schmerzpunkt bei diesem Gerät ist das SCPI-Handbuch. Es fängt schon damit an, dass es nirgends zum Download angeboten wird und man den Support nerven muss, um es zu bekommen. Hält man es dann in (virtuellen) Händen, stellt sich schnell heraus, dass es in wirklich schwierig verständlichem Englisch ist und allen Ernstes mit der Free-Version des Word-PDF Konverters von pdf.youdao.com erstellt wurde, denn dessen Banner prangt jedenfalls quer über allen Seiten. Ist es echt zuviel verlangt die paar Kröten für Adobe auszugeben, oder einfach LibreOffice zu verwenden???

Dafür deckt es inhaltlich scheinbar alles ab, auch wenn man es oft mehrfach lesen muss bis man versteht was gemeint ist.

Zuguterletzt ist es mir mehrfach gelungen, das Instrument durch zügiges Senden von SCPI-Befehlen ins Nirvana zu schicken, auch wenn diese bei der manuellen Überprüfung dann problemlos liefen.

Fazit

Ich bin sowas von froh, wenn meine Python Implementierung fertig ist und ich im normalen Betrieb nie wieder manuell SCPI-Befehle eingeben muss...