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.
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.
06-16-2015 03:37 AM
Hi,
He have a custom program to acquire images from a Pulnix 6710CL. It used to work in LabVIEW 2009 (32 bits) installed in a Windows 7 operated computer (32 bits also). Due to computer updates, we are now using Windows 7, 64 bits and have installed LabVIEW 2011 (64 bits also). One of our VIs is not working anymore since then (I attatch it, with the corresponding subVIs), we have performed several tests and seems to be "IMAQ BCGlookup.vi" what is causing the crash, the VI works perfectly without it but crashes (LabVIEW stops running and closes) when we call it. We have performed several basic tests but we are unable to find the reason for the crash. We would appreciate any help or advice.
Julene
06-16-2015 06:36 AM
I'm going to guess that the vast majority of LabVIEW Installations are on Windows 7 (64-bit), running LabVIEW 20xx (32-bit). While there is a 64-bit version of LabVIEW, most of us do not need the extra address space capability, nor the weird problems associated with 64-bit LabVIEW. I'm sorry to recommend this, but try removing 64-bit LabVIEW and installing 32-bit -- I'm betting your problem will go away.
Bob Schor
06-16-2015 06:42 AM
06-16-2015 06:59 AM
@mikeporter wrote:
Yes, 64 bit LabVIEW has a history of being a bit flaky. Also many of the toolboxes don't work with it.
Mike...
Except that the IMAQ Vision Toolkit was excplicitedly one of the Toolkits that was fully ported to LabVIEW 64 bit because image analysis applications are the most likely applications that can require a 64 bit application memory space.
However, something apparently seemed to have gone missing in the 64 bit version. Since it is done in an old version of LabVIEW (2009) the most likely recommended remedy would be to upgrade to a newer LabVIEW and IMAQ Vision version. 2009 was the first to support 64 bit in any way and there is a good chance that something has been fixed in the last 6 years.
06-16-2015 07:02 AM
Bob_Schor escribió:
I'm going to guess that the vast majority of LabVIEW Installations are on Windows 7 (64-bit), running LabVIEW 20xx (32-bit). While there is a 64-bit version of LabVIEW, most of us do not need the extra address space capability, nor the weird problems associated with 64-bit LabVIEW. I'm sorry to recommend this, but try removing 64-bit LabVIEW and installing 32-bit -- I'm betting your problem will go away.
Bob Schor
Hi Bob,
Thank you very much for your answer. Unfortunately, we have just been testing that option (we have tested LabVIEW 2011-32 bits) but it crashed exactly in the same way. We have even tried installing the same LabVIEW 2009-32 bits we used in our old OS, and it does not work either.
I don't know if this may be a problem related with dlls compiled for 32 bits, we are trying to figure out how the 64 bit OS is affecting the program...
06-16-2015 07:07 AM - edited 06-16-2015 07:14 AM
One thing that could neck you is the image type used. Depending how your interface for the camera is configured for the camera you may end up with a different image type than what you later try to extract (U8 greyscale). What image type does your OverviewInit.vi show?
Also try to explicitedly allocate an image with IMAQ Create before the loop and connect it to the shift register. Use the image type returned from the OverviewInit.vi to determine the type for the IMAQ Create Image Type input.
WAIT! Are you sure you didn't loose a wire connection from the New Image output on OverviewInit.vi to your shift register somewhere along the porting to your new computer?
06-16-2015 08:00 AM
rolfk escribió:
One thing that could neck you is the image type used. Depending how your interface for the camera is configured for the camera you may end up with a different image type than what you later try to extract (U8 greyscale). What image type does your OverviewInit.vi show?
Also try to explicitedly allocate an image with IMAQ Create before the loop and connect it to the shift register. Use the image type returned from the OverviewInit.vi to determine the type for the IMAQ Create Image Type input.
WAIT! Are you sure you didn't loose a wire connection from the New Image output on OverviewInit.vi to your shift register somewhere along the porting to your new computer?
Hi Rolf, thank for the note. We are sure the image type is U8 greyscale as it is the output given by the property node IMAQ in Overviewinit.vi, when the program is running and displaying a image in real-time.
Also in Overviewinit.vi we create an image with IMAQ Create using the image type gyven by the property-node. The output of IMAQ Create: "New Image" is connected to the shift register in "Prueba_solo_camera.vi".
We are sure there are no loose wire connections from the New Image output to the shift register.
more ideas?
Julene
06-16-2015 08:16 AM
Hi, we just noticed that another vi from the Vision & Motion / Image Processing / Processing palette : IMAQ Equalize also produces a crash of labview, just in case this provide more clues...
06-16-2015 10:14 AM
You can't use a 32-bit dll in a 64-bit application. This applies to anything, not just LabVIEW.
06-16-2015 12:50 PM