How can I ensure I am accessing the SD card on cRIO linux RT and not a USB drives

[Muri777]

Hi. I have a cRIO RT that I run a program on. In my program I log some data to an SD card. The problem is, the cRIO seems to name the device inserted first as U, then the next inserted device as V etc. I would like to write to an SD card but I am not sure of a way to read the name of the SD card.

Is there a way I can ensure I will always be writing to the SD card? My program currently reads the U drive, but this depends on what is inserted first (USB or SD card) so it isn't consistent.

Thanks!

[natasftw]

Create a file unique to the SD Card.  Try to read it.  If that errors, try the next drive.  Otherwise, you have the SD Card

[Muri777]

Bump.

I dont want to create a unique file because it isnt the best solution. The scenario that comes to mind is, if this program is out on the field and the SD card dies and it needs to be replaced, someone opens a new packet and puts the SD card in (it wont have the unique file on it) the program wont work.

Is there a way I can read the card name or type? Ive searched the linux commands and nothing seems to help me. Surely NI has considered this?

Thanks

[Muri777]

From what I can see, the SD card when mounted onto the RT is always listed under "sdb1". Further devices (USB for example) are named "sdc1", "sdd1" etc. Can someone confirm this for me?

Thanks

[Kyle97330]

I don't have access to a device Linux cRIO so I don't know if this will work, but looking here it seems like you could try either running commands like "lsscsi" or "hdparm" and then parsing the data there to see if you can determine which is which, or you could check out all of the files located in /proc/* to see if any of those contain information you can use to determine the difference between them.

[MichaelBalzer]

I'm interested to hear NI's response to this, as we're looking at using cRIOs with built in SD slots to increase the on board storage, in conjunction with USB drives for bulk data transfer.

Reading around it seems like sda1 or sdc1 could be used for USB drive access, depending on the model of cRIO (see https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/NI-Linux-Real-Time-FAQ/ta-p/3495630). How an SD card fits into the mix is unclear - it might always be sdb1, or it might be cRIO model dependant.

The above link also mentions reading the device UUID and volume label using the 'blkid' command (installed through NI's repo), so that might be an option.

[Muri777]

Bump - Can anyone from NI comment on this please?

[Mike.B · Accepted solution]

This is expected behavior in a Linux environment, as devices are traditionally only named when they are initialized by the kernel. This means persistent block device naming is not a native functionality, but as the article I linked suggests, there are ways to get around this.

The KnowledgeBase article Why Do My USB Devices Change Directories When My Linux Real-Time Target is Restarted? addresses this concern. Since you've already mentioned adding an "identification file" is not a robust enough solution for your case, the other solution mentioned in this article is to detect the UUID of the drive by using the blkid utility package. This should allow you to check if a device matches a specific UUID number and determine if it is your USB or your SD storage device.

[Muri777]

Thanks for this update. I will look into it and see if it works for our systems.The "SDB1" naming convention still seems to hold true though, I will report back if there are any edge cases with it.

[david.grimm]

You can use a VI like this to figure out all the drives you have plugged in. It'll tell you what the path is, USB/SD cards always begin with /media/... 

This call will actually give you processor and memory information as well. I use it as a "computing resource" monitor.