Re : Re: Re : IMAQdx Open Camera.vi very slow

[DOC-doc]

Hi All,  

 I am using a firewire IEEE1394-a camera with IMAQdx with labview 2009.

1 - I configured the camera in MAX and tested it. It works great.

2 - I used the "Grab and Attributes Setup.vi" from Labview examples. With this vi, it takes around 1 second to find the camera, and works very well.

3 - I copied the "IMAQdx Open Camera.vi" from this example into my own software. When I run it takes around 20 to 30 seconds to open the camera. It finds it but it is extremely slow.

4 - To make a test, I opened simultaneously the "IMAQdx Open Camera.vi" from the "Grab and Attributes Setup.vi" and from my application, configured the same camera name on both clones, and run them one after the other : I still observe the same behavior : the first one (from step 2) takes 1 second to open the camera, while the second one (from step 3) takes 30 seconds to open it, without sending any error message.

I came to the conclusion that there must be somewhere a link to a configuration file or anything that makes the startup faster in one case than in the other.

Did anybody experienced something similar ? / Does anyone has an idea on how to solve this issue ?

 

[DOC-doc]

up... any idea anyone ???

[BlueCheese]

What kind of camera are you using? A large portion of opening the camera consists of reading various registers. Perhaps the camera is in an odd state the second time around? Can you try power cycling the camera in between calls?

Eric 

[DOC-doc]

Hi BlueCheese,

Thank you for your interest.

I don't think that this is not due to the camera : every time I use the step 2 method, it is fine and fast, and every time I use the step 3 method it is very slow... I tried to mass compile, force recompile and so on without any success.

 I can run step 2 method 3 times and it still works fine, then step 3, and slow again., then step 2, fast again.

 It looks like it is waiting until it gets a timeout or something like that because the time is always the same.

Message Edité par DOC-doc le 05-07-2010 05:05 PM

[BlueCheese]

Can you attach a simple VI that reproduces this problem?

Eric 

[DOC-doc]

Well I can't because I soon as I copy the IMAQx Open Camera.vi out of my code it woks fine...

[BlueCheese]

Doc,

The symptoms you've described just don't really add up to anything other than either some camera problem or a problem with your code. Copying the VI out of your code shouldn't affect the behavior of that VI itself. Without more details about the code it is running in I don't know if there is anything more I can suggest.

Eric 

[DOC-doc]

Here are the detailed symptoms : as soon as I save the VI that drives my camera, if I open and run the "IMAQdx Open Camera.vi" it contains, it gets slow. If I run it from another place, it runs normally. To prove it, I added a tick counter in the  "IMAQdx Open Camera.vi". On the left, the one that is not in my own vi, on the right, the one in my onw vi. Please note that my vi is not running, I only run the "IMAQdx Open Camera.vi" vi in both cases.

[BlueCheese]

Hi Doc,

In both cases, they are pointing to the same VI inside of vi.lib, right? Is it possible that the execution thread that your VI that the Open call is set to something different? I believe all our VIs ship as "same as caller", so they will inherit whatever your caller is using. I'm not sure how this would apply if you run it directly...

Eric 

[DOC-doc]

 Hi BlueCheese,

When I look at the Call Library Function configuration screen, I noticed that the configured dll is "niimaqdx.dll" without any other path (see attached image of the capture of the configuration window of the dll call), so it seems to be pointing to a location that does not exists. In my project explorer, the dll seems to be in C:, but it is not of course.

When I click on the browse button, it does not show anything... this may be why I have this problem. Shall the dll be pointing to a static directory like "C:\WINDOWS\system32\niimaqdx.dll" or is this linking done dynamically at the start of the vi to the adequate location ?

I guess that if the link is static it can make problems if I install the software on a non 32 bit system ??? what is your opinion ?