Timing issue with parallel timed loops

[New_user_2500]

I am working on a monitoring application where a timed loop is used to grab images from a high-speed camera via an NI 1429 frame-grabber. The images are then processed within the same timed loop for the purpose of closed loop control. At the end of each iteration of the timed loop, the memory allocated to the image is freed up by an “IMAQ dispose VI”. Each iteration of the timed loop takes 1-2 ms, which is acceptable for our application.

Recently I decided to save the images to the hard disk using the producer/consumer loops concept. The producer loop again grabs images, analyses them, and puts them into a FITO. The consumer loop reads the frames from the FIFO one by one, saves them on the hard disk as a JPEG file and finally frees up the memory allocated to each frame. The problem is that now (with the consumer timed loop running), the iteration time of the producer timed loop increases to an unacceptable level (3-4 ms)!!

I am using an 8-core CPU and therefore didn’t expect to get this problem since I thought each timed loop would be run on a separate core. I am wondering if I have to use a special technique to divide the computation load between different CPU cores or is it done automatically by the OS (in my case XP)? In general, I would like to know if it is possible to save the captured framed on the hard disk without reducing the frame acquisition rate.

Any help is highly appreciated in advance.

[Norbert_B]

Can you post some code?

Norbert

PS: Having more than a single core only profits if the program is able to take advantage from multiple cores. The content of a  timed loop always executes in a single thread, which binds it to a single core (but it can swap to another core from time to time!). Depending on your code, you probable use only two cores of your system. Additionally, file IO might always introduce a bottle neck... did you verify that the FIFO is not running full?

[New_user_2500]

Thanks Norbert for the reply. Please find attached the VI. Yes, I did verify the FIFO, it doesn't even get close to full.

[Norbert_B]

First and most important:

This code is running on a realtime target?

Looking into the code, you definetly have to incorporate some of the LV style guides to increase readabilty, possibly also runtime performance.

You are wasting time and memory for instance by all those auto-indexing outputtunnels in your loop.

You are using improper data types (like extended) where not needed.

Obviously, you have never seen that single shift register can be extended by dragging down the bottom on the left shift register node.

Some of your algorithms can be simplified by a great deal or are possibly not necessary at all.

You are disposing the image reference twice, one time in your acquisition loop, another time in your logging loop. FIFOs are working in place if use properly.

Those are the foremost points of feedback, i hope that you can use them in order to improve the performance.

Norbert

[New_user_2500]

The code is running on a LabVIEW 2009 NOT LabVIEW real-time. The code has been developed over a long time and obviously not very consistent. I'll take into account your comment to improve it. However I still don't understand how I can make the consumer loop run on a different core. As long as the consumer loop is not there, the producer loop runs reasonably fast (despite all inefficiencies).

As for the unnecesary auto-indexing outputtunnels, did you mean the ones on the nested for loop inside the consumer loop? or the one one the producer loop? Do you think replacing the graph with a chart and putting it inside the consumer loop would work faster?

[Norbert_B]

If it does not run on realtime, why are you using RT FIFOs?

I am talking about the outputs of your producer loop, which are autoindexing (e.g. error cluster). This is not recommended.

Putting the graph/chart into the loop will reduce performance additionally.

Norbert

[New_user_2500]

I removed the autoindexing tunnels, moved the chart inside the loop and also replaced the RF FIFO with QUEUE but still no imprevement !!!

[Norbert_B]

As i said, moving the chart INTO the loop will REDUCE performance (so it will get bad).

Have you deleted the "IMAQ Dispose" in the acquisition loop?

Norbert

[New_user_2500]

OK I already put the chart back outside the loop. I had already deleted the "IMAQ Dispose" in the acquisition loop before be previous post

[Norbert_B]

What does your CPU load look like if

- Running only the acquisition

- Running both loops in parallel

?

Norbert