NIDAQmx 15.0 and and app delegates on the Mac

[VC_TMW]

Hello,

We were trying to use NIDAQmx base 15.0 on the Mac and have run into issues that have been previously reported. See this thread - CAR #528664. 

The issue is also reported by other users on this thread. Based on the suggestion in the last comment in the thread, is it necessary for the NI driver code to make the call to it’s application delegate’s setHandler:withData:? If not, the simplest alternative is for the driver to check the dynamic cast to their delegate; if it fails, then the driver code should avoid making the call. Alternatively, the driver could check respondsToSelector, before making the call.  Both these solutions are in the NIDAQmx base driver's code.

Without knowledge of the driver code we cannot make an accurate judgement if we can implement the workaround suggested in the thread. 

Can someone at NI R&D can confirm that it’s safe to implement this workaround?

Thanks,

-Vinod Cherian

MathWorks

[JustJohn]

Hello VC_TMW!

I have check on the specific CAR you mentioned, and the attached workaround refers to simply calling the NI libraries before starting up the GUI. This workaround is not guaranteed by R&D, but it has been implemented by other Applications Engineers and has successfully worked in their scenarios. The second post that you are referencing has its own method that has not yet been verified by our engineers. However this solution seemed to fix that users issue successfully. If either of these workarounds make sense for your application, they may be worth trying. The first has been verified by our Applications Engineering department, the second has not but seems to be a good option. Is there any specific reason for not trying the option mentioned in the forum? What is the purpose of verifying this workaround? 

[VC_TMW]

Hi John,

Thank you for checking on the status of the CAR.

The first workaround, launching the NI DAQmx libraries before my GUI starts, is not a feasible solution. There are many workflows in my GUI that do not require the NIDAQmx driver to be loaded at all. Loading the NIDAQmx library introduces a runtime dependency on it, which is an unreasonable requirement for users who do not use the functionality in my GUI that requires NIDAQmx.

The second workaround seems dangerous to implement without an idea of the impact of this on the NI DAQmx driver. It would be great to have someone who is familiar with the internals of driver operation on the Mac chime in on if it is likely to cause instability in the driver. The workarounds may allow us to work around the bug in the driver which prevents us from supporting certain NI devices on the Mac platform.

In the ideal case the driver would resolve the issue reported in the CAR. If that is not expected any time soon, please let me know if the second workaround is likely to cause the driver to misbehave.

Thanks,

Vinod Cherian

MathWorks

[JustJohn]

Hello VC_TMW!

I understand why this workaround gives you pause. The way that the solution you mentioned handles the situation does seem a bit haphazard and would cause me to question its effects on the driver functionality itself. The best thing I can do is to bring this up with R&D and show them both the CAR that you are referencing and the workaround mentioned earlier. I will report back as soon as I have some information for you. Thank you for your patience!

[JustJohn]

Hello VC_TMW!

I finally was able to track down an R&D engineer and had them take a look at the workaround you have mentioned here. Due to the fact that this workaround has not been/can not be implemented or tested by R&D it is still not an officially supported workaround. With this in mind, the workaround documentation was looked over and it did not appear to be immediately malicious. This, however, does not mean that the workaround is officially supported by National Instruments. I apologize if this reply isn't as straightforward as you might have wanted it to be, but it is an option that might be helpful for your application. The quickest way to find out the implication of this workaround is to try it and see if anything is negatively affected by its implementation. Please report back with any findings! 

Have a great week!

[VC_TMW]

Thank you for checking, John. We will try out the workaround.

Could you pass R&D the suggestion for the driver to check the dynamic cast to their delegate; if it fails, then the driver code should avoid making the call. Alternatively, the driver could check respondsToSelector. These suggestions can probably help you resolve CAR #528664 permanently.

[Jonsfilter]

I spent 4 weeks trying to debug my app on Mac OS X Sierra using NIDAQmx and it kept crashing. I simplified the code to essentially what is reported in CAR #528664. It is really frustrating to find that an issue reported 2+ years ago is not getting any attention and the suggested "workaround" is to build a 32-bit app.

Can someone at NI provide an update if CAR #528664 is ever going to be fixed?

[DigDoug]

Update: This bug (CAR #528664) has been fixed in LabVIEW 2016.

[vharihar]

Hello Aaron,

Please let me know which version of NI-DAQmx Base this is fixed in. The latest I am able to find on your website is NI-DAQmx Base 15.0 (http://www.ni.com/download/ni-daqmx-base-15.0/5648/en/). 

Thanks,

Varun Hariharan.

MathWorks

[JonSFilter1]

I'm not using LabVIEW to program my device. I am writing my own app and compiling in XCode. The crash is coming from my NIDAQmx call.

Where can I download the patch or updated version of NIDAQmx that does not have this problem?