Hallo zusammen,
zu meinem Problem haben meine Recherchen nichts ergeben. Andererseits ist es auch schwierig soetwas zu suchen.
Also: Zur Zeit entwicklen wir ein Programm, bei dem die Datenerfassung über DAQmx und USB Messungen vornimmt. Da wir ein bisschen regeln möchten, haben wir uns nach und nach an die Grenzen der USB-Verbindung zum cDAQ-Chassis herangetastet, die Abtastrate ein bisschen hoch, die Anzahl der Samples etwas runter; naja...
Soweit so stabil; jedenfalls haben wir festgestellt, dass wenn wir den Inhalt eines Anzeigeelements, das mit in der DAQmx-Schleife liegt, mit der Maus schnell hintereinander markieren oder das Fenster wild hin und her schieben, der DAQmx Treiber einen Timout-Fehler ausgibt. Dieser Effekt lässt sich auch mit einem Minimalbeispiel zeigen: Wenn man die Titelleiste mit der Maus gedrückt hält, unterbricht die Ausführung für einen Augenblick. Anbei ein Video einer Bildschirmaufnahme, leider jedoch ohne Mauszeiger und auch das VI dazu.
Weiß jemand etwas darüber? Gibt es Möglichkeiten, dieses Verhalten zu beeinflussen? Uns ist das nie aufgefallen...
Beste Grüße
stoa
Hallo stoa,
Zitat:Dieser Effekt lässt sich auch mit einem Minimalbeispiel zeigen: Wenn man die Titelleiste mit der Maus gedrückt hält, unterbricht die Ausführung für einen Augenblick. Anbei ein Video einer Bildschirmaufnahme, leider jedoch ohne Mauszeiger und auch das VI dazu.
Das Demo-VI ist leer und damit wenig hilfreich…
Zitat:Soweit so stabil; jedenfalls haben wir festgestellt, dass wenn wir den Inhalt eines Anzeigeelements, das mit in der DAQmx-Schleife liegt, mit der Maus schnell hintereinander markieren oder das Fenster wild hin und her schieben, der DAQmx Treiber einen Timout-Fehler ausgibt.
Dann nimm doch das Anzeigeelement aus dieser Schleife raus! (Bzw. spendiere dem DAQmx-Task seine eigene Schleife oder besser noch sein eigenes VI!)
Und du kannst den Fensterrahmen verschwinden lassen, dann kann der User auch nichts mehr wild hin- und herschieben…
Abgesehen davon: an Windows (als Betriebssystem) kannst du recht wenig ändern.
Hallo Stoa,
Fenster schnell hin und her bewegen kann man mit einem Vollbild ohne Rechte auf Änderung verhindern.
Eigenschaften VI-> Fenstererscheinungsbild
Eine Eingabe in einer Messschleife ist wie GerdW schon andeutet nicht schön.
Verwende doch in diesem Fall einfach Nachrichten-Queues mit Ereignis- Struktur.
Damit kannst Du zumindest verhindern, dass die DAQ Schleife durch eine Eingabe unterbrochen wird.
Gruß
Freddy
Hallo zusammen,
vielen Dank für eure Antworten. Tatsächlich gab es ein Problem beim Abspeichern des VIs, wie ich erst heute morgen feststelle. Anbei die überarbeitete Version.
In unserem Programm ist die Messschleife in einem VI mit eigener Schleife separiert. Wir haben nur zu Testzwecken die Laufzeit in Sekunden berechnen und auf der Benutzeroberfläche ausgeben lassen und dabei ist uns der Effekt aufgefallen. Sicher kann man die Titelleiste ausblenden oder deaktivieren oder die Anwendung im Vollbild erzwingen; Anzeigeelemente, die Schwierigkeiten bereiten einfach löschen.
Wir haben uns gefragt, wie der Effekt zustande kommt. Ist es dann die einzige Lösung die Titelleiste zu deaktiveren? Dann müsste jedes Programm mit irgendwie zeitkritischen Elementen so gestaltet sein, oder?
mit Gruß
stoa
(28.04.2020 07:19 )stoa schrieb: [ -> ]Wir haben uns gefragt, wie der Effekt zustande kommt.
DAQ, Anzeigeelement und Windows-Fenster in ein und demselben Blockdiagramm? Da müssen sich alle diese Elemente ein Zeitfenster teilen => Wenn Windows gerade meint, das Fenster bearbeiten zu müssen, sieht es halt schlecht aus für den DAQ.
Es gibt nur eine richtige Lösung (siehe meine Vorredner): DAQ auslagern in ein (StandAlone)VI und die Daten per Queue (oder Melder) weiterleiten.
(28.04.2020 08:22 )IchSelbst schrieb: [ -> ]DAQ, Anzeigeelement und Windows-Fenster in ein und demselben Blockdiagramm?
Nein. Siehe meinen letzten Beitrag. Ich weiß, Studierende können das nicht, die sind besser im Sourcecode im Netzt suchen ...
In Ordnung, wir sind also einen Schritt weiter: Wenn Windows meint, es müsse jetzt etwas mit dem Fenster anstellen, kann LabVIEW mit den Elementen nicht weiter arbeiten. Das kann ich nachvollziehen. Das würde bedeuten, dass eine separate Schleife, die keine Verbindung zur Benutzeroberfläche hat, davon ausgenommen wäre.
Jetzt hab ich mein Minimalbeispiel um zwei weitere Varianten des Hochzählens erweitert. Die erste Variante arbeitet nach wie vor und aktualisiert das Anzeigelement bei jedem Schleifendurchlauf. Die zweite Variante hingegen aktualisiert ihr Anzeigelement erst nach der Ausführung. Die dritte Variante ist als SubVI separiert. Trotzdem haben nach Beendigung alle Anzeigeelemente den gleichen Wert (±1), leiden also alle gleichartig unter dem "Titelfensterfesthalten". Damit haben wir noch keine Lösung für das Problem.
Wie seht ihr das?
mit Gruß
stoa
Das ist der Beweis, dass alle Schleifen parallel arbeiten.
Dies ist doch genau Deine Lösung.
Wenn Du nun noch die Eingabe in eine der 3 Schleifen als Ereignisstruktur setzt und die DAQmx in eine andere Schleife, wird alles gut.
(28.04.2020 10:34 )Freddy schrieb: [ -> ]Das ist der Beweis, dass alle Schleifen parallel arbeiten.
Dies ist doch genau Deine Lösung.
Wenn Du nun noch die Eingabe in eine der 3 Schleifen als Ereignisstruktur setzt und die DAQmx in eine andere Schleife, wird alles gut.
Na, aber ich brauche doch eine Schleife, die nicht durch "Fenstertitelhalten" unterbrochen wird. Übrigens hat mein Kollege auch beobachtet, dass das Sperren des Rechners also "Win+L" ebenfalls dazu führen kann.
Es ist ein Trugschluss, das die Bewegung des Fensters die Zählerfunktion unterbricht.
Nur die Anzeige wird durch die Windowsfunktion unterbrochen.
Wenn Du es wissenschaftlich angehen willst. Dann Stop die Zeit die vergeht bis die Schleife eine bestimmte Anzahl Schleifen durchlaufen hat.
Dann bitte das Gleiche mit bewegen des Fensters.
Beide Varianten nicht nur einmal durchspielen.
Der Versuchsaufbau
Oh man, Freddy, du hast absolut Recht. Ein Trugschluss. Ich dachte, ich beobachte damit den Effekt, der die DAQ-Schleife abrauchen lässt, aber danach sieht es wohl nicht aus. Damit habe ich aber auch keinen Anhaltspunkt mehr... vielleicht bleibt einem dann nichts weiter als die Echtzeitunfähigkeit schulterzuckend zu akzeptieren. Vielleicht kann ich das Timeout noch ganz anders provozieren? Parallel zu all dem PI exakt ausrechnen lassen vielleicht?
Na gut, belassen wir es dabei. Wenn sich noch etwas spannendes in der Angelegenheit ergibt, melde ich mich wieder. Bis dahin, vielen Dank für eure Hilfe!