LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

timed loop modes

I'm trying to use Timed Loop to monitor and eliminate the missing iterations because my program can not finish on time once in a while. What I want the program to do is that if the program can not finish on one iteration, don't wait in the next iteration but to keep on processing it. There will be a good chance the program will catch up in the second iteration. I'm trying to study the example which comes with LabView "Modes for the timedloop". In the example, what I saw is only if we set the mode as "Discard missed period, maintain original phase", then not only it keptthe phase, but also processed the missed period. All the other three didn't process missed period and didn't maintain original phase. All the four modes are listed below:
 
Discard missed period, ignor original phase
Process missed period, maintain original phase
Process missed period, ignor original phase
Discard missed period, maintain original phase
 
Any one can explain it to me about the modes' meanings? Thanks in advance,
 
Guangde Wang
0 Kudos
Message 1 of 10
(5,197 Views)
Hi Guangde,
 
Thank you for contacting National Instruments.  I believe I understand the behavior that you are trying to achieve with the Timed Loop structure.  However, in referencing the VI that you mentioned, the behaviors that are best described in the LabVIEW help.  From within LabVIEW Help, the possible behaviors, and those present in this VI, are explained in the 'Configuring Timed Loops' article.  Here it discusses how to set the mode of a Timed Loop, and the possible methods LabVIEW can use to handle late execution.  In referencing the explanations at the bottom, I believe the method you are looking to obtain is to process missed periods, and maintain original phase.
 
I hope this helps!  Let me know if you have any related questions or need additional clarification.  Have a great day!
 
Jason W.
National Instruments
Applications Engineer
0 Kudos
Message 2 of 10
(5,164 Views)

Hi Jason,

Thank you for responding to my messege. I have already read the references you mentioned, I think I understand what these modes mean, but just their behavier is not what I expected, or I just don't know what it's doing. it's true that my intention is to process missed periods, and maintain original phase, but if I set it in the example program, it's not the kind of outcome I expect. How it can run even faster than the sending loop? If possibe, please give me some detailed explanation.

Best regads,

Guangde Wang

0 Kudos
Message 3 of 10
(5,157 Views)
Guangde,
 
From my understanding of the example program that we are working with here, the 'process missed periods and maintain original phase' is behaving as follows.  By double clicking on the time loop structures, you can verify that the loop period for each loop is 100ms.  By setting the receiver mode as mentioned above, the receiver loop will receive the values from the queue as they arrive, but when it experiences the software delays in this program, this setting allows for the receiver loop to iterate multiple times during the loop period of 100ms, in order to catch up and empty the queue.  The sending loop remains on the 100ms loop period and thus is not populating any additional values during this time period, while the receiving loop is running numerous times.  This empties the queue during one iteration of the sender loop.  This is because the processor is able to process a large number of these fairly simple loop iterations within 100ms.
 
I hope this helps in describing the behavior of this loop mode.  Let me know if you need more clarification.  Have a great day!
 
Jason W.
National Instruments
Applications Engineer
0 Kudos
Message 4 of 10
(5,136 Views)
Hi Jason,
 
Thank you for your response.
 
I have been trying to understand the example the same way as you explained. The problem is, we set it to keep the original phase, not just try to catch up like crazy. If the receiver loop processes the missed iterations and get some zeros, it's understandable, but it's not surposed to move far ahead and finishes a lot faster the the sending loop. What I expect is the two loops finish at the same time, the receiver loop does some catch up after the delay, but after it catches up the same number of cycles, it should slow down and keep pace with the sending loop. Two loops should reach the end at the same time. Is it a reasonable expectation?
 
Best regards,
 
Guangde Wang
0 Kudos
Message 5 of 10
(5,132 Views)

From my understanding, all of the 'catching up' is done in the time of one loop cycle of the sender loop.  After this catch up has occurred, the two loops put in and take out points at the same rate until reaching the end of the samples at the same time.  I think your description and expectations match the behavior of this VI with these settings.

Regards,

Jason W.

 

National Instruments
Applications Engineer
0 Kudos
Message 6 of 10
(5,113 Views)
It depends on how we set the intial delay. If we set the initial delay long enough, such as 100, then the receiving loop runs a lot faster than normal. On the other hand, if the initial delay is low enough, then the two loops run at the same pace except the catchup period which is the expected behavior.
 
Best regards,
 
Guangde Wang
0 Kudos
Message 7 of 10
(5,109 Views)

Guangde,

I have set my initial delay to specifically 100ms and 10000ms, in case you intended 100 loop iterations, and still see the expected behavior.  The only irregularity that is present is if you sent the initial delay to be large enough that its delay encompasses the delay that is present at the tenth iteration.  The receiver loop then has to overcome both of the delays.  However, neither setting affects the rate at which the receiver loop runs after it catches up, or the fact that both loops finish at the same time.

Jason W. 

National Instruments
Applications Engineer
0 Kudos
Message 8 of 10
(5,083 Views)
HI Jason,
 
Probably we are talking about different things. I'll attach this program and you see whether they will reach the end at the same time. You can just use everything default.
 
Best regards,
 
Guangde
0 Kudos
Message 9 of 10
(5,052 Views)

Hi Guangde,

It looks to be the same VI that I am using as well.  The only differences appear to be the point at which the delay is introduced, and a graph indicator was added.  I went ahead and ran it just as it is posted here on the forum, and received the expected behavior.  The receiving loop is programmatically delayed at the 50th iteration, but runs 1 for 1 with the sending loop on both sides of this delay period.  The loops also finish at the same time according to the items sent/received indicators.

Jason W.

National Instruments
Applications Engineer
0 Kudos
Message 10 of 10
(5,037 Views)