+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: Synchronisation LV mit TDS 5034B Oszi (/Thread-Synchronisation-LV-mit-TDS-5034B-Oszi)
Synchronisation LV mit TDS 5034B Oszi - AndiMetzger - 01.08.2007 15:52
Ich habe so ein ähnliches Problem,
siehe: http://www.LabVIEWforum.de/index.php?showt...amp;hl=Syn+Oszi
(als Anhaltspunkt gedacht)
Wenn ich meine Messungen vom Oszi über die virtuelle GPIB Schnittstelle holen will klappt das zwar schon, ich bekomme aber immer einen Wert gehn unendlich zurück. Füge ich nun zwischen jedem Befehls VI eine Pausenzeit ein, so bekommt das Oszi jeden Befehl sauber mit und sendet auch den korrekten Messwert ins LV. Ich nütze aber viele VI's hintereinander weg um alles mögliche wie Trigger, Kanal, Ablenkung,...etc einzustellen und mache mehrere Messungen hintereinander weg. So bläht sich die Gesamte Ablaufgeschwindigkeit immer mehr auf und es dauert ewig (unnötig lange Pausenzeiten).
Nun wollte ich es über direkte *WAI Befehle machen, so dass nur so lange gewartet wird wie nötig, dies funktioniert aber leider irgendwie nicht.
Wenn ich stattdessen *OPC? übergebe und wieder auslese so kann ich über die Abfrage = 1 oder =0 sehen ob das VI fertig abgearbeitet wurde.
--> geht aber auch nicht so recht, auch immer Overflow.
Wenn ich all diese Dinge weg lasse und nur meine einzelnen Treiber VI's vom Oszi hintereinander weg abarbeiten lasse und dies langsam ablaufen lasse (mit der Glühbirnenfunktion) dann geht es auch sauber durch!
Wie also kann ich mein Problem lösen, ohne fiktive und vor allem unnötig lange Pausenzeiten integrieren zu müssen????
Danke!
Synchronisation LV mit TDS 5034B Oszi - dc6xs - 01.08.2007 16:10
' schrieb:Ich habe so ein ähnliches Problem,
siehe: http://www.LabVIEWforum.de/index.php?showt...amp;hl=Syn+Oszi
(als Anhaltspunkt gedacht)
Wenn ich meine Messungen vom Oszi über die virtuelle GPIB Schnittstelle holen will klappt das zwar schon, ich bekomme aber immer einen Wert gehn unendlich zurück. Füge ich nun zwischen jedem Befehls VI eine Pausenzeit ein, so bekommt das Oszi jeden Befehl sauber mit und sendet auch den korrekten Messwert ins LV. Ich nütze aber viele VI's hintereinander weg um alles mögliche wie Trigger, Kanal, Ablenkung,...etc einzustellen und mache mehrere Messungen hintereinander weg. So bläht sich die Gesamte Ablaufgeschwindigkeit immer mehr auf und es dauert ewig (unnötig lange Pausenzeiten).
Nun wollte ich es über direkte *WAI Befehle machen, so dass nur so lange gewartet wird wie nötig, dies funktioniert aber leider irgendwie nicht.
Wenn ich stattdessen *OPC? übergebe und wieder auslese so kann ich über die Abfrage = 1 oder =0 sehen ob das VI fertig abgearbeitet wurde.
--> geht aber auch nicht so recht, auch immer Overflow.
Wenn ich all diese Dinge weg lasse und nur meine einzelnen Treiber VI's vom Oszi hintereinander weg abarbeiten lasse und dies langsam ablaufen lasse (mit der Glühbirnenfunktion) dann geht es auch sauber durch!
Wie also kann ich mein Problem lösen, ohne fiktive und vor allem unnötig lange Pausenzeiten integrieren zu müssen????
Danke!
Kann das Oszi sein Setup nicht speichern?
Dann bräuchtest nur noch die Einstellungsdatei ferngesteuert laden.
Was sagt denn das Handbuch bezüglich Timing beim Programmieren über die GPIB?
Ansonsten wirste Wohl um eine Struktur mit Warte-Pausen nicht herumkommen.
Schaltest Du denn während der Messungen so oft um, das es sich störend bemerkbar machen würde?
Gruß, Rob
Synchronisation LV mit TDS 5034B Oszi - AndiMetzger - 02.08.2007 09:02
Hi,
nun ja, ich schalte schon sehr oft um, so dass auch die 8 Measurements die max. zu Verfügung stehen mehrfach überschrieben und ausgelesen werden.
Ja, im Handbuch sehe ich nur den *WAI und den *OPC? Befehl, mit denen es leider nicht so richtig funktioniert.
Hm, ja ich glaube es ist möglich das eingestellte setup zu holen und auch hinzuschicken.
Stimmt, dann sendet er es ja anders und spricht nicht direkt den Kanal etc. an.
So könnte es auch funktionieren.
Danke erstmal, schau mal danach noch.