Detecting external USB drive mounting

[QFang]

We have a system running (currently) on cRIO-9014 controllers. They run headless and un-supervised for long periods of time and log periodic (~1 to 2 hour between writes) data logs to the local SSD on the controller. On occasion, a field person will connect a USB thumbdrive to the controller. Without any further action on the part of the field technician, I wish to dump data files since last visit onto the drive.

Ideally I was hoping to find that connecting a thumbdrive would assert an IRQ or some system event? The only other way I can think of is to periodically attempt to read the root on whatever drive is mapped to the thumbdrive and if it errors, I know there is no thumbdrive attached, but this seems... crude. Is there a better way to do this?

Thanks,

Q 

[Patricia B]

Hello,

Periodically checking for the u:\ drive is a possibility. Another possibility is checking the values of the Size and Directory outputs of the File/Directory Info VI with the Path input set to u:\ . I am in the process of verifying this as an option and can post the results once I have them; just wanted to make you aware.

Regards,

Patricia B.

[QFang]

Thanks. 

I'm hoping that maybe in the future, NI can make this an event we can register for with the event structure, or an interrupt or some non-polling scheme in future versions of the NI-RIO drivers.

I would think the event structure would be perfect for this. I know RT does not support front-panel events, but dynamic and programatic events from other sources are.. so that seems like a natural place to add support for it?

What does people here think? Is that idea worthy of entering as a user feature request?? 

[Patricia B]

Hello,

The Idea Exchange is a great place to make suggestions such as this.I posted the link below for your reference and also attached a code snippet that you may be of some use for you.

NI Idea Exchange

https://decibel.ni.com/content/community/zone/blog/2009/06/01/introducing-ni-idea-exchange

Best,

Patricia B.

[QFang]

Posted on the idea exchange:

http://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/quot-USB-mount-quot-programatic-event-on-RT/...

[QFang · Accepted solution]

Sorry for the thread resurrection but I wanted to document a potential pit-fall to warn everyone else needing to enumerate/detect a USB memory stick on a real-time target:

The solution posted by Patricia B has the down-side of also returning 0 if the memory stick has been recently formated (e.g. it is empty) since the "size" return will return the number of files/folders and not the size of the stick if the input path is a directory. Now, if instead you use the error out status as your check you would be all good.

Where I went wrong was when I thought to myself, well, why not use the "Get Volume Info.vi" instead (also on the advanced file palette. That way I will get the volume size so I could potentially check if I have enough free space before I start my file dump routine. This worked swell, but, there is a documented (internally at NI) problem (bug) with the "Get Volume Info.vi":

IF the Error INPUT terminal to this VI is wired AND the function returns an error (which it will do if no USB stick is present), then it will leak memory. If you use this in a polling fashion (say once per second) on a cRIO, you will run out of contiguous memory in a few days (depending on your poll rate and how much memory allocation and deallocation activity you have going on.) This makes for a pesky hard to find long-term stability problem.. that you could easily miss unless you do really detailed memory monitoring over days of run-time prior to deploying your code.... 

The fix is to NOT wire the error input terminal to this VI and the memory leak goes away.

Hope this helps keep others out of trouble! 🙂 

[QFang]

...also, running on my laptop (so results are only good for comparing relatively to each other),

Get file/folder info returns on average in 0.01ms on error (using drive letters with no drives attached) and 1 ms on success (with empty USB stick attached).

Get Volume Info.vI returns on average 0.01 ms on error and in 0.5 ms on success (using empty USB stick) 

Putting a mix of large and small files in 3 folders off of the root of the USB stick changed the numbers as follows. (The test may bias the Get File/folder function since there are only 3 folders on the root vs.  448 files, 46 folders, 194MB data total on the stick, depending on how the get volume info gets its information.)

Get file/folder info on error: no change (0.01ms) on success: no change (~1ms)

Get volume info on error:  no change (0.01ms) on success: no change (~0.5ms)

For my use scenarios the empty and somewhat loaded stick is very representative, your mileage may vary.