win32 file VIs

[Garcas]

Hi

I am having problems when using LabVIEW file VIs after opnening a file with Win32 File IO VIs

I am trying to create a binary file for a high speed streaming to disk application with a header containing the configuration info. Therefore first I create the header. Then, in order to get maximum performance, I open the file with Win32 Open File.vi. The problem comes when I want to write the data. If I use the "Set File position" VI to write at the end of the file tit generates the following error :

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

I am sure I must be doing something very basic wrogn, but i cannot see it. Any help?

The code is in the attached file. If I open the file with LV Open/Create/Replace File vi everything goes fine 😮

Thanks. Regards

guillermo

[RamonaL]

Hi,

what you are doing cant work. If you read the help you can see, that the input "From" has nothing to do with setting the cursor on the end of the file.  How to do that you can see on the screenshot I attached.This should solve the problem.

Good luck,
RMathews

[Jacob G]

I am having a similar issue to this however the inputs to Set File Position are all validl (I am attempting to start reading from about 4 GB from the start of a 100 GB file).

The code will run fine when using Open/Create/Replace File however using the Win32 Open File it fails. The Win32 File API explicitly states it supports the use of set/get file position however it is acting like that is an issue.

Observed under LabVIEW 2010 using the files here: http://zone.ni.com/devzone/cda/epd/p/id/5348

Jacob

[smercurio_fc]

That sounds suspiciously like a 32-bit/64-bit issue, especially since you said you're seeing the problem at 4 GBm which is what the 32-bit limit is. Are you running 32-bit or 64-bit LabVIEW? 32-bit or 64-bit OS?

[Jacob G]

This issue is present regardless of the file size or skip/offset amount, I have tried as little offset as 64 bytes with a 2kB file and several other values inbetween. The specifics were just some additional detail regarding the end goal.

To answer the question though, I am running LV2010, 32-bit running on Windows XP 32-bit (PXIe-8133).

My understanding was since 8.something LV has used 64-bit integers to represent file locations resulting in some an exabyte order-of-magnitude file size limit.

Thank you for the input and let me know if I am mistaken in my understanding,

Jacob

[Jacob G]

One additional question regarding the win32 file VIs:

Is there an appreciable difference between using the win32 file VIs and opening the file using the standard labview Open/Create/Replace file with buffering disabled? I benchmarked them using the LV Read Write Block Size Test.vi files and couldnt tell a significant difference in speed for read or write but I assume there is some reason the win32 file VIs exist.

Thanks,

Jacob

[Jacob G]

I believe I have solved this issue:

The number of bytes to skip is required to be an integer multiple of the sector size (512 Bytes). I was not abiding by this which was causing the issues.

If you open a file with the Open/Create/Replace function with buffering disabled and fail to abide by the sector size requirement imposed by disabling buffering you will get error:

Code 1544:

Possible reason(s):
LabVIEW:  LabVIEW attempted a read, write, or seek on a file opened in unbuffered mode, and the data size is not a multiple of the disk sector size.

However if you do this when opening the file using the Win32 Open File you will get:

Code 1:

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

which is technically accurate but much less helpful.

Hopefully this will be helpful to anyone else in my position.

I am still not clear what the differences are in using the read binary vs Win32 read. I used the benchmarking examples included (http://zone.ni.com/devzone/cda/epd/p/id/5348) and they perform nearly identically for any of the block sizes (250-300 MB/s) however in my code the read binary is limited to about 150 MB/s everything else held the same.

Jacob