LabVIEWForum.de - "Nicht genügend Speicher zum Abschließen dieser Operation"

LabVIEWForum.de

Normale Version: "Nicht genügend Speicher zum Abschließen dieser Operation"
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo Leute!
Ich bekomme die oben stehende Fehlermeldung. Mein Arbeitsspeicher ist 2GB und sollte eigentlich nicht solche Fehlermeldungen verursachen...
Die Fehlermeldung tritt auf, wenn ich ein Array mit 2x7200 Zellen an ein Array mit 6x7200 Zellen anhängen will. Jetzt würde ich gern wissen, kann ich LabVIEW mehr Arbeitsspeicher bereitstellen? Oder muss ich die Genaugikeit der Zellenwerte reduzieren? Gib es weitere Tricks oder hat jemand ein ähnliches Problem schon mal gehabt?

Danke für Ideen und Tipps!
Hab den Fehler gefunden. Das eine Array hatte 7200 Zeilen, das andere 7200 Spalten... Ein Transformation war nötig und das Problem war verschwunden...
Gruß,
Excalibour
Jetzt habe ich extra mein altes 7.0 angeschmissen, um dich auf den Fehler hinzuweisen, den du jetzt selber entdeckt hast.

MfG, Jens
Meine VI spuckt auch diese Fehlermeldung aus.
Ich habe mal Screenshots von den Meldungnen und dem offensichtlichen Übeltäter hochgeladen.

Wie man sehen kann ist noch mehr als genug Arbeitsspeicher vorhanden.
Er macht jedesmal bei der Funktion "write to spreadsheet file" Probleme. Wenn ich 1 Millionen Zeilen schreiben will macht er es ohne
Probleme - er schreibt auch Problemlos 8 Spalten mit jeweils 1 Millionen Zeilen.
Aber wen ich nur eine Spalte mit 2 Millionen Zeilen schreiben will kommt diese Fehlermeldung.
Also an der Datenmenge kann es nicht liegen oder? Weil 8 Spalten a 1 Millionen Zeilen ist deutlich mehr als eine Spalte mit 2 Millionen Zeilen.


Ich hatte mal irgendwo gelesen, dass Labview selbst seinen Speicher begrenzt und man den irgendwo einfach erhöhen kann, stimmt das?
Oder wie könnte ich das Problem sonst lösen?

Wenn noch Fragen sind was die Vi sonst macht, sagt bescheid.

Im Prinzip habe ich einfach nur ein 2d Array mit max. 8 Spalten und halt jeweils ein paar Millionen Zeilen (max. 4 Millionen Zeilen pro Spalte) und muss das in eine Tabellendatei (csv) Speichern. Dabei bricht das Programm mit den geposteten Fehlermeldungen ab.
Hallo,

wieso es im einen Fall geht und im anderen nicht, kann ich dir nicht sagen. Das Problem bei großen Datenmengen mit "Write to Spreadsheet" ist, dass dieses VI einen einzigen, riesigen String erzeugt und diesen auf einmal in eine Datei schreiben möchte, soweit ich weiß.

Du könntest versuchen, das Schreiben selbst zu übernehmen, indem du die Arrays manuell durchläufst und zeilenweise in eine Datei schreibst.
Dann entstehen nur kurze Strings und du kannst theoretisch so lange schreiben, bis das Betriebssystem es nicht mehr zulässt.

Einen Versuch ist es wert.
Hi,

könnte es am Append to file liegen? Wenn das Ding in einer Schleife liegt, schreibst du mehrmals - und LV öffnet immer die Datei, hängt an und schreibt wieder. Sprich es braucht Speicher von der anzuhängenden Menge plus der Menge von Daten, die schon im VI sind.

Was du versuchen könntest wäre, nicht das Top-Level-VI zu verwenden, sondern außerhalb der Schleife die Datei zu öffnen und dann innerhalb der Schleife nur auf die Referenz zu schreiben. Das ist glaube ich die einzige Möglichkeit, auch bei Binär- und TDMS-Dateien (und zusätzlich auch schneller...)

Grüße,

ch
' schrieb:Hallo,

wieso es im einen Fall geht und im anderen nicht, kann ich dir nicht sagen. Das Problem bei großen Datenmengen mit "Write to Spreadsheet" ist, dass dieses VI einen einzigen, riesigen String erzeugt und diesen auf einmal in eine Datei schreiben möchte, soweit ich weiß.

Du könntest versuchen, das Schreiben selbst zu übernehmen, indem du die Arrays manuell durchläufst und zeilenweise in eine Datei schreibst.
Dann entstehen nur kurze Strings und du kannst theoretisch so lange schreiben, bis das Betriebssystem es nicht mehr zulässt.

Einen Versuch ist es wert.


Es scheint eindeutig an der Zeilenanzahl zu liegen. Ich hatte auch mal testweise alle anderen Prozesse, die gleichzeitig noch geschehen deaktiviert - die machen keinen Unterschied. Es ist wirklich einzig und allein die Zeilenanzahl. Was du sagst leuchtet mir deshalb ein. Wenn da wirklich ein einziger String erstellt wird kann es natürlich sein, dass dieser einfach zu groß ist um noch geschrieben zu werden. Da ich ja weiß, dass 1 Millionen Zeilen kein Problem sind werde ich das glaub ich einfach mal in so 1 Millionen Zeilen Pakete zerlegen und schauen ob es dann klappt.
Bin schon auf der Arbeit, ob es geklappt hat sehen wir in so ca. einer StundeWink


' schrieb:Hi,

könnte es am Append to file liegen? Wenn das Ding in einer Schleife liegt, schreibst du mehrmals - und LV öffnet immer die Datei, hängt an und schreibt wieder. Sprich es braucht Speicher von der anzuhängenden Menge plus der Menge von Daten, die schon im VI sind.

Was du versuchen könntest wäre, nicht das Top-Level-VI zu verwenden, sondern außerhalb der Schleife die Datei zu öffnen und dann innerhalb der Schleife nur auf die Referenz zu schreiben. Das ist glaube ich die einzige Möglichkeit, auch bei Binär- und TDMS-Dateien (und zusätzlich auch schneller...)

Grüße,

ch


Das schreiben in die Datei ist nicht in einer Schleife. Ok strenggenommen schon, da es innerhalb eines Zustandsautomaten (innerhalb eine slave Schleife) ist, aber es wird definitiv nur einmal ausgeführt.
Es wird einmal eine Datei erzeugt, da wird dann der Header geschrieben (eine Zeile, 9 Spalten) also eine 1kb .csv Datei. Ich schließe die Datei danach nicht wieder sondern lasse sie offen das ist richtig. Das werde ich mal ändern und schauen ob das vielleicht die Lösung ist. Ich kann es mir aber nicht vorstellen, da mein Schreibvorgang wie gesagt nicht in einer Schleife ist sondern er die Datei nur ein einziges mal wieder öffnet nachdem der Header geschrieben ist und dann eben diese x Millionen Zeilen reinschreibt (auf einmal und nur einmal).
Wäre es möglich, dass du uns ein kleines Demoprojekt bastelst, mit dem wir das reproduzieren können?
Also ein ähnlicher Programmaufbau mit einer Schleife, die die Werte generiert (Zufallswerte) und dann das Konstrukt, mit dem du die Datei erstellst.

Wenn es geht, lade das bitte für LV 8.5 hoch oder mach einen Screenshot vom gesamten Blockdiagramm.
Dann ist es leichter für uns, das nachzuvollziehen. Du hast oben so viel eingeschwärzt.
' schrieb:Wäre es möglich, dass du uns ein kleines Demoprojekt bastelst, mit dem wir das reproduzieren können?
Also ein ähnlicher Programmaufbau mit einer Schleife, die die Werte generiert (Zufallswerte) und dann das Konstrukt, mit dem du die Datei erstellst.

Wenn es geht, lade das bitte für LV 8.5 hoch oder mach einen Screenshot vom gesamten Blockdiagramm.
Dann ist es leichter für uns, das nachzuvollziehen. Du hast oben so viel eingeschwärzt.


Puh nur sehr schwer. Das ganze ist eine Messgeräteansteuerungsoftware. Ich befürchte, wenn ich Dummydaten mit 1 Millionen Zeilen Arrays erzeuge, ich den Arbeitsspeicher schon so auslaste, dass man das nicht wirklich reproduzieren kann.

Bevor ich anfange zu Speichern ist mein Arbeitsspeicher nämlich fast gar nicht ausgelastet, die Auslastung geht erst beim abspeichern hoch.



Ich habe übrigends beide Vorschläge ausprobiert und hatte keinen Erfolg. Ich schließe die datei jetzt nachdem ich den Header geschrieben habe, es hat aber keinen Einfluss.

Dann habe ich eine Abfrage eingebaut ob die Zeilenanzahl 1 Millionen überschreitet. Wenn ja teilt er die Zeilenanzahl durch 1 Millionen, das Ergebnis ist das n meine Forschleife. In der Schleife nehme ich ein Teilarray mit der länge=Zeilenanzahl und dem Index schleifeniteration x 1 Millionen. Das Teilarray speichert er dann innerhalb der forschleife wie gehabt ab.
Das heißt bei der ersten Iteration speichert er 0 bis 1 Millionen-1 Zeilen ab. In der zweiten Iteration 1 Millionen bis 2 millionen-1 ab etc.

Das funktioniert auch (habe es erstmal mit kleineren Zeilenzahlen ausprobiert), aber er gibt trotzdem die selbe Fehlermeldung aus.
Ich verstehe das nicht Huh
Oooook.

Ich habe grade noch mal die Zeichnung des Graphs deaktiviert nachdem ich die Änderungen an der Speicherung durchgeführt hatte und siehe da es funktioniert.
Jetzt habe ich die Speicherung und die Erstellung des Graphs einfach in eine Sequenz gepackt, so speichert er erst das File (das ist wichtiger) und erstellt danach den Graph. Bei 2 Millionen Zeilen in einer Spalte hat es gut geklappt.

Weil ich mich grad glücklich fühle lasse ich grade den absoluten Stresstest laufen für mein Programm: 8 Spalten a 4 Millionen Zeilen. Das dauert allerdings eine Weile (das Messgerät überträgt in Modemgeschwindigkeit Rolleyes ).

Wenn das auch klappen sollte bin ich soweit glücklich.


Um auch dem Thread eine Problemlösung zu präsentieren: Der erste Teil der Lösung war definitiv, dass die "write to spreadsheet file" Funktion versucht hat einen einzigen riesigen String zu erstellen und konnte den dann nicht mehr abspeichern. Nachdem das (wie oben beschrieben) gelöst wurde denke ich, dass das Programm versucht hat wärend es noch abgespeichert hat, den Graph zu zeichnen.


Vielen Dank für die Hilfe.
Referenz-URLs