Using NI-IMAQ imgSnap (ANSI C) with Windows 7 x64

Question

Hello,
I am trying to perform some basic image acquisition using ANSI C calls to NI-IMAQ (as distributed by the November 2009 release of NI Vision). I am developing on Windows 7 x64.
Setup seems to work fine, but when I make the following call:
   void* theTempBuffer = NULL;   Int32 theRetVal = imgSnap(mSession, &theTempBuffer);
I get the following error:
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.
I see this whether I compile to a 32-bit or 64-bit target. I would have concluded that the PCI-1422 simply isn't supported under Windows 7 x64, but the card (and attached camera) work fine for snapping or grabbing images when I go to the Measurement & Automation Explorer.
Thanks for your help.
Solved!
Go to Solution.

Answer 1

Hi KKRand,
Currently you are using a non-supported combination. Due to the hardware limitations of the 1422 board, it is limited to 32-bit DMA. Due to IMAQ's C API where users have the ability to allocate their own buffers to be acquired into, we have no way to enforce that this memory is below the 32-bit boundary for *all* use cases of our C API.
Because of this, we officially do not support using the IMAQ C API on a board with this 32-bit DMA limitation on a 64-bit system and more than 3GB of memory because we cannot guarantee that a user's application will run without any modifications. These limitations do not apply if you use an API like LabVIEW where the user does not control the memory allocation directly or you have a newer board with 64-bit DMA support.
Measurement & Automation Explorer can get around this limitation because it uses limits its use of our API to ensure that memory is allocated properly to guarantee that it is below the 32-bit boundary if you have an affected board/system combination. With possibly a little modifications to your app, you should be able make it able to work as well, but as I mentioned it is not an officially supported combination.
The modifications to your application are:
- Make all allocations of image buffers that you will use for acquisition from that board be allocated by calling into imgCreateBuffer() as opposed to allocating them by other means (new, malloc, on the stack, etc). Memory allocated in this manner must be released by calling imgDisposeBuffer().
- Disable enforcement of checking this condition by calling a private function exported from imaq.dll as "int niimaquDisable32bitPhysMemLimitEnforcement(SESSION_ID boardid)"
The first part is likely already satisfied in your case because the high-level imgSnap() allocates the memory for you and thus ensures that it meets our requirements. You'd have to add the second to your application. Keep in mind this is unsupported. We currently do not check that all buffers in your bufferlist were allocated in this manner and so if you allocated a buffer by some other means you would get a run-time configuration failure when and if any memory ever fell past the 32-bit boundary when you start acquiring.
This behavior might change in the future, but from a support standpoint it is unlikely that we'd officially support this configuration since it is highly dependent how the user's application is written (if it relies on its own memory allocations). What we wanted to avoid was customers starting with simple usage of our API (like a high-level Snap()) and finding it working but then later going and allocating their own buffers and seeing a failure.
Hope this helps, 
Eric