Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
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.
nutzt du in deiner Schleife Systemresourcen, wie Queues oder Semaphoren?
Wenn ja vorderst du sie immer neu an?
Dies würde nämlich Speicher verbrauchen, auch wenn du sagst, "gib vorhandene aus".
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.
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.
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)
Ich danke euch für die Tips. Da werd ich mich mal reinknien. Das mit der Speicherfreigabe und den Referenzen hört sich plausibel an. Hab auch gerade das VI Profile Window entdeckt - vielleicht hilft mir das auch noch bissel weiter? Mal sehen.
Ich stell das VI trotzdem mal ein - vermutlich könnt ihrs eh nicht gscheit öffnen, aber ein Versuch ists ja wert (nicht erschrecken;-))
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.
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.
richtig - was du gemacht hast habe ich auch gemacht.
Früher durchverbunden - nun halt die Verbindung sparen wollen...
Ich habe mal ein kleines Demo VI geschrieben. Dazu zunächst den Taskmanager öffnen und den Tab mit den Systemleistung öffnen.
Dann das VI einfach mal laufen lassen...
Siehe da der Speicherverbrauch des Systems klettert langsam höher.
Erst wenn LV ganz geschlossen wird, wird der Speicher wieder frei.
Daher die Verbindung zu tosi's Problem.
Gruß
Oliver
Ps: Habe übrigends auch schon eine Lösung, die aber an die jeweilige Queue angepasst werden muß:
Um das VI create Queue herum ein VI programmieren, welches über ein Shiftregister alle Queues diesen Typs verwaltet und bei Anfrage zunächst prüft, ob der Name schon im Shiftregister vorhanden ist und dann ggf. die Referenz herausgibt. Klar??
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, ...).
