Überlauf des Speichers

Hallo,

ich messe anhand DAQ, viele sensoren und mit einer Abstastrate von 1000 Hz. ich hab etwa 10 SubVIs. Da werden die Signale je nach Kategorie eingeordnet gezeigt.

mein problem ist, dass dieses fehler ab und zu tritt. kann ich es irgedwie vermeiden ? ich will aber keine kleiner abtastrate haben. was sind euere vorschläge ? das tritt am meisten auf wenn ich SubVIs mit bildern usw.. aufrufe..(halt kommt schneller zum fehler.)


Grüße,
Prince

' schrieb:das tritt am meisten auf wenn ich SubVIs mit bildern usw.. aufrufe..(halt kommt schneller zum fehler.)

Das klingt sehr danach, dass der Puffer (also der DaqMX) zu langsam ausgelesen wird.

Ich rate, den Puffer der Task mal auf das fünffache zu erhöhen.

Schlecht wäre z.B., wenn das Auslesen der Task in den Datenfluß eingebunden ist, in dem sich auch SubVIs befinden, die undefiniert lange (wie z.B. solche mit Bildern und/oder Graphik) brauchen. Besser wäre, die Tasks in einem selbständigen SubVI auszulesen und die Daten per Queue an ein HauptVI zu senden, das die undefiniert langen SubVIs enthält.

Hallo,
ha habe exakt das Selbe Problem.
Siehe hier: Vergrößern des Puffers

Leider bringt auch nur eine Vergrößerung des Puffers nur bedingt was. dann hat irgendwann deine Festplatte/Ram viel mehr zu tun.
Wirklich weiter bin ich aber leider auch noch nicht.
Im anderen Beitrag wird geraten, dass man von dem kontinuierlichen Modus in den "endliche Anzahl"-Modus wechselt.
Aber leider gibts bei mir da auch nen fehler.
Vllt hilft aber ein timing: erst daten genügend daten auslesen bevor neue eingelesen werden?!!?!

Gruß

Dirk

wenn ich mich recht entsinne, hattest du in deinem Beispiel die Datenerfassung und dSpeicherung als auch das Öffnen der Messdatei in einer Loop. Da kann es dann durchaus zu Fehlern kommen. Du solltest für alle drei Arbeiten eigene Loops verwenden. Bei dir ist am Eingang des ExpressVIs zum Laden von Datein keine Pfad angegeben. Ich habe das VI noch nicht verwendet, aber bestimmt poppt dann ein Dialog auf, und solange der geöffnet ist, läuft die Schleife nicht weiter. Ich rate dir, die Beispiele im Examplefinder anzuschauen. Ein paar Stunden Zeit nehmen um durch die Ordner klicken.

' schrieb:dann hat irgendwann deine Festplatte/Ram viel mehr zu tun.

Das ist ein Trugschluss. Der Puffer ist nur als Puffer da. Um nämlich genau die Zeitungenauigkeiten auszugleichen, die in der Applikation auf höchster Ebene entstehen.

Ich mach das wie folgt: Es gibt ein SubVI, das selbständig mit einer Statemachine läuft. Gesteuert wird das SubVI mittels einer Queue. Dieses SubVI liest aus einer (Analog-)Task immer alle Daten aus, die sich im Puffer der Task befinden. Diese neuen Daten werden in einem SubVI-internen Array abgelegt (=Puffer). Das Array hat eine an sich beliebige Größe (Beispiel: Abtastrate 1kHz, Signaldauer 3min. Eine Messung dauert also maximal 3 Minuten). Dieses Array wird per Melder an die Hauptschleife der Applikation gesendet (die dann die Daten an einem Graph anzeigt oder als TDMS speichert). Das SubVI arbeitet mit einem Raster von 50ms, d.h. alle 50ms wird die Task ausgelesen (und deren Puffer praktisch geleert). Das SubVI macht also nichts anderes, als den Puffer der Task auf einer höheren Ebene zu vergrößern.

Irgendwelche Probleme bezüglich Speicherauslastung oder CPU-Auslastung hab ich bisher nicht feststellen können.

Zitat:Das SubVI arbeitet mit einem Raster von 50ms, d.h. alle 50ms wird die Task ausgelesen (und deren Puffer praktisch geleert). Das SubVI macht also nichts anderes, als den Puffer der Task auf einer höheren Ebene zu vergrößern.

Kannst du mal ein Beispiel bitte hochladen. So genau kann ich mir das nicht wirklich vorstellen

Anzeige

' schrieb:Kannst du mal ein Beispiel bitte hochladen. So genau kann ich mir das nicht wirklich vorstellen

Kuckst du mal hier.

So , erstmal vielen Dank für zahlreiche Antworten.

@IchSelbst, werde es ausprobieren, für datenspeichern und daten skalierung eigene Loops machen, und die daten von DatenLesenTaskt Loop per Queues da übertragen.(werde es morgen berichten !!!)

@Julius, "Aus der Data lesen Express VI" benutze ich nicht mehr. dafür habe ich ein eigenes Loop eingebaut für Daten lesen und hole sie per Datensheet als Tabelle rein. Was eigenlicht mit einem Buttom erst aktiviert werden soll. davor ist auf False gelegt, was kein einfluss hat (weil es momenta deaktiviert ist...) Danke für den Tipp!!

ich erkläre hier mein programm ein bissschen genauer.
Wie im screenshot lese ich im ersten schritt 6 Analog kanäle mit DAQ. in einer loop. mit 1000 hz rate und 1 sampel per kanal (screenshot 1). ( Hab hier kein Time/Verzörungsfunktion für Schleife gebaut!! oder soll ich ?)

im 2.schritt in der loop, skaliere ich jedes signal und bearbeite, dann speichere ich in datei. (Screenshot 2 und 3). wie man sehen kann mache ich alles in einem schrit ( die daten erfassung) brauche eigenlich in diesem fall keine Queues mehr oder ?(wenn ich richtig verstehe)
ich kriege den fehler, vor dem start der messspeicherung auch. (taskt manager im windows zeigt fast 90% mit start des programms mit 1000hz)

im nächste schritt mit globalen variablen zeige ich nur die werte im anderen SubVIs die parallel zu diesem Messdatenerfassung VI laufen. ( es ist nur eine reine monitoring.) soll ich mit Queues hier arbeiten ? kanns daran liegen an Global variable?

insgesamt habe ich 9 parallele schleifen zum Haupt Messdaten erfassung schleife. (die eigenlich die erfasste messwerte zeigen und nix mehr.) Für meine parallele Schleifen habe ich eine warte zeit . damit nicht gleich alle laufen. (die sind eigenlich mit einem boolische bottum verbunden, damit sie als pop up fenster sich öffnen.) screenshot 4

ist da am mein programmarchitektur was falsch? oder kannst irgendwas mit programmierungstil zutun haben?
Mein rechner hat 4Gig. Ram und läuft mit Win. Vista 64Bit.(ist eigenlicht kein schlechter..)

ich werde mal hier weiterlesen. wäre sehr dankbar für jeden Tipp.

Grüße

' schrieb:Wie im screenshot lese ich im ersten schritt 6 Analog kanäle mit DAQ. in einer loop. mit 1000 hz rate und 1 sampel per kanal (screenshot 1). ( Hab hier kein Time/Verzörungsfunktion für Schleife gebaut!! oder soll ich ?)

Ein Sample? Und dann diese vielen Berechnungen? Und das alles innerhalb einer Millisekunde? Eine Wartezeit wird hier alles noch verschlimmern! Hier sehe ich nur eine Lösung: Das Konzept ändern! (Hiermit erübrigen sich eigentlich alle weiteren Antworten.)

Zitat:(taskt manager im windows zeigt fast 90% mit start des programms mit 1000hz)

Ja, klar! Du tust ja ständig arbeiten. Und wenn hier mal mehr als 30% steht ist das eigentlich schon kritisch. Bei 90% steht der Rechner praktisch.

Zitat:im nächste schritt mit globalen variablen zeige ich nur die werte im anderen SubVIs die parallel zu diesem Messdatenerfassung VI laufen. ( es ist nur eine reine monitoring.) soll ich mit Queues hier arbeiten ?

Queues sind besser als globale Variablen.

Zitat:kanns daran liegen an Global variable?

Es liegt mehr am Gesamtkonzept als an den globalen Variablen.

Zitat:insgesamt habe ich 9 parallele schleifen zum Haupt Messdaten erfassung schleife. (die eigenlich die erfasste messwerte zeigen und nix mehr.) Für meine parallele Schleifen habe ich eine warte zeit . damit nicht gleich alle laufen. (die sind eigenlich mit einem boolische bottum verbunden, damit sie als pop up fenster sich öffnen.) screenshot 4

Diese parallelen Schleifen sind an sich nicht kritisch. Eigendlich macht man das so. Nur sollte auch im False-Case eine Wartezeit drinnen sein. Ist dem so?

Zitat:Mein rechner hat 4Gig. Ram und läuft mit Win. Vista 64Bit.(ist eigenlicht kein schlechter..)

Und der läuft auf 90%? Die Leistung des Rechners geht in die Vorlaufzeit ein bis der Fehler auftritt. Je besser der Rechner, desto später der Fehler.

Ich bin immer noch der festen Meinung, dass du dein Konzept ändern musst. Die Schleife, in der die Task ausgelesen wird, muss nachweisbar garantiert (also zu 100%) schneller arbeiten können, als der Puffer voll laufen kann.

Gegen den Programmierstil kann ich nichts sagen.

Hallo IchSelbst,

danke für ausführiche Antwort

' schrieb:Ein Sample? Und dann diese vielen Berechnungen? Und das alles innerhalb einer Millisekunde? Eine Wartezeit wird hier alles noch verschlimmern! Hier sehe ich nur eine Lösung: Das Konzept ändern! (Hiermit erübrigen sich eigentlich alle weiteren Antworten.)

Diese parallelen Schleifen sind an sich nicht kritisch. Eigendlich macht man das so. Nur sollte auch im False-Case eine Wartezeit drinnen sein. Ist dem so?

Ich bin immer noch der festen Meinung, dass du dein Konzept ändern musst. Die Schleife, in der die Task ausgelesen wird, muss nachweisbar garantiert (also zu 100%) schneller arbeiten können, als der Puffer voll laufen kann.

was meinst du genau mit konzept ändern?die schleife mit task lesen meinst du bestimmt. kannst du bitte näher erklären, was ich da ändern soll?

ja hab da eine wartezeit, (für parallele SubVIs)

wie soll ich das realisieren? kannst du näher eklären bitte.


PS: Ich will eigentlich beim LESEN mit 1000 HZ. genau 1000 werte in der Sekunde speichern. sind dann meine einstellungen für Sampels Pro kanal beim DAQ Lesen und Timing und Einzelwerte HW getaktet richtig? nicht dass ich es total falsch verstanden habe!! und dann mittels software abtastung nochmal mit 100 / 10 / 1 Hz abtasten! für langsame sensoren.

Grüße