State Machine with Refs and Local Variables

[pete_dunham]

I am working with some code that was developed, by someone else, as a state machine with a lot of local variables and VI server references.

The locals variables have been easy enough to clean up, but looking for a better approach to clean up the references tied to indicators.

In some states a VI server reference of an indicator is passed into a state, because the indicator needs to be updated from several loops within subVIs.

Not necessarily in real time, but serial communication that needs to be updated faster than the SubVIs or states could directly update the indicator.

Because of the complexity and needed modularity of the subVIs it woudln't make sense to de-modularize the subVIs that contain loops.

For me, sending in VI server references seems like adding un-needed complexity and area that can cause issues during debug. Or is this good practice?

What is the best way to update such an indicator?

I like keeping all of my data passing within a cluster within the State machine. Could I bundle a queue "handle" and then periodically enqueue my cluster within my subVI'ed loops? The disadvantage of this approach would be that a consumer loop would be solely in-charge of any displaying/ updating indicators. Is this better than using VI server references?

Any thoughts?

[Mark Yedinak]

What if you were to add a parallel loop with an event structure to handle the UI stuff. The subVI's can generate an event to update the indicator with the appropriate data. The data can be included in the event itself. Each indicator can have its own event associated with it. For reuse purposes you can have the subVI's test the event reference to validate that a value was passed in. If it is "Not a Reference" it could skip posting the event.

[PaulL]

Pete,

Mark's suggestion is a great one. (Separate the view from the model.)

One way of doing essentially this very easily is with shared variables.

Paul

[pete_dunham]

Mark,

Thanks for the reply! I am going to look into this and I am sure I will use this in some way or another.

In the mean time, I may have come full circle and may keep some of the VI server references. Are there some basic rules in closing these references?. Do I need to close the reference, say everytime I update the value through a property node (pass the ref num through the property node to a close ref vi)?

[jgcode]

Do I need to close the reference, say everytime I update the value through a property node (pass the ref num through the property node to a close ref vi)?

Hi Pete

Any VI Server reference you explicitly open - you should close. That is good practice to avoid memory leaks.

I am pretty sure tho that AQ posted somewhere here, that with property nodes, the references are closes when the owning VI goes out of memory.

[tkuiper]

Hi Pete

Any VI Server reference you explicitly open - you should close. That is good practice to avoid memory leaks.

I am pretty sure tho that AQ posted somewhere here, that with property nodes, the references are closes when the owning VI goes out of memory.

Absolutely. The practice of closing any opened references will be very useful when branching into other more unfriendly technologies like ActiveX/.NET where you must close your own references, or Bad Things ™ will happen.

AFAIK as long as any VI holds the reference open (passing it into another VI, etc) then the reference - and thus the original VI - will remain open. (That is, unless explicitly closed, and no matter how many times you pass a NULL reference around it's still NULL.) So if you open a VI and another VI opens a reference to that original VI, even after you close that VI's window, it will still remain in memory.

That being said, if all VIs stop executing then LabVIEW will automagically close those open VI references. (Keep in mind, tho, that you may not see all running VIs - the tools menu and project window are capable of spawning 'thread' VIs that could keep those references open!)

The main concern I have is that using a property/invoke node will bump the executing VI into the user interface LV system thread at enormous (something like 1ms as compared to 1us) speed penalty. I wish I had a link to that original post from long, long ago - it was a real eye-opener. Realistically, if you're only updating a few controls every couple seconds, this isn't an issue. If, OTOH, many indicators are being updated via invoke nodes in other VIs quite frequently, you might want to consider separating the business logic and the screen update logic. An extra loop in the VI owning the controls with a queue or user event would work nicely.

Just my $0.02⁹. (If gas stations can do it, why can't we?)

Tony

[jgcode]

I wish I had a link to that original post from long, long ago - it was a real eye-opener.

Check out from around slide 52

improving_performance.pdf

Check out from around page 10

17 - Managing Performance and Memory.pdf

[Aristos Queue]

Here's another suggestion:

Create a new state called "Update Indicators". Put all the indicator FPTerms in that state. Now instead of displaying the values in the state that generates the value, you wait to get to the Update Indicators state to update the indicators. Of course, this would require one of two things. Either:

A) a queued state machine so that you could queue up the Update Indicators state followed by the next state that you really wanted to go to, o

B) you make the next state to transition to another value in a shift register that the Update Indicators state can use.

[pete_dunham]

Thanks everyone for the input!

In past applications I have implemented similar architecture similar to what Aristos Queue mentioned as an "Update Indicators" state. However, in the code I am looking at, it doesn't make sense since I am looking to update indicators that are being acted on within a SubVI. Basically, some call and response communications that don't make sense to de-modularize.

I am still investigating closing references and built some code to use as an example in this discussion:

If I have a simple state machine that has a basic layout without closing the references:

Which of the following options makes more sense in closing the VI server refs:

OPTION #1:) Closing refs on each "pass" to property node

-OR-

Option 2:)Closing the created references on exit of state machine (which LV does anyway?)

[Mark Yedinak]

Which of the following options makes more sense in closing the VI server refs:

OPTION #1:) Closing refs on each "pass" to property node

-OR-

Option 2:)Closing the created references on exit of state machine (which LV does anyway?)

I would opt for option #2. Have your state open whatever references it requires and close then upon completion. The subVIs will only get a reference to use and therefore it does not need to worry or be concerned about managing the references.