Write datas to a file, which path to specify?

[Mahmoud63PPC]

Hello to all,

I am developing a LabView application using the producer-consumer pattern. The application is going to run on a compactRio cRIO-9045.

The producer acquires several data from the cRio, performs some operation, and send data to a FIFO. 

The consumer writes data on a text file (using the FIFO). I would like to save that file either on my computer or on the cRIO.

I have a problem using "Open/Create/Replace File" functions, because, my application is running on a cRIO-9045, but I don't know what path to give to the function  "Open/Create/Replace File".

When I try to give a path located on my computer, it obviously doesn't work and return an error (operation canceled by user). How can I tell the function to save the text file on the target, or somewhere else?

Thank you.

[Bob_Schor]

If you search the Web for "Save file cRIO", you will get multiple "hits", most to this Forum.

The cRIO is part of LabVIEW Real-Time, where LabVIEW runs on both the Host (your PC) and on a Remote processor (your cRIO), with TCP/IP being the communication path between them.  The RT Target uses a "Real-Time OS" so that it can respond  to time-critical "interrupts" without minimal interference from the OS, and relegates tasks such as Displays and Files to Windows, running on the Host.  You can find multiple responses on the Web, and can probably find answers at the level you are ready to read.

Bob Schor

[kartiknattar]

You can save the files in "/c" location as shown in figure and then copy it to host using FTP.

[Bob_Schor]

While you can save files on an RT target (on the C drive), it offers the worst of both worlds:

• The RT Target is where you run your time-critical code, as it runs a time-optimized OS "where the Words don't get in the way" (as the Beatles would say).  Using those CPU cycles that should be devoted to acquiring the data (often using a Producer/Consumer pattern to optimize use of CPU cycles) to handling File I/O seems counter-productive -- off-load them to the Host.
• If you have a fair amount of data, it's "another step" (and takes a block of time, instead of happening simultaneously with running your program) to transfer it from the Target to the Host via FTP.
• Should your Target crash, your data may be left on the Target in an "unstable" form, and thus be difficult to recover.

My first significant LabVIEW RT project involved saving data on the Target and ftp-ing it to the Host.  We encountered all three of the issues mentioned above.  As part of a major refactoring of this code, the Consumer part of the RT routine packed the data up in "chunks" of 50 samples from 16 analog channels at 1 kHz and sent them via a Network Stream to the Host (at 20 "packets" / second, which was just ideal for creating a running chart of the incoming data the 16 channels).  We also had sporadic digital signals (button pushes, LED flashes) that were also sent via another Network Stream to the Host to be streamed to an Event file.  This system worked twice as fast (we didn't need to push it any harder, so I don't know the upper limit) and proved to be much more stable, and much more responsive, than the original code.

Bob Schor