04-04-2006 01:59 PM - last edited on 05-07-2024 02:21 PM by Content Cleaner
Hi bef,
@bef wrote:
If you try to run a RAMdisk-linux with NI drivers you really have to be careful. Eg. NI writes temporary data into /usr/local/natinst (which is not really the right place for that- NI: please use /var or /tmp for stuff like that in the next release). If you have a readonly filesystem for these "static" directories you will have trouble loading the modules.
I agree that we should be writing temporary data into /usr/local/natinst. Can you provide some examples of this so I can bring it to the attention of the relevant groups?
@bef wrote:
While I'm at it, here is a question for NI: why don't you open the source for drivers and RTE? It would make life so much easier when using different distros or other kernels. Maybe the GNU-community could even help with kernel support. For some people it's not easy to be forced to use only the 2.6.13-kernel.
You may be happy to learn that for many of our boards we have Register Level Programming manuals, as well as a free DDK. Try searching for RLP at www.ni.com, and check out the Measurement Hardware DDK . In fact if you are interested in open source linux drivers for NI products you may want to check out some existing projects which have used the RLP manuals to develop open source drivers:
Comedi
Linux GPIB Package
These projects are not sponsored by NI so we can not provide any support, however I'm sure they would love your assistance.
If you choose to use the NI drivers you can still contribute by posting tips, suggestions, or bugs to the forums. The forums are monitored and if you find a problem in one of our drivers we will do our best to fix it for the next release.
Shawn B.
National Instruments
04-04-2006 03:39 PM
@Shawn B. wrote:
Hi bef,
@bef wrote:
If you try to run a RAMdisk-linux with NI drivers you really have to be careful. Eg. NI writes temporary data into /usr/local/natinst (which is not really the right place for that- NI: please use /var or /tmp for stuff like that in the next release). If you have a readonly filesystem for these "static" directories you will have trouble loading the modules.
I agree that we should be writing temporary data into /usr/local/natinst. Can you provide some examples of this so I can bring it to the attention of the relevant groups?
You mean you should NOT write session data into /usr/local/natinst, right?
OK, here are the files I found that need to be accessed read/write :
/usr/local/natinst/max/mxs.mxr
/usr/local/natinst/max/Data/<all files in this dir>
If these files can't be written, the kernel module falls back into writing the config data into /tmp. But that takes approx 2-3 minutes after each boot (that can be really confusing if you try to figure out why the driver is not working...)
Comedi: I know that project, too bad nobody really published a LV-Interface (? I remember finding a Comedi-LabVIEW-project somewhere on the web but I can't find it any more )
Still I'm glad NIDAQmx8.0 for linux is out. It seems to be working really well.If you can manage to support USB-devices at some point of time I can finally toast my last Windows box...
04-04-2006 03:44 PM
06-19-2006 11:06 AM
@Shawn B. wrote:
Just to make sure this is clear... You can only build a Windows
executable with the Windows Application Builder, and a Linux executable
with the Linux Application Builder.
Shawn B.
National Instruments
06-20-2006 01:32 AM
07-24-2006 04:13 PM
07-25-2006 09:29 AM
Hi,
The TPC-2006 currently does not support our USB DAQ products. We are currently in the process of investigating this issue. However, the CompactFlash DAQ Device (CF-6004) does work on the TPC-2006.
-Sal