LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

executables from code using IMAQ for machines not using IMAQ

Im working on a multifunctional piece of camera software.
This software is able to perform several operations on USB cameras and is also capable of using analog cameras via the 1409 framegrabber.
When I compile an executable for a target machine (I have the vision deployment engine) I run into trouble after installing.
I will be informed that IMAQ.DLL is missing.
After looking around I found that this is because I have not installed IMAQ on the target machine.

Is there any way of circumventing this?
I would like to build an executable which detects if the target machine has IMAQ installed.
And if it does not (because it has no framegrabber and thus no need for IMAQ) ignores the VI's from the IMAQ library.
These VI's are never called anyway because not framegrabber is present to respond to them.

The program uses two or three case statements to check for the presence of a framegrabber and disables all framegrabber options if not present.
0 Kudos
Message 1 of 7
(3,991 Views)

try this:

encapsulate all your IMAQ stuff in a single VI, load this vi dynamically and get the property Execution->State. If the value is "Bad" IMAQ is not installed, if "Idle" IMAQ is installed.

 

Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 2 of 7
(3,990 Views)
Thanx for the quick reply.

But I do not entirely get it.
How does this prevent the program from looking for the required vi's that are in imaq.dll?

0 Kudos
Message 3 of 7
(3,987 Views)
well, the encapsulated IMAQ-stuff VI WILL actually search for the IMAQ functions when you open a reference to it. If IMAQ is not installed, then this VI will be broken. BUT: you are still able to open a reference to this VI and read its execution state to determine proper installation of IMAQ. your app that opens the reference will therefore NOT be broken.
 
remember that you have to call the IMAQ VI dynamically to avoid any calls to IMAQ outside the encapsulated IMAQ-stuff vi.
 
another solution would be to create a dll in LV that does all your IMAQ-stuff. then you could create a dll for platforms with IMAQ installed and one for those who have not. its then up to you to deliver the correct version of the dll with your app.
Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 4 of 7
(3,985 Views)
So will this prevent labview from generating a whole series of errors while starting the program?
Because that is not acceptable.

And what do you mean with calling a vi dynamically?

The option I'm currently thinking of is putting all of my IMAQ using VI's in a separate directory and making a duplicate directory with all of the same VI's in there with the IMAQ content removed. That way I could swap directory names before compiling.
0 Kudos
Message 5 of 7
(3,982 Views)

hi there

i attached a simplified example. i don't expect any dialogs for missing VIs or dlls. what could happen is that it takes a while until the property node returns the execution state, depending on the number of calls for missing VIs or Dlls. maybe you could create a VI with only one single IMAQ-VI and then determine the existence of IMAQ by calling this VI. if it takes too long you could save the result of the test to an ini file and skip the test at next startup.

Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 6 of 7
(3,972 Views)
Hi,

Thanks for the example. I'll have a try doing it this way.
Now I think I understand what you mean.

regards,
Arend
0 Kudos
Message 7 of 7
(3,956 Views)