To download NI software, including the products shown below, visit ni.com/downloads.
Overview
When transferring large file from one disk to another, it is often advantageous to show a progress bar to the operator. With Widows 7, you cannot monitor the transfer process (using "Copy" or "Move" functions) because the final file size is allocated at the beginning of the process. (In XP you could periodically check the size of the destination file to monitor the transfer process)
This example program uses native LabVIEW function to efficiently transfer large files while showing the progress of the transfer.
Description
The program performs the file transfer by opening a file at the destination location, then reading a block of binary data from the source and writing the block of the data to the destination. The data transfer block size is based on the users target block size trimmed to be an integer number of the destination disk's sector. (This is similar to saving data in a binary streaming mode.)
The number of Read/Write transfers is calculated from the File size divided by the Data Block size and rounded down to the nearest integer (modulo function). The progress bar is set up between zero and the integer value and tied to the index of the transfer "While" loop. The last part of the source file that is less than the block data size is written to the destination on the final loop of the process. To "Move" a file, the source file is deleted if there is no errors at the end transfer process.
If the destination disk has "Write Caching" enabled (as most do) there can be significant lag between the apparent end of the transfer and when the program terminates as the data is emptied from the memory. We normally disable the "Write Caching" (Properties/Hardware/Policies) since it adds an unexpected lag to the transfer process. (When "Write Caching" is enabled, the transfer process starts off very fast (at the rated the date can be read) and then eventually slows down once the system memory is filled up.)
There is an optimum data block size to for the fastest transfer: To small (1 MB) and there are too many Read/Write function swaps, to large (~10 MB) and data to go into memory and it all bogs down. From hard-disk-to-hard-disk tests on our system the around 4 MB (the default value in the program) appears to be the block size sweet spot. However, experiment with your system and transfer links (internal ESATA or Ethernet link). We have had very good transfer rated with either ESATA or Thunderbolt connected external drives.
Requirements
Steps to Implement or Execute Code
Additional Information or References
VI Snippet of Block Diagram
**This document has been updated to meet the current required format for the NI Code Exchange. **
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
This is a nice function. However, I found a bug: the last "Close File" VI should use the refnum from the last "Get File Size" VI