NIDAQmxbase Compatibility with Mac OS X 10.6

[markf424]

I suppose I was mistaken.  I can indeed force 32 bit kernel, but it breaks some other stuff I have running.

I guess maybe I should have better researched my purchase.  Still I am curious if I can access this device using tty.

[Iandol]

Most new macs boot to a 64bit kernel (both my 2010 Mac Pros and MBP do at least). To boot to 32bit kernel, hold down '3' and '2' when you boot to do it on a per-boot basis, or edit your apple.boot plist as described here:

http://macperformanceguide.com/SnowLeopard-64bit.html

 And don't hold your breath waiting for NI to update its drivers to support your OS...

[sth]

Well the xserves are the ones that defaulted first to a 64 bit kernel.  You can boot them into a 32 bit kernel, Apple provides dual compiled drivers for OS 10.6.X.  The newest (2010) Mac Pros also default to a 64 bit kernel.  All of these can boot to 32 bit kernels by setting system parameters or NVRAM.

The basic problem you have is that NI did not dual compile their drivers.  Until the VISA folks compile to run on 64 bit you will not be able to use any of the NI drivers in 64 bit mode.

If you have "other stuff" that only runs in 64 bit mode, you are in the middle.  Possibly the third party for your other kernel extensions is more helpful than NI and can provide a 32 bit mode kernel extension.

Both 32 and 64 bit kernel extensions can work with any type of application.  So it is only with conflicting extensions that you have such a problem.  You are free to run 64 bit programs even though the kernel is 32 bits.

[markf424]

Thanks all for the follow-up.  I'd forgotten when I first posted that I could force a 32-bit kernel boot.  You're right that I could probably work on the non-NI portion of my issue and make some headway, but in general I'm pretty glad I've got my server running with 64-bit kernel + kernel extensions.  I wish I could just mount this single device as a serial device and develop directly to it.  All I'm trying to do is count pulses generated from some residential water meters...

Anyway, appreciate the time taken to respond.

[markf424]

I have gone ahead, at least for the time being, and gotten my box (and all my other data collection items) working with a 32-bit kernel.  I've successfully installed NI-DAQmx BASE and I'm in the process of attempting to make the examples.

However, I am running into the following:

ld: warning: in /Library/Frameworks//nidaqmxbase.framework/nidaqmxbase, missing required architecture x86_64 in file

ld: warning: in /Library/Frameworks//nidaqmxbaselv.framework/nidaqmxbaselv, missing required architecture x86_64 in file

Undefined symbols:

  "_DAQmxBaseCreateDOChan", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseWriteDigitalU32", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseReadDigitalU32", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseClearTask", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseCreateTask", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseGetExtendedErrorInfo", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseStopTask", referenced from:

      _main in ccr9i4FO.o

ld: symbol(s) not found

collect2: ld returned 1 exit status

make: *** [readWriteDigPort] Error 1

I don't know if I need to force i386 architecture here, or if I'm doing something else wrong.  I'm definitely on the 32-bit kernel:

macsi: ~$ uname -a

Darwin macsi.xxx.xxx 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

Any tips would be appreciated.

[markf424]

Forcing it to compile with -arch i386 worked..  In case anyone else is having this issue.

[JoeFriedchicken]

---

markf424 wrote: 

However, I am running into the following:

ld: warning: in /Library/Frameworks//nidaqmxbase.framework/nidaqmxbase, missing required architecture x86_64 in file

ld: warning: in /Library/Frameworks//nidaqmxbaselv.framework/nidaqmxbaselv, missing required architecture x86_64 in file

Undefined symbols:

  "_DAQmxBaseCreateDOChan", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseWriteDigitalU32", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseReadDigitalU32", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseClearTask", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseCreateTask", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseGetExtendedErrorInfo", referenced from:

      _main in ccr9i4FO.o

  "_DAQmxBaseStopTask", referenced from:

      _main in ccr9i4FO.o

ld: symbol(s) not found

collect2: ld returned 1 exit status

make: *** [readWriteDigPort] Error 1

I don't know if I need to force i386 architecture here, or if I'm doing something else wrong.  I'm definitely on the 32-bit kernel.

---

Sadly, Apple still sets the default target architecture for 64-bit even when running in the 32-bit environment. The DAQmx Base for Mac readme [1] also highlights this peculiarity and lists a work-around.

[1] DAQmx Base 3.4 for Mac readme

http://ftp.ni.com/support/softlib/multifunction_daq/nidaqmxbase/3.4/Mac%20OS%20X/ReadMe.rtf

[markf424]

Just for the benefit of future participants, I wanted to update this thread with my solution.  I've decided to forego the enormous (and 32-bit forcing) NIDAQmxbase in favor of writing my own software to communicate with my USB-6501.  I was fortunate enough to stumble across some work done by Mark Schütz, who disassembled the protocol used to communicate with the device.  His C library wouldn't work with libusb on my Mac, but I was very easily able to write my own application in Ruby (ruby-usb --> libusb-compat) using his excellent documentation (http://www.ai3.uni-bayreuth.de/software/niusb6501/documentation.html).  

So I'm still running my SL server in 64-bit mode with all my 64-bit kernel extensions in place, and still collecting data from my 6501. 

Thanks for everyone's help here.  If future participants need help, I'm happy to point you in the right direction.

[Iandol]

Great solution - i really wish NI could release just simple core drivers, implemented via libusb (as the wonderful LabJack devices do) , without having to install hundreds of megabytes of incompletely updated stuff just to toggle a digital I/O!!! If a tiny firm like LabJack can do this, why not NI?

[markf424]

For what it's worth, and I realize this is very instrument-specific, but Marc has been kind enough to post his USB-6501 code on GitHub.  Once I make my Ruby code into more of a library format, I will do the same.  Marc's code is here:

https://github.com/schuetzm/ni-usb-6501