LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed Loop not executing contents but CPU 97%

Hi,  I have a timed loop inside a while loop, a simple VI but the contents of the timed loop don't get executed and the CPU gets taken over.
 
I have attached the VI.  I know it's something simple but knowing me I'll be banging my head against a brick wall for days if I don't ask the question first.
 
The offending VI is attached.  Version 8.2
0 Kudos
Message 1 of 8
(4,812 Views)

You have a user control wired to the dt input of the loop.  This is very uncommon.  The default for the control is 0.  So if you run it like that, you'll have something similar to a normal while loop with no wait statement in it.  Essentially running as fast as it can eating up all the CPU resources.

Also, you have a 0 in the Processor node.  I would leave that at the default of -2 unless you have some very good reason for assigning the thread to a specific processor.

How do you know the inner timed loop is not running?

0 Kudos
Message 2 of 8
(4,803 Views)

Sorry, I only program occasionally in LabVIEW.

Sorry, I am having trouble understanding concepts of Timed loops.  According to the help, dt is the period of the timed loop.  I thought I should be able to wire a number to that and that would define how fast the loop goes.  I don't see why that should be uncommon.

You say "you have a 0 in the Processor node" .  I looked up LabVIEW help and can't find any mention of  a Processor Node.

0 Kudos
Message 3 of 8
(4,795 Views)
You can wire a number to the dt node.  But it is uncommon to wire a control to it.  And the default value of that control is zero.  So unless you are putting a value besides zero into that control before running the loop, I think you iwll have a problem.  Try turning that control into a constant and make it something besides zero and see how that works.
 
Never mind about the processor node.  You can see it in the attachment.  It shows up in LV 8.5.  But now I see you are using LV 8.2 where it doesn't exist.  When I opened it in LV 8.5, it put a zero while the default value is -2.  According to the help, -2  means let Labview automatically assign a processor, 0 means let Labview assign the first available processor.  I though a zero was a bad value to assign, but it is all moot anyway because you are using LV 8.2.
 
If you are still having problems with the time loop.  Try turning it into a regular while loop with a wait until next ms function placed inside.  Timed loops are a little bit more advanced, and I think there have been occasional bugs with them as well.  Simplifying it to a regular while loop would help show whether there is some other problem, or whether it is something about the setup of the timed loop causing the problem.
0 Kudos
Message 4 of 8
(4,786 Views)
just looking at the picture, your "array of spectra" is just one spectrum right now (the last value that "Spectrum" ends up). Could that be your problem?
0 Kudos
Message 5 of 8
(4,765 Views)
Oops, thanks for pointing that out.  I have made the array a 2d array and turned on indexing but that is not the answer.
 
I have since found out that the VI runs correctly (apart from the above error) when run by itself but when called from another VI with the same values for Integration Time, Sample Time and number of Spectra feeding into it it doesn't work. 
 
By the way, the message in the error indicator on the right hand side which is attached to the Ouput Node Error is code -808 and the source is:
 
Timed structure(s): 112555896L1648<append>
<b>Timed structure(s):</b> L1648
 
I did a search on NI for error -808 and found nothing as far as I recall.
0 Kudos
Message 6 of 8
(4,757 Views)
Hi pgaastra,
 
Please see Timed Loop Error Codes found in the LabVIEW Help for a description of this error. Error -808: "The given name is already being used by the following timed structure." This leads me to believe that more than one timed structure of the same name is being used at the same time. Since you only get this error "when called from another VI", are you setting the subVI as reentrant or do you have another timed loop in your caller VI? I hope this information helps!
0 Kudos
Message 7 of 8
(4,723 Views)

Thanks Mike,

It was the timed loop name.

I had a main VI which called a subvi with a timed loop.  This VI was stopped  and the "offending" VI run from the main VI.  I had based the offending VI on the first VI so the timed loops had the same name.  I changed the name of the one of the timed loops and it all goes. 

It's wierd to have named structures, I mean, while loops, case structures etc. don't have names (that I know of).  Anyway it's fixed and I can carry on.

Thanks again.

0 Kudos
Message 8 of 8
(4,706 Views)