From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

point grey chameleon camera

Hi,

 

I'm trying to talk to a point grey chameleon USB camera with Labview using ActiveX.

 

I was able to register the DLL and display the live image and change the settings (shutter, gain, etc.). When I tried to get the image data using the "GetImageData" method, Labview crashed with the error message "Exception: Access violation" (See the attached figure). I also tried to using the "SaveImage" method. It sometimes crashed, too. But it can only save 8-bit pgm files and we need to have 16-bit (12-bit actual resolution).

 

I'm using Labview 2011 SP1 (32-bit) on windows 7 (64-bit). The camera model is CMLN-13S2M with the Flycapture 2.3.1.8.

 

Does anyone get the camera to work properly to be able to get the image data in 16-bit?

 

Thanks,

Joseph

0 Kudos
Message 1 of 8
(4,336 Views)

Hi,

 

I have two suggestions for you. First I would like to recommend you follow these steps to verify that there is no problem with your dll and project configuration:

 

  • Make sure you are using the same calling conventions as the DLL.   When using C calling conventions, the caller is responsible for cleaning up the stack.  When using Standard calling conventions, the called function is responsible for cleaning up the stack.  If the caller (LabVIEW) and the called function (your DLL) don't have the same calling conventions, then they will either both take things off the stack or neither of them will.  Either situation will certainly cause LabVIEW to crash when your DLL function returns.
  • Make sure that all inputs on both sides of your Call Library Function Node are wired. If the left side is not wired then the DLL will write over unallocated memory.  If the right side is not wired up,  LabVIEW will assume that your DLL does not need or use that allocated memory and will use it for something else.  Your DLL will then overwrite reserved LabVIEW memory space, causing LabVIEW to crash.
  • Make sure your DLL is not overwriting LabVIEW memory.Frequently DLL functions will take allocated memory as input, write to this memory, and return it.  If not enough memory is allocated or the DLL writes more than has been allocated, the DLL will overwrite reserved LabVIEW memory space and cause LabVIEW to crash.  For example, consider the following function: double *Waveform (double *waveform, uInt32 size); The proper way to allocate the memory in this case is to initialize the array with the appropriate size prior to calling the DLL.  The image below demonstrates the proper method.   

     

  • Make sure that LabVIEW is passing parameters to your DLL in the format that your DLL is expecting. If LabVIEW and your DLL do not agree on how a parameter is being passed (by value, reference, handle, etc.), then it is possible for your DLL to unintentionally point to some random place in memory.  This can cause faulty data at best and LabVIEW or Windows crashing at worst.
  • If you built the DLL in LabVIEW and you are showing the front panel of the DLL, then there are two strict requirements to make it work.
    • The Call Library Function must be set so that the DLL call is Reentrant. This is set by changing the execution category (under the Browse button) from Run in UI Thread to Reentrant.
    • The calling VI (the VI from the LabVIEW development environment that is calling the LabVIEW built DLL) must not be running in the User Interface execution system. This can be checked by selecting File»VI Properties»Execution and making sure that the execution system is standard, instrument i/o, data acquisition, other 1, or other 2 (same as caller may run in the user interface system if the parent VI calling this VI is running in the user interface system).

My second advice is to use the National Instruments Vision and Acquisition software to interface LabVIEW with you camera.

 

Warm Regards,

Miguel Fonseca

National Instruments - Applications Engineering

0 Kudos
Message 2 of 8
(4,311 Views)

Hi,

 

Thanks for your reply.

 

I'm using the activeX control and not call library function nodes. I'm not familiar with the point grey camera dll.

 

Thanks,

Joseph

 

0 Kudos
Message 3 of 8
(4,307 Views)

ActiveX control?

 

Do you have a VI showing exactly what you are talking about?

 

0 Kudos
Message 4 of 8
(4,303 Views)

Hi,

 

Here is the code I got from point grey tech support. You will have to install the point grey Flycapture SDK to be able to run it. You can modify the code and use different methods (such as GrabImageData).

 

Thanks,

Joseph

 

0 Kudos
Message 5 of 8
(4,291 Views)
I also have the same problem with u. How to get 16bit image from usb camera?
0 Kudos
Message 6 of 8
(3,890 Views)

Same problem with Grasshopper3.

0 Kudos
Message 7 of 8
(3,442 Views)

When you open the VI that Point Grey provides, is the ActiveX Control "active"?  On my machine, it says "Control could not be loaded" because I do not have their SDK.

 

The other suggestion, from NI, was to use LabVIEW's Vision tools (for which you need the Vision Toolkit).  Does your camera show up in MAX?  If so, and if you have the Vision Toolkit, this may be a simpler way to go.  Here is what MAX shows me for my PC, which has three cameras (two USB, one Ethernet) attached:

My Cameras.png

 

Bob Schor

0 Kudos
Message 8 of 8
(3,435 Views)