functional global error

[JeffOverton]

Hey everybody,

  I'm running a shell vi that calls either of two subvis into a subpanel.  Both subvis have the same display, it's just a question of extra steps and other small changes in the structure of the operation.  The problem is, I'm using a functional global to update the display in both subvis, and it's acting pretty funny.

  Upon first opening and running the shell, the first subvi to be called (it doesn't matter which, just the first) runs properly for about 3/4 of its execution.  Then the display just stops updating.  I've probed it, and the data is updated inside the FG, but it does not update to the output of the FG (basically, I can see it inside the FG, but it doesn't come out).  Once this happens, the screen will not update for the rest of the subvi execution and will not change past the default for any future subvi that is run.

  The only thing I can think of would be that something else is calling the FG vi and preventing it from being called again, but there is nothing else calling it.  The FG is used in a write-to-hardware statement and a read-to-display statement, and those are tightly controlled.  The write statements are not programmatic, and the read statements occur every 100ms.

  I'll see if I can get some code later, but has anything like this happened to anybody?

Oh, and I'm on 8.2.1 Full Development on XP.

Thanks,

  Jeff

[altenbach]

Yes, please attach some code.

Does the FG complete its operation in all modes when called? It will only return data on the outputs if it finishes.

Have you tried execution highlighting?

What code occurs at the 3/4 point of execution of the subVI?

What is a write statement that is "not programmatic"??? I am not familiar with that term in relation to LabVIEW code.

Message Edited by altenbach on 01-14-2008 08:53 AM

[JeffOverton]

"Not programmatic" means that I know exactly what and when everything will be written.  There is no user input.  However, I figured out that my problem was just sloppiness

3/4 of the way through the code was the final major step except for cleanup, and I had unwittingly left a boolean in from testing earlier that ended the code

The overall problem, and I'm still not sure about this, was that I apparently wasn't closing the subVI reference in the shell properly.  There had to be some data or reference still open to the FG after one of the subvis ended, because I explicity closed all my references and solved my problem.  I'm still not sure why that would matter, since the subvi ran and ended and should have dropped all calls to the global.  Does any of this make sense to you?

Message Edited by JeffOverton on 01-14-2008 11:28 AM

[RavensFan]

---

JeffOverton wrote:

"Not programmatic" means that I know exactly what and when everything will be written.  There is no user input.  However, I figured out that my problem was just sloppiness

If there is no user input, then I would be more inclined to call it "programmatic"!!

3/4 of the way through the code was the final major step except for cleanup, and I had unwittingly left a boolean in from testing earlier that ended the code

That could do it. 

The overall problem, and I'm still not sure about this, was that I apparently wasn't closing the subVI reference in the shell properly.  There had to be some data or reference still open to the FG after one of the subvis ended, because I explicity closed all my references and solved my problem.  I'm still not sure why that would matter, since the subvi ran and ended and should have dropped all calls to the global.  Does any of this make sense to you?

Functional global sub VI's maintain a presence in memory along with their previous states of the uninitialized shift registers as long as the calling VI's are open.  So all VI's and subVI's would have had to ended and been completely unloaded from memory in order for the functional global to also be unloaded.  That is pretty unlikely to happen with most common programming practices.  If you need to have a FGV start fresh at some point, the best practice would be to be sure to have an "Initialize" case that you can call when needed to reset all the uninitalized shift registers back to some default values.

Message Edited by JeffOverton on 01-14-2008 11:28 AM

---

[JeffOverton]

Thanks for the clarification on the FG memory usage.  Those are the kinds of tips I really appreciate, because they let me get a more intuitive feel for LabVIEW, reducing the number of times I have to bother you nice folks.  I actually have it initialize at the beginning of a for loop in the shell, so I guess my good practices are getting better.

Also, you're probably right on the "programmatic" thing.  I guess it was the word that popped into my head because non-UI controls are easy to code compared to accounting for all the various things a user can do wrong (hence a lot of programming).

[JeffOverton]

Well, it just stopped working again, so I guess I'll bring my flash drive in tomorrow and post some code.

[JeffOverton]

Ok, here it is.  Sorry that it's poorly commented, but the VI names and icons are fairly descriptive.  fd ae.vi is my Functional Global that is meant to store all the data.  It's only called during Write Valve State Auto.vi (where the front panel is updated and potentially errors are updated), Fault.vi (where errors are updated), and Sensor Update (polled every 100ms to update front panel).  Test Engine is the main calling VI, and the for loop is to iterate the cycle count and determine which of two possible tests to run.  The problem comes in when after the first test, the display initializes but won't update, leading me to think that something has called my FG and has not returned control of it.

p.s. Ignore the Flow Switch Display.ctl prompt that comes up.  I forgot to include it, and it has no purpose (eventually it will indicate a hardware shutoff).

Message Edited by JeffOverton on 01-15-2008 07:32 AM

[JeffOverton]

Oh, I also just noticed this.  Given the FG below, will this blank/delete/reinitialize all data that's not wired on a "write" command?

[JeffOverton]

Alright, never mind, I guess.  If I force the VI to invoke Default Vals.Reinit All before I close the reference to it, it resets the boolean that ends screen updates.

Which actually brings up a good question.  How was the boolean not resetting to its default value when the VI had finished running and I had closed all the references to it?  Does it stay in memory in the same way that a functional global does?

Message Edited by JeffOverton on 01-15-2008 08:19 AM