Daten aus datei lesen und getriggert auf dig. Port schreiben

Hallo,
Ich habe ein VI erstellt, mit dem man Daten (extern getaktet) aus einer Datei liest, die nach auftreten eines externen triggers auf einen Dig. Port ausgegeben werden.... Das VI funktioniert ungefähr bis zu Datei-groesssen von 50 MB. Bei groesseren Dateinen kommt eine Fehlermeldung, dass nicht genuegend Speicherplatz vorhanden ist.
Ein fast identisches VI (ohne Triggerbedingung) funktioniert auch mit beliebig grossen Dateien.

Ich vermute, dass das Problem folgendes ist: Die Daten werden beim Starten des VIs in einen Puffer geschrieben, der für den Task vom OS allokiert wird. Da LabVIEW nicht weiss, wann die Triggerbedingung eintritt, versucht es die komplette datei zu Puffern. Hier wird sich Windows wehren, wenn LabVIEW GB-weise speicher haben möchte....

Die Lösung für das Problem koennte sein, das Lesen der Datei erst zu starten, wenn der Trigger aufgetreten ist. Ich weiss leider nicht wie ich das realisieren kann. Evt. durch einenen eigenen Task fuer das lesen ? (und wie geht das dann?) .... oder durch eine logische verknuepfung von Triggerbedingung und ext. Clk der auf das "Datei-lesen-VI" geht... - leider weiss ich auch nicht wie ich das umsetzten kann..

fuer hilfe wäre ich dankbar....
gruesse

Anzeige

Das von dir vermutete Problem kann es eigentlich nicht sein, weil vor der Ausführung von DAQmx Write IMMER erst die komplette Datei eingelesen wird, egal, ob mit Triggersteuerung oder ohne. Das liegt daran, dass erst alle Eingänge eines VIs anliegen müssen, bevor es ausgeführt werden kann.

Eine wesentlich speicherschonendere Methode ist es, das DAQmx Write und das Read From Binary File in einer Schleife anzuordnen und immer nur ein Byte (also genau soviel, wie du an deinen digitalen Output senden willst) einzulesen.
Die Schleifenabbruchbedingung ermittelst du dann aus der Dateigröße und der aktuellen Dateiposition. Dadurch bekommst du raus, ob deine Datei komplett eingelesen ist.

Allerdings habe ich keine Ahnung, wie schnell die Dateioperationen sind. Ob du durch das ständige Einlesen dem DO wirklich so schnell Daten liefern kannst, wie er will? Alternativ eben nicht ein Byte, sondern z.B. 50 in einem Schritt einlesen...

Erst mal Dank an monoceros84...


NI hat mir mitlerweilen folgende Antwort zukommen lassen:

The attached program opens a file and then writes the data into the DAQmx buffer using the DAQmx write. The reason they are seeing an error is not specific to the PCIe-6537, but rather a general programming problem. They are running out of memory.

In order to store data in memory, you need contiguous memory. By reading a 1 GB file, you are using most of this space. When you try to write this data into the DAQmx buffer, there is no longer 1 GB of free contiguous memory and you are getting an error. This error is not very descriptive.

To fix the problem, the customer has several options:

1) Only read smaller files.
2) Read the file into memory in chunks and write these chunks into the DAQmx buffer.
3) If the files are not much bigger than the size that works, you can use LabVIEW 8.5 and use the /3GB switch which will increase the chances of getting contiguous memory.

Ok,
1) ist trivial aber irgendwie ein "sinnloser" Hinweis. Du hättest ja wohl kaum gefragt, wenn das akzeptabel wäre.
2) ist genau das, was ich vorgeschlagen habe.
3) habe ich nciht verstanden;)Was ist /3GB switch?

zu Punkt 3 :: Switch.....


Enhancing Virtual Memory Usage

(Windows) LabVIEW 8.5 is large address aware. On a 64-bit operating system, LabVIEW can access up to 4 GB of virtual memory by default. On a 32-bit OS, LabVIEW can access up to 2 GB of virtual memory by default. You can enable LabVIEW to access up to 4 GB of virtual memory on a 32-bit OS by modifying the Windows boot configuration settings. Enabling LabVIEW to access more virtual memory decreases the likelihood of experiencing general LabVIEW errors related to memory allocation when you work with large sets of data.

* (Windows Vista x64 Edition) LabVIEW can access up to 4 GB of virtual memory by default.
* (Windows Vista) To enable LabVIEW to access up to 3 or 4 GB of virtual memory, open the command line window as an administrator and use bcdedit commands to add an entry in the Boot Configuration Data (BCD) store. To open the command line window as an administrator, navigate to the window in the Windows Start menu, right-click the program name, and select Run as administrator from the shortcut menu.
* (Windows XP/2000) To enable LabVIEW to access up to 3 GB of virtual memory, you can add the /3GB tag to the Windows boot.ini file on the line that specifies the Windows version to boot. If you have more than 4 GB of physical RAM, you can use the /PAE tag in place of the /3GB tag to enable LabVIEW to access up to 4 GB of virtual memory.

Leider habe ich immer noch keine Ahnung, wie ich in LabVIEW ein cluster-häppchen-buffer-array programmieren soll. Vor allem wo ich den Read- bzw Write- enable anschliessen koennte. Kann ich den Trigger mit der Taktflanke irgenwie boolsch verunden und damit einen Counter inkrementieren? Gibts fuer etwaige Anforderungen vielleicht schon Beispiele?

thanx, marco

Erzeuge um dein DAQmx Write.vi eine For-Schleife.
Ersetze die Instanz dieses VIs durch 1Kanal 1Abstastung.
Schalte den Indexing Tunnel für die Datenleitung am Rand der For-Schleife an (durch Rechtsklick).

Wenn das mit kleinen Dateien funktioniert, kannst du zum nächsten Schritt übergehen:

Verlagere das Read From Binary File.vi ebenfalls in die For-Schleife und lese immer nur 1 Byte. Als Anzahl der Interationen kannst du deine Dateigröße in Byte angeben.

Hoffe, du verstehst, wie ich das meine. Wenn nicht, dann poste mal dein VI, ich bau's dir fix.

PS: Ich verstehe nicht ganz, was dein Task Start und Wait Until Done nach dem Schreiben sollen... Hast du einen Grund für diese? Normalerweise setzt man doch Start VOR dem Schreiben/ Lesen...

Hmm... also wenn ich ehrlich bin, habe ich nicht wirklich Ahnung von LabVIEW. Meine Steckenpferde sind eher C und VHDL. Aber nichts desto trotz, denke ich (soweit ich das beurteilen kann), dass das LabVIEW ein ziemlich mächtiges Werkzeug ist - vorraussgesetzt man hat Ahnung was man tut

Nach längerem probieren habe ich es geschafft, eine For-schleife erstellen. Mit dem Indexing Tunnel, bzw instanzieren habe ich meine Probleme...
Zusätzlich weiss ich auch nicht, wie ich eine Logische Bedingung für "Read From Binary File.vi" anschliessen kann. Da ja nur gelesen werden soll, wenn schon einmal getriggert wurde UND ein ext-clock anliegt.

Mein VI habe ich angehängt.... ich wäre reichlich dankbar, wenn dir das Programmieren hierfür keine Mühe bereitet...
gruesse, Marco

(VI LV 8.2)

Hi

Das geänderte VI ist im Anhang.

- Es ist ungetestet mangels passenden Dateien und Hardware.
- Ich habe die Führung des Error-Clusters ein bisschen geändert, so hat es wenig Sinn gemacht.
- Du solltest den Expression Node evtl. noch anpassen. Ich habe nicht die geringste Ahnung, was der macht, aber evtl. stimmt es jetzt nicht mehr, weil statt vielen vielen Bytes immer nur ein Byte bearbeitet...
- Ich bin nach wie vor der Meinung, Start Task und Wait Until Done haben da hinten nichts zu suchen, auch wenn sie nichts kaputt machen. Sie sind eben sinnlos;)Falls der Rest läuft, versuche es doch mal ohne die beiden, sollte noch genauso gehen.
- Der Zeiger in der Datei sollte je Schleifendurchlauf ein Byte weiterrücken. Habe das aber noch nie versucht, also bin ich mir nicht sicher. Falls immer das erste Byte ausgelesen wird, musst du eben noch das Set File Position.vi einbauen.
- Die Quotient & Remainder Funktion ist ziemlich sinnlos, wenn eine 1 rangehängt wird...

Ich bitte um Feedback


  Write_DigPort_read_file_triggered.vi (Größe: 42,99 KB / Downloads: 252)
(LV 8.2)