Moin zusammen,
ich habe mein Oszi mal ein bisschen ausgereizt und unter Anderem mal
endlich die Datenübertragung zum PC genauer angeguckt.
Da gibt es die Standards:
-IEEE Std 488.2–1987
-IEEE Std 488.2-1992 (Revision von IEEE Std 488.2–1987)
Die Befehle sehen als Beispiel wie folgt aus:
1
MEASU:IMM:SOURCE CH1
2
Channel 1
3
MEASU:IMM:TYPE FREQ
4
MEASU:IMM:VAL?
5
DAT:SOU CH1
6
DAT:ENC ASCI
7
DAT:WID 2
8
DAT:STAR 1
9
DAT:STOP 1000
10
CURV?
siehe auch: Beitrag "Oszilloskop Tektronix TDS380"
Schön wäre jetzt wenn man nicht für jedes Oszi ein anderes Programm
braucht um sich die Daten herunterzuziehen. Oftmals kosten die Programme
zusätzlich Geld oder Lizenzen müssen verwaltet werden. Eventuell könnte
man da ein Programm bauen.
Meine Frage:
Welche (aktuellen) Oszis halten/orientieren sich an diesen Befehlssatz
aus den oben genannten IEEE-Standards?
Dieser Befehlssatz nennt sich übrigens SCPI und setzt auf dem
IEEE-488-Standard auf. Und genau damit bewerben ja viele Hersteller auch
ihre Messgeräte und Oszilloskope. Allerdings gibt es auch etliche
herstellerspezifische Erweiterungen bzw. Auslegungen.
Entgegen dem ursprünglichen Standard kann man SCPI auch hervorragend
über UART/EIA232 oder Ethernet betreiben. Die standardgemäße Verwendung
mittels USB nennt sich USB-TMC, aber auch USB CDC oder proprietäre
UART-Emulationen sind gebräuchlich.
Andreas V. schrieb:> Meine Frage:>> Welche (aktuellen) Oszis halten/orientieren sich an diesen Befehlssatz> aus den oben genannten IEEE-Standards?
Das Problem wird schon damit anfangen, das eine IEEE-488 Schnittstelle
bei heutigen Oszis eher selten bis gar nicht zu finden ist.
Parallelschnittstellen sind ziemlich out und durch serielle
USB-Schnittstellen verdrängt. Keiner hat heutzutage mehr Lust, sich mit
den IEEE-488 Kabeln abzuplagen.
Wolfgang schrieb:> Das Problem wird schon damit anfangen, das eine IEEE-488 Schnittstelle> bei heutigen Oszis eher selten bis gar nicht zu finden ist.
IEEE Std 488.2 hat überlebt im heutigen SCPI-Standard. Und der läuft
auch auf Ethernet, USB, Bluetooth, ...
Eigentlich ist IEEE Std 488.2 / SCPI genau das gewünschte "Esperanto".
Damit werden alle Geräte mit einer identischen Struktur und nahezu
identischen Kommandos bedient. Wer sich an die Zeit davor erinnert, das
war komplette Anarchie. Da setzte z.B. "0100800( <eoi>" die Frequenz auf
100,8 MHz. Der Generator (ohne Mikroprozessor!) hatte keine Befehle im
klassischen Sinne verarbeitet, sondern einfach die einzelnen Datenbits
als Steuerleitungen benutzt. 0b0011 xxxx bedeutet eine Zahl, die ins
Eingaberegister geschoben wird, alles andere sind Latch-Befehle, die das
Eingaberegister in ein anderes kopieren. <eoi> ist eine Steuerleitung,
belegt also keinen ASCII-Code.
Wolfgang schrieb:> Das Problem wird schon damit anfangen, das eine IEEE-488 Schnittstelle> bei heutigen Oszis eher selten bis gar nicht zu finden ist.>> Parallelschnittstellen sind ziemlich out und durch serielle> USB-Schnittstellen verdrängt. Keiner hat heutzutage mehr Lust, sich mit> den IEEE-488 Kabeln abzuplagen.
Es geht um den Befehlssatz, nicht um die Schnittstelle!
Und, wie Andreas schon schrieb, sprechen die SCPI.
@TO:
Geräte eines Hersteller oder zumindest einer Hersteller-Serie haben
i.d.R. reagieren auf die gleichen Befehle.
Andreas V. schrieb:> Welche (aktuellen) Oszis halten/orientieren sich an diesen Befehlssatz> aus den oben genannten IEEE-Standards?
Die mit einer USB-Device-Schnittstelle... vermutlich.
Das lässt sich nur herausfinden, indem man die Datenblätter/Handbücher
des infrage kommenden Messgerätes studiert.
> Das Problem wird schon damit anfangen, das eine IEEE-488 Schnittstelle> bei heutigen Oszis eher selten bis gar nicht zu finden ist.
Das laeuft aber auch genauso ueber RS232, USB und Ethernet.
Ich glaube ich hab nur 2-3Tage gebraucht um mir ein Programm zu
schreiben mit dem ich mein Hameg auslesen konnte. Das geht eigentlich
relativ einfach...
Wichtig ist nur das man eine Doku zum Befehlssatz hat weil der sich halt
schon zwischen den Geraeten unterscheiden kann. Teilweise sogar je nach
Firmwareversion anders.
Olaf
Andreas V. schrieb:> Die Befehle sehen als Beispiel wie folgt aus:MEASU:IMM:SOURCE CH1> Channel 1> MEASU:IMM:TYPE FREQ> MEASU:IMM:VAL?> DAT:SOU CH1> DAT:ENC ASCI> DAT:WID 2> DAT:STAR 1> DAT:STOP 1000> CURV?
Diese Befehle sind weder in IEEE 488.2 noch in SCPI spezifiziert. IEEE
488.2-Befehle beginnen mit einem "*", SCPI-Befehle mit einem ":".
Mit den "Common Commands and Queries" aus IEE 488.2 alleine kann man
noch nicht viel anfangen. Sie stellen nur eine (sehr überschaubare)
Schnittmenge der Befehle aller Messgerätetypen (vom einfachen Voltmeter
bis zum Spektrumanalyzer) dar. Damit kann man aber bspw. noch keine
Messwerte einlesen.
SCPI geht da deutlich weiter, aber viele (vor allem ältere) Geräte
unterstützen diesen Standard nicht. Trotzdem würde ich SCPI als das von
dir gesuchte "Esperanto" ansehen. Wahrscheinlich gibt es deutlich mehr
Messgeräte, die SCPI können, als Menschen, die Esperanto sprechen :)
Ich glaube ich habe meine Frage falsch gestellt. Ich will kein neues
Oszi kaufen.
Zwei Punkte!
Der Befehlssatz:
Ich suche nur nach Gemeinsamkeiten bei der Fernsteuerung von Oszis. Wenn
SCPI der kleinste gemeinsammer Nenner ist; - dann gut! Mich würde auch
interessieren welche Oszi's SCPI-Befehle verwenden. Lohnt es sich etwas
zu programmieren?
Die Schnittstelle:
GBIP ist als einzige Schnittstelle echtzeitfähig. USB, Ethernet,
Bluetooth, WLAN, BLE, RS232, usw. sind nur Übertragungswege. Das ist
nach ISO/OSI eine Schicht unter dem Befehlssatz. Wenn man es cool
aufbaut sollte das egal sein über welche Schnittstelle die Befehle
laufen.
Ich stelle mir ein Programm vor, in dem man das Oszi einstellt und die
gespeicherten Daten herunterladen kann.
> GBIP ist als einzige Schnittstelle echtzeitfähig.
Das ist bei einem Oszi ziemlich wumpe oder? Ich meine du kannst die
Daten ja erst auslesen nachdem die Echtzeit bereits im Speicher
festgenagelt ist.
> Ich stelle mir ein Programm vor, in dem man das Oszi einstellt und die> gespeicherten Daten herunterladen kann.
Yo, das ist soweit kein Problem. Ich hab das jedenfalls schon gemacht.
Eine Grenze ist eventuell die Geschwindigkeit deiner Schnittstelle.
Bei den Hamegs ist das z.B so das die RS232 maximal 115k kann. Die
USB-Schnittstelle setzt im Oszi auch auf 115k um und die LAN auch.
Und jetzt stellt sich die Frage wie gross der Speicher in deinem Oszi
ist und
ob er sich vielleicht auch nur in Teilen auslesen laesst oder eher
nicht. .-)
Aber es ist schon alleine deshalb praktisch weil man so immer auf
Tastendruck einen Screenshot fuer seine Dokus auslesen kann ohne
jedesmal mit dem Stick rumzuwirbeln. Und man kann sich Dinge
programmieren die der Hersteller vergessen hat, z.B auf Knopfdruck alle
Strahlen an die Lieblingsposition setzen oder die Kaenaele gleich nach
wunsch beschriften.
Olaf
Olaf schrieb:>> GBIP ist als einzige Schnittstelle echtzeitfähig.>> Das ist bei einem Oszi ziemlich wumpe oder? Ich meine du kannst die> Daten ja erst auslesen nachdem die Echtzeit bereits im Speicher> festgenagelt ist.
Es kommt auf die Anforderungen an. Ich kann mir durchaus Mess-Szenarien
vorstellen, bei denen die Zeit eine Rolle spielt. Und sei es nur einen
Single-Shot nachdem ein Befehl über eine Leitung ging. Aber so weit bin
ich gerade nicht...
> VISA?
Ah! Ich glaube das war der Grund sich was selber zu schreiben. :)
Es gibt nur weniger das fetter, traeger und murksiger ist. Wobei, die
Software von Keysight zum auslesen ihrer neuen Multimeter uebertrifft
das noch...
Olaf
Soul E. schrieb:> Da setzte z.B. "0100800( <eoi>" die Frequenz auf> 100,8 MHz. Der Generator (ohne Mikroprozessor!) hatte keine Befehle im> klassischen Sinne verarbeitet, sondern einfach die einzelnen Datenbits> als Steuerleitungen benutzt.
Klar,
zum Zeitpunkt der Einführung von GPIB war ein µP teure Highend Lösung.
Gegenüber 1000 herstellerspezifischen "TTL Schnittstellen" aber ein
Riesenfortschritt.
Möge mal jemand SCPI ohne Prozessor nur mit TTL/RTL Gattern
implementieren...
Butzo
Ich bin mir sicher dass unsere Manager und Entscheider es in Zukunft
noch murksiger, träger und langsamer hinkriegen. Selbst mit einer 10GBit
Schnittstelle sollte es möglich sein einen I7 oder schneller zum Absturz
zu bringen oder zumindest so auszubremsen dass es keinen Spass mehr
macht.
Im Übrigen bin ich der Meinung dass 99% der Genannten 30cm zu groß sind!
Wolfgang schrieb:> Das Problem wird schon damit anfangen, das eine IEEE-488 Schnittstelle> bei heutigen Oszis eher selten bis gar nicht zu finden ist.
Mag bei Oszis passen, jedenfalls bei den unteren Modellen, bei allerlei
HF Messtechnik ist das aber immer noch verfügbar, genau wie für
Multimeter.
Es gibt bis auf Ethernet vlt. auch keine richtige Alternative.
LG
Andreas V. schrieb:> Der Befehlssatz:> Ich suche nur nach Gemeinsamkeiten bei der Fernsteuerung von Oszis. Wenn> SCPI der kleinste gemeinsammer Nenner ist; - dann gut! Mich würde auch> interessieren welche Oszi's SCPI-Befehle verwenden.
Schau ins Datenblatt des jeweiligen Oszilloskops.
> Lohnt es sich etwas zu programmieren?
Es gibt Unmengen an Standardsoftware, die auch explizit mit SCPI-Geräten
umgehen kann, z.B. NI LabVIEW, HP/Agilent/Keysigh VEE. Und es gibt
etlichen kommerzielle und freie Bibliotheken zur Erzeugung und
Auswertung SCPI-konformer Daten, und das auch noch in sehr vielen
Programmiersprachen. Insbesondere in und für Python gibt es da sehr,
sehr viel.
Vielfach erfolgt aber auch eine Abstraktion von Gerätefunktionen in Form
von VISA- und/oder IVI-Bibliotheken. Damit werden dann wieder SCPI- und
Nicht-SCPI-Geräte zusammengeführt. Ob man sich solch einen
Bibliotheksmoloch antun will, hängt aber sehr von der Anwendung ab.
> Die Schnittstelle:> GBIP ist als einzige Schnittstelle echtzeitfähig.
Schwachsinn. GPIB ist sogar multimasterfähig, ohne dass es dabei
Methoden gibt, die Übertragungsbandbreite zuverlässig aufzuteilen.
> USB, Ethernet,> Bluetooth, WLAN, BLE, RS232, usw. sind nur Übertragungswege.
Von den genannten Schnittstellen besitzt nur RS232 einen echten
Vollduplexbetrieb und bietet damit schon auf der physikalischen Ebene
eine "Echtzeitfähigkeit". USB ist ebenfalls echtzeitfähig, weil das
Timing komplett durch den einzigen Host im System definiert wird,
einschließlich der Pollingintervalle für Interrupt-Endpoints. Bei
isochronen Endpoints sind neben der strikten Echtzeitfähigkeit sogar
Timinganpassungen des gesamten Paketrahmens möglich. Für Ethernet gibt
es mittlerweile etliche Echtzeiterweiterungen auf verschiedenen
Protokollebenen.
> Das ist nach ISO/OSI eine Schicht unter dem Befehlssatz. Wenn man es cool> aufbaut sollte das egal sein über welche Schnittstelle die Befehle> laufen.
Die wenigsten Protokolle sind nach dem OSI-Modell aufgebaut. Es wird
jedoch von vielen Möchtegernexperten versucht, nachträglich jedes
geschichtete Protokoll in das OSI-Modell hineinzudrücken. Dieses Thema
haben wir hier schon unzählige Male ausgiebig diskutiert. Das müssen wir
nicht noch einmal tun.
> Ich stelle mir ein Programm vor, in dem man das Oszi einstellt und die> gespeicherten Daten herunterladen kann.
Mach doch. Dabei kann man sehr viel lernen. Und anschließend lässt Du
Dir die drölfzig fertigen Bibliotheken und Programme zeigen, in denen so
etwas schon implementiert ist.
Andreas V. schrieb:> Es kommt auf die Anforderungen an. Ich kann mir durchaus Mess-Szenarien> vorstellen, bei denen die Zeit eine Rolle spielt. Und sei es nur einen> Single-Shot nachdem ein Befehl über eine Leitung ging. Aber so weit bin> ich gerade nicht...
Du verleugnest also den heutzutage üblichen technischen Stand. Der
LXI-Standard umfasst neben der eigentlichen Messgerätesteuerung, z.B.
mittels SCPI, auch die Zeitsynchronisation zwischen Messgeräten auf
Basis von PTP bzw. IEEE 1588. Aber Du hast ja ohnehin schon für Dich
beschlossen, dass so etwas über Ethernet eh nicht möglich ist. Dann
musst Du Dir also auch gar nicht mehr anschauen, wie es "die Großen"
machen, die damit auch Mess- und Prüfsysteme für die Flugzeugindustrie
usw. aufbauen. Die warten nur sehnsüchtig darauf, dass Du denen
erzählst, dass so etwas gar nicht mit Ethernet möglich sei.
Andreas S. schrieb:> Du verleugnest also den heutzutage üblichen technischen Stand. Der> LXI-Standard umfasst neben der eigentlichen Messgerätesteuerung, z.B.> mittels SCPI, auch die Zeitsynchronisation zwischen Messgeräten auf> Basis von PTP bzw. IEEE 1588. Aber Du hast ja ohnehin schon für Dich> beschlossen, dass so etwas über Ethernet eh nicht möglich ist. Dann> musst Du Dir also auch gar nicht mehr anschauen, wie es "die Großen"> machen, die damit auch Mess- und Prüfsysteme für die Flugzeugindustrie> usw. aufbauen. Die warten nur sehnsüchtig darauf, dass Du denen> erzählst, dass so etwas gar nicht mit Ethernet möglich sei.
Natürlich ist Echtzeit über Ethernet möglich! Dafür gibt es
Speziallösungen wie Kithara. Das Teil zieht selbst den performantesten
Prozessor auf 100% wenn man bestimmten Kriterien gerecht werden will.
Bei einem 10 Gbit Netzwerk kann man so auch Echtzeit-Kriterien gerecht
werden. Außerdem kommt es darauf an wie man den Begriff "Echtzeit"
dehnt. TCP / UDP gibt keine Garantie dass das Paket in einer bestimmten
Zeit ankommt.
Ob USB mit seinen Zeitscheiben dem gerecht wird sei dahingestellt. Man
muss nur einen USB-Stick einstecken und eine Maschine für eine halbe
Million rammt das Werkzeug in den Boden; - Alles schon miterlebt! Wenn
man natürlich sicherstellt dass sich die Anzahl der Geräte in der
Zeitscheibe nicht ändern kann und sich kein Gerät neu anmelden kann und
das Gerät in Notbetrieb geht wenn sich ein Gerät abmeldet...
Andreas V. schrieb:> Außerdem kommt es darauf an wie man den Begriff "Echtzeit"> dehnt. TCP / UDP gibt keine Garantie dass das Paket in einer bestimmten> Zeit ankommt.
Komisch. Vorhin hattest Du ja noch keine Probleme damit, solche völlig
unhaltsamen Verallgemeinerungen zu betreiben.
> Ob USB mit seinen Zeitscheiben dem gerecht wird sei dahingestellt.
Zeitscheibenverfahren sind hochgradig deterministisch, was genau das
Kriterium für Echtzeitfähigkeit ist.
> Man muss nur einen USB-Stick einstecken und eine Maschine für eine halbe> Million rammt das Werkzeug in den Boden; - Alles schon miterlebt!
Kannst Du mir bitte die Stelle in der USB-Spezifikation zeigen, in der
solch ein systemkostenabhängiges Verhalten gefordert ist?
> Wenn man natürlich sicherstellt dass sich die Anzahl der Geräte in der> Zeitscheibe nicht ändern kann und sich kein Gerät neu anmelden kann und> das Gerät in Notbetrieb geht wenn sich ein Gerät abmeldet...
Offenbar verwechselst Du eine fehlerhafte Implementierung eines riesigen
Softwareklumpens mit den genau spezifizierten Eigenschaften eines
Übertragungsprotokolls. Gerade USB ist doch diesbezüglich vorbildlich.
Ein Gerät meldet sich niemals selbst an, sondern verhält sich zunächst
völlig passiv und zieht nur einer der Datenleitungen hoch. Und der
betreffende USB-Hub zeigt dies in einem Statusregister an. Das Abfragen
dieses Statusregisters und die anschließende Enumeration des Geräts
erfolgt komplett durch den Host. Und wenn das Gerät Ressourcen anmeldet,
die der Host nicht erfüllen kann, z.B. Bandbreitenanforderungen für
isochrone Endpoints, dann bekommt es diese auch nicht zugeteilt.
Wenn Anwendungssoftware oder auch einige Gerätetreiber mit dem
Hotplugging von Geräten nicht zurechtkommen, dass sind sie einfach
scheiße implementiert. Das hat nichts mit dem an dieser Stelle sehr
übersichtlichen und robust definierten USB-Protokoll zu tun. Dies hängt
damit zusammen, dass viele Entwickler munter auf Ressourcen zugreifen
und nicht jeden einzelnen Zugriff auf Fehler überprüfen.
Andreas S. schrieb:> Zeitscheibenverfahren sind hochgradig deterministisch, was genau das> Kriterium für Echtzeitfähigkeit ist.
Es kommt nur darauf an wieviele Geräte daranhängen, welche
Geschwindigkeit USB hat und wie man "Echtzeit" für sich selbst
definiert!
Ich habe noch nie einen Begriff erlebt der so dermaßen schwammig
geworden ist und entsprechend gedehnt wird ...
Andreas S. schrieb:> Offenbar verwechselst Du eine fehlerhafte Implementierung eines riesigen> Softwareklumpens mit den genau spezifizierten Eigenschaften eines> Übertragungsprotokolls. Gerade USB ist doch diesbezüglich vorbildlich.> Ein Gerät meldet sich niemals selbst an, sondern verhält sich zunächst> völlig passiv und zieht nur einer der Datenleitungen hoch. Und der> betreffende USB-Hub zeigt dies in einem Statusregister an. Das Abfragen> dieses Statusregisters und die anschließende Enumeration des Geräts> erfolgt komplett durch den Host. Und wenn das Gerät Ressourcen anmeldet,> die der Host nicht erfüllen kann, z.B. Bandbreitenanforderungen für> isochrone Endpoints, dann bekommt es diese auch nicht zugeteilt.
Genau! Und da liegt auch das Problem! In der Regel läuft auch alles gut!
Es reicht halt manchmal nur eine kurze Verzögerung und das
"Echtzeitsystem" ist keins mehr! Die Anwendung hat nämlich nichts unter
Kontrolle was die Zeitscheibe betrifft. Ist das dann noch Echtzeit?
Andreas S. schrieb:> Ich gebe es auf, auf diesen völlig gequirten Unsinn überhaupt noch zu> antworten. Das bringt eh nichts.
USB ist ohne massive Manipulationen nicht echtzeitfähig! Und selbst dann
hat es seine Probleme; - aber das war ja auch nicht das Thema.
Thread beobachten
Seitenaufteilung abschalten