for loop inside while loop

[Cosmica]

To all,

I have a question, I have a for loop inside a while loop. The for loop runs and displays the log data. It seems that until I stop the while loop that the log data is display. It almost seems that the for loop runs until the while loop is stop.

The following attachment is an example of what I have in my code. But, the for loop does run in this example. My code is the same idea, but the for loop seems to run only when I run my program with Highlight execution.Otherwise, it runs after I quit the while loop.

Any inputs?

Thank you,

 Cosmica

[Broken_Arrow]

Is the case statement containing the For Loop being constantly triggered without your knowledge? Use a boolean indicator to check the behavior.

Highlight Execuion will slow down your serial port code and cause different results. We probably need to see the actual code.

Message Edited by Broken Arrow on 06-11-2009 07:43 AM

[Cosmica]

Do you mean an indicator before I check if the Test button is ON?

Thank you,

Cosmica

[jcarmody]

You have a race condition somewhere where data flow isn't being forced.  When Execution Highliting is on the order of execution is (apparently) different than when it's running normally.  If the VI you attached is working then it won't help us troubleshoot your issue.

Jim

[Broken_Arrow]

---

Cosmica wrote:

Do you mean an indicator before I check if the Test button is ON?

Thank you,

Cosmica

---

yes, in other words, first troubleshoot if the case statement is being triggered as you expect.

If you have a serial port read and/or write, be aware that the highlight expecution is making those functions take longer, which is apprently "fixing" your issue. Try putting 100mS delays between all functions.

[Ray.R]

You can also place a probe on the boolean wire just before the case statement to see what value reaches it.  That way, it won't create delays that the highlight execution would cause but still allow you to see the value.  Then you can place more probes to find your way up to the culprit.

Sorry I couldn't look at your VI.  I only have LV8.2 on this PC.

R

[JÞB]

Cosmica,

as we don't have the broken code we can only point you in a general direction.  That being said, I have some observations about your handling of the VISA session and Error chain.

1 Use shift registers.  If a subvi makes a change to the VISA properties the default and input referances become stale and the following functions will error.  This can be a maintainence NIghtmare.  Similarilly, you probably want to pass through the first error that occurs to the following functions.

2 Move the error case structure to to the extreeme outside.  You seem to want no action taken with error in True.

3 Make error in an input to the vi so you can reuse the code from a higher level caller.  

4 VISA close is unnecessary- from the Tools menu select Options, Enviroment, and check "Automatically close VISA sessions.  LabVIEW will handle the resource clean-up when it shuts down and the session will remain valid so you can use it for debugging between calls to this vi.

5 instert a Wait for next ms multiple in the while loop to prevent system hogging. The while loop is running at top speed leaving no time for other operations

6 consider replacing the "test?" case with and event structure and run your loop on event value changed.  This will hold the execution until the operator presses test and execute the code once. Also you could use a property node to reset the tab control to pg 1 to start the next test cycle.

[altenbach · Accepted solution]

I tried your VI and there is nothing wrong the way it executes. Nothing happens until the second tab is selected and the "off" button is pressed, at which time the FOR loop runs until the indicator shows a "9". In subsequent runs, it again counts up to nine, but this is so fast that you will never see it. For the observer, the indicator remains at nine.

Of course you would see things a little better if you would place small waits inside the various parts of the loops. Right now, the VI consumes all CPU doing nothing but spinning empty loops forever while once in a while spending a few nanosecods to iterate the FOR loop. You are also destroying your VISA resource with default output tunnels, so the close at the end will most likely fail. Overall, the code seems overly complicated for what you want to do. Do you really need to tie a case structure to the tab control? Seems unnecessary. The FOR loop should run when the button is pressed, since this automatically implies that your'e on the second tab, you don't need to read the tab control. That's redundant!

[Cosmica]

Thank you all for all your inputs, they are very helpful.

Originally I had an event structure to handle the Test Button, but I do have to run 5 devices simultaneously, and it seem not to work when trying to run all of them.

Would it be wise having an event structure for each of the test buttons?

Thank you,

Cosmica

[altenbach]

---

Cosmica wrote:

Would it be wise having an event structure for each of the test buttons?

---

No, ONE event structure is enough! You can have an event case for each button. 😉

(Of course you should only place the FOR loops inside event cases if it completes quickly.)