Nachträgliche Optimierung von funktionierendem Prgramm

Hallo libe Labview Freunde,

ich habe mir zwecks meiner Doktorarbeit ein Prozessleitsystem für einen Bioreaktor mit Labview gebastelt.
Klassischerweise habe ich eigentlich kaum Zeit mich mit der Programmierung zu beschäftigen, da mein Thema sich auf andere Dinge bezieht...

Dementsprechend sieht auch mein Labview Programm aus, dass von Zeit zu Zeit mit Steigenden speziellen Anforderungen wuchs.
Es funktioniert wie es soll, nur nach dem es jetzt immer komplexer wurde und ich es ohne "Labview Fachwissen"
immer weiter ergänzte wurde es immer Langsamer und hängte sich teilweise auf.

Grundsätzlich werden in dem Programm externe Daten (Digital und Analog) über ein NIUSB-6001 und seriellen Ports aufgenommen, verarbeitet,
in Graphen angezeigt und über das write to measurement file in Excel gespeichert

Das Programmm befindet in einer großen while Schleife die sich alle 100 ms wiederholen soll. Ich sehe allerdings, dass er dies nur alle 2 sec oder so schafft (Sekundenanzeige steigt nur alle 2 sec)
Das größte Problem habe ich mit der Speicherung. Hier speichere ich alle Daten jede Minute in Excel. Nach ein paar Stunden habe ich allerdings einen Delay drin der sich immer fortsetzt.
(z.B 1000 mal gespeichert, es stehen aber 1010 Minuten in der Zeitspalte).
Ich habe das Gefühl, dass mein Rechner mit dem riesigen Loop nicht klar kommt.

Gibt es eine generelle Möglichkeit große Programme stabilier und schneller zu gestalten oder gibt es bei mir schon auf dem ersten Blick "Bremsen" im Programm?

Vielen Dank

Tyll

Anzeige

Hallo Tyll,

Zitat:Gibt es eine generelle Möglichkeit große Programme stabilier und schneller zu gestalten

Ja: Man überlegt sich vor dem Programmieren einen vernünftigen Aufbau…

Zitat:gibt es bei mir schon auf dem ersten Blick "Bremsen" im Programm?

Bei einem Blick auf den Screenshot fallen mir Unmengen an ExpressVIs auf: die sind nicht gerade auf Geschwindigkeit hin optimiert… (Wofür benötigt man sooo viele ElapsedTime-Funktionen?)
Und die vielen Knicke in den Drähten lassen die Daten auch langsamer im Programm fließen!

Zitat:Es funktioniert wie es soll, … wurde es immer Langsamer und hängte sich teilweise auf.

Solche Zusammenfassungen sind immer wieder hübsch zu lesen…

Im Ernst:
LabVIEW kommt auch mit Beispielen, wie man Programme erstellt, die bestimmte Aufgaben effizient erledigen können.
Einfach mal im Dateimenü auf "Neu…" klicken und schauen, welche Vorschläge es für neue Projekte gibt!

Hauptübel auf den ersten Blick:

Deine vielen Express-XY-Graphen, in denen du ALLE erfassten Daten sammelst. Da läuft dir wahrscheinlich recht schnell der Speicherverbrauch hoch - ganz zu schweigen davon, dass ein XY-Graph auch immer langsamer wird, je mehr Daten er zu zeichnen hat.

Zweite "Bremse": Du hast da 2 VISA-Read, die bei einer Baud-Rate von 1200 auf (bis zu) 14 Zeichen warten. Grob überschlagen dauert alleine das Übertragen von 14 Zeichen bei 1200 Baud mehr als 100 EDIT: Zwecks 2 Stop-Bits > 125 ms. Und wehe, da kommt nichts auf der seriellen Schnittstelle, dann wartest du den eingestellten Time-Out, und das sind 10 Sekunden. EDIT: Je nach Einstellungen eines Schalters liest du sogar 2x von derselben Schnittstelle, das wären dann > 250 ms.

Zum Rest der Tapete sag ich jetzt lieber nichts...

Gruß, Jens

Danke für die erste Einschätzung... Ich weiß das ist kein Meisterwerk nur leider habe ich nicht viel Zeit mich mit Labview im Detail zu beschäftgen (obwohl mir das echt Spaß bringt ...)

Ich dachte mir schon, dass die Expess VI nicht die optimalsten Lösungen sind aber gibt es eine Möglichkeit die Daten ohne,
dass sie den Speicher belasten continuierlich aufzutragen?

Hallo Tyll,

Zitat:gibt es eine Möglichkeit die Daten ohne, dass sie den Speicher belasten continuierlich aufzutragen?

- verwende Charts statt Graphen. Die haben eine eingebaute Historie, die du auf eine maximale Länge konfigurieren kannst
- sammle deine Plotdaten in eigenen Schieberegistern und achte dabei selbst auf die maximale Datenmenge

Wenn man dann noch die Anzeige der Daten in eine parallele Schleife packt (und damit ein Producer-Consumer-Schema umsetzt), dann verhindert man auch, dass die Anzeige den DAQ-Teil deines Programms blockiert/verlangsamt…

(16.03.2017 09:49 )Tyll schrieb:  gibt es eine Möglichkeit die Daten ohne, dass sie den Speicher belasten continuierlich aufzutragen?

Definiere kontinuierlich: Wenn du damit meinst, dass du alle erfassten Daten angezeigt haben willst, dann NEIN. (Logisch, oder?)
Ansonsten siehe Gerds Hinweis.

Gruß, Jens

Anzeige

naja ich dachte daran, dass nur der graphverlauf angezeigt bleibt, wird ohne dass ein riesen datensatz dahinter steht, da ich diesen ja sowieso minütlich speichere.

Hallo Tyll,

Zitat:naja ich dachte daran, dass nur der graphverlauf angezeigt bleibt, wird ohne dass ein riesen datensatz dahinter steht, da ich diesen ja sowieso minütlich speichere.

Ein Graph zeigt genau das an, was er an Plotdaten bekommt.
Ergo: ohne "riesen Datensatz" kein "großer Plot"!

Möglicher Workaround: Ein Bild des Graphen machen und dieses als Hintergrundbild des Graphen einblenden. Dann kann der "riesen Datensatz" gelöscht werden. Ob das jetzt sinnvoll/einfach ist, sei mal dahingestellt…
(Das ist nichts, was sich mit einem ExpressVI erledigen ließe. )

Außerdem: Ist deine Tastatur kaputt? Hol dir mal eine mit funktionierender Hochstelltaste…

Demenstprechend könnte ich dann ja auch den Graph z.B. nur alle Minute mit einer Case Struktur ausführen und so weniger Daten plotten oder?

(16.03.2017 13:36 )Tyll schrieb:  Demenstprechend könnte ich dann ja auch den Graph z.B. nur alle Minute mit einer Case Struktur ausführen und so weniger Daten plotten oder?

Könntest du. Aber nach 24 h hast du dann auch schon 86400 Datenpunkte (EDIT, oh, das waren Sekunden, in Minuten natürlich) 1440 Datenpunkte pro Plot in den Graphen. Wie lange läuft das Programm denn am Stück?

Vergiss aber auch nicht die Bremse VISA-Read. Hast du schon einmal ausgewertet, wie lange diese beiden Reads wirklich auf die Daten warten?

Das Datenspeichern würde ich an deiner Stelle auch selber erledigen, und zwar im csv-Format - nicht durch ein Express-VI im XLSX-Format.

Gruß, Jens