ni.com is currently undergoing scheduled maintenance.

Some services may be unavailable at this time. Please contact us for help or try again later.

Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

IMAQ Vision 7 trouble - probably bug...

Hello, LabVIEWers!

I've got one big trouble in IMAQ Vision 7.0. Probably its a bug, but before asking NI I would like ask you - do you have the same behaviour, or not?
Problem is following: some components sometimes (sporadically) caused unexpected delays in my application. There are some interference and deadlocks in memory. I don't know exactly.
I have tested my VIs on three different computers, and always can see this problem.

This problem was isolated by me. In attachement you can find my test VIs.
Please, if you have also LV7/IMAQ Vision7, then make following:
1. Open !test_1.vi (don't open anoter two at this time!)
2. Run this VI. All running perfect. Depends on your computer speed you can ajust delay in while-lo
op for avoiding 100%CPU load (70-80% will be OK)
3. Now open !problem.vi. I add button for loading this VI dynamically, but problem also occured, if File->Open... will be choosed (just open this VI, don't start it).
4. Now main cycle will be sporadically stopped for seconds. If you computer fast enough, wait a little bit - this problem not repeatable and occured sporadically.

I've got following results:
P-III/733 MHz - every 30-50 cycles for 3-5 seconds
P4/1.6 GHz - every 200-400 cycles for 2-3 seconds
P4/2.0 GHz - every 300-500 cycles for 2-3 seconds
On Dual P4Xeon 3 GHz situation better, but sometimes I have 100-120 ms time instead of 2-3 ms "normal" time for this construction.
It was tested with IMAQ Vision 7.0.0 and with patched 7.0.1. This problem doesn't present in IMAQ Vision 5.0/6.0/6.1

Please, your short test will be very helpful for me!
0 Kudos
Message 1 of 3
(2,995 Views)
I looked at this, and am seeing the same behavior. One thing I tried was resetting the priority of all the VIs to normal. This cleared up the problem. Also I noticed that it seemed to be related to having more than one Vision VI trying to be accessed at a time. It may be that because the !problem.vi was higher priority, the dll was being used primarily by that VI. It's still unclear to me why the dll is in use when the VI is simply open not even running.
0 Kudos
Message 2 of 3
(2,995 Views)
Thank you for the test.
I already had found this trouble with priorities yesterday. Interesting,that enough only loading vi with high priority.
Its not a really "bug", but my opinion, that this behavior unexpected, undocumented and incorrect.
0 Kudos
Message 3 of 3
(2,995 Views)