LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cRIO Close USB Flash Drive

I am having issues with writing files to a USB flash drive on Linux based cRIOs.  I write the files fine, close everything, but Windows always needs to repair the USB drive.  Most of the time, it finds nothing wrong.  But I have had it find partial files, and most recently corrupt a data file.

 

I have even performed a test where I don't write anything to the drive, and Windows still reports an issue.

 

Unmounting the partition does not seem to be enough.  Is there a proper way to gracefully shutdown the USB drive?

 

Thanks,

Matthew

 

0 Kudos
Message 1 of 22
(5,282 Views)

Hello Matthew_Kelton,

 

In order to get a better idea of the troubleshooting steps you have tried and the nature of the issue, I have a few questions about the issue.

 

Considering that you mentioned Windows reporting an issue and “unmounting the partition”, that leads me to believe that you have a “dual-boot” cRIO with two operating systems on your cRIO. What cRIO are you using? What Operating systems are on it?

 

When you say that “[you] don’t write anything to the drive”, are you simply connecting the USB drive to the cRIO, or are you writing a blank file to it?

 

Have you tried using a different USB device?

 

What sort of file system is on your USB drive? Is it “FAT32”, “NTFS”, etc.?

 

What sort of files are you writing to the USB drive?

 

Thanks,

Gabby
National Instruments Applications Engineer
0 Kudos
Message 2 of 22
(5,229 Views)

Gabby,

 

No, this is a NI Linux chassis.  I have seen it now on the 9068 and the 9063.  If a USB flash drive is placed into the USB port of the chassis, then removed and placed into the USB port of a Windows PC, Windows will report that the USB drive was not properly shutdown and wants to scan and repair the drive.

 

In the case of the project using the 9068, I directly create files on the USB flash drive during testing.  Files are flushed and closed.  As fas as I know, the customer has never had a data corruption issue and Windows has never found any errors when it scans the drive, but every single time the flash drive is inserrted after being used in the chassis, Windows reports that it was not properly shut down.  The same flash dive can be used between Windows computers without issue.

 

For the project using the 9063, I never directly write files to the flash drive.  I create the data files on the chassis, and these files are copied to the USB flash drive using LabVIEW's canned copy VIs.  Again, every time the flash drive is inserted into the Windows PC after the chassis, Windows reports the flash drive has not been properly shut down.  In several cases, I have seen corruption problems and Windows has reported errors and lost files during its scan.  In one case, I had gotten distracted, and the flash drive was in the chassis for several minutes after the copy was complete, so I know it is not me pulling the drive before the copy has finished.  Again, this flash drive works amongst Windows PC without issues.

 

In both cases, I can insert the flash drive into the chassis and write nothing to it, remove it from the chassis, and Windows will report the drive was not properly shut down.  The issue is NI Linux mounts the drive and there appears to be no way to properly shut it down.  I have tried to unmount it through SSH as a test, and it still doesn't fix the issue because I believe the USB flash drive is still not properly powered down.  (As an aside, I tried to follow the steps outlined here to do it through LabVIEW, and they did not work).

 

The flash drives are FAT32, since NI Linux doesn't support NTFS.  Both systems have had multiple flash drives used, and as mentioned above, the drives can be used between Windows PCs without issue.  For the 9068, the file being created is a tab delimited text file.  On the 9063, the files copied are tdms files, text files, and CSV text files.  As stated, no files have to be copied or created for the issue to occur.

 

Again, I believe the ultimate issue is that there is no option to shutdown the flash drive (or I haven't found it documented yet), so that NI Linux at an OS level closes everything as it should.  Simply unmounting the drive is not sufficient.  Withe the 9068 project, since we never saw data corruption, I told my client that it is an annoyance they probably have to accept.  With the 9063, though, I am now seeing errors on the flash drive (not every time), so not shutting the flash drive down is causing issues instead of annoyances.

 

Thanks,

Matthew

0 Kudos
Message 3 of 22
(5,214 Views)

Matthew,

 

Do you have access to a PC chassis with some flavor of Linux available to see if the same thing happens under non-real-time Linux?

 

Lynn

0 Kudos
Message 4 of 22
(5,206 Views)
Lynn,

No I do not. The closest would be a Raspberry Pi 2. I came across a website that talked about Ubuntu's ability to safely remove hardware (thru it's Desktop UI), but it didn't explain what it was doing.

Thanks,
Matthew
0 Kudos
Message 5 of 22
(5,193 Views)

Hello Matthew,

 

I have investigated this issue thoroughly and have not found any possible causes for the behavior you are seeing. Typically, assuming that all file references are properly close, the most one would have to do to safely remove a USB device is to unmount the device itself. Considering that unmounting the devcie through Linux commands still does not remedy the issue, I am led to believe that there is either a reference that is not being closed somewhere, or you may need to reformat your cRIO, because it is possible that the image on the controller has somehow become corrupt.

 

Do you know if there are any startup or RT executables currently deployed to the cRIO that may be opening/closing file references?

 

Typically when a cRIO controller is not behaving as expected on the OS level, I would recommend reformatting, because it will put the cRIO into its uncorrupted, factory settings. I will continue looking into this issue further, but at the moment, there do not appear to be any other workarounds.

 

Thanks,

Gabby
National Instruments Applications Engineer
0 Kudos
Message 6 of 22
(5,184 Views)

Hi,

 

I have the very same problem with a two different cRIO-9063 : I made sure the file is closed before removing the USB drive, but still I get the same error message about possibly corrupted files when I plug it to a computer with Windows (I cannot try with Linux either)

I even tried to close the file and then shut the cRIO down, without improvement...

Any news on the subject?

0 Kudos
Message 7 of 22
(4,968 Views)

I had to give up the chassis I was working on, so had to ship with this problem.  However, I have another chassis in house now, and will try to get back to the problem.  It happens on every Linux chassis.  I have seen 4 systems now that do this, and have not yet received one that doesn't.  Reformatting doesn't fix the issue.  It is a basic OS level issue.

 

Just like Windows, Linux has to bring up the drive to mount it.  So, if you pull the drive without Linux powering down the drive, it will always report it was not properly closed (just like Windows).  I had bookmarked some sites to try to get the proper commands necessary to run a script to properly bring down the USB drive.

 

It's something NI should have on its RT pallette.

0 Kudos
Message 8 of 22
(4,959 Views)

Thanks for the answer... I hope NI will make a VI for this!

0 Kudos
Message 9 of 22
(4,943 Views)

Old I know, but a search found this thread.  I have this exact problem with FAT32, and NTFS drives USB drives and SD cards.  We have 10 cDAQ-9136's and 2 cDAQ-9132, all running Linux RT.  Every system have always behaved this way with various software.  This also includes the newest LabVIEW 2018 developer suite updating the controllers to the latest everything.  I have reproduced this on a VI that just calls Open, Write, Close.  Once the VI is done running I'll unplug it from the controller, plug it into Windows, and it always asks to repair.  The only solution I've found is to shut the controller down before unplugging it, then it won't ask to repair.  Pretty minor issue since I don't think it has ever found a problem with the driver after scanning, but it is annoying.

 

Make text file_BD.png

0 Kudos
Message 10 of 22
(3,987 Views)