10-01-2015 08:45 AM - edited 10-01-2015 08:45 AM
Hi,
I'm having a bit of a problem building my application against the headers provided by NI Vision Acquistion 15.0 and CVI 2012SP1. The problem seems to be conflicting typedefs in the header files related to the "uInt32" and "SESSION_ID" types. In NIIMAQdx.h, there's this:
#ifndef _NI_uInt32_DEFINED_
#define _NI_uInt32_DEFINED_
#if defined(_MSC_VER)
typedef unsigned long uInt32;
#else
typedef unsigned int uInt32;
#endif
#endif
Now, _MSC_VER is not defined, so we get uInt32 defined as a unsigned int. In niimaq.h there's:
#ifndef _NI_uInt32_DEFINED_
#define _NI_uInt32_DEFINED_
#if defined(_MSC_VER)
typedef unsigned long uInt32;
#elif __GNUC__
#if __x86_64__
typedef unsigned int uInt32;
#else
typedef unsigned long uInt32;
#endif
#endif
#endif
Which since neither _MSC_VER or __GNUC__ is defined, does nothing except define _NI_uInt32_DEFINED_ which prevernts it from being defined by another header. niimaq.h also has this in it:
typedef uInt32 INTERFACE_ID;
typedef uInt32 SESSION_ID;
typedef uInt32 EVENT_ID;
typedef uInt32 PULSE_ID;
typedef uInt32 BUFLIST_ID;
typedef Int32 IMG_ERR;
typedef uInt16 IMG_SYNC;
typedef uInt32 GUIHNDL;
Which means that by itself, a module that includes niimaq.h won't build because uInt32 never gets defined. You can include NIIMAQdx.h before it so that it cand defrine uInt32 (as unsigned int), which works except that nivision.h has this line int it:
typedef unsigned long SESSION_ID;
So once again it won't compile due to the conflicting types (unsigned int versus unsigned long). It seems that there is no way to include niimaq.h, nivision.h, and NIIMAQdx.h in the same .c file, no matter the order, without some conflict or unknown types. Comparing back to an older version (3.9.1), I see in NIMAQdx.h,
#ifndef _NI_uInt32_DEFINED_
#define _NI_uInt32_DEFINED_
typedef unsigned long uInt32;
#endif
Which is nice and simple. niimaq.h also has the exact same code in it too for NI-IMAQ 4.6.1. This does imply that I can "fix" it by defining _MSC_VER, and indeed putting
#define _MSC_VER 1300
At the top of my .c file does indeed get things to build, but I'm leary of doing this because I know there are other things that appear to key off of this.
Any ideas or is the solution to roll back to an older version of the Vision Acquisition? Thanks.
Solved! Go to Solution.
10-05-2015 03:26 PM
tstanley,
Unfortunately I don't have an immediate answer for you, but thank you for bringing this to our attention. I'll do some testing and see if I see the same results.
10-09-2015 06:44 PM
Hey tstanley,
You mentioned potentially reverting to another version of the software. Have you written code with a previous version of Vision Acquisition software without these compliation errors? May I ask what your project is, and why you need to include all three header files in the project? You may have seen these already, but I wasnted to mention the examples that install with the Vision Acquisition software that install in the default directory of C:\Users\Public\Documents\National Instruments\CVI\samples\Vision
10-10-2015 02:06 PM
Briana C: You are asking why someone wants to use your multifunction daq, vision acquisition and vision processing libraries together? Really? Is it so hard to imagine that someone might want to do some image acquisition and processing and need some analogue+digital I/O as well?
The WHOLE POINT of staying within the NI ecosystem is the tight integration between all the parts because is is all owned, developed and sold by the same organisation. I use LabWindows because I want assurance that whatever combination of interface requirements I have, I can meet them with hardware and software drivers from the NI range, and NI are ultimately responsible for them all. I have no wish to return to the 1990's, where different interface cards from different suppliers would require different versions of the OS and compiler, and the retailer would be unable to help because they had simply purchased a crate of 1000 cards from the importer, and would not have been able to track down the developer even if they wanted to.
However, as I repeatedly point out, the NIVISION functions for LabWindows are falling far behind those for LabView. It now seems that NI barely bother testing the Vision functions with each new LabWindows release at all. See this post: http://forums.ni.com/t5/LabWindows-CVI-Idea-Exchange/Test-New-CVI-Versions-with-ALL-the-add-on-toolk...
10-12-2015 08:57 AM
Thank you SteveD, for putting my thoughts into words so eloquently. The whole reason for using NI (and paying the licensing fees) is because things are supposed to be simplier and work together nicely.
To answer Briana C's question, before I was working with Vision Acquisition 2011-09, which didn't have this issue. It seems a lot of these compatibility problems kind of crept in with the change in CVI 2013 to the clang compiler. Not that the change itself was a bad thing necessarily, but it certainly has not been a smooth transisiton.
I suppose I could try and split up the code into smaller .c modules to try and eliminate the header overlap to deal with this issue, but this is an older codebase that was working before and I don't feel I should have to do that. Besides I would still have things like SESSION_ID defined as different types in different areas of my project which could potentially still lead to problems.
10-12-2015 10:41 AM - edited 10-12-2015 10:42 AM
For the record I support Vision products, and I asked BriBear to look at this with me because they have more experience with CVI. We weren't trying to accuse you of using it wrong or suggest that what you were doing was outlandish, just attempting to ensure that we fully understood the scope of your issue. I can empathize with both of your frustrations with CVI and Vision, and I assure you that we genuinely want to help you.
It's worth noting that unsigned int and unsigned long are the same datatype in C when building 32-bit applications. The following code compiles successfully for me when using Debug, but fails when using Debug64 with the error "typedef redefinition with different types ('unsigned long' vs 'uInt32'(aka 'unsigned int'). Would you confirm that you are using Build>>Configuration>>Debug?
#include "niimaq.h"
#include "nivision.h"
int main (int argc, char *argv[])
{
return 0;
}
I'm using IMAQ 15.0 and CVI 2013 to ensure that we're running equivalent tests, and will install 2012 SP1 if we can't get to the bottom of this otherwise.
10-12-2015 02:29 PM
Hi Tanner!, Thanks for the reply. I am using the Debug mode, not 32 bit. The code example you provided does not build in my configuration. The problem is this code in niimaq.h
typedef uInt32 INTERFACE_ID;
typedef uInt32 SESSION_ID;
typedef uInt32 EVENT_ID;
typedef uInt32 PULSE_ID;
typedef uInt32 BUFLIST_ID;
typedef Int32 IMG_ERR;
typedef uInt16 IMG_SYNC;
typedef uInt32 GUIHNDL;
And the reason is that uInt32 and Int32 are not defined (though uInt16 is defined). On another PC with NI Vision 2009 installed it builds just fine, though on this PC with IMAQ 15.0 it does not.
Playing around with this, I think the problem is that CVI 2012 SP1 is not defining _MSC_VER or __GNUC__, whereas CVI 2013SP1 has __GNUC__ defined as 4 (and leaves _MSC_VER undefined). Since __GNUC__ is defined, then in niimaq.h, uInt32 is defined as unsigned long (for 32 bit), and everything is happy with CVI 2013, so the problem seems to be related to the combination of CVI 2012 and newer versions of IMAQ.
10-12-2015 02:50 PM
Tanner B
Thank you for your follow-up and comments.
Is there any chance of a timetable for NI Vision for LabWindows reaching feature parity with NI Vision for LabView?
10-12-2015 02:50 PM
Got it. I'm going to reproduce it for posterity, then I will file a corrective action report to at least update the documentation to reflect what we're seeing. Thank you for bringing this to our attention.
10-12-2015 02:53 PM
Unfortunately I can't speak to time tables or product releases, but I can say that our text-based vision solutions are an active product.