Hameg HMO1524 Waveform per SCPI und USB auslesen

IIRC war es Olaf Kaluza und sein Terminalprogramm verschluckte die CR Signale. Als er ein Terminalprogramm benutzte wo CR durchkam ging es m.W.

Bei den meisten Scopes ist das so.

Kann ich fuer Hamegs nichts zu sagen. Bei meinem (Instek) weiss man das aus diesem vorherigen Kommando:

:ACQuire:LENGth

Bei Instek wird als zweites Paket nach der folgenden Anfrage das Datenvolumen gemeldet:

:ACQuire:MEMory?

Das ist dann allerdings bereits das Abholkommando. Beim Instek sind es immer acht Bytes mehr als der Speicherinhalt. Ist im Prinzip normaler SCPI Standardkram, ich weiss aber nicht wie gut sich das HMO1524 daran haelt.

Sleep well in den Bettgestell :-)

--
Gruesse, Joerg

http://www.analogconsultants.com/

Tja, wir verwenden hier aber echte Maennersprachen. Also C++!

Es funktioniert. Aber die Schnittstelle ist in der Praxis kaum brauchbar weil viel zu langsam. Wenn ich mich recht entsinne so dauert es 7 Sekunden einen einzelnen Waveform auszulesen. Ausserdem habe zumindest ich auch keine Moeglichkeit gefunden nur einen Teil der Daten auszulesen.

Hier mal ein Ausschnitt aus meinem Programm:

void SCPI::WaveData(int Channel,QString *Wave) [..] SendString = ":CHAN"; SendString += QString::number(Channel); SendString += ":DATA?\n";

MainInit::OsziDevice->OpenPort(RS232Parm->RS232_Settings); MainInit::OsziDevice->SendQString(SendString); [..]

Hm..noe.

Ja. Ich merke zwischen RS232 und USB keinen signifikanten Unterschied. Und wo wir schonmal dabei sind, auch die Ethernetkarte ist nicht schneller. Wenn du wissen willst wieso, brauchst du nur mal die Karte hinten rauszuziehen. Da ist ein FTDi USB/RS232 Wandler drauf. Von den Karten geht es dann naemlich seriell ins Gehirn des Oszis.

Olaf

Das ist ja ernsthaft gruselig und wird sogar vom Billig-Rigol besser gemacht (das hat allerings auch kein Ethernet oder RS232).

Gruß, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

Johannes Bauer schrieb:

Mein Rigol (DS1052E) hat RS-232 und USB und trotzdem hat Rigol der Versuchung widerstanden, USB über einen USB->RS-232-Wandler zu implementieren. Stattdessen ist -- wie es sich gehört -- die USB Test and Measurement Class implementiert und die Geschwindigkeit über USB ist tatsächlich schneller als über RS-232.

Christian

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

Würde ich nochmal bei 0 anfangen würde ich a) kein LabView verwenden und b) für Linux auf dem Meßrechner stark machen.

Aber das hilft mir jetzt nicht.

Ohjee... 7 Sekunden ist verdammt langsam. Vielleicht kommen daher meine Fehler. Der Timeout steht nämlich auf 2000 ms. Man kann nur hoffen, dass eine LAN Schnittstellenkarte da besser ist.

OK also (:)CHAN1:DATA?\n Das mache ich hier auch. Dann lag es wohl an den Timeouts.

Aber selbst seriell könnte ja schneller sein. Vermutlich ist der auch noch auf eine geringe Baudrate gestellt.

Gibt es einen Nachfolger von dem Scope ohne diesen Baufehler?

Vielen Danke für Deine schnelle und hilfreiche Antwort hier!

Beste Grüße,

--
Jonas Stein

Kann schon sein. :-) Funktionieren denn andere Kommandos? Zum Beispiel:

MainInit::OsziDevice->SendQString("*IDN?\n");

Oder:

switch(Mode) { case TrigAUTO: SendString = "TRIG:A:MODE AUTO\n"; break;

case TrigNORM: SendString = "TRIG:A:MODE NORM\n"; break; }; MainInit::OsziDevice->OpenPort(RS232Parm->RS232_Settings);

Ist sie nicht. Alle drei Schnittstellen werden (IMHO) auf ein serielles (syncron?) Protokoll umgesetzt um mit dem Prozessor zu reden. Ich habe zwar ueber die LAN-Karte noch nichts programmiert, aber alleine wenn man sieht wie lange die Karte braucht um nur einen Screenshot vom Oszi zu holen dann weiss man was Sache ist.

Achte darauf das du die modernste Firmware im Oszi hast. Ich glaube Hameg arbeitet auch noch an den SCPI Kommandos. Es gibt ja auch 1-2 Ungereimtheiten in der Doku. Ausserdem stand auch irgendwo das sich in der neuen Firmware der HMO2524 auch etwas am SCPI aendern wird. Daher vermute ich mal das SCPI noch ziemliche Baustelle ist.

Nein. Der ist schon maximal schnell. Aber die Daten werden ASCI-Codiert uebertragen und zwischen den Bytes gab es noch ein Trennzeichen. Das ganze ist ja ganz schoen aufgeblaeht. Ausserem haben die Babys ja auch einen fetten Speicher. Schneller wuerde man es nur bekommen wenn man das Oszi veranlassen koennte nur einen Teil seines Speichers zu verschicken. Das habe ich aber nicht geschafft.

Naja, das ist wohl weniger ein Fehler als eine Designentscheidung. Schneller waere teurer und wer braucht das schon.

Meine Idee war halt ein Programm zu schreiben das den Oszi zu 100% auf dem PC visualisiert und nur die Hardware extern zu nutzen. Dafuer ist die Schnittstelle aber eindeutig zu lahm. Deshalb hab ich die Sache erstmal eingestellt. Ein Programm zu schreiben das nur die DAten ausliesst ist eher einfach. Andererseits funktioniert auch der USB-Stick ganz gut, daher brauch man soetwas kaum.

BTW: Mein HMO2524 in der Firma geht morgen nach Hameg zur Kur und Gehirnwaesche. Bin mal gespannt wie er sich hinterher verhaelt.

Olaf

Das war des Rätsels Lösung! Nachdem ich den Timeout hochgesetzt habe bekomme ich auch Daten.

Zwischendurch mischt das Scope aber

1` als Zeichenfolge darunter. Wenn keine weiteren Daten mehr koemmen folgen nur noch 1`1`1`1`1`1`1`1`1`...

Der Datenstrom beginnt hier manchmal mit einem und manchmal mit mehreren 1`. Ich sehe das System dahinter noch nicht. Es hat bestimmt etwas mit Statusbits zutun, die vorangestellt werden.

Vermutlich soll man die Daten in fester Paketgröße lesen. Weiß jemand in welcher?

--
Jonas Stein

Fehler.

Das hoert sich burggrabenverdaechtig an, da muss mehr als einer bei der Entwicklung etwas geschlafen haben.

auf

Wenn man die ACQ Length auf einen moderaten Wert einstellt sollte ein gescheites Scope von sich aus in der Lage sein nur den Teil zu senden und nicht noch den ganzen Rest des Speichers wo keine aufgenommenen Daten drinstehen.

Noe, Instek konnte das schon seit Jahren. Ich lasse dieses DSO aus augenoptischen Gruenden (muss bei Loeten 2.5x Brille tragen und beim lesen aber max 1.75) meist ueber den Laptop mitlaufen und das ist praktisch eine Live-Uebertragung. Ebenfalls beim Abfragen eines Einzelschusses ... blitz ... Daten sind auf dem PC oder auf dem USB-Stick.

Selbst das kriegen einige hin zu vergeigen. Ich wollte mal mit einem Tek auf einen Stick schreiben. Das klappte auch, das Scope bat sich aber jedesmal sehr viele Sekunden Bedenkzeit aus. Bin jedenfalls froh dass ich ein DSO ohne solche Macken habe.

Ich wuerde darauf bestehen dass sie das bereinigen. Spanabhebende Datenuebertragung war im Zeitalter der Lochstreifen abkzeptabel, aber heute?

Manchmal frage ich mich wie sowas passieren kann. Probieren die ihre eigenen Entwicklungen nicht mehr selbst aus?

--
Gruesse, Joerg

http://www.analogconsultants.com/

Am 15.04.2012 22:23, schrieb Joerg:

Wozu dass denn? Application Note + Reference Design + Auftragsfertiger --> feddich!

Ich habe gerade einen Trennverstärker zerlegt bei dem am Ausgang im Sinus merkwürdige Sprünge waren:

Ausgang eines TL082 auf die Basis je eines BC547/557, die Emitter zusammengeknotet und auf den Ausgang + Gegenkopplung geklemmt. Also klassische B-Endstufe ohne Ruhestrom, kann nicht funktionieren :-(

Butzo

Da liegt eines der Probleme. Hinzu kommt dass etliche Referenzdesign heutzutage "iffy" sind.

Alter Trick: Un piece de resistance von den beiden zusammengeknoteten Basen auf den Emitterknoten. Knapp 100ohm oder so. Wenn die Last nicht zu herbe ist und der TL082 in der Lage ist bis knapp ein Volt allein zu uebernehmen muesste das gehen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Am 16.04.2012 00:11, schrieb Joerg:

Jep! 68 Ohm

Da hängt maximal ein Oszi oder ein Opamp Input dran, ich hab die Transen einfach totgelegt, seitdem astreines sauberes Signal.

Ist ein AD202 + Kleinkram drin, gibt mit einem LEM 6A Wandler ein Messinterface für Strom und Spannung auf der 230V Seite.

Butzo

Bei Tek muss man sowieso etwas aufpassen. Ich habe einen Stick der ist partioniert. Also ein Teil ist FAT32, ein Teil ist EXT2. Ein Tek zerstoert dann beim Zugriff kommentarlos und ohne Fehlermeldung die Daten auf dem Stick.

Also jetzt verlierst du aber die Bodenhaftung oder?

Es gibt zwar durchaus Produkte wo ich mir genau diese Frage gestellt habe, aber die Oszis von Hameg gehoeren sicher nicht dazu.

Olaf

Aber auch sehr langsam. Die Refreshrate ist bei 115k2 über die Serielle nicht gerade berauschend, wenn die 25k Speicher eingestellt sind.

Und die .Net-Implemetierung der Software führt auf einem neu aufgesetzten, mit allen Updates gepflegten XP mit ansonsten mehr als ausreichender Rechenleistung zu sagen wir einmal unerwarteten Zuständen, wie zB. nach einem Aufwachen aus dem Ruhezustand findet die SW das Oszi nicht mehr oder so, also GWInstek ist diesbezüglich auch aber anders mühsam.

Die Software, die ohne .NET auf die Seriellen zugreift macht diesbzüglich quer durch die Bank _keine_ Probleme.

Grüße

- Michael Wieser

Aber der Pfiff ist, es funktioniert sofort und ohne Gedenksekunden.

Ja, diese .NET Implementation hat auch mich enttaeuscht. Das ist kein gutes System um drauf aufzusetzen, hat man sich was einfach gemacht. Auch hier kam ab und zu ein "DSO not connect" vor. Aber wenn es dann laeuft ist das recht flott. Jedenfalls gegenueber den Wartezeiten bei anderen Fabrikaten.

--
Gruesse, Joerg

http://www.analogconsultants.com/

Meine Schwester sagte sowas sei ihr mal mit einer SD-Karte passiert. Allerdings nicht in einem Oszilloskop.

Viele Sekunden Bedenkzeit bevor ein Paket ausgelesen wird findest Du im

21.Jahrhundert zeitgemaess? Ich nicht. Was machen die da im Scope? Irgendwas vorgluehen?

--
Gruesse, Joerg

http://www.analogconsultants.com/

Also ist jetzt schon wieder eine Weile her das ich das programmiert habe, aber daran kann ich mich nicht erinnern.

Haeh? Wieso? Einfach lesen.

Olaf

Ich hab gerade gesehen das Hameg am 2.4 eine neue Anleitung fuer die SCPI Kommandos der neuen Firmware auf ihre Homepage gestellt haben. Die sollte man wohl auf jedenfall mal lesen. Wenn ich das richtig sehe, habe es noch nicht probiert, gibt es jetzt auch die Moeglichkeit nur einen Teil der Datenpunkte auszulesen.

Olaf

wenn man nach dem Problemen mit dem Scope googelt landet man schnell in diesem thread, daher möchte ich gerne noch eine abschließenden Bericht für die schreiben, die mir geholfen haben und die hier verzweifelt landen.

Mein erstes Problem war eine veraltete und noch sehr fehlerhafte Firmware, die ich dann aktualisiert hatte.

Zweitens ist die Schnittstelle -wie mir hier auch schon erklärt wurde- kein richtiger USB Anschluß, sondern nur ein RS232 Wandler, der einen speziellen Treiber benötigt, um einen virtuellen COM Port in Windows anzulegen.

Eine Falle ist, dass Windows 7 das Scope als USB Gerät erkennt, einen Treiber installiert und man unter LabView wunderbar in USB-Raw kommunizieren kann. Z.B. *IDN? wird ausgeführt und man sieht keinen Fehler. Aber ganz sporadisch erhält man eben diese 1` Zeichen oder der Stream bricht ab.

Die Daten werden mit maximal 115kB als Zahlen in ASCII übertragen. Das heißt es werden viel mehr Byte übertragen, als eigentlich für die Zahlenwerte notwendig sind. Somit kann ein Datensatz schnell mal 6 MB werden. Hier ist unbedingt darauf zu achten, dass man keinen Timeout bekommt. Ich habe die Daten in LabView daher in 1024 Byte Stücken ausgelesen und dem Anwender die übertragenen kB angezeigt. So sieht man dass sich tatsächlich etwas tut und umgeht das Timeoutproblem.

Ein Tipp zum USB-Stick Anschluss: Hier konnte ich nur immer jeweils einen Kanal speichern und auch nur mit einer fixen Zahl von Datenpunkten. Ich meine 2000 Pkt. statt z.B. 1 Mio., bitte korrigieren, falls falsch, ich habe die Zahlen nicht mehr genau im Kopf. Daher geht es zum Stick auch schneller, als zum PC. Über dem PC Anschluß kann man jedoch die Anzahl der abzuholenden Datenpunkte angeben.

Ich hatte dann noch Kontakt mit dem Rhode und Schwarz/Hameg Support und muss sagen, dass man sich wirklich sehr viel Mühe gegeben hatte, mir zu helfen und ich auch relativ bald Kontakt mit einem Techniker hatte, der auch viele Verbesserungsvorschläge weitergeben wollte. Also vielleicht kann man bald per Druck auf "Offset" den Offset auf +/- 0mV stellen und alle Kanäle gleichzeitig als csv auf einen USB-Stick speichern.

Ich hoffe, dass das Gerät auch nach Firmwareupdates ohne Bildschirmschoner und die Menueführung so schnell und übersichtlich bleibt.

Man sagte mir, dass ein zertifizierter LabView Treiber seit einigen Wochen in Auftrag ist. Ausserdem würde man überlegen die Daten bei Bedarf Binär und nicht als ASCI zu übertragen. Dadurch würde die Übertragung um ein zehnfaches schneller, da jetzt nur

13 (0-9 . E ,) von 128 Bit genutzt werden. Also wird sicher bald erfreuliches auf der Webseite verlinkt sein.

Beste Grüße,

--
Jonas Stein

[...]

Vielen Dank fuer den ausfuehrlichen Ergebnisbereicht. Der wird vielen spaeteren Lesern helfen und leider machen sowas nur wenige.

Wenn Du nochmal Kontakt mit denen hast empfehle ihnen ein revolutionaeres Konzept mit dem sie sich viele solcher Schnitzer und viel Verdruss bei Kunden ersparen koennen: Sie sollen sich die einschlaegigen Konkurrenzgeraete beschaffen und eingehend probefahren. Besonders die aus Asien.

[...]

--
Gruesse, Joerg

http://www.analogconsultants.com/