Arbeitsspeicher nach 3 Tagen voll/Systemabsturz

Hallo,

folgende Problematik:

Ich steuere ein kleine Anlage (Ventile, Pumpen, Messsignale) zu Wasseraufbereitung mit LabVIEW und einem WAGO I/O System 750. Das VI besteht aus Steuerungs, Datenlogging (als .txt file), Messdatenvisualisierung in Diagrammen, und der Bedien/Parametrierungsoberfläche. Alles funktioniert soweit exzellent.

Allerdings gibts nach 3 Tagen Dauerbetrieb die Meldung (von Windows?) "Speicher voll!" HAbe dann via Taskmanager die Nutzung des virtuellen Speichers und der Prozessorleistung beobachtet: steigt bis zum Absturz.

Das VI ist zugegebenerweise recht primitiv programmiert, d.h ich benutze Lokale Variablen um die Daten und Ventilzustände in meinen vielen Do-while Schleifen auszutauschen. Es sind bestimmt so an die 50 lokale Variablen.

Die Schleifen sind alle getaktet (min 100 mS), die Diagramwerte limitiert bzw Absturz auch ohne aktive Diagramme/Datenaufzeichnung. Das System "überlädt" sich sogar, wenn die Anlage nicht in Betrieb ist, sondern das VI nur auf Eingabe (Start-Button) wartet. Habe natürlch schon soviel wie möglich Schleifen rausgelöscht, um zu sehen, welche den Fehler birgt, aber keinen Erfolg, immer dassselbe. Auch ohne Verbindung zum Wago System stürzt der (die) Rechner ab.

Kann es an den lokalen Variablen liegen? Hat jemand ne Idee?

VI hänge ich erstmal nich an, will ich keinem zumuten...
Danke.

Tag!

' schrieb:Kann es an den lokalen Variablen liegen? Hat jemand ne Idee?

VI hänge ich erstmal nich an, will ich keinem zumuten...
Danke.

Die Vermutung mit den lokalen Variablen liegt schon nahe... Alternativ ist es auch keine gute Idee, Messdaten über längere Zeit in Frontpanel-Elementen, Variablen etc. zu speichern, besser in Dateien oder andere Dignen, die nicht im Speicher liegen...

Wenn das VI fehlt, wirst Du hier glaub ich außer Mutmaßungen nicht viel mehr zu hören bekommen...

ch

Lokale Variablen könnten ein Fehler sein.

Ich tippe aber viel eher auf nicht geschlossene Referenzen. Du erzählst da was von WAGO System, was ist denn die Schnittstelle dazu? Irgendwas mit ActiveX vielleicht? Dann liegt es garantiert daran, dass du irgendwelche Refnums aufmachst und nicht schließt.

Lad dir mal den Process Explorer von SysInternals (http://technet.microsoft.com/de-de/sysin...6653.aspx) runter und schau nach, ob bei deiner Applikation Handles hochlaufen, das wäre ein sehr schlechtes Zeichen.

Gruß, Jens

Danke erstmal,

Jens, ich habe den Process Explorer installiert, es laufen tatsächlich "Handles" hoch, sobal ich die Applikation starte.

Allerdings habe ich keine Refnums aufgemacht, zumindest nicht bewußt....das exotischste was ich habe, ist ein Typendefinition.

Das WAGO System wird über ein WAGO-Treiber SUBVi kontaktiert (Ethernet Verbindung, TCP Protokoll). HAbe aber das VI auch ohne den Teiber laufen, und die Handles laufen hoch.

Schicke morgen dann doch mal das VI, no pain, no gain...

Grüße

Patrick

Ein weiterer gern gemachter Fehler sind Melder und/oder Queues. Jede Anforderung per "Obtain" kostet etwas Speicher, der durch ein Close wieder freigegeben werden sollte.

Gruß, Jens

  Steuerung_PUE11_27.vi (Größe: 2,17 MB / Downloads: 341)


Habe das Gesamtprogramm nochmal gecheckt, die Ursache für die Handles war tatsächlich der "WAGO"Treiber. Allerdings müllt sich der Arbeitsspeicher auch ohne Treiber zu, ohne dass Handles hochlaufen...

Ich hänge mal das VI mit an...habe in jeder Schleife ein Textfeld mit deren Funktion eingefügt, bleibt immer noch verwirrend...die WAGO SUBVIs habe ich rausgelöscht, sonst wird nach der entspechenden Bibliothek sucht...

Grüße

Patrick

Ich kann nicht anders...so ein Chaos hab ich noch nicht gesehen...diese SW-Struktur ist echt bescheiden...solange du da nicht mal aufräumst, wird sich hoffentlich keiner die Mühe machen und dir helfen! Ich krieg ja ne steife Hand vom scrollen...

Merke: Alles was über eine Bildschirmgröße im BD raus geht, sollte das letzte Zeichen sein um endlich mal SubVIs einzuführen! Und außerdem: Was sollen den die riesigen leeren Bereiche?

Hi Achim,

ja, ja, ist ja gut.
Die leeren Bereiche kommen von der "Aufräum"-Funktion in LabVIEW.
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).

War ja nur ein Strohhalm, bin mir über die Strukturprobleme durchaus bewusst, ist aber auch ein komplexes Programm.

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?

Grüße

Wer hat gesagt, das man keine SubVIs benutzen soll?!

Tipps zur Vermeidung von Speicherüberläufen hast du schon gekriegt. Offenbar hilft dir das erst mal nicht. Um jetzt weitersuchen zu können müsste man sich deinen Code mal genauer anschauen. Ich hab aber keine Lust, mich da durch zu wühlen. Solange der Code nicht so aufgeräumt, das man schnell einzelne Funktionen darin identifizieren kann, werde ich da nichts weiter unternehmen...

Also: Alles schön von links nach rechts coden, gerade Drähte ziehen...und nicht größer als eine Bildschirmseite pro Blockdiagramm!

Viel Spaß...

A.

' schrieb:Wer hat gesagt, das man keine SubVIs benutzen soll?!

Ein SubVI belegt zusätzlichen Speicher, weswegen es in der LV-INI den Schlüssel InlineSubVI gibt. Besagter Schlüssel fügt dem Kontextmenü eine Option zur Auflösung von SubVIs hinzu. Über den Nutzen lässt sich vortrefflich streiten, insbesondere wenn der restliche Code ausschaut wie Kraut und Rüben. In manchen Fällen mag das aber etwas bringen. In diesem Fall bringt es nichts, denn der erneute Aufruf eines SubVIs belegt ja nicht noch einmal Speicher.

Wie Achim aber schon sagt, wir helfen dir gerne, aber da keiner von uns dafür bezahlt wird möchte jedenfalls ich auch ein bißchen Spaß dabei haben. Und der kommt nicht auf, wenn unaufgeräumter Code vor einem liegt (er muss nicht schön sein).

Edit: @Achim:War natürlich ein Tippfehler.