Arbeitsspeicher nach 3 Tagen voll/Systemabsturz

' schrieb:Und der kommt nicht auf, wenn aufgeräumter Code vor einem liegt.

What?

Anzeige

' schrieb:Ich habe übrigens alle Sub Vis wieder zurück ins Hauptprogramm geführt, weil ich bei NI gelesen habe dass SUB Vis auch Speicher belegen können, da auch Sub Vis Kopien im Speicher anlegen. Deswegen kam von dort die Empfehlung, keine (!) Sub Vis zu benutzen (was klar gegen die Schön- Programmier-Richtlinie geht).

Hallo,
das glaube ich nicht..

' schrieb:Prinzipiell gehts ja um die Frage: was lässt die Arbeitssspeicherbelegung anwachsen? Sind es die lokalen Variablen? Wenn ja, kann ich den durch LabVIEW leeren, ohne das VI zu stoppen?

Ich habe jetzt nur mal flüchtig den Code angesehen und nachdem Achim eine steife Hand hat musste ich den Reifen vom Scrollrad wechseln, also keine
Wunder erwarten.
Schleife 1:Liefert die Daten für die Diagramme
Hier erstellt Du für max. 72 Std bei einer Aktualisierung von 1/s für jeden der 9 Kanäle ein Array und führst diese Arrays CHARTS zu die von Hause aus eine Historienlänge haben.
Nebenbei bemerkt entsprechen diese Arrays max. 9*3600*72 = 2332800 Werte die erstmal dargestellt und intern gehandelt werden müssen.
Suche mal hier im Forum nach Ringspeicher..

Gruß
Ralf

Von NI? Das glaube ich beim besten Willen nicht. Ich habe so ziemlich jede LabVIEW-Schulung bei NI mitgemacht (inkl. Performance Guide) und dort machen sie eher ein SubVI zu viel als zu wenig!
Wer hat Dir das denn gesagt, bzw. wo hast Du das bei NI gelesen?

Gruß Markus

' schrieb:Deswegen kam von dort die Empfehlung, keine (!) Sub Vis zu benutzen (was klar gegen die Schön- Programmier-Richtlinie geht).

' schrieb:Ich habe jetzt nur mal flüchtig den Code angesehen und nachdem Achim eine steife Hand hat musste ich den Reifen vom Scrollrad wechseln, also keine
Wunder erwarten.

Ich auch, ich auch...

Habe aber trotzdem was gefunden, was mit gar nicht gefällt:
   

Gruß, Jens

' schrieb:Ich auch, ich auch...

Ich auch, ich auch ...

Das mit der File-Referenz-Verzweigung sehe ich bezüglich Schließen nicht so eng. Schlimmer ist, dass dadurch zwei parallele Schreibzugriffe auf die Datei möglich sind. Frage: Welcher der beiden Schreibzugriffe findet zuerst statt?

Ansonsten schließe ich mich den Hinweisen von rasta an. Möglicherweise kommt der Speicherverbrauch von den Graphen, die bekanntermaßer Speicherverbraucher sind.

Außerdem sollte folgendes überlegt werden:
Wenn in einen (Sub)VI Speicher alloziert wird, so wird der frühestens am Ende des (Sub)VIs wieder freieggeben. So gesehen haben SubVIs also weitere Vorteile. Sollte in einem so großen VI Speicher zyklisch angefordert werden (was ich zwar nicht beweisen, mir aber ohne weiteres vorstellen kann), so wird eines Tages der Speicher überlaufen. Programmiert mit SubVIs würde kurzzeitig verwendeter Speicher wieder freigegeben werden.

LV löst viele SubVIs schon von sich aus auf, aber eben nicht alle, bei denen es möglich wäre. Ab welcher Version LV das macht weiß ich leider nicht, aber ich tippe mal auf 8.5.

http://zone.ni.com/devzone/cda/pub/p/id/347

Dein Link beantwortet das ja schon eingehend:

Zitat:The LabVIEW compiler performs compile-time inlining, but you also can force inlining in the development environment by adding the line “inlineSubVIEnabled=TRUE” to your LabVIEW.ini file. Once you restart LabVIEW, a new item called Inline subVI appears in the right-click menu of subVIs on block diagrams (see Figure 4). Selecting this item moves the code from the subVI into the calling VI, effectively the reverse of “Create subVI.” This feature does not usually make for the most attractive code and removes several often important features of using subVIs – including modularity, encapsulation, and scalability – but it is a handy shortcut if you need to force visibility in the development environment.

Meistens sind SubVIs eben doch die bessere Wahl...

Hi,
tschuldigung für die Abnutzungserscheinungen beim VI check.
Habe aber leider keine Zeit, das VI prinzipiell neu aufzusetzen, was ich aber gerne machen würde (wenn ich könnte). Muss so halt weiter mit dem Spott der LabVIEW Pros leben...

Die Info, dass ein SUBVI eine höhere Speicherauslastung zur Folge haben kann, stammt aus der LAbView Hilfe, da steht zwar unter "Speicherauslastung" dasss man die Style Guide befolgen soll (Sprich:SubVis), an einem andern Ort in der Hilfe (den ich zugegebenerweise nicht mehr finde, deswegen: auch egal!) wurde behauptet, dass wenn das VI schnell wie möglich mit der wenigsten Speicherauslastung laufen soll, dann, sinngemäß wiedergegebn: solle man sich nicht an die Style guide halten und ohne SubVis programmieren...ICh habs da halt gelesen, jetzt mühselig darüber zu diskutieren. Ganz klär täten meinem VI SubVis gut, das ist nicht die Ursache für die Speicherauslastung (habe ich auch getestet, so dass jetzt ca. 4 Schleifen vorher in einem SubVi realisiert waren--> Kein Unterschied in der Performance.

Ich habe wie bereits anfangs erwähnt, sämtliche "verdächtige" Schleifen (z.B: Diagramme, Datenarchivierung, PID Regler) rausgelöscht, trotzdem stieg die Speicherauslastung innerhalb der 3,4 Tage bis zum Absturz.
In der Hilfe fand ich folgendes:

"Lokale Variablen erstellen Kopien der Datenpuffer. Das heißt, beim Auslesen einer lokalen Variable wird für die Daten des damit verbundenen Bedienelements ein neuer Puffer erstellt.
Wenn eine große Anzahl an Daten von einer Stelle im Blockdiagramm an eine andere übertragen wird, ist im Allgemeinen mehr Speicherplatz erforderlich, und dementsprechend verlangsamt sich auch die Ausführungsgeschwindigkeit gegenüber dem Datenaustausch über eine normale Verbindung. Zur Speicherung von Daten während der VI-Ausführung empfiehlt es sich, Schieberegister zu verwenden. "

Ist meine Variablenanzahl wirklich so hoch, dass es zum Überlauf kommen kann? Kanns irgendwie nicht glauben....Ist die "Struktur" mit x parallel laufenden Schleifen ein Problem? Oder gibts ein Problem mit der "State Machine (Schleife 2)?
Grüße

' schrieb:"Lokale Variablen erstellen Kopien der Datenpuffer. Das heißt, beim Auslesen einer lokalen Variable wird für die Daten des damit verbundenen Bedienelements ein neuer Puffer erstellt.

Wenn hier gesagt wird, dass lokale Variablen Speicherplatz verbrauchen, dann ist das so gesehen richtig - aber ggf. unerheblich für dein Problem. Der Variablen-Speicher muss ja nicht ständig neu angefordert werden. Einmal vorhanden ist ja ausreichend. Das gilt für Basistypen (INT, Bool, DBL etc.) und Zusammenstellungen von Basistypen (cluster).
Achtung Ausnahme: dynamische Datentypen wie z.B. Strings und Array werden bei jedem Beschreiben neu alloziert.

Zitat:Ist meine Variablenanzahl wirklich so hoch, dass es zum Überlauf kommen kann?

Da muss ich, da mir das mit den dynamischen Typen eingefallen ist, noch mal kucken.

Zitat:Ist die "Struktur" mit x parallel laufenden Schleifen ein Problem?

Per se nicht. (Ich zähl die vielen Xe schon gar nicht mehr).

Zitat:Oder gibts ein Problem mit der "State Machine (Schleife 2)?

Soll ich die auch noch ankucken?

' schrieb:(Schleife 2)?

Wieso denn erst Schleife 2? Bei deinem Programm geht's schon in Schleife 1 los! (Wie war das mit dem Schaden und dem Spott?)

Du hast dort 9 Stück Array in Schieberegister. Die Länge der Arrays ändert sich pro Schleifendurchlauf. Wenn die maximale Arraylänge erreicht ist, löscht du das erste Element und fügst ein neues hinten an. Das alles kostet Speicher. Da die Schleife nur einmal pro Sekunde durchlaufen wird, kann ich mir vorstellen, dass der Absturz erst nach 3 Tagen passiert.

Ich würde hier folgendes machen: Initialisieren der Schieberegister mit 1DArr of DBL, Wert NAN, Länge MAX. Statt "An Array anhängen" nimmst du "In Array ersetzen". Das mit dem Löschen lässt du weg und nimmst stattdessen "1DArr rotieren".

Nachtrag:
Beachte weiterhin auch Beitrag #12.