DAQmx base on MacOS X, Error -89136 occurred at an unidentified location, Specified route cannot be satisfied, because the hardware does not support it.

[mtedaldi]

I'm using a NI USB-6211 on MacOS X now.

I first developed the software on windows and had quite some changes to get it to work under MacOS X. Mostly because on MacOS X only DAQmx base is supported instead of DAQmx (which despite the similarity in names behaves quite differently in quite surprising ways).

One thing that I could not solve until now is signal Routing.

I'm using ctr0InternalOutput as sample clock for ao0. This works well under DAQmx but under DAQmx base I get the error message:

"Error -89136 occurred at an unidentified location, Specified route cannot be satisfied, because the hardware does not support it."

If I replace the timing source with for example pfi1, it does almost work (but this problem should go into another post I think). Is there a way to get around this limitation in DAQmx base (since it is clearly NOT a hardware limitation) or do I really have to waste two perfectly fine pfi ports just to route the clock signal externally?

Using:

MacOS X 10.8.5

DAQmx Base 3.7

NI USB-6211

Quite some anger management techniques

[FCTesting · Accepted solution]

Hi,

I didn't see in your post above whether you are using LabVIEW or a text-based programming language. If you are using text-based, then DAQmx Base does not support routing (see link below).

http://digital.ni.com/public.nsf/allkb/DE80B096D6FECBC7862570E7007B674A?OpenDocument

I haven't tested this before, but if you are using LabVIEW for Mac the article states "Additionally, it is possible to perform task synchronization in DAQmx Base for LabVIEW" yet doesn't explicitly state that routing is available. On the NI-DAQmx for Linux FAQ (not the same as Mac but NI-DAQmx for Linux is much closer in features to NI-DAQmx Base for Mac than NI-DAQmx for Windows), it states Device Routing Tables are not available (Part 5, and Part 6 which addresses this).

http://www.ni.com/white-paper/3695/en

You may be able to use DAQmxBase Export Signal VI, but I'm not sure if it will support output to a sample clock. I am guessing currently you have "Dev1\ctr0InternalOutput" connected directly as sample clock source at the moment?

Hopefully some of this info helps.

[mtedaldi]

---

@FCTesting wrote:

Hi,

I didn't see in your post above whether you are using LabVIEW or a text-based programming language. If you are using text-based, then DAQmx Base does not support routing (see link below).

http://digital.ni.com/public.nsf/allkb/DE80B096D6FECBC7862570E7007B674A?OpenDocument

---

I'm using LabVIEW 2012. Sorry, I omitted that Information.

---

I haven't tested this before, but if you are using LabVIEW for Mac the article states "Additionally, it is possible to perform task synchronization in DAQmx Base for LabVIEW" yet doesn't explicitly state that routing is available. On the NI-DAQmx for Linux FAQ (not the same as Mac but NI-DAQmx for Linux is much closer in features to NI-DAQmx Base for Mac than NI-DAQmx for Windows), it states Device Routing Tables are not available (Part 5, and Part 6 which addresses this).

http://www.ni.com/white-paper/3695/en

You may be able to use DAQmxBase Export Signal VI, but I'm not sure if it will support output to a sample clock. I am guessing currently you have "Dev1\ctr0InternalOutput" connected directly as sample clock source at the moment?

Hopefully some of this info helps.

---

The documentation really seems to be a bit lacking here.

So it seems, that I can't use the timer output as a sample clock for my project here. But I should be able to bridge the signal externally...

That's somehow sad since it is (despite the software telling me something else) not a hardware limitation but one in the software. I think I've learned my lesson by now: "Never try to do something DAQ related with LabVIEW on a Mac."

When I started the project I was looking forward to prove how awesome cross platform compatibility is... Seems, I failed that mission 😞

[johnsold]

Marco,

---

When I started the project I was looking forward to prove how awesome cross platform compatibility is... Seems, I failed that mission 

---

<Soapbox mode = ON>

I would argue that is is not you but NI which has failed that mission. NI has never provided a robust, cross-platform DAQ driver. In the days of the Motorola processors in the Mac the bus structures were completely different from those on Windows PCs so both the hardware and software were different. It was understandable that some perfomance differences were to be expected. Since 2006 when Intel processors began to appear in quantity in Macs the justification for a two-tier driver system has diminished.

To make DAQmx run on the Mac the only thing NI would need to do is to rewrite nilvaiu.dll to an equvalent performance nilvaiu.framework and link it to the existing DAQmx VIs. Now that may be a significant task, I have no way of knowing. But the interface hardware - PCI busses, USB, Ethernet, etc. is all the same.  The primary difference appears to be the hooks to the OS API.  Since NI has drivers which use all those interfaces already, it seems to me that they know where those API hooks are and how to call them.

Furthermore, on USB and Ethernet the communications consists of message passing. That should be completely OS agnostic. To me that means that the full capabilities of any DAQ devices with USB or Ethernet communications should be easily made available on all platforms.

This is the block diagram of DAQmx Read.vi when opened on the Mac:

If the Mac version of the nilvaiu.framework is configured with the same I/O structure as the Windows DLL, the DAQmx VIs would likely work with no modifications.

</ SoapBox Mode = OFF>

Lynn

[Chris_VandeVelde]

Hi,

Is there any evolution for this topic?

I 'm also trying to use DAQmx VIs on a Mac (labview 2015 and DAQmx Base 15.0) but I get the same problem with the 'nilvaiu.framework'.

This DAQmx VIs are currently used with labview 2014 and DAQmx on a PC (Win7) (see the attached VI as example).

Thanks !