One of the VI stops

[Joseph_Loo]

I have several top level VI running within subpanel for a single top level VI under Labview 8.2.1 under windows XP. What happens is that at random, the VI will stop running. What is strange, I have the same program running on another machine and this situation does not seem to occur.

I use the Insert VI within the sub-panel to acitvate the VI.

A snapshot of the block diagram is shown in the attachment.

Is there any way to determine why the VI stops running? I almost suspect it is some kind of scheduling problem. I have about 10 VI running in various sub-panels.

[Joseph_Loo]

Forgot to add the attachement

[Ray.R]

I didn't see your attachment.

What triggers a stop in that sub-vi?  Maybe the condition was met (for some reason).

RayR

[Ray.R]

I quickly looked at your attached image.

You are using a Local Variable and a reference to another vi for your "Run/Stop".  I could not see the top of your While Loop. 

However, if you write elsewhere to the Local Variable (Run/Stop) or you change the values of the boolean within the sub-vi where you are sending the "run/Stop" reference, then the loop could be stopped externally to the loop (or internally with an unseen Local at top of loop). 

Curious... Why are you using a Local Variable for Run/Stop???

Message Edited by JoeLabView on 10-22-2007 11:04 AM

[Joseph_Loo]

It is never suppose to stop. The whole application is a continuous chart recording system.

In the VI I disable the run/stop button and made it invisible.

I frogot to add the attachment in the first message. Fingers are too fast.

[Ray.R]

Wait...  what??...  😉

I need to step back a little and understand what you're trying to do..

Looking at your subpanel-vi.png, you're code will be facing some race condition.

When Run/Stop is true in the upper loop, that True value is immediately sent to the Local Variable is the bottom loop.  So unless the Stacked Sequence Structure gets to the Run/Stop Local variable first, then the bottom loop will stop..

Okay.. now to the reason I tilted at the top of this message....

You are disabling the Run/Stop button and hiding it??  That's probably why you're using the reference...  (deep breath 😉  )

You don't want to do that..  You always want to be able to control (especially stop) any code that you write.  There are tricks out there, but the tricks are to help you regain control of the PC and not the VI 😄   That's why it's a good idea to describe the logic in your approach.  Tell us more about what you are trying to do.

🙂

[Joseph_Loo]

The stack has two previous item. The first one is to generate front panel activity and wait a second. This is to allow the second independent loop to terminate the operaion. The last portion is to reset the switch back to the run condition. I used this construct when I am testing the program. If I am running for real, I have the program just exit. I know it is not the best way to terminate all the VI but when I exit, I want all of them to disappear at this time.

If you have another trick to stop independ loops within a VI I am all ears.

[Ray.R]

Does Front Panel activity affect both loops (and stop them)?

If so, you should have a look at Event Structures.

[Joseph_Loo]

Yes the sub-vi is suppose to do it. When I created the VI, I was not familiar with event structures, not that familiar, but I have a wait for the second loop via waiting activity on the front panel.

I guess I could embed the second loop into the first loop and with the event structure. It still does not fix the main problem why one of the Vi would arbritrarily stop.

I wonder if this could be related to soft memory errors?

[JamesR]

Hi Joseph,

Does the subVI stop running if it's running by itself as well?  How about if run in a simplified version of the very outer level VI.