I've installed osx 10.10 ( Yosemite ) and since then the device (NI-USB 6210) is not working anymore.
The problem is obviously driver related. I called National Instruments and they confirmed the issue, and they also told me that the problem will be probably fixed in the next release of the nidaqmx, that will happen not so soon.
So their suggestion is to downgrade to Mavericks, which kinda suck.
They also told me to check the compatibility table
http://www.ni.com/labview/os-support/i/
in order to know when if will be supported, until then I have to struggle with downgrade or find a workaround which would be the best thing. anybody found a solution to this problem lately?
Depending on your device and how you program it, you should be able to get it working on Yosemite using NI-DAQmx Base 14.0 [1].
NI-DAQmx Base 14.0 does not claim Yosemite support, but after inspecting the installer and running a few tests, here is what I have determined:
The installer, kernel extensions, frameworks, and applications are signed by National Instruments, which means Gatekeeper won't interrupt you with "are you sure you want to do this?" questions.
Both 32-bit and 64-bit LabVIEW APIs are provided.
Both 32-bit and 64-bit C APIs are provided, but a C or Cocoa application emits a warning on exit. It appears one of the components in the driver attempts to access UI elements from a background thread. My suspicion is that the LabVIEW Run-Time Engine, in which the DAQmx Base C API runs, is doing that.
Links
[1] NI-DAQmx Base 14.0 for Mac
http://www.ni.com/download/ni-daqmx-base-14.0/5060/en/
I had this same problem, and spent an evening figuring out the problem.
Apparently, the NiDaq framework tries to send a message setHandler:withData: to the appdelegate. On yosemite, this handler no longer exists, causing the exception.
If you haven't implemented such message in your own app delegate, things go bad.
But you can simply implement a dummy handler by adding this to your application delegate class :
- (id)setHandler:(id)a withData:(id) b
{
return nil;
}
this way, the framework doesn't crash !!! I still have to test if the measured data is correct, but at least i'm running again !
Related
im wondering if operating systems can be a cause of a crash, example if I have a code, is it possible for it to crash under windows environment but not on linux? or is this impossible?
The simplest example is come code where your intention is to make it platform compatible but your have a bug in your code so it crashes on one OS but not on the other. Pseudo code:
if (osIsLinux())
laodLunixDriver(); // causes an exception
else if (osIsWindows())
loadWindowsDriver(); // works
Note how laodLunixDriver() is a faulty function that may cause the program to crash.
Another good option for an OS specific crash is accessing files.
ifstream file("c:\\myfile.file");
may work on Windows, but crash on Linux.
I have an app I've been developing under 10.9 using the 10.9 SDK, and I want to distribute it to my friends who are running 10.8. I know I can't guarantee it'll work there without finding an OS X 10.8 system (maybe in a virtual machine) and running it there, but is there any way I can check that I'm not using any 10.9-only APIs? Or even get a list of 10.9-only APIs that my application uses?
My understanding is that:
"Deployment Target" doesn't do this -- this just sets the LC_VERSION_MIN_MACOSX, so that if you tried to run it on an earlier version of OS X, it would refuse to even start.
"Base SDK" doesn't do this -- this is the version of the API it's compiled with. Some features added in newer versions of the SDK are available even on older versions of OS X at runtime (e.g., NSArray -firstObject).
Xcode's static analysis is pretty good at identifying the source of symbols (classes / methods) that I use, so it seems like this should be fairly easy to do, but I don't know how to do it.
"Base SDK" does what you want in a legalistic sense. Yes you may get some false negatives - for methods like firstObject - but better those than false positives. You can check any reported non-existant APIs and put in code to check dynamically (respondsToSelector:) and code defensively for those cases, or ignore them if you must and are really sure they are available.
My C# app uses a C++ WinRT component I've written to get a list of system fonts using Direct X.
This is based on this example:
http://msdn.microsoft.com/en-us/library/dd756582(v=VS.85).aspx
My app is published in the store, but my latest update failed to pass the store review process on point 3.10 complaining about my use of Direct 3D and how this might not run on ARM tablets. As far as I know I'm not using Direct 3D and the only Direct X feature I'm using is GetSystemFontCollection.
How can I make sure I don't fail this requirement and do I need to remove some rogue reference in my component to Direct3D?
Also, why am I failing this now, when it passed before?
Did you target all three platforms or choose any cpu in your release?
Does this page help:
http://msdn.microsoft.com/en-gb/library/windows/apps/hh994923.aspx
It looks like you may have inadvertently requested a higher level.
I submitted again and included a note to the tester explaining that my app didn't use any Direct 3D features, and I told them the exact DirectX function I did use.
I still failed, but the Direct3D reason was no longer one of the reasons.
Apparently my app is crashing, which was another failure reason the first time round, but I thought this must be related to the Direct3D problem. I can't reproduce the crash, but at least I now know that I can stop looking at my use of DirectX. This was a red herring.
I am building my app using iOS 5.0 as base SDK and iOS 3.0 as deployment target.
I know I need to check for existence of methods and classes when I work with features that are not available in the earlier iOS versions, but lately I've lost a few hours on a problem just to discover I was calling a method not available in some iOS versions. I simply did not notice it was a new method and did no check before to call it. The app of course compiled with 0 errors and 0 warnings.
This is a big problem because if I forgot some other check somewhere in the app, I will not know it until I or, worst, some user will activate that specific part of code.
Maybe I am missing something, is there some compiler option I can set to detect the calls I make to methods not available in the iOS deployment target? How do you deal with such a problem?
This link might point you in the right direction. Supporting mutiple ios Versions in your apps. It explains how to deal with taking advantage of the newer ios features while maintaining backwards compatibility. Hope that helps.
The only way to check for compatibility with a prior version of iOS, currently, it to test the app on an old non-updated device running that version of the OS.
If you can't find a device that old, even just to borrow for short time, then there may not be a good buiness reason to set the Deployment target that low.
Can someone point me to the correct place to start development of a twain scanning appliation for the MAC osx. I have done some simple objective c development in the past, but nothing interfacing with a device.
If you're talking about Objective-C and TWAIN on the Mac, this page on the twain.org site has a DMG you can download which contains a sample project called TWAINClientCocoa.
It's from 2002 or something so it requires a little finagling to get it to load and build (rename the .pbproj folder to be a .xcode folder so it will open in Xcode and then do an "upgrade" when you're in Xcode) but it works (just tried it last week) and should give you a good starting point. It relies on the concept of the TWAIN source providing its on GUI but that's something you could modify.
If someone if still interested in this, I have just written a TWAIN client on macOS for my application. This documentation is quite helpful.
The main problem doing this today is that the PicHandle returned by native transfer mode requires some deprecated functions to operate on. On my system (10.13) I can workaround this by making up the headers for those functions but they might be removed totally some time in the future. It's probably worth trying to use memory transfer mode which is more complex.