Parallel while loops, data acquisition supersede user interface

[LrAssyCtlEng]

In my app I have two while loops, one for the acquisition through fire wire port and analysis of the data, the other for user interface.

If during the acquisition, the user interface is clicked on by the mouse, part of my data from the acquisiton is lost.

The acquisition is a triggered event, waiting for a digital input from automation.

Is there a way to change the priority of the user interface loop during the acquisition?

[xntricity]

Hi,

The only thing I can think that may be causing this is perhaps a lack of buffering on your data acquisition device, possibly combined with a resource-intensive user interface. This could be causing your data to be over-written before your program has had a chance to use read it. It would help greatly if you could post your code.

A solution might be to use input buffering on your daq device if it has this feature and perhaps using an event triggered user interface to free up the system resources.

Regards,

Andy

[LrAssyCtlEng]

Andy

Thanks for the reply.

It is kind of an intensive project, with 3-D graphs and charts of different sorts.

At this time I can not release the source code.

However, I did come across some other problems that other people have had concerning Parallel While Loops.

The one that kind of stuck with me was one that there was a sync problem between the two loops.

For some the while loops would run in erratic cycles, one would run more cycles than the other.

The suggestion to him was to place a wait timer in each while loop with zero value.

This somehow allowed the while loops to even out their processing time.

So, with this in mind, I placed wait timers in each of my while loops.

There were no wait timers in any of the while loops, becuse we wanted this process to run as fast as possible.

On my anylisis while loop, I used zero for the value, but, in my interface loop wired in five hundred.

Also, within my anylisis loop, there was the loop where the acquisiton took place until so many scans had been acquired then terminated that loop, also placed a wait timer with zero there.

Before these changes, I was only able to acquire about 210 profiles per second, the unit in this mode should be able to output up to 400 profiles per second.

Now, I am getting right at 350 scans per second.

I still have the issue with when the mouse is clicked on the interface, it sometime misses a few scans and gets caught up in the acquisiton loop.

I have another way of aborting that process with out terminating the application.

But, this is a problem for the operator, because we do have several tabs with different information, for different failure modes or setup parameters.

When they change tabs to see what may be their problem, or are curious, it gets locked into the acquisition.

Not sure if this is turning into a windows resource problem now.

I am using an Acer desktop, 1.80GHz, 896MB Ram, XP Pro Ver2002 SP2.

Thanks

Martin

[Claire_Reid]

Are you hoping for the Parallel While loops to be synchronized? Because multiple loops run asynchronously. They are usually opened in different threads, that the operating system usually decides on. So the time that the loop takes to run is dependant on how much priority it is given

[LrAssyCtlEng]

Claire

During the acquisition portion I would prefer for it to have priority. approx 6 sec.

But, because of various situations, don't want to lock out the functionality of the interface.

That is why my interface loop I have a value of 500 tied to the wait timer and zero on the acquisition.

This seems to allow my acquisiton more processing time.

Because we have only 2 to 3 seconds between acquisitions, odds usually are the interface is clicked on during acquistion.

Thanks

Martin

[Claire_Reid]

Hi Martin,

It is hard for me to figure out exactly what is going on without seeing a screen shot of your code. What does the user interface have on it?

[LrAssyCtlEng]

Claire

Because of the nature of this application, we are doing a 3-D scan of a connector using a line laser.

So, we have eight tabs of information, five of which has graphs, one is the 3-D display.

Two of the other pages are setup info, number inputs, then a page of three arrays, one bool, two number.

All of the graphs are updated at the end of the analysis.

I have 1G of Ram, but, looks like 128M of it is shared for Video.

The only assumption that I can make at this time is, since the Video is shared, when the interface is changed, the Video update is taking up processor time that we need for the acquisition.

Because, otherwise we are acquiring as fast as the hardware is sending the data.

Thanks

Martin

[Ben]

Let me echo the others when the said "we can be of only limited service without seeing your code".

So I'll throw out some idea based on what you have said.

Since putting in waits have helped it sounds like your UI threads (single threaded) is the bottle-neck. "Still guessing" ... the reduced number of swaps to the UI thread has "reduced the traffic trying to use that exit".

The DAQ loop should not have any dirrect interaction with the FP. No Indicator updates of any kind (no terminals locals property nodes etc and definatly no globals!)

Ben

[kehyler]

Did you ever solve this problem fully? I am having a similar problem in my Labview code.

[[dk]]

kehyler,

I saw that you posted your question in a new thread and received a solution. I just wanted to make sure that all your questions regarding this topic were answered thoroughly. In the future, I would recommend creating a new forum post for any questions you may have, so that more forum users will be able to view it more easily and help to get to the solution you need.