bad lag in vi using "initialize array"

[altenbach]

---

@Ben wrote:
The initialize array stalls while allocating memory.

---

I seriously doubt that! 😄

A 32x32 fixed array is peanuts. Since the array size is defined with diagram constants, the entire thing will be allocated at compile tme anyway, and no initialization is ever needed at runtime.

[Ben]

" Since the array size is defined with diagram constants, the entire thing will be allocated at compile tme anyway, and no initialization is ever needed at runtime."

But the contents of the buffer are defined from a control.

Ben

[Candice]

I don't know if this matters...but please keep in mind that the FP is lagging even when the program is not running.

[Ben]

Then repsot to the machine vision forum

The imaq stuff runs even when your code is not

Ben

[Candice]

1) After the image is written to the indicator, I destroy it.  The image display is set to "snapshot" mode which means it retains the last image that was written to it, so it doesn't matter that the image gets destroyed so quickly (I think).  This is just the way I have always done it (always = the last 6 months or so since I started using Labview).  If anybody has a better suggestion, feel free to tell me.

2) A general error handler gives no errors.  The FP lags even when the program is not running.

3) ^

4) There are no overlapping elts on the FP. It's easy to keep track of because there are only 5 total elts on the front panel.

5)  not sure

6) I'm not sure if this is helpful considering that the FP lags when the program is in edit mode as well.

Ok I will repost in the machine vision forum. Thanks for all your help.

[altenbach]

---

Ben wrote:

But the contents of the buffer are defined from a control.

---

I wasn't saying that the array gets folded into a constant, just that the memory footprint for it can be preallocated because it will never change at runtime. 🙂

[Ben]

I agree Christian.

I remember taking a performance hit in the Prime Factor challenge due to an initialize array. I filled it away as due to memory allocation. Small or large the call to the OS was still required (I believe).

Ben

[EdDickens]

Don't know if you're still wathcing this, but I've duplicated your origianl code and added some timing code and it runs in about 20 mS for me with Snapshot disabled. If I enable Snapshot mode, the code still runs in about 20 mS, but there is indeed a delay in updating the front panel. I also see the delay go away without the init array function in there.

My best guess would be that not passing an array into the IMAQ VI is the difference. I can vary the delay by changing the size of the array to initialize. The larger the array, the longer the delay. It seems the data that it needs to process, the longer it takes to update the front panel.

Maybe the IMAQ experts will have better insite as tho what's going on and how to handle it.

This is on LV 8.2.1, IMAQ 3.7.0 running on Win XP SP2 on 2 GHz Centrino Dell laptop.

Ed

Message Edited by Ed Dickens on 07-26-2007 11:16 AM

[Candice]

Thanks for your input.  I don't think the problem is passing such a large array into the IMAQ function b/c there are several other places in the larger program where I pass a 32x32 array into the function and there are no issues.  That's what makes me so certain it's a problem with the init array and not the IMAQ vi's.  However, I have posted in the Machine Vision forum and have my fingers crossed.

Thanks again!
Candice

OK in case anyone ever searches for answers in this thread...problem solved. A coworker of mine showed me that the problem lies where I am expanding the image from a 32x32 to a 1024x1024.  It's doing calculations on single floating point numbers there, which bogs down the processor.  Furthermore, the display is only capable of 8-bit data so it gets converted to U8 before being displayed.  Using IMAQ Cast Image before expanding the image solves the problem.

[Ben]

Thanks for the update re:the solution!

Without it, Christian and myself would have to arm wrestle to settle this mystery.

Ben