Hamegs HMO und SCPI

Mon Dec 26, 2011 11:02 pm   

Ich glaub ich bin zu bloed und brauch mal eure Hilfe.

Hat schonmal einer ein Hameg ueber SCPI ausgelesen?

Ich habe die Kommunikation mit dem HMO jetzt grunsaetzlich laufen, ich
kann also z.B die Seriennummer oder das Geraet auslesen:

*IDN?
Device: HMO2022
SerNum: 014315064
Firmware: 03.740

Ich kann auch das Geraet veranlassen eine Messung als Singleshot
auszufuehren, oder die Helligkeit des Grids einstellen.

Bloss die Waveform Data bekomme ich nicht.

Zum Beispiel sollte das hier:
CHAN1:DATA:HEAD?\n

Unter anderem die Record Length of the Waveform in Samples liefern.
Es kommt aber immer
0,0,0,0
zurueck.

Dabei stehen die ausgewaehlen Samples auf DMAX, also 6000 und das
laesst sich auch so auslesen.

Auf CHAN1:DATA?\n also dem Auslesen der Daten antworte es dann
aber garnicht.

Gibt es irgendwas das ich vergessen habe?

Olaf

Mon Dec 26, 2011 11:26 pm   

Olaf Kaluza <olaf_at_criseis.ruhr.de> wrote:


Gut da hatte ich ein Fehler. Hab versehentlich die
Envelopeheader ausgelesen.

Auf CHAN1:DATA:HEAD?\n kommt jetzt:
-2.0360E-04,2.1960E-03,6000,1

Das Oszi hat also 6000Datensaetze fuer mich zum auslesen.

Aber auf CHAN1:DATA?\n kommt aber immer noch keine Antwort.

Interessanterweise scheint das Manual von Hameg da noch einen Fehler
zu haben. Sie geben dort als Beipiel an:CHAN1:WAV1:DATA?\n

Das entspricht nicht der Kommandobeschreibung. Aber beides
funktioniert nicht...

Olaf

Mon Dec 26, 2011 11:42 pm   

Olaf Kaluza wrote:

*IDN?

Device: Airbus A320

Configure now? [Yes] [No] [Abort]

:-)



Sicher dass die Syntax so stimmt? Bei mir sie die so aus:

:ACQuire<1>:MEMory?

Die Zahl ist dabei der gewuenschte Messkanal. Voher wird die Laenge so
gesetzt:

:ACQuire:LENGth

Ist zwar ein anderer Hersteller (Instek), aber die Syntax mit CHAN am
Anfang wird nur benutzt fuer das was man auch im Channel-Menue setzt.
Bandbreite, Offset und so. Im Prinzip sind die Kommandos sehr aehnlich
dem was man auf dem Bildschirm und in den Soft-Menues sieht.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Mon Dec 26, 2011 11:57 pm   

Olaf Kaluza wrote:

Das entspraeche auch nicht dem Standard. Ein Geraete sollte sich hieran
hatlen:

http://www.ivifoundation.org/docs/SCPI-99.PDF

Vor dem Kommando ist ein Doppelpunkt. Also:

:CHAN ... und so weiter.

Aber wie gesagt, :CHAN ist normalerweise zum Setzen von Kanalparametern,
nicht zum Auslesen.

Hatte mich vorhin vertippt, es muss (normalerweise) heissen:

:ACQuire1:MEMory?

Guck mal was es daraufhin sagt.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Tue Dec 27, 2011 12:04 am   

Joerg <invalid_at_invalid.invalid> wrote:


Das ist bei Hameg ganz anders. Sie benuten ACQ Befehle fuer andere
Dinge wie z.b das Abfragen der Samplerate oder andere Dinge
einzustellen.

Ich glaube aber ehrlich gesagt Hameg weiss selber nicht was ihr Oszi
koennen soll und ihre Anleitung schonmal garnicht. Es gibt von Hameg
ine Anleitung fuer die HMO072x bis HMO0202x. Dort ist der Lesebefehl
angeblich: CHAN1:DATA? (WAV1:DATA? geht auch nicht)


Dann gibt es noch eine Anleitung zu den dickeren HMO3522 und HMO3524.
Dort heisst der Lesebefehl TRAC:DATA?

Und man glaubt es nicht aber der liefert Daten! Man kann sogar mit
TRAC:FORM ASC von Binaer auf ASCI umstellen. Aber nicht auf CSV.
Dabei gibt es den Befehl laut Handbuch der neueren HMOs garnicht!

Es sieht so aus als wenn SCPI bei den HMOs noch eine ziemliche
Baustelle ist. Ausserdem fragt man sich wieso schon ihre eigenen Oszi
untereinander inkompatible Befehlssaetze haben muessen.

Ich glaub ich muss mal eine Mail an Hameg schreiben....

Olaf

Tue Dec 27, 2011 12:15 am   

Joerg <invalid_at_invalid.invalid> wrote:



Interessant. Das sieht Hameg anscheinend anders:

http://www.hameg.com/typo3conf/ext/hm_downloads/pi1/download.php?uid=5408

Seite 43


Alle Kommandos die ich sonst sende funktionieren und zwar ohne
Doppelpunkt. Ich habe es aber gerade probiert:

:CHAN1:DATA?
ReadCount:5120
-4.000E-01,-4.000E-01,-4.000E-01,-4.000E-01,-4.000E-01,
-4.000E-01,-4.000E-01,4.000E-01,4.000E-01,4.000E-01,
4.000E-01,4.000E-01,-4.000E-01,4.000E-01,4.000E-01,
[..]

Es geht! Bei diesem einen Kommando braucht er wohl einen Doppelpunkt.

Aber das hier z.B: (Seite 44) geht, wie auch alle anderen, ohne Doppelpunkt.
CHAN1:DATA:HEAD?
-2.0360E-04,2.1960E-03,6000,1

ARGH!


Nicht bei Hameg.



:ACQ1:MEM?
ReadCount:0

Keine Antwort.

Richtig ist wirklich: SendString = ":CHAN1:DATA?\n";

Olaf

Tue Dec 27, 2011 12:54 am   

Olaf Kaluza wrote:

Urgs. Da gibt es einen Standard und sie muessen trotzdem ihr eigenes
Sueppchen kochen.



:TRAC ist auch eigentlich fuer die graphische Anzeige, nicht die
Datenschaufelei an sich. Na ja, ist wohl der Mainhausener Dialekt von SCPI.



Das waere nicht gut weil dann geschriebene Routinen mit dem naechsten
Scope nicht laufen.



Ja, aber warte lieber bis ein Teil Deines inneren Frustes aufgeklart hat
sonst ist in Mainhausen die ganze Weihnachtsstimmung im Eimer :-)

Beim Instek ist eine Software dabei mit der man die Daten abholen kann,
muss man nicht unbedingt selbst schreiben. Mir war das sehr paesslich
weil ich nicht so der Programmierer vor dem Herrn bin. Damit kann man
auch einen Screen Shot vom PC aus machen und ... schwupps ... ist es
schon auf dem LAN Server oder gleich im Messbericht.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Tue Dec 27, 2011 8:30 am   

Joerg schrieb:


Kein Hersteller, der mir bislang untergekommen ist, hielt sich
vollständig an die SCPI-Spezifikation. Daher muss man ohnehin jedes Mal
die Routinen anpassen, wenn man ein Scope von einem anderen Hersteller
verwendet. Allerdings ist es schon bitter, wenn die Hameg-Scopes
untereinander inkompatible Befehlssätze aufweisen.


Beim Hameg ja auch, aber: "Unsere Software für aktuelle Produkte basiert
(wie im Businessumfeld gefordert) auf Windows®." (Zitat Hameg-Webseite)
Das wird Olaf also nichts nützen.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA

Tue Dec 27, 2011 8:59 am   

Ich glaube das Problem liegt darin das entweder mein Computer oder der
Hameg von einem boesen Geist besessen sind. Oder gar alle beide, aber
mit einem inkompatiblen. :-)

Das Kommando zum auslesen ist jedenfalls eindeutig so:

CHAN1:DATA?

Meine Funktion zum auslesen sieht so aus:

SendString = "CHAN";
SendString += QString::number(Channel);
SendString += ":DATA?\n";

//usleep(100000);

//Fuer Tests
SendString = "CHAN1:DATA?\n";

MainInit::OsziDevice->OpenPort(RS232Parm->RS232_Settings);

MainInit::OsziDevice->SendQString(SendString);

Lasse ich obiges ablaufen bekomme ich jedesmal reproduzierbar die
Daten vom Oszi geschickt.

Jetzt faellt natuerlich dem kundigen Programmierer auf das ich den
Inhalt von SendString erst muehevoll zusammenbastel, und dann
hinterher einfach billig mit denselben Daten nochmal ueberschreibe.

Das habe ich gemacht um auf die schnelle verschiedene Kommandos testen
zu koennen. Kommentiere ich diese Zeile aus so laeuft wieder mein
urspruenglicher Code. Und dann antwortet das Oszi nicht mehr!

Wie man aber erkennen kann sollte das Ergebnis jedesmal identisch
sein. Genauer gesagt habe ich mein Oszi auch darauf verwendet mir das
anzuzeigen. Es ist dasselbe!

http://www.criseis.ruhr.de/bilder/scpi_gut.gif
http://www.criseis.ruhr.de/bilder/scpi_schlecht.gif

Bleibt also nur die Annahme das es ein Timingproblem ist. Deshalb gibt
es das auskommentierte usleep Kommando. Das habe ich mal reingenommen
um das zu testen. Es macht keinen Unterschied.

Jetzt bin ich erstmal etwas ratlos. Ich glaub ich brauch ein Bier,
oder mein Oszi. Also einer von uns beiden jedenfalls. :-)


In dem Zusammenhang sind mir zwei unschoene Dinge aufgefallen.

1. Wie man ob in den Bildern sieht stellt das Osci bei der Decodierung
die 0x0a nicht da wenn es auf ASCII eingestellt ist. Okay, das ist
kein sichtbares ASCII-Zeichen, aber da haette man doch vielleicht \n
oder halt 0x0a anzeigen koennen wenn es keine ASCII Entsprechung gibt.

2. Ich habe die Einstellungen des Oszis gestern Abend abgespeichert
und heute wieder eingelesen. Es hat aber nicht auf mein RS232 Signal
getriggert. Irgendwas stimmte mit den Einstellungen nicht. Daraufhin war
ich mal in den RS232 Einstellungen drin um sie mir anzuschauen, konnte
aber keinen Fehler entdecken. Als ich aber dann das Einstellfenster
verlassen habe, da hat auf einmal alles funktioniert. Ohne das ich was
geaendert habe. Ich muss aber nochmal schauen ob sich das
reproduzieren laesst.

Olaf

Tue Dec 27, 2011 9:15 am   

Olaf Kaluza <olaf_at_criseis.ruhr.de> wrote:


Der Fehler laesst sich reproduzieren:

Ich hab den Oszi gerade mal kurz ausgeschaltet und lese dann meine
abgespeicherten Einstellungen zurueck.

Ergebnis:

http://www.criseis.ruhr.de/bilder/recall_err.gif

Das ist auch kein Zufall. Auch durch mehrmaliges triggern mit
denselben Daten wird dasselbe angezeigt.

Gehe ich dann einmal in das BU-Menue und schaue mir die RS232
Einstellungen an und verlasse das Menue wieder ohne was zu
aendern wird das hier angezeigt wenn ich das Testsignal nochmal
schicke:

http://www.criseis.ruhr.de/bilder/recall_gut.gif

Jetzt schreibe ich erstmal eine Email an Hameg. :)

Olaf

Tue Dec 27, 2011 3:18 pm   

Am Tue, 27 Dec 2011 08:59:09 +0100 schrieb Olaf Kaluza:


Hardware-Debugging von PC-Software, nicht schlecht. :)


Timingproblem möglicherweise ja, aber nicht vor dem Kommando. Der
auffälligste Unterschied der beiden Bilder ist die deutliche größere
Lücke nach dem ersten "C". Der Leitungsdekoder rastet ja auch drauf ein,
aber der SCPI-Interpreter verschluckt sich daran. Zum nachstellen
vielleicht mal ein kurzes usleep() zwischen "C" und AHN1..." testen.

Eventuell steht sogar was in den Büchern zum Hameg, wie genau das SCPI-
Timing sein muß?

HTH,
Marc

Tue Dec 27, 2011 4:01 pm   

Marc Santhoff <M.Santhoff_at_t-online.de> wrote:



Das weiss ich, deshalb bin ich ja ratlos. :-)

Der

Hat nichts zu sagen. Die Luecke entsteht dadurch das mein Linux wohl
in der Zeit kurz mit etwas anderem beschaeftigt war. Wenn ich
denselben String mehrmals sende dann habe ich durchaus auch
Aussendungen wo es diese Luecke nicht gibt und dann geht es auch
nicht.
Der Gedanke war mir naemlich auch als erstes gekommen als ich da drauf
geschaut habe.


Ist natuerlich schnell getestet, aber so einfach sollte es nicht sein.


Nein, dazu steht da nichts. Allerdings schreibt Hameg man soll doch
bitte eine echte RS232 und keinen USB-RS232 Adapter nutzen. (was ich
mache!) Das ist schon mal eine interessante Anmerkung. Einfach deshalb
weil man bei dem Protokollaufbau erwarten wuerde das es auch auch
ueber USB-RS232 geht. Oh und Hameg empfiehlt in so einem Falle doch
besser den USB-Anschluss des Oszis zu nutzen. Was zumindest in sofern
lustig ist weil sie einen FT232 in ihrer Buskarte verwenden.

Aber mir faellt da gerade noch was anderes ein. Ich habe bisher immer
nur 115200Baud benutzt. Ich koennte ja mal testweise auf 9600B
runtergeben.

Olaf

Tue Dec 27, 2011 4:08 pm   

Olaf Kaluza wrote:

Bei :FREQ scheint es auch einen Dopplepunkt zu brauchen. Jedenfalls
scheinen die den Standard was locker zu sehen.



Gibt es bei Mainhausen Burggraeben?



Wie wollen sie denn mit Extrawuersten den internationalen Markt angehen?
Hoffentlich sind die Hamegs wenigstens untereinander glecih im Command
Set, sonst wird es wie bei Hempels unterm Sofa.

Irgendwie erinnert mich das an den teutonischen GPIB Stecker. Der musste
natuerlich einen Pin mehr haben und anders sein als der amerikanische.
Von wegen den gleichen benutzen, wo kaemen wir hin, waere ja wohl die
Hoehe, waere das.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Tue Dec 27, 2011 4:27 pm   

Christian Zietz wrote:

Wer im Messgeraetebereich Linux benutzen moechte muss ein dickes Fell
entwickeln und sich mit VMs und dergleichen abfinden. Der Markt ist
derart klein dass sie fuer Nischen-OS oft nichts tun und auch nicht
dafuer testen. Ist riskant, selbst wenn man es hinkriegt kann das nach
dem naechsten Firmware Upgrade alles vorbei sein.

Im manchen weniger elektronischen Fachbereichen geht das noch weiter, da
gehen Hersteller schonmal davon aus dass die Kaeufer LabView haben.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Tue Dec 27, 2011 4:35 pm   

Olaf Kaluza wrote:

Beim schlechten ist ein Bit mehr zwischen "C" und "H".



Sieh mal nach ob Dein RS232 Timing ok ist. Sieht akut nicht so aus.



Sieht nach einem SW Bug aus, kann passieren wenn das Scope gerade
rausgekommen ist. Es macht auf jeden Fall ein huebscheres Bild als mein
Instek, irgendwie sieht das beim HMO-2022 aufgeraeumter aus.

--
Gruesse, Joerg

http://www.analogconsultants.com/