Problems with typedef uInt32 and NI Vision

[tstanley]

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.

[Tanner!]

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.

[BriBear]

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 

[SteveD123]

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...

[tstanley]

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.

[Tanner!]

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.

[tstanley · Accepted solution]

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.

[SteveD123]

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?

[Tanner!]

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.

[Tanner!]

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.