Hi, i'm using an sbrio 9637 to perform real time simulation. The one thing i'm trying to achieve is to be able to run different simulation configurations based on some large lookup tables generated in matlab. So my idea is to store data of the previously generated lookup table in an .so file and place it onto the SD card (offline, using let's say a windows system fat32). Then use the call library function node to get the interpolated data during initialization and run time.
is this possible? i looked at the workflow of using .so from the call library function node, it only mentions how to place it under the \home\ directories, which i assume is on the onboard flash.
otherwise, is it possible to access the SD card from C/C++ eclipse project? there are a few tutorials on how to do socket programming in the eclipse but not much mentioning of other on board resources, like the SD card or CAN/SPI/RS232, etc.
appreciate if there are examples how to access these resources from the C/C++ env. either from .so or from executables.
Solved! Go to Solution.
Any particular reason you want to use an *.so file for a lookup table instead of using a file that can be read in LabVIEW using normal File I/O? E.g., a binary format or a *.csv? It seems to me that option would be more portable and less work than building a custom *.so for Linux Real-Time.
If the SD Card is the only removable storage on the sbRIO, it should be automatically mapped to "/u/" each time. See Writing to a USB Drive or SD from NI Real-time Device and Working with File Paths on Real-Time Targets, noting the Linux Real-Time sections. These file paths should apply to both LabVIEW and any C/C++ executable on a Linux RT system.
For LabVIEW: The Call Library Function Node can be given a full path once the file is accessible on the Real-Time system. Even if you placed it in one of the /home/ directories instead of in /u/, you would still be doing this unless that directory was on the LabVIEW search path (e.g., /usr/lib/).
Regarding the C/C++ project, that's a bit trickier. You have two options I'd suggest:
In my opinion, using the Call Library Function Node is the "easier" option if you don't have experience with C/C++ cross compiling but there's no better time to start learning than the present.
thanks for the prompt reply. I will give it a shot with the /u/ path then.
Charlie, the reason to use the .so is for some already existing C routines to do interpolations beside the lookup table data. I agree that csv is easier to manipulate as data but i have some program code that i would need to reuse/generate externally as well.