11.07.2005, 16:30
Beitrag #1
|
tosi
LVF-Grünschnabel
Beiträge: 32
Registriert seit: May 2005
kA
|
Rechner am Anschlag? Oder LabVIEW?
Hallo zusammen,
ich hätt mal eine ganz allgemeine Frage...könnt trotzdem sein, dass sie besser bei Hardware aufgehoben wäre - ich probiers trotzdem:
Ich bekomme hin und wieder die Fehlermeldung, dass meine Schleife die Daten, die ich über meine NI-PCI-6143 erfasse nicht schnell genug verarbeiten kann. Gut, hatte ich anfangs auch und habe dann meine VIs so optimiert, dass es keine Probleme mehr gab.
Jetzt läuft alles wunderbar über Stunden, bis die Meldung aus heiterem Himmel wieder kommt. Seltsamerweise zeigt die CPU-Usage dann nur 3% an (auch kurz bevor die Meldung kommt) die normalerweise bei 50% liegt. Wenn ich dann nur das VI stoppe und danach wieder starte, geht immer noch nichts(CPU 3%). Erst nachdem ich LabVIEW komplett geschlossen habe und dann wieder alles starte, habe ich für die nächsten Stunden keine Probleme mehr.
Kann sich da jemand einen Reim drauf machen? Ich kann den Fehler nicht reproduzieren, d.h. wenn ich LabVIEW und meinen Rechner besonders stresse (z.B. gleichzeitig auf 8 Kanälen erfassen, Graphen zeichnen und Textfiles schreiben) funktioniert meist alles. Dann aber plötzlich die Meldung...
Vielleicht hatte ja schon mal jemand ähnliche Probleme - wäre dankbar für jede Anregung.
Gruß, Tosi
|
|
|
11.07.2005, 18:27
Beitrag #2
|
|
|
12.07.2005, 08:15
Beitrag #3
|
tosi
LVF-Grünschnabel
Beiträge: 32
Registriert seit: May 2005
kA
|
Rechner am Anschlag? Oder LabVIEW?
Hallo Oliver,
ich glaube nicht, dass ich Queues oder Semaphoren benutze - ganz ausschließen kann ichs nicht, da sich in einigen VIs ja so manches versteckt. Aber klar, irgendwas muß es ja mit dem Speicher zu tun haben, da der Crash ja nach einer gewissen Zeit auftritt - und nicht wenn ich mein Zeug extra stresse.
Hmmm...was wird denn gelöscht, wenn ich LabVIEW ganz verlasse? Bestimmt so einiges. Ich würds halt gerne irgendwie eingrenzen können.
Gruß, Tosi
|
|
|
12.07.2005, 08:38
Beitrag #4
|
marker
LVF-Gelegenheitsschreiber
Beiträge: 226
Registriert seit: Feb 2005
8.2.1
2002
kA
Deutschland
|
Rechner am Anschlag? Oder LabVIEW?
Hi tosi,
hast Du viele SubVI-Aufrufe?
Dann schau Dir mal die Funktion "Speicherfreigabe anfordern (Request Deallocation)" unter "Fortgeschritten->Datenmanipulation" an.
Die Hilfe dazu wird weitere Fragen beantworten.
Außerdem könnte es sein, dass Du Referenzen in Endlosschleifen öffnest oder Arrays versehentlich dynamisch erweitert werden.
Gruß,
Marko
"Make it simple, make it strong!"
|
|
|
12.07.2005, 08:43
Beitrag #5
|
Oliver Listing
LVF-Freak
Beiträge: 721
Registriert seit: Sep 2004
2012 und 2014 (Windows und Linux)
1998
EN
22844
Deutschland
|
Rechner am Anschlag? Oder LabVIEW?
Hi tosi,
ich hatte ein Problem mit Queues gehabt, deshalb regte ich das an.
Ich hatte während der Messung die Messdaten in einem dynamischen VI gespeichert und die Referenz darauf per Queue verschickt zur weiteren Anzeige und Verarbeitung. Da ich die Referenz auf die Queue nicht durchschleifen wollte, dachte ich mir halt:
Setzt "create if not found" auf False, dann gibt er mir die vorhandene Referenz.
Aber denkste. Mit jedem mal, wo ich die Referenz mir auf diese Weise besorgte, verlor ich etwas Speicher. Dies war im einzelnden nicht zu bemerken, da es nur ein paar kB waren. Dauerte die Messung jedoch länger...
Wir sind erst mit einer Probe auf der Referenz darüber gestolpert, das er mir jedesmal eine neue Referenz besorgte.
Den verlorenen Speicher hat übrigends nicht LabVIEW veranschlagt. Man konnte ihn nur an der Anzeige für den gesamten Speicherverbrauch im Task Manager ablesen.
Fazit:
Solche Fehler sind, wenn man Sie nicht schoneinmal hatte, schwer zu finden. Wenn du kannst stelle den Code ein, aber ich denke du mußt Schrittweise versuchen den Punkt einzugrenzen. Leider ist das sehr Zeitaufwendig.
Deshalb würde ich erst versuchen, herauszufinden, ob du den Leistungsabfall nicht auch schon früher an anderen Stellen merken kannst (z.B. Speicherverbrauch von Windows)
Gruß
Oliver
|
|
|
12.07.2005, 09:01
Beitrag #6
|
|
|
12.07.2005, 09:10
Beitrag #7
|
marker
LVF-Gelegenheitsschreiber
Beiträge: 226
Registriert seit: Feb 2005
8.2.1
2002
kA
Deutschland
|
Rechner am Anschlag? Oder LabVIEW?
@ Oliver Frank
Ich erzeuge und benenne die Queues im Main-VI ("create if not found"=TRUE).
Im Sub-VI rufe ich sie wieder unter dem jeweiligen Namen auf ("create if not found"=FALSE). Wenn ich Dich richtig verstehe sind genau dabei bei Dir Probleme aufgetreten, oder war Deine Vorgehensweise doch anders?
Bisehr habe ich die Queue-Referenzen meist über Verbindungen übergeben.
Jetzt, nachdem ich Deinen Beitrag gelesen habe, kommen mir Zweifel ob ich das nicht weiterhin so machen sollte. Bis jetzt konnte ich keine Probleme feststellen, das kann aber auch damit zusammenhängen, dass die Software im Moment noch weiterentwickelt wird und immer nur kurze Testläufe (einige Stunden) gemacht werden.
Gruß,
Marko
"Make it simple, make it strong!"
|
|
|
12.07.2005, 09:31
Beitrag #8
|
marker
LVF-Gelegenheitsschreiber
Beiträge: 226
Registriert seit: Feb 2005
8.2.1
2002
kA
Deutschland
|
Rechner am Anschlag? Oder LabVIEW?
Hi tosi,
hast Du die Speicherprobleme wenn Du "Aufzeichnung bei Änderung des Pegels" gewählt hast?
Hier benutzt Du die Funktion "In Array einfügen" und als Index den Schleifenzähler. Das Array wird daher ziemlich groß und belegt Dir wohl mit der Zeit den ganzen Speicher.
Gruß,
Marko
"Make it simple, make it strong!"
|
|
|
12.07.2005, 11:49
|
marker
LVF-Gelegenheitsschreiber
Beiträge: 226
Registriert seit: Feb 2005
8.2.1
2002
kA
Deutschland
|
Rechner am Anschlag? Oder LabVIEW?
@ Oliver Frank
Hi Oliver,
schönes Demo-VI, vielen Dank. Da schein ich ja ein kleines Problem zu haben, aber Du hast ja schon einen Lösungsweg mitgeliefert.
Ich glaube das werde ich so realisieren, da besonders die dicken Referenz-Verbindungen (man hat ja sowieso schon genug davon) das Ganze ziemlich unübersichtlich werden lassen.
Das Problem besteht ja dann wahrscheinlich bei sämtlichen Referenzen (Melder, Semaphoren, Rendezvous, ...).
Gruß,
Marko
"Make it simple, make it strong!"
|
|
|
| |