Zustandsautomat Geschwindigkeitsreduktion

Ich habe eine Anwendung (lediglich 2 Vi´s) mit Labview 2010 programmiert, welche etwa 100mal schneller laufen sollten.

Frage. In einer While-Schleife ist eine Case-Stuktur enthalten, ähnlich wie bei einem Zustandsautomat. Die Cases (25Cases) werden nacheinander durchlaufen, bis in den letzten (25zigsten) Case hinein. Dann wird immer nur noch der letzte CASE Nr. 25 bearbeitet/durchlaufen.
Im letzten CASE werden lediglich 2 Queqeus mit Daten-Elemente gefüllt. Das Füllen der Que´s sollte wesentlich schneller geschehen.
Die anderen 24 Cases (welche hierbei dann nicht mehr durchlauf werden) habe ich (leider) reichlich mit Variablen und Eigenschaftsknoten (mit Wertzuweisungen) gespickt. Kann dies das langsame Verhalten (der Schleife) erklären?
Bringt es wirklich etwas diese Eigenschaftsknoten in den nicht durchlaufenden Programmstellen durch z.B. FGV´s zu ersetzen?

(Anwendung: Ich sammle zyklische Daten von einem CAN-Bus, mache eine vorsortierung in diese in dem Sub-Vi, und leite diese Daten über 2 Que´s an mein Main-VI weiter)
Nur wenn ich den CAN-BUS soweit drossle, dass alle 100ms ein Datenpacket gesendet wird, kann das VI- die Daten verarbeiten, ohne dass die Cue´s allmählich überlaufen. Mein Ziel ist aber im 1ms Takt Daten zu verarbeiten.) Die Schleifen laufen ungedrosselt.

Gruß Peter Götz

Anzeige

Hallo Peter,

Ich glaube nicht, dass die ersten 24 Zustände für die langsame Geschwindigkeit verantwortlich sind. Zumindest sofern sie wirklich nur einmal zu begin durchlaufen werden um z.B. Queues zu erstellen, das CAN-Interface zu initialiseiren usw. und dann in Case 25 nur noch vom CAN gelesen und in die Queue eingereiht wird. Allerdings finde ich Eigenschaftsknoten nicht so schön, da sie in der Tat sehr träge sind und vermeide diese wo immer es geht.

Es würde helfen dein VI bzw Screenshots vom Blockdiagramm hochzuladen (am besten beides). Dann ist es leichter Hilfestellung zu geben.
(Ich kann momentan nur etwas mit Bildern anfangen, da momentan auf meinem Firmenrechner kein LV installiert ist.)

Grüsse,
Tobias

Hallo Peter

Zitat: Die Schleifen laufen ungedrosselt...

Das könnte ein Problem sein. Es wird eine hohe CPU Last erzeugt, die dann bei Deiner Kommunikation fehlt.

Gruss, BDB

wenn ein mehrkernprozessor zur verfügung steht würde ich probieren 2 schleifenstrukturen zu verwenden, bei der eine nur für die erfassung der daten und die andere zur auswertung (sortierung) der daten zuständig ist

Leider schreibst Du nichts über die absoluten Geschwindigeiten der Schleifendurchläufe.

Wahr ist, die Ausführung eines Eigenschaftsknotens ist ca 200mal langsamer als die direkte Wertzuweisung und 100 mal langsamer als die Wertzuweisung über eine lokale Variable.

Ein Lese/Schreibzugriff auf "Wert" über einen Eigenschaftsknoten statt direkt oder über eine lokale Variable ist so ziemlich das Ungünstigste was man machen kann. Zeitraubend ist der Aufruf des Knotens, weniger die Abarbeitung der einzelnen Eigenschaften. D.h. wenn man den Eigenschaftsknoten sowieso aufrufen muss, z.B um das Element zu aktivieren/deaktivieren, dann kann man auch die Eigenschaft "Wert" gleich mit verwenden, dann ist es egal.

Die von Dir erwähnten FGVs sind eine Alternative zu Globalen Variablen. Wenn die globale Eigenschaft nicht gebraucht wird macht es keinen Sinn, sie anstelle von lokalen Variablen zu verwenden.

Man sollte Eigenschaftsknoten nach Möglichkeit überhaupt nicht in der zeitkritischen Hauptschleife verwenden. Also falsch: In der Hautschleife 1000mal pro Sekunde die Eigenschaft Aktivieren/Deaktívieren aufrufen. Richtig: In einer parallelen Ereignisbehandlungschleife das Aktivieren/Deaktivieren nur vornehmen, wenn tatsächlich eine Änderung ansteht.

Danke für die wirklich guten Tips von Euch. Ich habe zwischenzeitlich etliche Tests durchgeführt.
- einige Schleifen angedrosselt, und auch nur mit 0ms Wait, das half, damit Labview einen Thread abgeben kann.
- Die gesamte Prozessorlast ist beim aktivem Labview mit meinen VI´s bereits zu hoch ca. 80% auf Kern 1 und 60% auf kern 2. Ich werde noch mit timed Loops arbeiten um die Priorität zu verteilen.
- Neu für mich war/ist unter Profil VI´s Leistung und speicher. Damit kann ich meine VI´s analysieren, bin mitten dabei.
- Array nur mit Replace und Subset verwenden (Speicheroptimiert) aber was erzähle ich , Ihr seit (wie) Profis.

Mein Hauptproblem ist/war: Meine Main-Loop lief ungedrosselt und insgesamt zu schwache Hardware im Einsatz. Ich nutze einen Intel ATOM N270 mit 1,6GHz unter Win XPHome. Ich habe mir heute einen Intel M Prozessor für eine 479 Socket (3,5" Wafer Board mit PC104 Cards, was auch vom Format her in die Maschine passt) mit 1,8Ghz bestellt. Lieferzeit 2 Wochen.

Mein Ziel ist es Datenpackete vom CAN-Bus bis 64Byte im 0,5ms Takt durchzuschleusen und dabei zu sortieren, verarbeiten und dann alle 100ms graphisch darzustellen. Das mit der Datenaufnahme und sortierung schaffe ich derzeit nur stabil im 20ms- Takt. Gruß Peter

Anzeige

' schrieb:Mein Ziel ist es Datenpackete vom CAN-Bus bis 64Byte im 0,5ms Takt durchzuschleusen und dabei zu sortieren, verarbeiten und dann alle 100ms graphisch darzustellen. Das mit der Datenaufnahme und sortierung schaffe ich derzeit nur stabil im 20ms- Takt. Gruß Peter

Welche CAN HW benutzt du denn? Mit den Series 2 CAN Karten von NI könnte es schwer werden schnell genug an einzelne Messages dran zu kommen. Hab das nur mal bei einem Kollegen gesehen... Minimalaufbau Steuergerät<->PXI-Can Karte, die Software sollte im 1ms Takt einen Werte aus einer Message inkrementieren und wieder zurück schicken. Soweit ich das mitbekommen hatte das nie wirklich so schnell funktioniert.
Wie das mit den neuen XNET Karten aussieht... keine Ahnung. Aber viel Erfolg!

Gruß
Götz