Kurzzeitige Unterbrechungen eines VI verhindern

Hallo,

ist es möglich, ein VI so auszuführen dass es nicht durch Interrupts, andere Prozesse o.ä. kurzzeitig unterbrochen wird?

Das komplette Problem:
Mit LabVIEW werden Messwerte von einem EtherCAT-Slave aufgezeichnet. Es wird eine cifX-Karte verwendet, die Buszykluszeit beträgt 10ms. Es sollen alle Messwerte erfasst werden.
Die Daten werden in einer Schleife (siehe Screenshot, VI "Get N readings") aus einer DLL (welches vier SubVIs tiefer sitzt, Rückgabetyp ist ein U8-Array) ausgelesen, und bei einer Änderung (ein Counter im Slave, welcher bei jedem Buszyklus inkrementiert) wird das zurückgegebene Array in die entsprechenden Messwerte zerlegt und diese in ein Array geschrieben. Nach der Schleife werden die Messwerte in einem Textfile gespeichert.

   
   

Jedoch passiert es alle 1-5 Minuten nachdem die Schleife gestartet wurde, dass innerhalb von 350ms Messwerte nicht erfasst werden, also der Schleifenzyklus in dieser Zeit über 10ms dauert. Im "normalen" Betrieb liegt die Schleifenzykluszeit weit unter einer Millisekunde.

   

Der Ausschnitt aus dem Log zeigt links die in der Schleife erkannten Änderungen und rechts den empfangenen Wert des Counters. Das SubVI besitzt bereits höchste Priorität.
Es wurden 60000 Messwerte aufgenommen, dabei wurden 8 Werte nicht aufgezeichnet.

   

Vermutlich werden irgendwelche Prozesse oder Interrupts bevorzugt bearbeitet, scrollen mit der Maus oder aus- und einschalten des Monitors erhöhen dabei den Schleifenzyklus auf 2 - 700ms. Dies ist auch der Grund, warum die Buszykluszeit 10ms beträgt, da hier noch am wenigsten Messwerte verloren gehen.
Labview läuft dabei auf einem PXI-System mit Win7 und einem PXIe-8135 Controller. Der i7 hat eine Auslastung von ~60% auf zwei logischen Prozessoren während die Schleife läuft. Vier weitere logische Prozessoren sind dabei im Idle. Deshalb würde mich interessieren, ob ich mein SubVI auf einem ungenutzen Prozessor mit maximaler Priorität ausführen kann, damit die Schleifenzykluszeit 10ms nicht überschreitet.

Mir ist bewusst, dass Windows kein Echtzeitbetriebssystem ist, aber vielleicht hat jemand einen Tipp wie man den Schleifenzyklus unter 10ms halten kann.


Grüße
Hähnchen

Anzeige

Hallo Hähnchen,

schon mal beim Producer-Consumer-Schema nachgeschaut?
Manchmal hilft es, Messwert-Erfassung und -Auswertung in verschiedene Schleifen aufzutrennen!

Ansonsten kannst du gegen den Win-Taskmanager nicht wirklich viel unternehmen...

Ich weiß leider nicht, was ein "EtherXAT-Slave" und eine "cifX-Karte" ist. (Und deine Bilder habe ich mir aus Faulheit auch nicht angesehen.) Aber normalerweise ist Dein Problem, wenn Du Messwert-Erfassungskarten von NI verwendest, auf vollendete Weise gelöst. Diese Karten arbeiten, wenn die Messwerterfassung einmal in Gang gesetzt wurde, völlig autark, die gleichmäßige Erfassung kann durch Interrupts nicht gestört werden. Die Datenübergabe zwischen Karte (Also dem Mini-Realteil-System) und dem Windows-System erfolgt über Puffer. Das Einzige, was bei solch einem Interrupt mal passiert, ist, dass bei einem darauffolgenden Zugriff auf den Puffer ein paar mehr Messwerte drin sind - es gehen aber keine Werte verloren.
Aber natürlich ist es jederzeit möglich, durch entsprechend ungeschicktes Programmieren auch bei einer solchen Karte zu erreichen, dass Messwerte verloren gehen. Das ist insbesondere dann der Fall, wenn für die Datenerfassung mit einer bestimmten Rate nicht die internen Resourccen der Karte benutzt werden, sondern wenn über eine While-Schleife jeder Messwert einzeln in Auftrag gegeben wird und der Buffer nicht benutzt wird.

Zur Erzeuger-Verbraucher-Struktur: diese ist oft von Vorteil. Allerdings hat man mit dem Einsatz einer NI-Karte bereits eine Erzeuger-Verbraucherstruktur, und zwar nicht auf Basis von Software (unterschiedliche Schleifen), sonderen sogar auf der Basis von Hardware (Zwei autarke System mit Datenaustausch über Puffer). So gesehen ist das Hinzufügen einer zweiten Struktur in Kaskade zur bereits vorhandenen ersten eine Spielerei, die auf überflüssige doppelte Pufferung der Daten hinausläuft.

(25.07.2013 11:59 )GerdW schrieb:  schon mal beim Producer-Consumer-Schema nachgeschaut?
Manchmal hilft es, Messwert-Erfassung und -Auswertung in verschiedene Schleifen aufzutrennen!

Danke, das wird gleich mal ausprobiert.

(25.07.2013 12:34 )Lucki schrieb:  Ich weiß ja nicht, was ein "EtherXAT-Slave" und eine "cifX-Karte" ist. Aber normalerweise ist Dein Problem, wenn Du Messwert-Erfassungskarten von NI verwendest, auf vollendete Weise gelöst. Diese Karten arbeiten, wenn die Messwerterfassung einmal in Gang gesetzt wurde, völlig autark, die gleichmäßige Erfassung kann durch Interrupts nicht gestört werden. Die Datenübergabe zwischen Karte (Also dem Mini-Realteil-System) und dem Windows-System erfolgt über Puffer. Das Einzige, was bei solch einem Interrupt mal passiert, ist, dass bei einem darauffolgenden Zugriff auf den Puffer ein paar mehr Messwerte drin sind - es gehen aber keine Werte verloren.

EtherCAT ist ein industrielles (Echtzeitfähiges) Bussystem, dafür gab (gibt?) es jedoch kein Modul von NI für das PXI-System. Deshalb wurde die "cifX-Karte" von Hilscher verwendet.
Diese hat zwar auch einen eigenen Controller mit Echtzeitbetriebssystem welches die Daten verarbeitet und zugänglich macht, aber leider keine Pufferung.
Die Karte auch Interrupts erzeugen, jedoch scheint das Interrupthandling mit LV auch nicht gerade einfach zu sein.
Zur Not müsste eben eine Wrapper-DLL her...

Mittels einer Timed Loop kannst du eine Aufgabe exklusiv einem Kern zuordnen, der macht dann nix anderes. Es ist aber so, dass das nicht unbedingt schneller geht als mit einer normalen Loop...weil die Timed Loop auch jede Menge Overhead produziert...

Aber probieren geht (hier) über studieren...

A.

PS: Der mäßíge Support und die schwierige Einbindung in LV haben bei damals dafür gesorgt, dass ich von Hilscher auf Comsoft/NI umgestiegen bin...allerdings gings da um Profibus...

Die TimedLoops sind deutlich langsamer, als die "normalen" Schleifen!
Man kann aber eine "normale" Schleife in eine TimedLoop, die sofort wieder beendet wird legen und somit die Arbeit der "normalen" Schleife einem Kern zuordnen.


Gruß, Marko

Nachtrag:

man kann z.B. mal den Test machen, (bei einem Quad-Core-PC) 4 parallele TimedLoops mit darin befindlichen StandardLoops, die ungebremst sinnfrei im Kreis laufen, zu platzieren und wird es schwer haben, die ganze Kiste wieder zu stoppen, da fast keine Ressourcen mehr frei sind.


Gruß, Marko

(25.07.2013 14:01 )Achim schrieb:  Mittels einer Timed Loop kannst du eine Aufgabe exklusiv einem Kern zuordnen, der macht dann nix anderes. Es ist aber so, dass das nicht unbedingt schneller geht als mit einer normalen Loop...weil die Timed Loop auch jede Menge Overhead produziert...

Aber probieren geht (hier) über studieren...

Probieren ergab leider keinen eindeutigen Vor- oder Nachteil für eine bestimmte Schleifenart.
Egal ob mit einer Schleife, zwei normalen Schleifen und Queue, TimedLoop für das zeitkritische Auslesen und normale Loop für die Auswertung oder auch zwei TimedLoops mit unterschiedlichen Prozessoren und Prioritäten, es gab keine Lösung bei der keine Messwerte verloren gingen. Zwei (Timed) Loops haben jedoch etwas besser abgeschnitten.

(25.07.2013 14:57 )Trinitatis schrieb:  Die TimedLoops sind deutlich langsamer, als die "normalen" Schleifen!
Man kann aber eine "normale" Schleife in eine TimedLoop, die sofort wieder beendet wird legen und somit die Arbeit der "normalen" Schleife einem Kern zuordnen.

Genau das habe ich gemacht....

(25.07.2013 15:32 )Trinitatis schrieb:  Nachtrag:
man kann z.B. mal den Test machen, (bei einem Quad-Core-PC) 4 parallele TimedLoops mit darin befindlichen StandardLoops, die ungebremst sinnfrei im Kreis laufen, zu platzieren und wird es schwer haben, die ganze Kiste wieder zu stoppen, da fast keine Ressourcen mehr frei sind.

Mit Hyperthreading braucht man acht Schleifen

Mit einer Schleife
   
sieht die CPU-Auslastung so aus:
   

Mit einer TimedLoop drum...
   
sieht das schon schöner aus:
   

Interessant ist, wie bei einer normalen Schleife immer zwischen den Prozessoren gewechselt wird. Leider verändert das an den Interrupts von Windoof nichts

Trotzdem vielen Dank für eure Hilfe

Hallo Hähnchen,

deine Beschreibung klingt so, als würde Dein Programm im User Interface - Thread ausgeführt. Eine Synchronisation mit diesem kriegt man z.B. durch die Verwendung von Property nodes.
Aber auch der "Call library function node" kann darin laufen. Schau mal, ob das bei Dir der Fall ist. Die Farbe des Nodes ändert sich von orange auf gelb wenn er nicht mehr im UI läuft.

   

(31.07.2013 08:30 )Jopi schrieb:  deine Beschreibung klingt so, als würde Dein Programm im User Interface - Thread ausgeführt. [...]
Aber auch der "Call library function node" kann darin laufen. Schau mal, ob das bei Dir der Fall ist.

Da ich die DLL mit dem Tool von LabVIEW importiert habe, werden alle library function nodes im UI-Thread ausgeführt.
Nach der Umstellung auf in beliebigen Thread ausführen läuft es gefühlt* besser. Hier noch kurz das Fenster in der deutschen LV-Version:
   

Jedoch ist die Anzahl der verlorenen Frames nochmals gesunken, als ich nur die TimedLoop (ohne darin befindliche While-Schleife) verwendet habe. Die Auslastung liegt dann auf dem ausgewählten Kern bei praktisch 0% und es gehen nur noch 10‰ der Messwerte verloren. Das merkwürdige daran ist, dass dies alle 10 Minuten auftritt:
   

Jetzt müsste man nur noch wissen, welcher Prozess das verursacht....

*gefühlt deshalb, da ich die beiden Thread-Varianten nicht direkt miteinander verglichen habe.