Need to improve speed when graphing large arrays

[eweltmer]

Forgot to attach the images.

Earl

[eweltmer]

File size limitation image posted.

Thank You,

Earl

[Kevin_Price]

I'd like to ask a couple of "big picture" questions.  Without LV 8 or IMAQ, I can't look at the code now, and even if saved back a version I'm not sure how much I could figure out on my own.  I'll take a shot though if you can save back to 7.1.

1. I'm unclear on the specifics of your "trigger miss."  I'm thinking that triggering the capture of an image line is itself done in hw.  What is the minimum necessary software to execute between one line capture and the next?  How much time is available from the end of one capture to the beginning of the next? 

2. Is the hw inherently restricted to buffering 1 line?  Can the hw be configured to buffer up a few consecutive lines?  Then the software can read out whatever # of lines are available?

3. Why must the image data be put into LV array form?  It seems that this is where data gets copied and CPU gets consumed.  The fewer conversions and copies between LV arrays and IMAQ images and front panel graphs the better... 

3. Re: "CIN's".  I think that compiling to DLL would be a simpler route with few (if any) disadvantages.

4. You wrote:  ...Your analysis of the "C" code operation for handling arrays is exactly what the NI people have said: "C" writes directly into specific memory locations hence the speed...    This may be part of the speed issue, but I wouldn't guess it's the biggest factor.  I would guess that under the hood, LV writes pretty directly as well but also enforces bounds-checking.  Safer, but a bit slower. 

The bigger potential speed gain is for a very different reason.  In C, 2D arrays can be abstracted into non-contiguous memory.  Also, entire 1D arrays ("lines") can be abstracted into a single pointer.  As long as you stay in pointer-land (i.e., outside of LabVIEW which doesn't let you manipulate data indirectly via pointer), there are many efficiency gains possible.

Thus, an image-manipulation library can conceivably be made much more efficiently in C than LabVIEW, but it will need to be built up carefully to take advantage of such potential. 

I'm anticipating my 5000-char limit before long so I'll continue in another post...

-Kevin P.

[eweltmer]

Hi Kevin,

In response to your questions:

1. I'm unclear on the specifics of your "trigger miss."  I'm thinking that triggering the capture of an image line is itself done in hw.  What is the minimum necessary software to execute between one line capture and the next?  How much time is available from the end of one capture to the beginning of the next?

You are correct, the triggering is done in hw (TTL pulse). The minimum necessary software are the same for LV7 & LV8 although LV8 uses DAQmx: AI config, AI trigger,AI Start, AI read,AI stop, etc. Of course, the AI read is in a loop. The time available from one captured line to the next varies but can be made to  be in excess of 10ms depending upon clock rate & number of samples.

2. Is the hw inherently restricted to buffering 1 line?  Can the hw be configured to buffer up a few consecutive lines?  Then the software can read out whatever # of lines are available?

Yes the hw is limited to one line & special hw can be manufactured to store more than one line but this is not desirable as it makes the DAQ card redundant & unnecessary. We have considered making special hardware using counters, memory & a DSP but felt that all the necessary hw is available with the NI cards albeit one line at a time.

Instead of buffering using hw we buffer using sw in a for loop.

3. Why must the image data be put into LV array form?  It seems that this is where data gets copied and CPU gets consumed.  The fewer conversions and copies between LV arrays and IMAQ images and front panel graphs the better...

You are correct, the image data does not need to be put in an image array as IMAQ has it's own storage but we seem to have better stability in the image Acquistion if we beffer using a 2D array. See the previous pictures.

3. Re: "CIN's".  I think that compiling to DLL would be a simpler route with few (if any) disadvantages.

You are probably correct but I don't know that much about the functions of the available dll's.

4. Your analysis of the "C" code operation for handling arrays is exactly what the NI people have said: "C" writes directly into specific memory locations hence the speed...    This may be part of the speed issue, but I wouldn't guess it's the biggest factor.  I would guess that under the hood, LV writes pretty directly as well but also enforces bounds-checking.  Safer, but a bit slower.

You are probably correct. I am relying on other, more experienced programmers.

I understand NI is "redoing" IMAQ. It would be interesting to see what they come up with.

Earl

[Kevin_Price]

... started outlining stuff, but had to run.  Will get back to this soon...

-Kevin P.

[eweltmer]

No worries.

We can close this thread out as I think we have explored the possiblities.

Many thanks to (almost) all for their constructive input.

Earl

[Kevin_Price]

Actually, your other post made clear that the raw data capture is being done with some kind of DAQ board using DAQmx.  So it sounds like any use of IMAQ inside the data collection loop isn't so much necessary, but maybe is just for convenience of using optimized(?) functions.  In any case, could you back-save to 7.1?   DAQ boards are much more up my alley than IMAQ stuff.

Also, what specific DAQ board(s) do you have available?  My main hangout on these forums is counter/timer hardware.  Many times they can be used to drive an AI task in ways that couldn't be done with AI task settings alone.  If you've got a mutlifunction card, there may be some possibilties...

You mentioned 10 msec from one 2400 pixel grab to the next.  Could faster A-->D hardware help you?  Is any of the time spent acquiring the 2400 pixels "wasted" just because of A-->D or multiplexing speed limits?

Otherwise, you're dealing with 240,000 pixels/sec.  Not slow by any means, but it doesn't seem outrageously fast either.  My gut reaction is that it *feels like* it should be possible somehow.

Have your tried reading raw unscaled values from the A/D board rather than arrays of doubles or waveform datatypes?

Not ready to give up yet...

-Kevin P.

[eweltmer]

Hi Kevin,

I have tried different DAQ cards within the E & M series.

These are multifunction cards that have several input channels but the input channels are multiplexed.

Near as I can tell the critical timing issues are not the DAQ card but the limited time for the card to recover from the acquistion to the next trigger.

If you look at  Reply No. 31 to altenbach I have tried to change to a U32 but this screws up the timing which doesn't make any sense. Computers generally are able to handle U32 better than DBL.

What is even more unusual is that after several hours the system locks out at times and/or the display is distorted.

I have the proper Stop & close icon & have started & properly stopped the vi but to no avail.

I have even closed out LV & reopened the vi with the same results.

The only thing that allows it to resart is resetting the computer.

I have added an extra Stop vi in the loop.

I have tried to save the code in LV 7.1 but apparently I am unable to do so as LV gives an error.

Looks like the DAQmx functions have something to do with this.

Sorry but  I will ask.

Regards,

Earl

[eweltmer]

Shane,

If you are still listening to this post, I have been thinking about the events that have transpired & they seem to revolve around Mark's in ability or unwillingness to confirm my conversation with him. Well, he didn't deny it either but I was speculating about NI's reasons for this. It may be that as NI employees, they are reluctant to say anything potentially derogatory about their product in a public forum. This makes sense as any Competitor can advertise & quote the derogatory comments made by NI's own employees.

But this does not give you the right to insinuate that I am a liar, especially when I have tried to move on & suggested that you can call NI directly. In case you have forgotten NI's toll free number is (866) 275 6964. As far as the 30+ pages on handling arrays, as I have suggested do a search for "large arrays" & you will find 30+ pages on the subject many of which large arrays slow the computer down.

I am sure that you are a capable programmer but sometimes being a better human being is more important. I have tried to apologize, even though it was not necessary, only to be met with haughtiness.. You are not the NI discussion forum monitor.

As this is my first post, I have found that most of the people have (or tried to be) very helpful & I am grateful.

I am only following up on this in the hopes that in the future your threads are handled differently.

Given our history, I know that you will not assist but as I have said "I don't care". I generally don't post anyway. For my part I could have handled things differently but I tried to apologize & concentrate on the code as was the intent of this forum.

Earl

[Kevin_Price]

Near as I can tell the critical timing issues are not the DAQ card but the limited time for the card to recover from the acquistion to the next trigger.

This actually sounds like good news to me.  Especially if this "recovery" involves stopping a task and restarting it to prepare for the next hw-triggered analog acquisition.  There's a good chance that one of the extra capabilities your 2 on-board counters can provide is EXACTLY what you need.

Here is a link to an old example that shows how to combine counters with AI to accomplish a retriggerable finite AI acquisition task that requires NO reprogramming time between triggers.  There is also a picture of a DAQmx implementation here (see the Synchronization section), though the text around it is meant to play up the advantages of an FPGA.

If you look at  Reply No. 31 to altenbach I have tried to change to a U32 but this screws up the timing which doesn't make any sense. Computers generally are able to handle U32 better than DBL.

Yeah, I'd seen that, but am not sure I have a clear enough picture of the whole program architecture to speculate on what might or might not make sense.  I only know that some of LV's built-in functions support only a limited set of datatypes (like some handle DBL's only).  If any of those get called, then the swtich from DBL to U32 could require tickling the memory allocation functions every loop iteration when the values are converted.  There could be other things that make sense of it, or it could be a head-scratcher for me too.

I have tried to save the code in LV 7.1 but apparently I am unable to do so as LV gives an error.  Looks like the DAQmx functions have something to do with this.

Hmmm.  Wouldn't want to guess.  But I haven't seen a lot of difficulty for people back-saving DAQ apps around here, so it's probably a solvable problem.  Maybe someone else reading the thread could (would) do it?   I'm guessing the best candidate to back-save would be "Image Capture 9a.vi" found here in Reply 31?   If there's a better version to convert back, could you please post it?

-Kevin P.