Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Use 32-bit IMAQ library on 64-bit computer?

Highlighted

We have an existing 32-bit program written in C/C++, using the C IMAQ library. A customer requested a system with 64-bit Windows 7, and I'm wondering if it will be possible to use the code as-is. IE, have our 32-bit program call the 32-bit IMAQ library on a 64-bit system... does IMAQ install 32-bit drivers on 64-bit systems?

 

Thanks!

0 Kudos
Message 1 of 9
(2,585 Views)
Highlighted

I found this page on NI's website:

 

http://zone.ni.com/devzone/cda/tut/p/id/10339#toc3

 

It says LabView can run on a 64-bit computer in 64-bit kernel mode and 32-bit user mode - this is exactly what I need, but I'm wondering if this is the same for the latest IMAQ releases? Can I run IMAQ with a 64-bit kernel in 32-bit user mode?

0 Kudos
Message 2 of 9
(2,580 Views)
Highlighted

Absolutely. Many applications we ship (such as Measurement and Automation Explorer [MAX] ) are 32-bit apps regardless of host OS. You even gain some benefits running on a 32-bit app on a 64-bit OS compared to a 32-bit OS because the 32-bit app's available virtual memory goes from 2GB to 4GB.

 

Now, there is one item to note in that some of our older IMAQ framegrabbers have DMA engines only capable of 32-bit addressing. Because IMAQ's C API allows the user to allocate their own memory buffers directly, there is no guarantee that those buffers reside in physical memory that is accessible to the framegrabber's 32-bit DMA engine. As a result, by default we disable access to our C API when using a 64-bit OS on affected framegrabbers. There are some publicly documented workarounds that allow you to allocate the right type of memory through our driver instead of directly and this can allow you to use the C API on such a system.

 

Eric

Message 3 of 9
(2,577 Views)
Highlighted

Thank you very much for the response - this settles my nerves after a morning of searching.

 

Is there a list of framegrabbers which are only capable of 32-bit addressing? This particular application is using a PCI-1428. Also - if I allow the API to allocate buffers (ie send in a void *bufferList[] all initialized to NULL), will this skirt the problem regardless of the framegrabber?

 

Thanks again.

 

Gard

0 Kudos
Message 4 of 9
(2,575 Views)
Highlighted

Hmmm.  Doesn't seem to work for me.  I am trying to move code over from 32-bit XP, NI-1428 frame grabber, and encounter the following error:

 

IMAQ error:  -1074396857 'This 32-bit device is operating on a 64-bit OS with more than 3GB of physical memory.  This configuration could allocate 64-bit memory which is unsupported by the device.  To solve this problem, reduce the amount of physical memory in the system.'

 

The error comes after the call to imgSequenceSetup:

 

    // We let the driver automatically allocate the memory for us
    ImaqBuffers = new uInt8 *[nImaqFrames]; // malloc(nImaqFrames * sizeof(uInt8 *));
    if (!ImaqBuffers)
    {
        cout << "error.  couldn't alloc ImaqBuffers"<<endl;
        return FALSE;
    }
    else
    {
        for (i=0;i<nImaqFrames;i++) ImaqBuffers[i] = NULL;
    }


    // Setup and launch the sequence acquisition asynchronously
    errChk(imgSequenceSetup (camera->Sid(), nImaqFrames, reinterpret_cast<void **>(ImaqBuffers),
                      skippedBuffers, FALSE, TRUE));

 

Code works fine under XP.  Sys admin says we're using the same IMAQ libraries as under XP (4.3.1?)  but sounds like IMAQ is trying to allocate the buffers in 64-bit address space.

 

Any suggestions?

 

0 Kudos
Message 5 of 9
(2,550 Views)
Highlighted

The release notes for IMAQ state that the 1428 is supported on 64-bit for use with LabView, but NOT for use with C/.NET libraries, unless the computer has less than 3GB of memory.

 

The NI 1427 and 1429 do support 64-bit with greater than 3GB when using C/.NET libraries, but require a firmware upgrade. I'm planning on purchasing a 1427 for use with our 64-bit project - it looks like it equals or outperforms the 1428 in all areas (that I can see), and is less expensive.

 

I hope this helps,

Gard

0 Kudos
Message 6 of 9
(2,545 Views)
Highlighted

Hmmm.  ouch.

thanx (grumble...)

 

Can anyone point me to the "workarounds" mentioned above?

 

 

0 Kudos
Message 7 of 9
(2,543 Views)
Highlighted

Gard's reply is correct, as officially we do not support that configuration for a C application because we cannot guarantee all user applications will work driectly in that scenario. However, we do have ways to work around this if your application code follows certain guidelines.

 

Check out this post for further details:

http://forums.ni.com/t5/Machine-Vision/Using-NI-IMAQ-imgSnap-ANSI-C-with-Windows-7-x64/m-p/1078765

 

Eric

Message 8 of 9
(2,539 Views)
Highlighted

 


@middletongard wrote:

Thank you very much for the response - this settles my nerves after a morning of searching.

 

Is there a list of framegrabbers which are only capable of 32-bit addressing? This particular application is using a PCI-1428. Also - if I allow the API to allocate buffers (ie send in a void *bufferList[] all initialized to NULL), will this skirt the problem regardless of the framegrabber?

 

Thanks again.

 

Gard


 

In general it follows if the device is PCI express or not. All the PCI express ones are either 64-bit capable as shipped or require a simple firmware update to make them capable. All the (current) PCI IMAQ devices do not support 64-bit DMA.

 

Eric

0 Kudos
Message 9 of 9
(2,537 Views)