Hallo, wie der Titel schon sagt suche ich nach einer Möglichkeit die Daten eines Messgerätes über einen VCP mittels C#(.net 4.5) unter Win7x64 auszulesen. Die Messwerte werden maximal alle 4 ms aktualisiert und müssen gepollt werden. Jetzt habe ich als erstes das Problem den Windows Event Timer von default 15.6ms auf 1ms runterzusetzen. Habe hier zwar schon Codes für z.B den MicroTimer gefunden, dieser greift jedoch nur auf die Windowsstopuhr zu. Hat jemand von Euch einen Beispielcode in dem wirklich der Event Interrupt herabgesetzt wird? Sollte in der Win32 api möglich sein. Danke und Gruß
warum nicht einfach so schnell lesen wie möglich? Wozu überhaupt den Timer?
Ich wüsste für dieses Problem leider keine Lösung. Warum schreibe ich dann? Ein ähnliches Problem hatte ich auch mal, aber da Windows nunmal kein Realtime-OS ist, habe ich extern einen Mikrocontroller benutzt, der die Abfrage machte und dann an Windows gesendet hat. Dort wiederum kann man dann einfach ein DataReceived-Ereignis des seriellen Ports nutzen und braucht selber nicht mehr das Polling übernehmen.
Felix A. schrieb: > Ich wüsste für dieses Problem leider keine Lösung. Warum schreibe ich > dann? habe ich doch geschrieben. einfach ein einer while(true) schleife den ComPort mit Read auslesen.
Damit kann die Abtastrate aber nicht sichergestellt werden.
Weil ich nicht unbedingt Werte doppelt und dreifach erfassen will. Aktuell kann ich die Werte nur ca. alle 60 ms auslesen. Möglicherweise habe ich auch noch Geschwindigkeitseinschränkungen durch die Emulation des ComPorts, oder die Übertragungsrate des Messgerätes, daran mach ich mich, wenn ich zumindest mit 250 Hz pollen kann.
250 Hz sind auch unter Windows relativ langweilig. Stichwort: HPET. Und mit einem Kernel-Treiber kannst du beinahe Realtime fahren. Ob das allerdings mit C# möglich ist, weiß ich nicht.
Felix A. schrieb: > Damit kann die Abtastrate aber nicht sichergestellt werden. aber schneller geht eh nicht. Musst du vorher etwas senden, oder kommen die Daten von selber?
Felix A. schrieb: > Ich wüsste für dieses Problem leider keine Lösung. Warum schreibe ich > dann? > > Ein ähnliches Problem hatte ich auch mal, aber da Windows nunmal kein > Realtime-OS ist, habe ich extern einen Mikrocontroller benutzt, der die > Abfrage machte und dann an Windows gesendet hat. Dort wiederum kann man > dann einfach ein DataReceived-Ereignis des seriellen Ports nutzen und > braucht selber nicht mehr das Polling übernehmen. Felix, in meinem Fall hat das Messgerät eine USB-Schnittstelle und der µC müsste fürs Messgerät ein dann ein Host sein. Im reinen RS232 Fall geht das natürlich einfach über UART. Wie hast Du es gelöst? Hast Du einen Ansatz für µC als USB Host?
Stefan D. schrieb: > Felix, in meinem Fall hat das Messgerät eine USB-Schnittstelle und der > µC müsste fürs Messgerät ein dann ein Host sein Ja und? Immer noch wesentlich einfacher, als einen Windows-Kernel-Treiber zu schreiben (signiert natürlich). Der µC puffert auch die Daten, wenn Windows mal wieder anderweitig beschäftigt ist. Georg
sag doch erst mal wie die Kommunikation genau abläuft? Was verstehst du unter Pollen in diesem Zusammenhang? Wenn du ein einer Endlosschleife, nicht die 250 werte/s schaffst, dann geht es auch mit Timer nicht.
Peter II schrieb: > sag doch erst mal wie die Kommunikation genau abläuft? > > Was verstehst du unter Pollen in diesem Zusammenhang? > > Wenn du ein einer Endlosschleife, nicht die 250 werte/s schaffst, dann > geht es auch mit Timer nicht. Das Messgerät (DMM) erfasst Werte mit 250 Messungen/sekunde. C# Tool sendet den Befehl "FETCh\n" über VCP nach TimerTick(zb. 100ms) -> Messgerät antwortet daraufhin mit seinem aktuellen Messwert -> SerialPortReceived meldet empfangene Daten Das Messgerät benötigt für jeden einzelnen Wert eine Anfrage zur Übertragung.
Stefan D. schrieb: > Das Messgerät (DMM) erfasst Werte mit 250 Messungen/sekunde. > C# Tool sendet den Befehl "FETCh\n" über VCP nach TimerTick(zb. 100ms) > -> Messgerät antwortet daraufhin mit seinem aktuellen Messwert > -> SerialPortReceived meldet empfangene Daten > > Das Messgerät benötigt für jeden einzelnen Wert eine Anfrage zur > Übertragung. dann teste doch erst mal wirklich ohne Event und ohne Timer. Einfach in einer schleife. Ich vermute mal selbst dabei kommst du nicht auf 250 Abfrage/s. Hierbei könnte man USB mit seiner Latenz ein Problem darstellen.
1 | while(true) { |
2 | Send("FETCh\n"); |
3 | Read( ... ) |
4 | }
|
Gibt es keine Möglichkeit dem Gerät zu sagen, die Daten selbstständig zu senden?
:
Bearbeitet durch Moderator
Aso, das ist da dann eine Info, die meine Lösung so unmöglich macht. Und nein, für USB habe ich leider keine Lösung. Ich habe einen USB to Serial-Wandler gehabt und den uC zwischen USB-Wandler und Gerät geschaltet.
:
Bearbeitet durch User
Peter II schrieb: > dann teste doch erst mal wirklich ohne Event und ohne Timer. Einfach in > einer schleife. Ich vermute mal selbst dabei kommst du nicht auf 250 > Abfrage/s. Hierbei könnte man USB mit seiner Latenz ein Problem > darstellen. > > [c] > while(true) { > Send("FETCh\n"); > Read( ... ) > } > [/c > > > Gibt es keine Möglichkeit dem Gerät zu sagen, die Daten selbstständig zu > senden? Ich vermute auch, dass ich die maximale Rate nicht ereichen werde, dennoch würde ich zumindest so nah wie möglich drankommen. Auch das Auslösen des Empfangsevents kommt ja nur alle 15,6ms. Daher möchte ich diesen heruntersetzen. Nein, das Messgerät kann leider nicht selbstständig senden. Das würde einiges erleichtern. :-)
Stefan D. schrieb: > Ich vermute auch, dass ich die maximale Rate nicht ereichen werde, > dennoch würde ich zumindest so nah wie möglich drankommen. Auch das > Auslösen des Empfangsevents kommt ja nur alle 15,6ms. Daher möchte ich > diesen heruntersetzen. dann arbeite ohne Events! schneller als die Schleife geht nicht.
Mir fiel gerade ein, dass es da Chips von FTDI gibt, die VCP-USB-Wandler erkennen (vielleicht nur die eigenen). http://www.ftdichip.com/Products/ICs/FT313H.html Und dann vielleicht noch die FT120/121/122 sowie die Vinculum-Familie. Habe damit aber noch nichts gemacht. Trotzdem dürfte es einfacher sein, Windows die kürzeren Abtastzeiten abzuringen.
Felix A. schrieb: > Mir fiel gerade ein, dass es da Chips von FTDI gibt, die VCP-USB-Wandler > erkennen (vielleicht nur die eigenen). > > http://www.ftdichip.com/Products/ICs/FT313H.html > Und dann vielleicht noch die FT120/121/122 sowie die Vinculum-Familie. > > Habe damit aber noch nichts gemacht. > > Trotzdem dürfte es einfacher sein, Windows die kürzeren Abtastzeiten > abzuringen. Das wäre ok, im Gerät(HMC8012) werkelt soweit ich weiß ein FTDI. Das Datenblatt suggeriert zumindest, dass es nicht ganz trivial sein dürfte... Werd erstmal weiter versuchen das Maximum unter Windows rauszuholen. @Peter II, ich werd es mal ohne Events versuchen. Um aber nochmal auf mein Ausgangsanliegen zurückzukommen, hat denn jemand einen Beispiel C# Code wie man den Eventinterrupt herabsetzt?
:
Bearbeitet durch User
1 | Um aber nochmal auf mein Ausgangsanliegen zurückzukommen, hat denn |
2 | jemand einen Beispiel C# Code wie man den Eventinterrupt herabsetzt? |
wofür willst du das - es ist definitiv langsamer als die for-Schleife, egal was du machst - da passiert einfach viel mehr im Hintergrund, also einfach vergessen - mach die Schleife in einem Thread und gut ist dann auch mal daran denken eine echte serielle Schnittstelle zu verwenden - oder wenigstens ein USB-Serial Konverter mit FTDI Chip
Bei den FTDI Wandlern kannst du im Geräte Manager die Polling Zeit herunter stellen, ich glaube Default sind deine 16ms.
Bert3 schrieb: > dann auch mal daran denken eine echte serielle Schnittstelle zu > verwenden - oder wenigstens ein USB-Serial Konverter mit FTDI Chip wird wohl schlecht gehen, sein gerät hat je nur "USB". Man könnte als Trick noch versuchen, nach dem das 1.Zeichen angekommen ist schon den nächste Befehl zu senden, viel bringt das aber nicht.
Hallo,
hiermit kann man den Systemtick ändern / abfragen
[DllImport("ntdll.dll", EntryPoint = "NtQueryTimerResolution",
SetLastError = true)]
private static extern int NtQueryTimerResolution(out int
MinimumResolution, out int MaximumResolution, out int
CurrentResolution);
[DllImport("ntdll.dll", EntryPoint = "NtSetTimerResolution",
SetLastError = true)]
private static extern int NtSetTimerResolution(int DesiredResolution,
bool SetResolution, out int CurrentResolution);
1 | hiermit kann man den Systemtick ändern / abfragen |
sowas würde ich ja echt nicht machen - böse böse Stefan D.: denkst du die USB-TMC Schnittstelle koennte bessere Geschwindigkeit liefern
@ VolkerF: Danke, das werd ich mir ansehen. Hatte gedacht ich muss für Win7x64 an die Win32 Api dran. Bert3 schrieb: >
1 | hiermit kann man den Systemtick ändern / abfragen |
> > sowas würde ich ja echt nicht machen - böse böse > > Stefan D.: denkst du die USB-TMC Schnittstelle koennte bessere > Geschwindigkeit liefern Wieso böse böse? Wenn ich es nur temporär ändere, sollte es doch kein Risiko darstellen. Sehr gut möglich, allerdings habe ich das TMC noch nicht zum laufen bekommen. Treiber ist aktuell, Gerät auf TMC gestellt wird auch erkannt, liefert aber im Gerätemanager immer eine Fehlermeldung, dass es nicht verwendet werden kann(oder so ähnlich). Das ganze NI Visa Zeugs ist auch installiert, hapert halt momentan noch daran, dass das TMC-Gerät nicht verwendet werden kann - muss mich da mal an Hameg wenden - evtl. ist der verwendete Treiber halt doch nicht optimal. Evtl. gibt es ja noch die Möglichkeit ein RPi als Puffer einzubauen - kenne mich allerdings noch garnicht mit RPi´s aus.
Stefan D. schrieb: > Wieso böse böse? Wenn ich es nur temporär ändere, sollte es doch kein > Risiko darstellen. weil der Wert nicht ohne Grund so eingestellt ist. Danach kommt die CPU weniger zu schlafen. Es erhöht sich die Verlustleistung und der Overhead doch ständige Threadwechsel. Teste erst mal die schleife, dann kann man sich überlegen wie man weiter macht. Es ist einfach Dumm, wie das abläuft. Selbst das schnellste Interface kann man mit so einen Frage-Antwort spiel ausbremsen. Man versucht möglichst viele Daten auf einmal zu übertragen, damit man sinnvoll Geschwindigkeiten erreicht - hier wird genau das Gegenteil gemacht.
Schau mal hier, durch Zufall gerade gefunden: http://www.hobbytronics.co.uk/usb-host-board-v2 Der wandelt Uart oder I2C auf USB, ohne dass man USB-Programmierung machen müsste. Spielt auch mit den FTDI Serial Devices zusammen. Wäre das vielleicht was? Dann ginge die uC-Lösung wieder.
Felix A. schrieb: > Schau mal hier, durch Zufall gerade gefunden: > > http://www.hobbytronics.co.uk/usb-host-board-v2 > > Der wandelt Uart oder I2C auf USB, ohne dass man USB-Programmierung > machen müsste. Spielt auch mit den FTDI Serial Devices zusammen. > > Wäre das vielleicht was? Dann ginge die uC-Lösung wieder. Das habe ich auch gesehen. Das Gerät sollte nach Datenblatt aber auch LXI haben, dann braucht man nur Ethernet und eine LXI library (gibt es z.B. für C++ oder Python). Andrer Lösung: Man kann auch in den internen oder externen Speicher schreiben und einen Haufen Messwerte mittels DATA:DATA? abholen. Wobei mir aus dem Manual nicht ersichtlich wird, ob während dessen die Messung weiterlaufen kann.
Vorschlag : Bestudiere dir mal was fuer dieses geraet schon vorhanden ist von libraries in csharp. Sowie ich schnell gesehen haben benutzt er das SCPI protocol das durch viele dmms benutzt wird. Dur bis nicht der erst mit dieses problem, benutze die tools die dafuer schon vorhanden gibt. Du schreibst : "Das Messgerät benötigt für jeden einzelnen Wert eine Anfrage zur Übertragung." Ich denke die aussage ist nicht richtig, wie von einen anderen schon gesagt du kannst auch im dmm speichern lassen und mehrere samples zugleich auslesen. Nicht negativ gemeint, aber geh mal zurueck zum deine eigentliche Frage - du wollst diese geraet auslesen mittels C#. Fragen die da nach kommen so wie timing unter Windows usw, wenn du dafuer einen guten lib findest (und der musz irgendwo zu finden sein denke ich) brauchst du dir nichtmal zu kummern welche commandos per FTDI gesendet werden, und kannst du die library zo benutzen das du es auch via LAN oder andere schnitstellen auslesen kannst Patrick
Ein bisschen schneller gehts auch, wenn du direkt die D2XX DLL von FTDI benutzt statt den VCP Treiber. Und halt wie gesagt den Polling Wert in den Treiber Einstellungen runter setzen, auf z.B. eine Millisekunde, dann nochmal in der Schleife probieren.
@ Felix, das ist eine tolle Sache, muss ich mir später in Ruhe nochmal ansehen wie das genau läuft. Danke dafür! @ Physiker, an die LXI Geschichte hab ich mich bisher noch nicht rangewagt scheint aber auch zumindest schneller als ein Auslesen im 100ms Takt. Das speichern im Gerät und auslesen über DATA finde ich schwierig, da mein Wunsch ist ein Livebild einer laufenden Messung zu sehen. Man könnte natürlich überlegen immer 10 Werte ablegen zu lassen und diese dann über DATA auszulesen, allerdings werde ich das nicht synchron hinbekommen, da es kein Flag gibt, wann das Gerät die 10 Daten fertig geschrieben hat. Zudem gibt es, selbst wenn das geräteseitige Schreiben während eines Auslesens weiterläuft keine Timestamp, so dass man die neuen Daten nicht vernünftig anfügen kann. Hab auf die schnelle Infos zu einer LXI library gefunden - werde mich einlesen. Danke hierfür. Patrick, bei vielen Geräten gibt es einen Buffer in dem man mehrere Werte aufeinmal abholen kann, beim HMC8012 ist dieser Buffer hat die Loggingfunktion und hier sehe ich die eben beschriebenen Probleme. Aber das Thema mit der LXI Lib scheint schon lohnenswert. Auch dafür nochmal Danke!
Felix A. schrieb: > Schau mal hier, durch Zufall gerade gefunden: > > http://www.hobbytronics.co.uk/usb-host-board-v2 > > Der wandelt Uart oder I2C auf USB, ohne dass man USB-Programmierung > machen müsste. Spielt auch mit den FTDI Serial Devices zusammen. > > Wäre das vielleicht was? Dann ginge die uC-Lösung wieder. So, das Board ist erstmal für FTDI Treiber bestellt. Zum Testen und auch für andere Geräte ist das ja ne tolle Sache. Gruß
Stefan D. schrieb: > @ Physiker, an die LXI Geschichte hab ich mich bisher noch nicht > rangewagt scheint aber auch zumindest schneller als ein Auslesen im > 100ms Takt. Das speichern im Gerät und auslesen über DATA finde ich > schwierig, da mein Wunsch ist ein Livebild einer laufenden Messung zu > sehen. Ich habe die hier benutzt: http://optics.eee.nottingham.ac.uk/vxi11/ Es gibt auch ein Kommandozeilenprogramm mit dem testen kann, ob die Kommunikation prinzipiell steht.
Angehängte Dateien:
-
250HZ_1.PNG
2,8 KB -
250HZ_2.PNG
1,9 KB
>hiermit kann man den Systemtick ändern / abfragen > > >sowas würde ich ja echt nicht machen - böse böse > Das ist nicht böse. Der VLC-Player ändert auch den Systemtick und ist auch nicht böse. Wenn man nicht zu lange unterbrochen werden will gibt es halt keine andere Möglichkeit. Ein Thread mit niedriger Prio bekommt sein volles Quantum auch wenn ein Thread mit hoher Prio mitendrinn was machen will. Screenshot: Es werden 900000 B/s über Ethernet verschickt. Im Raster von 4ms Nur zum Test normalerweise 100Hz Mein PC-Lüfter wird nicht schneller:-) Vorausgesetzt er findet einen Adapter der schnell genug ist wird er den Systemtick anfassen müssen.
Hey, folgendes: Wenn das Messgerät in der Lage ist, Befehle zu puffern, könntest Du versuchen, interleavtes Lesen anzuwenden: Zu Beginn sendest Du sofort 2 Lesebefehle. Für jede Antwort, die Du vom Messgerät erhältst, versendest Du den nächsten Lesebefehl, während das Messgerät bereits den vorhergehenden (identischen) Lesebefehl abarbeitet. Diese Spielchen liese sich auch auf eine tiefere Verschachtelung erweitern, bis das Messgerät quasi kontinuierlich Befehle ausführt und Sende/Empfangslatenzen letztlich keine Rolle mehr spielen.
Wenn Geld nicht solch eine große Rolle spielt, kannst du auch Kithara verwenden. Das ist eine S/W-Paket (Bezahlware), welches u.a. Echtzeit für Windows bietet. Außerdem haben die Ich habe das vor ca. 10 Jahren mal verwendet und kann es guten Gewissens empfehlen. http://www.kithara.de http://www.kithara.de/de/loesungen/echtzeit-kommunikation Ich sehe gerade, es gibt eine 90 Tage Testversion. Das sollte reichen zum testen.
:
Bearbeitet durch User
900ss D. schrieb: > Wenn Geld nicht solch eine große Rolle spielt, kannst du auch Kithara > verwenden. Das ist eine S/W-Paket (Bezahlware), welches u.a. Echtzeit > für Windows bietet. Außerdem haben die es spielt überhaupt keine Rolle ob hier Echtzeit vorhanden ist oder nicht. jeden Wert einzeln abfragen geht einfach nicht schneller!
Peter II schrieb: > es spielt überhaupt keine Rolle Man kann damit präzise alle 4ms die Schnittstelle abfragen, Timer gesteuert und genau. Mehr wollte ich gar nicht mitteilen. Vielleicht versteht du es jetzt.
Angehängte Dateien:
-
CP210x.PNG
1,7 KB
Ich hab das mal mit einem CP2102 USB to UART von Silicon Laps probiert.
250000 Baud 4Bytes ("Test")
VolkerF schrieb: > Ich hab das mal mit einem CP2102 USB to UART von Silicon Laps probiert. > 250000 Baud 4Bytes ("Test") Und das mit heruntersetzen des Event Interrupt Timers oder ohne? Installiere gerade die NI Visa Treiber und werde mal die Geschwindigkeit über Ethernet testen. Leider sind die IVI Treiber aktuell bei Hameg nicht mehr zu finden :-(
:
Bearbeitet durch User
Wie schon weiter oben beschrieben muss man den Systemtick verändern. Das ganze ist nicht so einfach. Hab mich auch erst mal einlesen müssen. Wenn du willst könnte ich dir morgen aus meinem bestehenden Programm die wichtigsten Programmteile zukommen lassen.
VolkerF schrieb: > Wie schon weiter oben beschrieben muss man den Systemtick verändern. > Das ganze ist nicht so einfach. Hab mich auch erst mal einlesen müssen. > Wenn du willst könnte ich dir morgen aus meinem bestehenden Programm > die wichtigsten Programmteile zukommen lassen. Sehr gern :-) Kämpfe noch mit den IVI Treibern...
900ss D. schrieb: > Man kann damit präzise alle 4ms die Schnittstelle abfragen, Timer > gesteuert und genau. Mehr wollte ich gar nicht mitteilen. Vielleicht > versteht du es jetzt. und? Er muss sie aber nicht nur Abfragen, sondern auch etwas senden. Dann muss die Gegenstelle auch noch Antworten und dann muss es am PC wieder ankommen.
VolkerF schrieb: > Das ist nicht böse. > Der VLC-Player ändert auch den Systemtick und ist auch nicht böse. Wobei Multimedia-Anwendungen auch praktisch der einzige Grund sind, wieso es timeBeginPeriod (und das dahinterliegende NtSetTimerResolution) überhaupt gibt (und wird in der msdn auch unter "Multimedia Timers" aufgeführt) Im Normalfall hat sich um timing-abhängige Geschichten die Hardware zu kümmern und nicht die Software ;D
Stefan D. schrieb: > wie der Titel schon sagt suche ich nach einer Möglichkeit die Daten > eines Messgerätes über einen VCP mittels C#(.net 4.5) unter Win7x64 > auszulesen. Die Messwerte werden maximal alle 4 ms aktualisiert und > müssen gepollt werden. Das nennt man dann wohl "alle 4 ms abfragen"
Peter II schrieb: > und? Er muss sie aber nicht nur Abfragen, sondern auch etwas senden. Wie lange eine gesamte Abfrage dauert, weiss nicht mal der TO selbst. Woher weist du das? Glaskugel? Davon unabhängig und nochmal, ich wollte nur darauf hinweisen, dass es Werkzeuge gibt, die ein präzises Timing ermöglichen. Den Rest muss er schon selber rausfinden. Vermutungen helfen ihm wenig.
Hallo, wie versprochen hier ist das Programm. Getestet auf W7 und XP Die 4ms werden natürlich nicht garantiert eingehalten aber für die eine oder andere Anwendung ist das OK Es ist ein VC2010 Express Projekt .Net4.0
Hallo Volker, vielen Dank, Habs mal kurz angetastet und werd mich heute abend weiter vertiefen :-)
Christian R. schrieb: > Bei den FTDI Wandlern kannst du im Geräte Manager die Polling Zeit > herunter stellen, ich glaube Default sind deine 16ms. Hallo Christian, ich finde die Einstellmöglichkeit der Pollingzeit nicht. Im Geräte Manager wo der VCP Anschluss zu finden ist, taucht dieser Parameter nicht auf (Com & LTP), unter den USB Devices ist auch nichts zu finden.
Stefan D. schrieb: > Hallo Christian, ich finde die Einstellmöglichkeit der Pollingzeit > nicht. Im Geräte Manager wo der VCP Anschluss zu finden ist, taucht > dieser Parameter nicht auf (Com & LTP), unter den USB Devices ist auch > nichts zu finden. dann ist es eventuell kein FTDI chip.
Die Granularität des Windows-Timers (die normalerweise bei 10 msec liegt) lässt sich mit der Win32-API-Funktion timeBeginPeriod auf 1 msec reduzieren. Mir erscheint allerdings das Messgerät ein kaputtes Design zu haben. Ein Gerät, das über eine serielle Schnittstelle mit 250 Hz gepollt werden muss, das ist kaputt.
deswegen denken hier auch einige das der Thread-Starter sich möglicherweise ein wenig festgebissen hat - weil er ja was hat was irgendwie ein bisschen läuft - aber eher eine Sackgasse ist
Rufus Τ. F. schrieb: > Mir erscheint allerdings das Messgerät ein kaputtes Design zu haben. Ein > Gerät, das über eine serielle Schnittstelle mit 250 Hz gepollt werden > muss, das ist kaputt. Das Teil schafft laut Hersteller "Messrate bis zu 200 Messungen/Sekunde". Es steht aber nirgendwo, daß man es auch mit dieser Rate auslesen muß. Stefan D. schrieb: > C# Tool sendet den Befehl "FETCh\n" über VCP nach TimerTick(zb. 100ms) Eigentlich gehört doch zu dem FETCh auch noch ein INITiate. Wird das mit Parameter aufgerufen (e.g. ":IMMediate"/":CONTinuous")? Ansonsten könntest Du versuchen, ob einer der Messbefehle ("FETCh"/"READ"/"MEASure") den ":ARRay" Parameter unterstützt, das sollte dann mehrere Werte am Stück liefern.
guest schrieb: > Das Teil schafft laut Hersteller "Messrate bis zu 200 > Messungen/Sekunde". Es steht aber nirgendwo, daß man es auch mit dieser > Rate auslesen muß. Das ist dann ein Muster ohne Wert. Das Ding sollte dazu gebracht werden können, seine Messdaten unaufgefordert auszugeben - mit der Rate, mit der es sie erfassen kann. Oder n Datensätze mit Zeitstempeln zusammenfassen und en bloc zu übertragen.
Bert3 schrieb: > deswegen denken hier auch einige das der Thread-Starter sich > möglicherweise ein wenig festgebissen hat - weil er ja was hat was > irgendwie ein bisschen läuft - aber eher eine Sackgasse ist Das ist richtig, er hat sich festgebissen. Ich versuche das Maximum herauszuholen auch wenn es nicht die 200 - 250 Readings/sec werden. Guest: Der Hinweis mit dem Init war schonmal super, bekomme aktuell ca. 32 Werte/Sekunde über USB-TMC mit Event über den Standard Windows Timer. Heute dann mal Test ohne Event, einfach kontinuierlich, wie es Peter II vorgeschlagen hat. Vielleicht lässt sich das ja noch etwas steigern. :-) Anschließend nochmal den Ansatz von Volker um "definierte" Ausleseraten zu erhalten.
:
Bearbeitet durch User
Angehängte Dateien:
-
Pollingzeit.jpg
180 KB
Hier ist der Weg, der bei FTDI-Chips funktioniert, um die Pollingzeit einzustellen. 1) als Admin in den Gerätemanager, dann Rechtsklick auf den COM-Port und auf Eigenschaften 2) auf Anschlusseinstellungen klicken 3) auf Erweitert... klicken. Dann links vertikal mittig steht die Pollingzeit (Win7 Pro 64Bit). Hier 16ms
:
Bearbeitet durch User
Felix A. schrieb: > Hier ist der Weg, der bei FTDI-Chips funktioniert, um die Pollingzeit > einzustellen. > > 1) als Admin in den Gerätemanager, dann Rechtsklick auf den COM-Port und > auf Eigenschaften > 2) auf Anschlusseinstellungen klicken > 3) auf Erweitert... klicken. > > Dann links vertikal mittig steht die Pollingzeit (Win7 Pro 64Bit). Hier > 16ms Besten Dank, da das bei mir nicht aufgeführt, dann wird wohl kein FTDI-Chip sein. Ist aber hilfreich fürs Labornetzgerät :-)
nachdem jeder aktuelle PC unmengen an CPU Kernen hat. ist es ja wohl kein Problem, wenn man einen davon zu 100% auslastet also einfach einen eigenen thread mit einigermaßen hoher Priorität das hier https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx in eine Schleife abfragen, und immer wenn 4ms vergangen sind, die daten lesen (das funktioniert dann auch mit weit unter 1ms, als mehr als 1000Hz..)
Robert L. schrieb: > ist es ja wohl kein Problem, wenn man einen davon zu 100% auslastet > also einfach einen eigenen thread mit einigermaßen hoher Priorität > > das hier > https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx > > in eine Schleife abfragen, und immer wenn 4ms vergangen sind, die daten > lesen > > (das funktioniert dann auch mit weit unter 1ms, als mehr als 1000Hz..) da der PC ständig auf die Antwort warten muss, braucht man für diese Aktion keine CPU-Zeit. Und es wird auch nicht unter 1ms funktionieren, weil dafür das Frage-Antwortspiel über USB viel zu langsam ist.
So nach einigen weiteren Tests hier mal mein vorläufiges Ergebnis: Um keine Ergebisse doppelt zu erhalten lesen ich mit "INIT\nFETCh?\n" aus. Alle Ergebnisse kommen aus einer While-Schleife Test mit VCP ca. 16 Messungen/Sekunde Test mit USBTMC ca. 20 Messungen/Sekunde Test mit LXI über LAN(100Mbit Full Duplex) ca. 16 Messungen/Sekunde Der PC ist beim Auslesen auch nicht wirklich gefordert, so dass ich dann auch vermute, dass das Gerät halt wirklich nicht in der Lage die Messwerte mit deutlich höheren Raten über USB oder LAN zur Verfügung zu stellen. Ein interleavetes Lesen wird nicht unterstützt. Der Ansatz mit dem USB-Host von Hobbytronics brauchte auch nicht weiter, da es leider - wie schon vermutet - kein FTDI Device ist und das Teil nur mit 9600 Baud kommuniziert. Da diese Werte nicht wirklich zufriedenstellend sind will ich mich nochmal der Idee von Physiker aufgreifen und versuchen während der Aufzeichung auf den internen Speicher die Daten abzuholen. Ein weiterer Ansatz: Das Messgerät ist in der Lage die Messdaten auf einen USB-Stick zu speichern. Wenn es also gelänge eine kleine µC-Schaltung zu basteln, die vom Messgerät als USB-Stick erkannt wird, mir aber die Daten auf den PC streamt sollte das die Lösung sein. Werde hierzu mal einen separaten Thread aufmachen, da es doch recht weit vom Titelthema abweicht. Vielen Dank an Alle, die so fleißig Tips und Hinweise gegeben haben.
:
Bearbeitet durch User
Stefan D. schrieb: > Das Messgerät ist in der Lage die Messdaten auf einen USB-Stick zu > speichern. Wenn es also gelänge eine kleine µC-Schaltung zu basteln, > die vom Messgerät als USB-Stick erkannt wird, mir aber die Daten auf den > PC streamt sollte das die Lösung sein. Werde hierzu mal einen separaten > Thread aufmachen. vergiss es. Filesystem sind dafür nicht geeignet. Wenn deine Zeit nicht gerade kostenlos ist, ist es dann billiger ein passenden Messgerät zu kaufen. Warum kein USB-Oszi?
Zeit ist kostenlos das Freizeit und Hobby. Ein Oszi habe ich, ist aber wiederum nicht für ein lange Aufzeichnungsdauer geeignet.
:
Bearbeitet durch User
Man könnte es auch mit service requests versuchen. Obwohl das Handbuch da nicht näher drauf eingeht, sollten sie zumindest für GPIB und USB TMC implementiert sein (nicht sicher ob sie auch zu LXI 1.4 core gehören). MAV bit (message available) The bit is set, if a readable message in the output buffer is available. This bit can be used to enable data to be automatical read from the instrument.
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.