Nicht genügend Quoten?

Mir ist die Tage ein merkwürdiger Fehler untergekommen, dessen Ursache ich bislang leider nicht herausfinden bzw. lokalisieren konnte. Aber vielleicht hat ja jemand hier im Forum eine Idee...

Der Täter: Ein recht komplexes Labview-Programm (8.6) mit vielen parallel laufenden VIs auf einen Windows XP Rechner.

Der Fehler: Nach gewisser Zeit erscheint der Fehler "Nicht genügend Quoten um den Befehl auszuführen" und praktisch nix geht mehr (auch ausserhalb von Labview), d.h. es sieht so aus, als ob alle Ressourcen des Rechners (von Labview?) belegt sind und der Rechner die Waffen streckt.

Die Geschichte: Das Programmpaket entwickle ich auf einem Windows-7 Rechner der augenscheinlich keinerlei Probleme mit dem Programm hat. Die ganzen VIs hatte ich in LLBs gruppiert um Struktur in das Programm zu bringen. In dieser Form tat das Programm auf dem Windows XP-Zielrechner auch klaglos seine Dienste. Dann bin ich über die Bemerkung gestolpert, dass NI (aus mir durchaus nachvollziehbaren Gründen) inzwischen von der Verwendung von LLBs abrät und man lieber normale (Unter)Ordner benutzen sollte. Warum also nicht? So habe ich aus allen LLBs normale Ordner gemacht und die VIs entsprechend angepasst. Da das Programm noch in Entwicklung ist, wurden zeitgleich auch noch zusätzlich ein paar kleine Modifikationen eingebaut (meiner Erinnerung nach nix relevantes, eher kosmetische Korrekturen). Auf meinem Win 7 Rechner war danach auch soweit alles in Ordnung, also das Ganze auf den XP-Zielrechner überspielt, kurzer Testlauf - auch alles reibungslos. Aber dann als das Programm intensiver genutzt wurde, kam der oben erwähnte Fehler: Der XP-Rechner crasht mit "Nicht genügend Quoten um den Befehl auszuführen". Genauer gesagt, crasht der Rechner anscheinend, wenn er bei einer Meßreihe Daten auf die Platte schreibt (so alle 3-5 sec. eine Textzeile, Dateigröße üblicherweise im einstelligen MB-Bereich, der Crash korelliert aber nicht mit einer bestimmten Dateigröße). Da dieser "Quoten"-Fehler für mich recht nichtssagend ist, habe ich alles gecheckt, was meiner Meinung nach für übermäßigen Ressourcen-Verbrauch verantwortlich sein könnte: Überlaufende Queues, nicht geschlossene Referenzen, zu große Arrays - alles in Ordnung und im grünen Bereich. Auch der XP-Rechner scheint soweit ok zu sein: mehr als genügend freier Festplattenspeicher, keine Kontigentverwaltung auf dem Laufwerk aktiv, Auslagerungsdatei auch nur zum Bruchteil voll laut Ressourcenmonitor etc.

Ich steh derzeit ziemlich auf dem Schlauch, was denn nun genau diesen Fehler verursacht (zur Zeit tut wieder die alte LLB-Version des Programm seinen Dienst - die Meßdaten werden auch wie vorgesehen ohne Probleme auf der Platte gespeichert). Die Wandlung von LLBs nach normalen Ordnern kanns doch nicht wirklich sein, oder? Über Tipps wie man diesem Problem beikommen könnte würde ich mich freuen. Momentan weiß ich nichtmal, wo bzw. wie ich überhaupt ansetzen muss, um den eigentlichen Kern des Problems zu finden...

Nachtrag: Auch auf dem Zielrechner läuft das Programm in der Entwicklungsumgebung, da manches Feintuning am Programm leider nur vor Ort möglich ist, d.h. wenn die anzusteuernden Meßgeräte auch wirklich da sind und auf die entsprechenden GPIB-Kommandos reagieren. Also keine .exe-Kompilat.

Schon mal eine Analyse per "Sysinternals ProcessExplorer" gemacht? Das Teil zeigt dir nämlich sehr schön weglaufenden Speicher und Handles.
Vielleicht hast du doch irgendeinen Bug im entpackten Projekt.

Zur Fehlermeldung gibt es eine ganze Reihe von Treffern im Internet, schon überprüft, z.B. das hier:
http://answers.microsoft.com/de-de/windo...2a467cc70c
uvm.

Offtopic:
LLBs haben einen Riesenschwäche: Durch noch ein fehlerhaftes Byte kannst du dir die gesamte Datei "zerstören", d.h. es ist kein einziges VI mehr herstellbar.

Gruß, Jens

Hallo THL,

wird dieser "Quoten"-Fehler mit einer NI/LabVIEW-Fehlermeldung angezeigt oder durch eine WIndows-Fehlermeldung?

"Quoten" kann bedeuten: auf einem Win-System kann man jedem User eine bestimmte Festplatten-Kapazität ("Quota") zuordnen. Wenn diese voll ist, kann der User keine weiteren Dateien anlegen. Damit kann man auf einem MultiUser-Rechner die vorhandene Festplattenkapazität gerecht zuteilen...
Wikipedia

Wie ich schon schrieb: Bei dem Rechner ist die Kontigentverwaltung ausgeschaltet. Das Problem trat ja auch erst dann auf als ich das Programm von LLB auf Subdirectories umgestellt hatte. Vorher lief die gleiche Meßdatenerfassung problemlos und auch jetzt läuft sie wieder anstandslos, als ich auf die alte LLB-Version zurückgegangen bin. Am Speicherplatz kann es also nicht liegen - es werden jetzt ja wieder Meßdaten gespeichert. Lag die Chose jetzt tatsächlich an dieser Umstellung? Oder hatte ich irgendwo anders was verbockt? Aber was? Was veranlasst Windows zu dieser Fehlermeldung auf dem XP Messrechner (auf meinem Win 7 Rechner dagegen keine Probleme)?

Zum Fehler selbst: Im Programm selbst werden manche VIs mit "open VI reference" über ihren Namen aufgerufen. Der Grund liegt darin, das ich für jedes Meßgerät eine Standard-Bibliothek erstellt habe, die nur bei Bedarf überhaupt geladen wird und das System so offen für neue Meßgeräte bleibt. Quasi eine plug-and-play Schnittstelle. Wenn der Rechner nun anfängt zu spinnen, läuft der VI-Aufruf ins Leere (wohl weil keine Ressourcen mehr da sind um das Teil zu laden). Das Hauptprogramm läuft ohne Probleme weiter, so dass man (wenn man nicht gerade auf die eingebaute Fehleranzeige schaut) das erstmal gar nicht mitkriegt. Andere Programme im Hintergrund, z.B. Origin spucken jedoch kryptische Fehlermeldungen aus - das war auch der Grund warum ich vom Nutzer zunächst kontaktiert wurde ("Origin spinnt rum"). Wenn ich dann im Windows Explorer auch nur irgendwas versuche (Verzeichnis wechseln, Textdatei anzeigen lassen etc.) kommt die besagte Fehlermeldung "Nicht genügend Quoten um den Befehl auszuführen". Erst wenn man Labview abschießt, ist der Spuk vorbei.

Auf Grund der Beschreibung schwer zu sagen, was die Ursache ist.
Die Vermutung liegt natürlich nahe, dass die irgendwas "verbockt" hast, aber was,
Könnte natürlich sein, dass irgendwelche File-Handles hochlaufen durch deine dynamischen VI-Aufrufe und es deshalb zu dieser Meldung kommt. Der Process-Explorer könnte beim Debugging helfen, da sollten in einem solchen Fall Handles hochzählen.

Gruß, Jens

Als ich den Thementitel gelesen habe, dachte ich, jetzt ist LabVIEW endgültig auch in der TV-Branche angekommen.

Gruß Markus

Anzeige

(25.11.2013 17:21 )jg schrieb:  Könnte natürlich sein, dass irgendwelche File-Handles hochlaufen durch deine dynamischen VI-Aufrufe und es deshalb zu dieser Meldung kommt. Der Process-Explorer könnte beim Debugging helfen, da sollten in einem solchen Fall Handles hochzählen.

Werd ich mal machen, wenn ich wieder Zugriff auf den Messrechner habe. Derzeit laufen halt gerade Messreihen (mit der früheren Version meines Messprogramms), die ich natürlich jetzt nicht abwürgen möchte.

(26.11.2013 12:41 )THL schrieb:  Werd ich mal machen, wenn ich wieder Zugriff auf den Messrechner habe. Derzeit laufen halt gerade Messreihen (mit der früheren Version meines Messprogramms), die ich natürlich jetzt nicht abwürgen möchte.

Verständlich, "never touch a runnning system".

Gruß, Jens