Different behavior with timed loops and regular while loops

[InfiniteNothing]

I'm trying to run two cameras at different rates which requires parallel execution. It seems like with a timed structure, the two cameras run is series and without the timed structure. I was wondering why. See attached VI that shows this behavior. The outputs are the loop interval time of the camera aquisitions. In the timed structure the loop interval changes to the slowest camera interval.

[Chris_VH]

Hey Infinite,

I'm not sure I totally understand what you are asking, but I do have one thing to say. Using a timed loop in your case really does nothing for you. There is no benefit of using it over a while loop with a 1000 ms wait. You have not assigned a processor to run off of, nor have other timed loops to compete with in priority.

That might be unrelated to your question, but if you could just reword your question

"It seems like with a timed structure, the two cameras run is series and without the timed structure"

we might be able to help you more.

[InfiniteNothing]

In the real application the timed structure is used as part of a state machine where one of the states runs code similar to what's in the "2CamGrab500images2.vi".  Also, in the real application there is a parallel loop that runs at a lower priority. I was trying to simplify the VIs as much as possible where I could still show the problem occurring. 

To reiterate the problem, if you run the  "2CamGrab500images2.vi" inside of a timed loop like in "Use Timed Loop" case of "Test case for problem.vi" the two image grabs do not run in parallel. That is, if I trigger cam 0 at a rate of 20 Hz and I trigger cam 1 at a rate of 50 Hz, the loop will get to the "IMAQdx grab" for Cam 0, wait 50 ms. In this time, Cam 1 got two triggers. When "IMAQdx grab" runs in that lower loop, it completes instantly and retuns an image and then the top loop starts waiting again. The effect is that both loops run at the slower rate of 20 Hz. 

I included the case "Don't use timed loop"  in "Test case for problem.vi" to demonstrate the behavior I'm trying to get. The two "IMAQdx grab" VIs for both cameras run in parallel and both loops in "2CamGrab500images2.vi"  excecute at the frequency of their respective cameras.

I'm not sure if it's relevant but I'm running the VIs on a PXI-8106 controller running Labview Real Time. 

Message Edited by InfiniteNothing on 01-09-2009 10:14 AM

[Chris_VH]

Infinite,

Thanks for the clarification, it makes more sense now.

Are you seeing this problem in the actual image, or on the graph of tick count differences? Because even though the cameras are set to take frames at different rates, LabVIEW will still follow dataflow and wait for BOTH cameras to exit their loops before the sequence structure finishes. And since you have your image displays outside of the structure, it is expected that they will update at the same rate. 

However, if you are seeing large differences in the tick count graph, we'll have to try some other things.

On a side note, I just hooked up a firewire camera (only have one right now) and I see how the graphs are entirely different when using the timed loop as opposed to either a) just opening the subVI and running it or b) NOT using the timed loop.

Message Edited by Chris_VH on 01-09-2009 12:46 PM

[InfiniteNothing]

The images are fine. I was actually only using those images to make sure both cameras were runnning.

The tick count graph is one of the places I saw the problem. I can also "see" the problem if I use the execution trace toolkit (see attached trace logs)

Message Edited by InfiniteNothing on 01-09-2009 11:03 AM

[BlueCheese]

Infinite,

I see a few issues with your code. Firstly, your two Grab VIs are set to "Wait for next buffer" which will mean that due to timing you may end up missing images on one because the CPU is busy processing the other (essentially when you start waiting for an image determines which image is the next you acquire). This would be most noticible if the two cameras are triggered from the same source at high speed. I'd recommend to ask for an incrementing buffer number instead on each Grab VI.

The second is probably what is affecting you the most and it is that I believe timed loops run in only a single thread per timed loop. This is necessary to achieve the precise timing contraints of each loop. This means that the two Grab VIs (since they block while waiting for an image) will never be able to run truly in parallel. This wouldn't be so bad if you changed to above item of requesting the next buffer such that they don't both block for a frame interval. Instead, one would block for a frame interval, then the next would run and get one or more images immediately if they are available.

I think the bigger question is what you are using the timed loop for... Based on your given example, the timed loop seems to not be useful for this application...

-Eric

[InfiniteNothing]

Missing an occasional frame is preferable to processing old data in my application so I think I like the way I set it up. 

I use the timed loop as the main loop of my VI. In it, I have a state machine. The VI with the two cameras is similar to code in one of the states of that state machine. The other cases of the state machine use the timed structure to limit timing. I could probably accomplish the same thing by using a "Wait until next multiple" in those states.

I also use it for priority though. As I said before, I have a loop running in parallel at a lower priority. Do you know how priority is ranked between a traditional while loop in parallel with a timed loop? 

Does single threaded mean it only runs on one processor of a dual core machine?  Is there documentation on the other implications of a timed loop?

Message Edited by InfiniteNothing on 01-09-2009 02:20 PM

[Andrey_Dmitriev]

Hi, Chris and Eric,

I think you confused a little bit with Grab VIs. But this problem more "common" and not related to vision application.

Let me simplify this example. On the given BD I have two steps, mostly the same. Each one contained two for loops with delay (I have used delay function from kernel32.dll).  The only difference, that in one step "traditional" while loop was used, and another one - timed loop:

Now results:

Can you please explain timing differences now (VI also in attachment)?

regards,

Andrey

Message Edited by Andrey Dmitriev on 01-10-2009 11:00 PM

[Andrey_Dmitriev]

Update:

Have read this topic again, and see, that Eric mentioned that timed loop executed with single thread. That is exaplanation for the behaviour described above.

Andrey.