Hallo, ich möchte gern die Messwerte eines Hameg HMC8012 DMM per PC(Win7) über USB oder Ethernet auslesen und live als Trendchart darstellen. Mittels SPCI Befehlen sollte das ja machbar sein. Hat jemand das schonmal gemacht und kann mir sagen on ich die maximalen 200 Readings/sec auch über den PC auslesen kann, oder ob hier die Geschwindigkeit begrenzt ist? Danke und Gruß
Also, wenn das DMM wirklich 200Werte / sec erfasst (Wahrscheinlich nur bei reduzierter auflösung, ohne filterung, und mit ein paar hacks) - dann hast du 1/200 = 5ms Zeit. Auf nem Windows-PC leider unrealistisch. Du wirst eher so bei 20ms herauskommen, wenn du dein Programm vernünftig schreibst, und der PC grad nix anderes tut.. Und das auch nicht immer, sondern nur oft. Was hast du denn vor?
Genau die 200 sind dann mit 4,5 Stellen Auflösung. Ich möchte gern das Multimeter um eine Trendchartfunkionalität erweitern. Die Agilent Modelle ab 34461a haben das. Für mich ganz praktisch um den Spannungsverhältnis über die Zeit gleich zu sehen und nicht erst die Logfiles auswerten zu müssen. Da hast Du Recht, da werde ich mit Win7 nicht unter die 15,6 ms kommen. Kannst Du Dir sowas mit Linux auf nem RPi vorstellen?
Klar, SCPI über Ethernet kann jeder. Schickst ein Read\r\n oder Aquire\r\n oder sowas und kriegst Daten. Kann man mit jedem beliebigen Telnetclient aka putty machen. aber auch linux ist kein echtzeitsystem. wie die realen werte da so sind, keine ahnung. wenns dir nicht drauf ankommt, dass die werte deterministisch und zu exakten zeitpunkten geholt werden, kannst du das ja durchaus machen, dann aber lieber direkt aufm pc, da ists mit der weiterverarbeitung einfacher, und der hat einfach mehr bumms...
Sagt mal fühlt Ihr die Antworten oder gibt es da auch belastbare Aussagen oder vielleicht sogar Kenntnisse? 1) Das Hameg HMC8012 hat mit USB TMC, Ethernet/LXI 100Mbps und sogar per IEEE488.2 ausreichend schnelle Schnittstellen, um die 200 Messwerte/s zu übertragen. Nur der optionale IEEE Bus mit 1 MByte/s kommt aufgrund der intensiven Header vermutlich in straucheln, aber die meisten modernen Karten und Geräte unterstützen HS-488 mit 8 MByte/s (müsste man bei Hameg anfragen). 2)"... 5ms Zeit. Auf nem Windows-PC leider unrealistisch." Was habt denn Ihr für Hardware daheim stehen!? Die aktuelle Gigahertz Klasse mit USB2.0/3.0, voller DMA Unterstützung soll keine 200 Messwerte/s empfangen und verarbeiten können? Jeder streamt heute Videos mit erheblich höheren Datenraten aber messtechnisch soll Windows am Ende sein. Das ist ein kleines bisschen naiv. 3) "Echtzeit" - ein schwer geschundenes Wort, besagt es doch eigentlich nur, dass Daten in der Geschwindigkeit verarbeitet und bereit gestellt werden, in der man sie benötigt. Es steht nicht für "kaum vorstellbar wahnsinnig schnell". In dieser Anwendung müssen 200 Messwerte empfangen, verarbeitet und dargestellt werden und das alles verzögerungsarm. Wenn das System es schafft, dann ist es quasi ein Echtzeitsystem für diese Aufgabe. 4) Windows arbeitet oft für sich selber. Stimmt, ist aber meist nicht dramatisch und ausserdem gibt es mittels Multicore Programmiertechniken, die solche Probleme umschiffen. Diese sind aber sicherlich noch nicht bei zu erwartenden 200 Messwerte/s relevant. Gruß kokisan
Moin! Ich würde mir mal die Logs mit Zeitstempel ansehen. Man wird feststellen, dass die Einträge nicht in exakten Zeitabständen erfolgen. Ich postuliere: wenn das schon bei der internen Aufzeichnung so ist, wird es extern nicht besser werden. Besonders wenn der Auslöser für die Messung ebenfalls von Außen kommt. Evtl. für sowas doch auf Oszi-Dings ausweichen (Stichwort Roll-Mode). Grüße
Kokisan: Das Problem sind die Timerinterrupts des Windowssystems alle 15,6 ms. Würde das DMM die Werte einfach kontinuierlich schicken, wäre das wohl kein Problem, jedoch muss ich hier für jeden Messwert ein SPCI Request schicken. Guido: Wenn die Zeitstempel nicht ganz genau stimmen ist das nicht tragisch. Ich möchte halt live Tendenzen sehen, bspw. geringe Spannungsabweichungen durch eigenerwärmung. Mit dem Oszi, oder zumindest meinem Oszi kann ich keine Änderungen im mV-Bereich bei 2V/Div sichtbar machen. Schön wäre natürlich auch für Strommessungen Peaks mitzubekommen, daher die hohe Abtastrate.
Hallo Stefan, der fixe Timerinterrupt ist aus alter Zeit. Schon seit Jahren können die Systeme den Timer über die Win32-API auf minimale 1ms setzen. Über interne APIs lassen sich noch geringere Zeiten programmieren. Gruß
Guter Hinweis, da muss ich mich nochmal einlesen. Danke dafür.
Didi S. schrieb: > Hallo Stefan, > > der fixe Timerinterrupt ist aus alter Zeit. Schon seit Jahren können die > Systeme den Timer über die Win32-API auf minimale 1ms setzen. Über > interne APIs lassen sich noch geringere Zeiten programmieren. > > Gruß Dann zeig mal wie man das macht, dass man in Windows deterministisch zu äquidistanten Zeitpunkten dinge tut. Und zwar, weils hier grad so schön passt, im 5ms Raster. Frage - Verarbeitung- Antwort. Mit nem externen Gerät, über ne Schnittstelle. Ich weiß nämlich wirklich nicht wie das geht, und, da ich nichts kenne was ernsthaft sowas auf Windows macht, sondern im gegenteil selbst embedded dinge bau, damit ich sowas machen kann.. du hast hier wohl "auch belastbare Aussagen oder vielleicht sogar Kenntnisse?" dann mal her damit.
Ich habe ein kleines Programm geschrieben um die Geschwindigkeit der Schnittstelle zu testen. Damit komme ich im Schnitt auf 200 Messwerte/s. Kann natürlich sein, dass da einige Werte doppelt sind weil ich mit Fetch auslese. Meine Parameter: USB - VCP (Port66) DCV (Ohne zweiten Messwert) Messrate: Fast
Dann miss mal bitte, wie lange du brauchst, für dein Thread.Sleep(1).
1 | long gesamtzeit = 0; |
2 | |
3 | Stopwatch gesamtzeitmessung = new Stopwatch(); |
4 | gesamtzeitmessung.Start(); |
5 | for (int i = 0; i < 1000; i++) |
6 | {
|
7 | Stopwatch einzelzeitmessung = new Stopwatch(); |
8 | einzelzeitmessung.Start(); |
9 | System.Threading.Thread.Sleep(1); |
10 | einzelzeitmessung.Stop(); |
11 | gesamtzeit += einzelzeitmessung.ElapsedMilliseconds; |
12 | }
|
13 | gesamtzeitmessung.Stop(); |
14 | long durchschnitt = gesamtzeit / 1000; |
Mit diesem Code komme ich auf meinem Rechner auf 9ms.
Da bin ich ja doch beeindruckt, wie schnell Du das mal eben getestet hast. Die doppelten Werte stören auch vorerst nicht, da es ja wie gesagt mir eine Tendenz zeigen soll. Durch Deinen Test weiß ich, dass es sich lohnt da doch mehr Zeit reinzustecken und etwas mit grafischer Darstellung umzusetzen. Wird bei mir allerdings deutlich länger dauern, da ich nicht so versiert im Programmieren bin - ist ja aber eine schöne Übung :-) Kann das Tool leider erst am Montag testen, da ich übers Wochenende unterwegs bin. Vielen Dank für Deine Hilfe/Info!
Hallo Dunno, werd ich dann auch mal testen, wären ja fürs erste schonmal gute 100 Readings / sek.
Das ist schade, dass das HMC8012 nicht in ein Buffer schreiben kann, wie Agilent, Fluke oder Keysight. Dort kann man die Daten völlig entspannt aus dem Buffer, als FIFO benutzt, regelmäßig abholen, ohne dass eine Messung verloren geht oder doppelt gelesen wird, auch wenn der PC mal einige Zeit was anderes macht. Erstaunlich dass das Hameg nicht kann. Hätte ich nicht erwartet. Wollte mir das HMC als 3.-Gerät holen. Ist aber nun definitiv gestorben. Danke für den Thread!
Didi S. schrieb: > Nur der optionale IEEE Bus mit 1 MByte/s kommt aufgrund der > intensiven Header vermutlich in straucheln, aber die meisten modernen > Karten und Geräte unterstützen HS-488 mit 8 MByte/s (müsste man bei > Hameg anfragen). Also ich habe nur eine HP82341C IEEE488 Karte unter Win2000 im Einsatz. Der schafft es locker 1000 Werte/Sek aus dem HP34401 auszulesen. Allerdings nur bei abgeschalteten Display und DC 4,5 Stellen. Ein Bildschirminhalt eines Oszillografen auszulesen ( 1024*256 ) dauert etwa 1 Sekunde ebenfalls über IEC-Bus. Es braucht dazu kein HS-488 mit 8Mbyte/sek dazu. dafür reichen auch die üblichen 350Kbyte/sek älterer Karten. Ralph Berres
Hallo Ralph, ich stimme Dir und Deinen Erfahungen voll zu. Die HP82341C war ihrerseits eine der robustesten und schnellsten Karten auf dem Markt und schaffte mehr als die anfänglichen spezifizierten 1 MByte/s. Auch die alten CEC-Karten (später Keithley) und die NI Karten waren flott. Einzig die Hameg-Karten (gibt es schon lange nicht mehr) dümpelten vor sich hin. Karten anderer Hersteller hatte ich nicht im Einsatz. Für die gewünschten 200 Werte/s reicht dieser Bus prinzipiell locker aus. HS488 hat sich meiner Erfahrung nie durchgesetzt. Ich kennen nur ganz wenige Messgeräte, die dieses unterstützen. Und wenn ich mich erinnere, dann gab das langsamste Gerät am Bus die maximale Übertragungsgeschwindigkeit vor. Also war es durchaus sinnvoll zwei IEEE488-Karten für den Betrieb von zwei Bussen vorzusehen und HS488 Geräte auf dem Bus zu separieren. Aber alles Historie ... Aber das Problem mit dem HMC8012 scheint ja wirklich an anderer Stelle zu liegen. Ein heutiges Gerät dieser Preisklasse ohne Buffer und damit der Möglichkeit der blockweisen Abholung von Daten ist nicht ganz zeitgemäß. Gruß Didi
Didi S. schrieb: > Und wenn ich mich erinnere, > dann gab das langsamste Gerät am Bus die maximale > Übertragungsgeschwindigkeit vor. Aber nur wenn das langsamste Gerät adressiert wird. Ansonsten hält er sich weitgehend raus und bremst auch unwesentlich aus. Ralph
Meint Ihr, diese Buffergeschichte ist ein reines Firmware Thema oder müsste Hameg hier etwas an der Hardware anpassen?
Stefan D. schrieb: > Meint Ihr, diese Buffergeschichte ist ein reines Firmware Thema oder > müsste Hameg hier etwas an der Hardware anpassen? Das müsstest du Hameg fragen. Selbst wenn bereits ausreichend Ram vorhanden ist, und nur eine Softwareänderung notwendig ist, kann ich mir kaum vorstellen, das Hameg solch ein Update vornimmt. Also ist das mehr eine rhetorische Frage. Hameg schreibt in den technischen Daten , das er 200 Messungen/Sek bei 4,75 Stellen macht. Also kann er dies auch auf den Bus schreiben. Und das ohne zusätzliche Einschränkungen. Ralph Berres
:
Bearbeitet durch User
Wenn es für Nutzer wie den Erstaunten ein Kriterium ist das Gerät nicht zu kaufen und sich der Programmieraufwand in Grenzen hält könnte Hameg ja schon darüber nachdenken. Wenn ich mir anschaue, wie umtriebig Keysight mit ihren FW-Updates ist muss das sich das ja wohl auszahlen. Und vielleicht liest Hameg hier ja mit :-)
Ich lese mit Interesse über die Erfahrungen mit dem HMC8012. 3 Fragen, deren Antworten ich aus dem Manual nicht (oder nicht sicher) erkennen kann, hätte ich an Besitzer: 1. Zur Erklärung: (M)ein HM8112, also ein uralter Vorgänger, misst im AC-Bereich auch den DC-Anteil, nach der Erkenntnis das 1 VDC auch 1 VRMS und nicht 0 ist. Das kann man technisch einsehen, ist praktisch ungeheuer nervend. Macht das HMC8012 auch so einen Unsinn oder sind AC-Messungen auch AC-gekoppelt? 2. Ist das HMC8012 auch über den HMExplorer zu erreichen? 3. Das HMC8012 kann Messwerte intern (50.000 Messpunkte max.) oder auf einen USB-Stick loggen. Ist das nicht eine Lösung für das hier diskutierte Thema? Noch zwei kritische Anmerkungen: Da haben die ein hübsches grafisches TFT-Display und keine Funktion, die geloggten Daten grafisch darzustellen. Was für eine Verschwendung von Hardware, so eine (bestimmt nicht nur für mich) wichtige Funktion nicht vorzusehen. Bei den Oszis eine ähnliche Krankheit: Man hat zwar Megasamples als Speicher, aber eine "Ablenkzeit" von weniger als wenige 10 Minuten lässt sich nicht einstellen. Wie oft will ich Spannungs, Strom- oder Temperaturverläufe über längere Zeit, bis zu Tagen aufnehmen! Geht nicht, nur weil "sich der Knopf nicht weit genug drehen lässt" Grrrrrr.... Das Manual vom HMC8012 sieht hübsch aus, aber zur Kontrolle hat es noch keiner gelesen - außer vielleicht Rechtschreibung. Den Preis des HM in Relation zu dem Preis der hier gelobten Wettbewerbsprodukte muss ich mir noch mal ansehen.
Hallo Uwe, zu Punkt 1. kann ich Dir gerade nichts sagen. Zu Punkt 2. Ja es ist über den Hameg Explorer erreichbar, jedoch kannst Du ausser einen Screenshot vom Displayinhalt und einen rudimentären Terminalprogramm über das Du SPCI Befehle schicken kannst nichts weiter ausrichten. Auch hier hätte ich mir ein wenig mehr Kontrolle gewünscht. Für die HMP-Netzteilserie ist hier auch ein Arbiträrgeneratortool verfügbar welches man deutlich benutzerfreundlicher hätte gestalten können. Wenn man den HM-Explorer mal mit der Keysight Benchvue Lösung vergleicht ist hier noch sehr viel Luft nach oben. Kann jemand sagen, ob Benchvue nicht nur schick aussieht sondern auch praxistauglich ist? Zu Punkt 3. Das ist leider nicht die Lösung, da ich beim Testen nicht immer erst die Log-Datei auswerten möchten. Das ginge natürlich auch jedoch ist das deutlich umständlicher und vor allem zeitaufwendiger. Dem Thema mit dem Display stimme ich voll und ganz zu. Hier sehe ich auch noch sehr viel Potential für tolle grafische Features.
:
Bearbeitet durch User
Uwe B. schrieb: > 2. Ist das HMC8012 auch über den HMExplorer zu erreichen? Habe ich nie gebraucht, da ich alle meine Messgeräte über selbst geschriebene Basic-Programme auslese und auswerte. Uwe B. schrieb: > Da haben die ein hübsches grafisches TFT-Display und keine Funktion, die > geloggten Daten grafisch darzustellen. wie schon geschrieben. Uwe B. schrieb: > Bei den Oszis eine ähnliche Krankheit: Man hat zwar > Megasamples als Speicher, aber eine "Ablenkzeit" von weniger als wenige > 10 Minuten lässt sich nicht einstellen. Wie oft will ich Spannungs, > Strom- oder Temperaturverläufe über längere Zeit, bis zu Tagen > aufnehmen! Geht nicht, nur weil "sich der Knopf nicht weit genug drehen > lässt" Grrrrrr.... Mache ich mit einen HP34401 Multimeter und Benchlink Suite von HP Das Multimeter hat 1. eine wesentlich höhere Auflösung und die Messreihen welche ich mit Benchlink aufnehme können beliebig lang sein. Dann gibt es ja noch die Möglichkeit die Messwerte direkt in ein Excel-Sheet zu schreiben. Ralph Berres
Stefan D. schrieb: > Hallo Uwe, zu Punkt 1. kann ich Dir gerade nichts sagen. Vielleicht mal später, aber ich halte es für ziemlich sicher, dass DC-Werte tatsächlich nicht angezeigt werden, so, wie es sich gehört. > Zu Punkt 2. Ja es ist über den Hameg Explorer erreichbar, jedoch kannst > Du ausser einen Screenshot Screenshots bei Multimetern sind nicht sehr attraktiv oder hilfreich... Außer, wenn man Manuals über das Gerät verfasst. > Zu Punkt 3. Das ist leider nicht die Lösung, da ich beim Testen nicht > immer erst die Log-Datei auswerten möchten. Ja, eine Log-Datei ist keine Trendanzeige. Kann man die Log-Datei 1. schon auslesen, während noch gemessen. bzw. geloggt wird, ohne das die Messungen unterbrochen werden und 2. evtl. sogar erst ab einem bestimmten Punkt (z. B. der, dessen Werte neu seit dem letzten Auslesen hinzu kamen)? Ralph B. schrieb: > selbst geschriebene Basic-Programme Nanu, gibt es denn noch jemanden außer mir auf der Welt, der Basic schreibt? Das gibt ja gleich einen Sympathie-Punkt :) > Mache ich mit einen HP34401 Multimeter und Benchlink Suite von HP Irgendwie kriege ich das bei mir ja auch gelöst, wenn ich will. Notfalls sogar noch mit einem XYT-Schreiber auf Papier. Aber für deinen Ansatz muss man immer einen PC in Reichweite haben, und sich um das ganze System aus verschiedener Hardware und Software kümmern. Das nenne ich umständlich im Vergleich zu dem, was mit nicht einmal einer einfachen Einstellung, sondern lediglich einem erweiterten Einstellbereich am Oszi zu erreichen wäre. Die Genauigkeit spielt bei mir in den seltensten Fällen eine Rolle (oder sogar noch nie). Da passt der Oszi, zumal er vier Kanäle hat.
Uwe B. schrieb: > Ja, eine Log-Datei ist keine Trendanzeige. Kann man die Log-Datei 1. > schon auslesen, während noch gemessen. bzw. geloggt wird, ohne das die > Messungen unterbrochen werden und 2. evtl. sogar erst ab einem > bestimmten Punkt (z. B. der, dessen Werte neu seit dem letzten Auslesen > hinzu kamen)? Ich meine das Benchlink Programm von HP kann auch sowas. Aber das das Multimeter das selbst kann ohne PC im Hintergrund? Ich meine das können wenn überhaupt nur die aktuellen HP Multimeter in der höheren Preisklasse HP34410 usw. Uwe B. schrieb: > Nanu, gibt es denn noch jemanden außer mir auf der Welt, der Basic > schreibt? Das gibt ja gleich einen Sympathie-Punkt :) Ja aber nur HP Instrument Basic bei welcher man die IEC-Bus Karte direkt ansprechen kann. Der aktuelle Nachfolger HT-Basic kann das auch. Mit Visuell-Basic von Mikrosoft komme ich z.B. nicht klar. Auch nicht mit dem Basic mit welche man Amtel Prozessoren programmiert. Ralph Berres
Angehängte Dateien:
-
EasyArb.png
34 KB
Uwe B. schrieb: > Macht das HMC8012 auch so einen Unsinn oder sind > AC-Messungen auch AC-gekoppelt? Das HMC8012 ist bei der AC Messung AC gekoppelt. Wenn man AC+DC messen will muss man das einstellen. Stefan D. schrieb: > Für die HMP-Netzteilserie ist hier auch ein Arbiträrgeneratortool > verfügbar welches man deutlich benutzerfreundlicher hätte gestalten > können. Welche Version hast du? Das Modul wurde mal komplett ersetzt und funktioniert jetzt super. Ich habe mal ein Screenshot angehängt.
> Das ist schade, dass das HMC8012 nicht in ein Buffer schreiben kann, wie > Agilent, Fluke oder Keysight. Also ich kenne den HMC80012 nicht! Aber die aktuellen Oszis von Hameg (2024/2022) setzen alles was sie ueber ihre Buskarte (Ethernet oder USB) bekommen auf eine interne serielle Schnittstelle mit 115k2 um. Das ist dort dann der Engpass. Wenn sie das beim HMC aehnlich geloest habe, zum Beispiel weil sie Hardware weiterverwenden, dann wuerde ich mir von der Schnittstelle nicht zuviel versprechen. Olaf
Olaf schrieb: > setzen alles was sie ueber ihre Buskarte (Ethernet oder USB) > bekommen auf eine interne serielle Schnittstelle mit 115k2 um Kann ich bestätigen. Die Oszis melden sich sogar mit FTDI als Vendor-ID. Ist mehr ein Zeugnis von "USB kann ich nicht selber, da muss mir jemand helfen" :( Nicht mal 'ne eigene VID können sie einsetzen. 115k könnten eigentlich für die 5ms-Messzeit reichen (55 Zeichen/Messung). Gibt es eigentlich ein verbindliches Manual zu den SCPI-Kommandos im HMC8012? Bislang fand ich nur den lapidaren Satz: "SCPI commands largely compatible with Agilent 34410A". Oder muss man sich überraschen lassen, wenn ein Kommando mal nicht dabei ist? @Ralph: VB ist (leider) die einzige Sprache, die ich auf dem PC einigermaßen beherrsche. Und auch bloß VB5. Früher auch mal GW-Basic und QB. Ja, und davor noch das auf dem PET2000...
Unter http://www.hameg.com/470.0.html?L=1&tx_hmdownloads_pi1[product]=HMC8012&tx_hmdownloads_pi1[product2]=HMC8012-G&tx_hmdownloads_pi1[product]=HMC8012&tx_hmdownloads_pi1[product2]=HMC8012-G findest du die Programmieranleitung zu dem Gerät. Es beinhaltet u.A. sämtliche SCPI Befehle. Was den Unsinn betrifft eine IECbus Schnittstelle an einen RS232 Port zu hängen wie Hameg es macht, sage ich lieber nichts. Aber ich glaube das macht jetzt auch bei Keysight Mode , die auch immer mehr die IEC-Busschnittstelle als Option anbieten. Ralph Berres
Die Aussage mit den 115k stimmt nur für die älteren Geräte mit austauschbarer Schnittstelle. Die Geräte mit integrierter Schnittstelle arbeiten intern deutlich schneller. Wurde mir so auf einer Messe erklärt. Die HMC Geräte haben ja auch kein FTDI mehr verbaut, es scheint da also wirklich Änderungen gegeben zu haben.
Rudi schrieb: > Die Aussage mit den 115k stimmt nur für die älteren Geräte mit > austauschbarer Schnittstelle. Im HMO20xx ist eine austauschbare Schnittstelle HO720, USB & RS-232. Die wird, wie ich schon schrieb, als FTDI in USBView gemeldet. Die FTDIs können ja auch mehr als 115k. Ich habe Geschwindigkeitsversuche gemacht: Ein Screenshot als GIF geht erheblich schneller als als BMP (PNG eher noch schneller bei weniger Daten). Also wird im Oszi komprimiert. GIF dauert mit Verbindungsaufbau etwas über 1 Sekunde bei 20 kB Daten. BMP dauert mit Verbindungsaufbau recht genau 5 Sekunden bei 327 kB Daten. Der Verbindungsaufbau dauert offensichtlich ca. 1 s, allerdings spielt da vielleicht auch eine Zeit, die der Oszi zur Kompression braucht, eine Rolle. Die reine Datenübertragungsrate muss also über 523 kb/s liegen. Wenigstens das, aber immer noch weit USB Full Speed entfernt.
Rudi: Stimmt, die neue Version sieht deutlich besser aus, wenn man jetzt noch Kurven bspw. aus Excel importieren könnte wäre das ja fabelhaft. Werde mal versuchen die Daten mit 200 Readings/sec über nen Atmega vom HMC zu ziehen und an den PC weiterzugeben. Dann sollten ja die 15,6 ms Windows Timer Interrupt egal sein.
:
Bearbeitet durch User
Uwe B. schrieb: > Im HMO20xx ... Richtig, das gehört zu den älteren Geräten. Hier geht es um den HMC8012.
Angehängte Dateien:
-
EasyArb2.png
47 KB
Stefan D. schrieb: > Stimmt, die neue Version sieht deutlich besser aus, wenn man > jetzt noch Kurven bspw. aus Excel importieren könnte wäre das ja > fabelhaft. CSV-Import geht super. Es wird nichtmal ein vordefiniertes Format erwartet. Man kann eine beliebige CSV laden und bekommt dann alle nötigen Einstellmöglichkeiten, dass es richtig interpretiert wird. Ist hübsch gemacht.
Hallo Rudi, hab es mal ausprobiert, ist jetzt wirklich komfortabeler.
Angehängte Dateien:
-
NoiseDCV.JPG
130 KB -
LED_Diode_Test.JPG
100 KB -
Zoom.JPG
110 KB
Hallo, ich habe mal meinen Wunsch nach dem HMC8012 Trendchart zum Anlass genommen um mich erstmalig mit C#(Visual Studio 2015 Express) auseinanderzusetzen. Diese ersten Gehversuche möchte ich gern mit Euch teilen und daher hier meine aktuellen Resultate vorstellen. Bis jetzt ist ein Programm entstanden, das in der Lage ist über die VCP USB auf das HMC8012 DMM zuzugreifen, Messwerte über "FETCh" auszulesen und diese grafisch darzustellen. Allerdings gibt es noch viele größere und kleinere Dinge, die ich noch tun muss. 1. Im Auslesebereich unterhalb von 100 ms stürtzt das Ganze sporadisch ohne Exception ab (noch keine Ahnung woran das liegt) 2. Nach dem Ausschalten des Multimeters während des Auslesens kann nicht wieder neu verbunden werden 3. Die Timestamp beruht derzeit noch auf dem Standard Windows Timer, wodurch die Werte gerne mal um bis zu 15.6ms streuen. - Hier soll ein Multimedia Timer weiterhelfen 4. Die TMC Klasse soll noch implementiert werden, da ich mir davon eine höhere Auslesegeschwindigkeit erhoffe 5. Irgendwann soll es auch noch ein CSV Export geben, aber vorher sollte es stabil laufen. 6. Verbessern der gesamten Programmstruktur - es gibt mit Sicherheit einige Dinge, die ich recht umständlich gelöst habe. Wenn Ihr hier gute Tips für mich bezüglich Programmstabilität und Auslesegeschwindigkeit habt gerne immer her damit - aber seht es mir nach, mein Verständnis zur Programmierung in C# ist noch sehr begrenzt :-) Gruß Stefan
Wer mag, kann es natürlich frei nutzen oder verändern - und dann auch gern teilen :-) Bei Interesse werde ich dann meine neueren Stände auch hier zur Verfügung stellen.
Didi S. schrieb: > der fixe Timerinterrupt ist aus alter Zeit. Schon seit Jahren können die > Systeme den Timer über die Win32-API auf minimale 1ms setzen. Über > interne APIs lassen sich noch geringere Zeiten programmieren. Hallo Didi, hast Du hier ein Beispiel in C# für das heruntersetzen des Timerinterrupts? Hatte es schon mit nem MicroTimer versucht, der setzt aber nicht die Interruptzeit herab sondern nutzt lediglich die hochauflösende Windows Stop watch. Gruß und Danke
Ich habe mit EXCEL/VBA über WinSock eine Verbindung zum HMC8012 hergestellt, die Kommunikation läuft über SCPI Kommandos. EXCEL schafft eine Messwertabfrage mit "read?" max. alle 10ms. Die Messwerte ändern sich jedoch nur ca. alle 80-100ms in der Einstellung Fast.
hanss schrieb: > Ich habe mit EXCEL/VBA über WinSock eine Verbindung zum > HMC8012 hergestellt, die Kommunikation läuft über SCPI > Kommandos. > > EXCEL schafft eine Messwertabfrage mit "read?" max. alle 10ms. > > Die Messwerte ändern sich jedoch nur ca. alle 80-100ms in > der Einstellung Fast. Brav, sehr brav. Gut gemacht Hanss bei dem Inhalt Deiner Nachricht ist das mehr als nur 3 Jahre zu spät.
Dein Post ist nicht zu spät sondern komplett überflüssig. Ich habe inzwischen eine Verbindung mit der R&S VISA/USB hergestellt. EXCEL schafft eine Messwertabfrage mit "read?" max. alle 5ms. Die Messwerte ändern sich jedoch ebenfalls nur ca. alle 80-100ms in der Einstellung Fast. Es ist also nicht die Schnittstelle, sondern das HMC8012 liefert max. alle 100msec. neue Messwerte an den Schnittstellen. Schade! Möglicherweise hat ja jemand inzwischen eine schnellere Lösung gefunden. Bitte spart Euch ähnlich überflüssige Kommentare wie dieser Miwi.
Hallo Hanss, ich bin auch auf keine schnellere Abfragezeit gekommen. Ich vermute das die Prozessing Zeit einfach zu groß ist. Beim HMC8012 ist die leider nicht angegeben. Beim HMP2020 ist die mit <50ms angegeben. Ein Ansatz von mir war noch eine Schaltung, die sich dem HMC gegenüber als USB-stick ausgibt und die Daten an den PC streamt. Ist aber recht aufwendig und leider nichts was ich mal eben so aus dem Ärmel schüttel. Vielleicht will sich ja jemand dran versuchen. Schade das R&S sowas nicht einfach von Haus aus implementiert hat.
Hallo Stefan, scheint mir auch so, als wenn über ein USB-Dongle-Interface der einzige Weg wäre. Auf den Dongle schreibt ja das HMC im 2msec. Takt. Das wäre ein Projekt für einen ESP8266, der dann die Daten mittels einem FIFO Puffer über WLAN bereitstellt. Lohnt sich direkt danach zu suchen, ob da schon jemand ein FAT32 Filesysem realisiert hat. Wenn Du da etwas finden solltest, bitte um Nachricht.
Dazu werde ich demnächst keine Zeit haben. Ich könnte bei Interesse die aktuellste SW-Version meines Auslesetools zur Verfügung stellen. Läuft aber auch nur runter bis ca. 80ms. Ist für mich auch nicht dramatisch, da ich es hauptsächlich zum Langzeitausmessen von Spannungsreferenzen nutze.
:
Bearbeitet durch User
Vielen Dank, brauche ich nicht; ich habe mit Excel/VBA alles was ich brauche: Verbindung über LAN, VISA, USB-RAW, Messwerte, Chart und sehr flexibel. Nachdem das DMM in das LOG-File Messwerte im 4ms (250 Sampl/sec.) Abstand schreibt, werde ich bei Gelegenheit einmal diese Daten auslesen. Vielleicht ist das ja mit dem Trigger sowieso der bessere Weg. Jedenfalls einfacher als mit einem selbstgestricktem Dongle. Mit der Verbindung über einen ESP8266 wollte ich eine I2C Schnittstelle zum HMC8012 realisieren. Ist aktuell nicht im Focus, vielleicht später einmal.
Hallo Stefan, gibt es in den SCPI Kommandos einen Status/Flag, das man abfragen kann, ob ein NEUER Messert mit "READ?" abgefragt werden kann?
Hameg hat ein Kommando vorgesehen, aber nicht dokumentiert weil es nicht SCPI Konform ist. "Data:Stream 1\n" liefert ungefragt alle Messwerte in voller Geschwindigkeit (200/s). "Data:Stream 0\n" stoppt das ganze wieder.
Muss ich heute Abend gleich austesten, das wäre ja Spitze! Danke dafür!
@Stefan: Also bei meinem HMC8012 kommt bei "Data:Stream 1\n" nichts. Wie ist das bei Dir?
Es sprudelt nur so. Habe es mit HTerm gemacht. Vielleicht kommt Excel mit der Geschwindigkeit nicht klar? Die Daten sind durch ein Komma getrennt und haben kein "\n" nach jedem Zeichen.
Jetzt sprudelt es auch. Den DatenStream erhalte ich jetzt auch, allerdings auch immer nur ein Messwert jede 200ms egal ob über LAN oder USB, Excel oder Terminalprogramm. Wie ist der Zeit Abstand bei Dir von einem Messwert zum anderen?
200ms passiert bei mir nur, wenn die ADC-Rate am HMC auf Slow gesetzt ist.
Hallo Hanss, ich hätte Interesse an deinem Programm. Würde gerne Messwerte direkt auf dem PC auslesen für meine Abschlussarbeit. Wäre super wenn du mir das zukommen lassen kannst. Ich hab von dem gebiet leider kaum Ahnung eine Erklärung dazu wäre auch nicht schlecht. Vielen Dank schonmal! Mit freundlichen Grüßen Jonathan
Hallo @Stefan D., hast du mittlerweile eine neuere Version deines Programms? Falls ja könntest du die mir zur Verfügung stellen das sieht sehr vielversprechend für meine Messungen aus. MfG Jonathan Buck
Beitrag #6812136 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.