Hamegs HMO und SCPI

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

Reply to
Olaf Kaluza
Loading thread data ...

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

Reply to
Olaf Kaluza

*IDN?

Device: Airbus A320

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

:-)

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

:ACQuire: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/
Reply to
Joerg

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

formatting link

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/
Reply to
Joerg

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

Reply to
Olaf Kaluza

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!

formatting link
formatting link

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.

  1. 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

Reply to
Olaf Kaluza

Der Fehler laesst sich reproduzieren:

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

Ergebnis:

formatting link

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:

formatting link

Jetzt schreibe ich erstmal eine Email an Hameg. :)

Olaf

Reply to
Olaf Kaluza

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/
Reply to
Joerg

Seufz und wie lange predige ich schon, dass man RS232 auch ordentlich machen kann :) Selbst mit Xon/Xoff und Dreidraht geht es.

Saludos Wolfgang

--
Wolfgang Allinger              15h00..21h00 MEZ: SKYPE:wolfgang.allinger
Paraguay            mailer: CrossPoint XP 3.20 (XP2) in WinXPprof DOSbox
 Click to see the full signature
Reply to
Wolfgang Allinger

Am Thu, 29 Dec 2011 14:54:22 +0100 schrieb Olaf Kaluza:

Ich bin kein Qt-Spezi, aber erstmal würde ich zwei Dinge tun:

  1. Die Kommandosequenz von einem Terminal testen, und zwar eins, daß die Schnittstelle explizit öffnen und schließen kann (oder ein Shellskript, um es drei mal zu starten). Danach solltest Du wissen, ob's am Hameg liegt.

  1. Sicherstellen, daß das String-Handling von Qt auch wirklich so arbeitet wie Du meinst. Will sagen ob Workstring.clear() wirklich den String nicht nur löscht, sondern ggf. auch Speicher alloziert oder ob das automatisch passiert. Strings sind öfter für Überraschungen gut.

Und die geschichte mit dem Delay kommt mir irgendwie seltsam undefiniert vor, lohnt aber erst daran zu fummeln, wenn das DSO wirklich die Erwarteten Antworten gibt.

HTH, Marc

Reply to
Marc Santhoff

Davon halte nichts weil dies ja in das Timing eingreift. Allerdings hab ich schon daruber nachgedacht mir einen Adapter zu loeten und mal mit einem anderen Rechner mitzuschreiben was da wirklich ueber die RS232 geht.

WorkString wird hier noch nicht benutzt.

Aber der grundsaetzliche Gedankengang ist ja nicht doof. Ich habe auch gerade schon ueberlegt ob irgendwo in der ganzen Puffer/Fifo-Verwaltung was schief laeuft, aber:

  1. Habe ich gerade einiges an meinem Program geaendert ohne das das Ergebnis beeintraechtigt.

  1. Wenn ich irgendwo einen wilden Zeiger haette wuerde ich erwarten das Linux entweder mein Programm beendet oder mein Programm Linux beendet. Aber es laeuft alles stabil.

Was mich aber an Qt noch etwas erstaunt sind Sachen wie dies hier:

class QQueue FIFO_Out; QString Test123;

Test123="Hallo"; FIFO_Out.append('a');

Anders als man es in C fuer echte MaennerInnen gewohnt ist, scheint man nirgendwo angeben zu muessen wie gross die Speicher sind die man da so nutzen kann. Aber das scheint wohl so ueblich zu sein und die Daten liegen einfach irgendwo... Leider gibt es aber wohl auch keine Qt Newsgroup wo man mal fragen koennte.

BTW: Wer sich schon immer gefragt hat wieso Computer heute so langsam sind der sollte mal ueberlegen was alles hinter QString versteckt sein muss. :-)

Die Delayfunktion ist von mir. Letztlich wird dort nur darauf gewartet das der Oszi irgendwann 0x0a sendet damit ich weiss das seine Daten vollstaendig angekommen sind. Die Zeit ist sozusagen ein Timeout damit bei einem Fehler nicht ewig gewartet wird.

Olaf

Reply to
Olaf Kaluza

Ich habs! Der Fehler lag doch bei mir.

Das Delay war schuld. Gut das wir mal drueber geredet haben. :-)

Ich muss es vergroessern:

Delay(10000);

Ein Delay(5000); reicht noch nicht! Es dauert also irgendwas zwischen 5 und 10s um den Speicher des Hamegs auszulesen. Das haette ich nicht gedacht.

Wenn mein Timeout zu frueh kommt dann mache ich einfach die serielle zu und macht man dann unmittelbar danach den Port wieder auf sind zwar meine Buffer alle leer, aber der Hameg ist immer noch fleissig am senden. ARGH! Ausserdem braucht wohl die RS232 einen Moment bis sie sich richtig aufsyncronisiert wenn man sie oeffnet waehrend gerade Bytes reinkommen. Das finde ich auch erstaunlich.

Und es erklaert auch warum ich diesen Fehler vorgestern nicht hatte, weil der Buffer des Hamegs je nach Messbereich verschieden gross ist.

Aber ganz schoen langsam! Vor allem weil es ja erstmal nur ein Kanal ist. Ich hoffe wirklich das es ueber USB schneller geht.

Olaf

Reply to
Olaf Kaluza

Sei froh dass es "nur" so wenig ist. Ich habe bei einem Tek mal geschlagene 20sec gewartet bis er geruhte die Messkurve auf den USB Stick zu schreiben.

BTW, man kann so einen Daten-Transfer normalerweise ueber Portmon mittickern lassen. Sozusagen als Eigen-Trojaner :-)

Dann sollte auffallen wenn ein erwarteter Transfer ab einer gewissen Stelle abbricht oder ab wann nur noch Marmelade kommt.

--
Gruesse, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

Sowas kann man unter Linux auch "mal eben" ohne zu Löten mit strace(1) ganz gut sehen.

Gruß, Enrik

Reply to
Enrik Berkhan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.