LabVIEWForum.de

Hallo,

ich bin neu in diesem Forum und möchte mich erstmal kurz vorstellen: Mein Name ist Kai und ich bin Student des Maschinenbaus.
Im letzten Jahr habe ich als Belegarbeit eine Prüfstandssteuerung / -regelung für einen Bremsenprüfstand in LabVIEW 8.5 aufgebaut. Jetzt bin ich studentische Hilfskraft und habe in diesem Zusammenhang die Software noch etwas erweitert, um den Prüfstand universeller nutzen zu können.

Kurz zu der geschriebenen Software: Sie wurde als Echtzeitanwendung implementiert. Auf dem Bedienrechner wurde das Programm als .exe kompiliert, um die Bedienung auch LabVIEW - Unerfahrenen zu ermöglichen. Auf dem Echtzeitrechner wurde die Software ebenfalls kompiliert und im Autostart hinterlegt. Das Ganze läuft in dem größeren Rahmen eines Zustandsautomaten mit folgenden Zuständen:

Initialize - Startwerte einstellen, Kontakt zwischen den Rechnern herstellen
Idle - Parameter eingeben und übertragen, auf Start warten
Measure - Durchführung der eigentlichen Messung
Stop - Prüfstand in sicheren Zustand überführen, auf Benutzereingabe warten (neue Messung oder schließen)
Shutdown - beide Programme schließen.

Ich hatte bereits letztes Jahr festgestellt, dass im Zustand Idle manchmal keine Messwerte an den Bedienrechner übergeben werden, habe das aber damals nicht weiter verfolgt, weil das nur in diesem einen Zustand auftrat und ich davon ausging, dass das nicht weiter kritisch wäre.
Jetzt hat sich aber gezeigt, dass dem nicht so ist. Die Messwertübertragung wird auch während des Betriebs unterbrochen. Genauer gesagt funktioniert die gesamte Regelung, Messwerterfassung und Wertausgabe nicht mehr. Das ist äußerst kritisch und kann so nicht bleiben! Ich konnte den Fehler bereits genauer einschränken:

Er liegt im Echtzeit - Hauptprogramm RT-Main.vi. Dort habe ich 3 zeitgesteuerte Schleifen. Eine Schleife übernimmt die gesamte Datenerfassung, -ausgabe und die Regelung. In ihr laufen die einzelnen Messmodi.
Dann gibt es eine Verarbeitungsschleife für die Messdaten. Sie läuft mit einer höheren Frequenz als die Erzeugerschleife. Die Daten werden über einen FIFO übergeben. Wenn eine Einzelmessung des Messprogramms abgearbeitet wurde, werden die Daten über einen weiteren FIFO an eine dritte Schleife übergeben, die die Daten in die TDMS Datei schreibt. So kann ich die Datei kompakt halten.
Der Fehler liegt in der Erzeugerschleife. Das kann ich sehen, weil während eines solchen Aussetzers die CPU Auslastung massiv absinkt. Durch die manuelle Verteilung der Schleifen auf die beiden Prozessorkerne konnte ich sehen, dass nur die CPU Auslastung auf dem Kern absank, der ausschließlich diese Schleife abarbeitet (von ca. 35% auf 6-10 % auf diesem Core, der andere Core bleibt unverändert bei 67 - 69%). Dort finde ich aber kein Problem! Der Schleifenzähler läuft weiter, nur sonst scheint die Schleife nichts mehr zu machen. Die Netzwerkverbindung steht zuverlässig (Sondenwerte werden sauber übertragen). Edit: Das merkwürdige daran ist nur, dass das in unregelmäßigen Abständen passiert. Manchmal vergehen mehrere Minuten zwischen diesen Aussetzern, manchmal nur wenige Sekunden. Die Aussetzer sind unterschiedlich lang, ich schätze mal maximal 10 Sekunden aber das Programm macht immer irgendwann wieder weiter. Wenn es dann wieder weiter geht, ist interessant, dass die CPU Auslastung 2 - 3 Sekunden auf über 50% auf diesem Kern geht und danach wieder auf das Normalniveau absinkt. Ich komme einfach nicht weiter.
Sämtliche DAQ-Tasks sind im MAX definiert und das soll auch so bleiben, da je nach Messung zusätzliche Sensoren integriert werden müssen, für die individuelle Skalierungen nötig sind und dafür keine Programmcodeänderung vorgenommen werden soll.

Vielleicht hat ja einer von euch eine Idee, woran es liegen könnte.

Das Programm lade ich hoch. Ich habe hier zu Hause allerdings kein LabVIEW und komme ziemlich sicher in dieser Woche nicht nochmal an den Prüfstand. Deshalb hoffe ich, dass es kein Problem ist, wenn ich das gesamte Projekt als .zip hochlade.
Weiterhin bitte ich zu entschuldigen, dass es dem gesamten Programm an Übersichtlichkeit mangelt. Es war mein erstes LabVIEW - Projekt und ich konnte nicht einschätzen, wie sich das ausdehnt. Bisher fehlte mir auch die Zeit, alles übersichtlich zu verpacken.

Edit: Vielleicht ist das noch interessant: Alle Werte werden als einzelne Samples gelesen. Die Abtastfrequenz beträgt bedingt durch den Schleifendurchlauf 500 Hz. Es werden analog mittels der PXI-6229 16 Kanäle gemessen und 3 Kanäle geschrieben. Digital werden 4 Kanäle geschrieben, gelesen werden 7 Kanäle. Digital I/O passiert über die PXI-6528.

Alles, was nicht deterministisch ablaufen kann oder muss (also gerade File I/O oder Netzwerk-Kommunikation) hat nichts in einer Timed-Loop zu suchen! An deiner Stelle würde ich mir die beiden unteren Timed-Loops schenken und durch normale Schleifen ersetzen. Die Taktung hast du automatisch durch die FIFOs.

Dann zu den RT-FIFOs: Zwecks Einstellung "Polling" jagst du die CPU-Last unnötig in die Höhe. Probier mal lieber den Modus "Blocking".

Gruß, Jens

Danke dir Jens für die Hinweise. Ich werde das mal so versuchen.
Was würdest du empfehlen? Blocking für lesen und schreiben oder nur für eines der beiden?

Was mich daran nur wundert, ist, dass die CPU Last ja sinkt, als ob er nichts mehr zu tun hätte. Aber selbst, wenn er keine Messwerte lesen würde, würden die Berechnungen und die Weitergabe ja funktionieren, weshalb die CPU Last nicht groß anders sein dürfte.

Viele Grüße
Kai

Leider hat es das noch nicht gebracht. Ich habe jetzt zwar eine deutlich geringer Auslastung der CPU aber das Problem ist nicht verschwunden.

In unregelmäßigen Abständen bleiben die Messwerte für unregelmäßig lange Zeiten aus. Die Schleife läuft dabei definitiv weiter durch aber es werden keine neuen Messwerte erfasst. Es scheint so, als würde der Messtask abstürzen bzw. einfach keine neuen Werte lesen / schreiben.
Ich habe jetzt DAQmx auf die Version 9.3 aktualisiert (mWn. die letzte mit LabVIEW 8.5 kompatible Version). Keine Änderung. Die zeitgesteuerte Schleife bringt keinen Fehler. Die Messwerterfassung und -ausgabe bringen keine Fehler. Es ist geradezu zum verrückt werden.

Hat jemand noch einen anderen Ansatz?

Viele Grüße
Kai

Rückfrage:
Woran erkennst du, dass die Datenerfassung (angeblich) aussetzt? Am RT oder am Host? Hast du schon mal debuggt, ob die Schleifen wirklich verspätet laufen (Stichwort Left Data Node, Auswahl Finished late?). Oder sieht es einfach nur so aus in deiner Host-Applikation, die irgendwann nicht mehr nachkommt bei der Netzwerkkommunikation per Netzwerkvariablen?

Ganz übel in deiner Host-Applikation: Dein permanentes Setzen von PropertyNodes! Jedes Setzen erzwingt ein Frontpanel-Update, das ist echt übel! Bitte ändern.

Gruß, Jens

Ich nehme alles zurück und behaupte das Gegenteil! Das Problem ist gelöst! Es war die Umwandlung von Double in Single. Meine FIFOs waren beide als Single - Arrays definiert. Nachdem ich das in Double - Arrays geändert habe und den Rest des Programms entsprechend angepasst habe, war der Fehler weg.

Dabei hatte ich teilweise explizite Konvertierungsfunktionen und die automatische Konvertierung im Programm. Scheinbar war es primär die automatische Konvertierung, die den Fehler auslöste. Aber auch die Konvertierungs-VIs scheinen in seltenen Fällen zu Problemen geführt zu haben.

Noch als Antwort auf deine Frage @Jens: Eine Sonde am Schleifenzähler brachte ein kontinuierliches Hochzählen. Eine Sonde an Finished late zeigte, dass die Schleife nicht verzögert lief. Eine Sonde an den Messdaten (direkt nach dem Ausgang des DAQ-read-VIs) zeigte aber, dass die gelesenen Daten sich während des Problems tatsächlich nicht mehr veränderten. Das mit den Property Nodes habe ich geändert. Vielen Dank für den Tipp und allgemein die Hilfe!

Viele Grüße
Kai

Auf Sonden am RT-System (gerade im interaktiven Modus und per Netzwerk) würde ich mich nicht verlassen.

Gruß, Jens