Need to improve speed when graphing large arrays

[eweltmer]

Hi Kevin,

I think I have sucessfully saved a version for 7.1.

This is an earlier version so it may have some problems in coding.

Anyway, I think I may have solved some of the issues.
Strangely enough, after running the ap all night, I came in & found that the digital port reading the count was mis reading the line counter. The counter was general incrementing but the delta was not consistent.

I copied the port read functions to another vi with no problems. I also closed & reopened the ap & the problem persisted. I also closed down the ap (as oppossed to halting) to properly erase & close the task functions.
It was only resolved after closing LV & reopening.
Checking with NI, they acknowledge that this can be a potential problem & wanted to see my code.

Earl

[altenbach]

I don't understand how you can correlate the digital port read with the acquired lines at all, since the two loops run independently and there is only a variable sized queue linking the two loops.

[eweltmer]

Dear Altenbach,

You are correct. There is no sw connection between the two. The connection is done with external hardware.

In the initial code we had a line counter that would increment after the acquistion of every line(s). We would then reset the line counter after receiving a hw trigger from the equipment (frame or vertical reset). The problem was that we had problems reliably detecting this pulse. Sometimes the picture would continue far past the intended frame in a large array or reset to the top depending upon what sw scheme we chose. We would also get a "shift" in the vert position between frames. This is not good especially when we were considering a frame average routine. I thought it was from the timing of the vertical reset so I installed an hw counter to keep track of the line number then read this number for line position.

The 12 bit counter is a CD4040BE. I hardwire the AI trig to the clock & the Vert reset to the reset lines. The output is connected to the DAQ port read.

While I am on the subject, I need to "crop" the borders of this image. I am sure there is a vi that does this. I would also like to correct for the mistriggering where I get a line that is empty. I think the best scheme is to add the array elements to detect an empty line & if it equals zero to replace it with the previous line. Anyone have any ideas?

Earl

[Kevin_Price]

I had a chance to try to take a quick look today, but the file "Image 13.llb" you posted is still version 8.01

-Kevin P.

[eweltmer]

Hi Kevin,

Sorry haven't gotten back sooner.

I am getting together with one of our programmers this weekend & will ask him to save for the earlier version.

I thought I did ad it is the same version used by our programmer, 7.1

Best Regards,

Earl

[minnellac]

Kevin, I'm guessing that you can open the previous llb posted by Earl (Image 13.llb) as long as you click okay to the warnings. I tried to save for previous as well, and I ran into some problems. For some reason LabVIEW is refusing to save a few vi's because it thinks they are from a toolkit. I'm not sure why that is, as it looks like they are just DAQmx vis. Anyway, I've included an image of the AI Read config.vi, which is probably the important one to look at for the moment. I don't have the vision toolkit, so I wasn't looking at a functioning program, but I'm pretty sure we can sort out the bit about it skipping lines. I also included an image of the main program (Image Capture 13.vi) that I cleaned up enough to get on a screen (Earl, I'm guessing you've got a sweet 30" screen..).

So, Earl, I think you are a little to willing to accept problems as limitations of LabVIEW (but you are here, so maybe I'm wrong). Anyway, I'm just jumping in, but the first thing we can address is the missing lines. btw, your approach to replacing the lines may work, but I'm not ready to accept that that is necessary. I think we need to get the Start and Stop AI functions out of the loop. You want to just start the acquisition once, and then Stop it at the end. I'm not clear exactly what you want the acquisition to do. From reading, I thought it was acquiring 2400 points (one line) on each trigger, but the AI Read config doesn't seem to be set up that way. I probably misunderstood something. Anyway, it should be achievable doing retriggerable finite acquisitions. If you can describe specifically what you want from your M series card, I can try to rig up an example that does that part of the program.

There's more to say, but I'd like to make sure I'm not completely on the wrong track.
Hope this helps,
Chris

[eweltmer]

Hi Chris,

Thanks for the help.

Earl

[eweltmer]

Hi again Chris,

Thanks for your response.

There may be a little misunderstanding concerning my willingness to "accept problems as limitations of LabVIEW". I really wasn't. If you read the thread, I defer to a more experience person (my LV programmer)when I had the time to see where the problem was. I was trying to determine the problem as opposed to blaming Kevin or LV. In the meantime, I had surmised that it was my own inexperience.


One of the nice things we have here is that I can ask NI but I usually ask if I have a serious problem or I can ask one of the programmers we use for a trivial problem. I had intended to take the publised llb to another LV version to see if it opened.

In the prior thread concerning Arrays was confirmed by NI & our experienced programmers.

Anyway getting back to the code, I will post the code portion due to the 5000 word limitatiion.

[eweltmer]

Chris,

Concerning the code.

As I have mentioned in the prior threads, this is one of several versions. Each was an attempt to minimize the line mis-triggering.
This project has been somewhat frustrating, not only for me but other much more experienced programmers (15 years +).

We would try something but by the end of the day the lines would increase. Finally I decided to let the application run overnight & got the attached picture. Instead of skipping lines we would get whole portions missing. In troubleshooting the code, I found that the line counter was not counting properly & somehow the AI trigger was interfering. I recopied the line count code onto anther vi & it worked perfectly. I also went into MAX & reset the card & also closed them re-opened my application. No dice. The only thing that worked was closing LV then reopening. I suspected that I did not close a file or I/O properly.

One of the nice things we can do is check with NI or one of my programmers with as I am a beginner programmer. NI suggested that I move the Start vi outside the while loop. Doing this caused the application to stall. Moving the Start & Stop vi's outside the for/next loop also stalled the app. I sent NI my code & they suggested that I use an updated driver for DAQmx at:

http://digital.ni.com/softlib.nsf/websearch/D31D46FFFB745ECA862571490053EAB8?OpenDocument

Updating the driver seem to work as I don't get the bars after overnight operation.

I haven't tried to move the vi's after the installation of the new drivers.

The upshot of all of this is that I am very reluctant to blame anyone including LV but I will look & ask people who more experienced in a given area than I.

In this case the problem appeared to be a "bug" in LV8 which was confirmed by replacing the drivers.

Earl

[eweltmer]

Forgot the attachement again.

Earl