subvi execution/closing

[Kev1823]

Hi all,

I'm currently working on a project using LV7.1 that invloves the use of multiple subvi's linked back to the top level VI, acting as a main menu screen. However, I am running into a spot of bother when attempting to close a particular subvi panel/block diagram when no longer required and then to return to the top level VI without stopping the program completely.   

I have developed a method of achieving this within the subvi by wiring a true constant from inside a case of a state machine i'm using, to the conditional terminal  outside of the case (but within the while loop). This seems to work ok, but on occasion it can cause the subvi to freeze so that no buttons on the FP can be pressed. Is there any other means of achieving this same result without getting too complicated (as I'm a fairly inexperienced programmer in comparison to some of you folks on here)?

I've set the FP to 'show when called' and 'close afterwards'  using the subvi node setup panel on the top level VI and to 'run when opened' using the vi properties panel.

Could it be that my inexperience here is leading to bad practice which is causing it to run less well?

I've attached some screen shots of my program in the word doc, with some description of what it is I'm actually trying to achieve.

Hope you can help!

Regards,

Kevin

[srikrishnaNF]

hi kev1823,

  Instead of this document...can you please attach your code..Because there is some confusion regarding the states in the subvi,,you have only defined one state with -1,default condition and immediately you have defined 2 conditions..

Thanks and regards,

srikrishnaNF

[Kev1823]

Hi srikrishnaNF,

All states should be properly defined, but it could be that I'm missing something glaringly obvious having stared at these VI's for so long now attempting to debug!!

I've used pretty much the exact same code in a few different applications and it works completely fine, without any bugs, in those cases. However, here it just doesn't behave as it should.

Anything obviously wrong here, to you?

As requested, here are some of VI's that aren't working right.

Regards,

Kevin

[Yamaeda]

2 things come to mind, why not an Enum for the states, and why a state architecture at all? It can easily be solved within each event case. 🙂

Also, unless you already know it, setting a button wont fire an event (if that's what you're after) you need to use the Value Change(signal) property.

/Y

[Kev1823]

Hi Yamaeda,

Thanks for the reply. The reason I opted for the state architecture was for convenience (laziness on my part I know) as I had already used this same architecture for other applications/VI's linked into this. Also, as I'm fairly inexperienced with the more-complex labview programming (i'm an instrument engineer so don't have a clue about most of the computer jargon that gets thrown about on here) so I tend to stick to simple means of making it work. I know about value changes for the button set in the event structure, hence why the button on the front panel is not wired.

If you read through this feed, you'll see that I HAVE had this layout working, perfectly well in fact, it's just that with this particular VI it's not playing ball...

But your suggestions are more then welcome (if you keep them simple for me)

Regards,

Kevin

[Yamaeda]

Highlight Execution and Retain Wire Values are good tools when this happens. 🙂

In your OpenTest i got stuck in state 1, but then i cant use Daq. Unless your item opens/closes fully it'll be stuck unresponsive here forever.

When you reach state 2 you stop the vi, ofc making it unresponsive. A better solution is to simply wire True to the loop-stop so the sub-vi exits.

Your Event loops key-checks are redundant, as there's no timeout they'll wait forever for an event, which always will result in one of the numbers you check against, thus you can remove it.

Your Stop button isn't handled by events which will mean you need to press stop and then one of the other buttons to leave the event frame.

State 3 and 4 uses an unnecessary comparison and a doubly unnecessary DBL comparison. 🙂

I've made a couple of changes, although not complete. It might give you some ideas.

/Y

[aeastet]

I made a few more changes. Take a look and let me know if you have questions.

[Yamaeda]

Beautiful, what a difference. 🙂

I can see one issue and one improvement:

Issue:

Begin X test -> Read DI -> Check X -> ... Message dispatcher through Default. You only check if you're at end position once. You'll need to queue up Message+Read X again. (assuming you want to be able to handle event in the mean time) To not get stuck at event wait you'll need a timeout on the event structure.

Improvement:

Local variables are frowned upon, as you can do without them 80% of the time. Move the controls inside their events and skip the DataCopies (since a LV local /= C++ local) 😉

Setting the tab control through a property is unnecessary, use a local, it's alot faster. 😉

(Not that speed is an issue at this point, but as a general rule the only time you set a value through a property is if you only got a reference to work with)

/Y

[aeastet]

---

@Yamaeda wrote:

Beautiful, what a difference. 🙂

I can see one issue and one improvement:

Issue:

Begin X test -> Read DI -> Check X -> ... Message dispatcher through Default. You only check if you're at end position once. You'll need to queue up Message+Read X again. (assuming you want to be able to handle event in the mean time) To not get stuck at event wait you'll need a timeout on the event structure.

Improvement:

Local variables are frowned upon, as you can do without them 80% of the time. Move the controls inside their events and skip the DataCopies (since a LV local /= C++ local) 😉

Setting the tab control through a property is unnecessary, use a local, it's alot faster. 😉

(Not that speed is an issue at this point, but as a general rule the only time you set a value through a property is if you only got a reference to work with)

/Y

---

Issue:

Begin X test -> Read DI -> Check X -> ... Message dispatcher through Default. You only check if you're at end position once. You'll need to queue up Message+Read X again. (assuming you want to be able to handle event in the mean time) To not get stuck at event wait you'll need a timeout on the event structure.

I was not sure of the exact execution of the program. It can easily be changed.

Improvement:

Local variables are frowned upon, as you can do without them 80% of the time. Move the controls inside their events and skip the DataCopies (since a LV local /= C++ local) 😉

Setting the tab control through a property is unnecessary, use a local, it's alot faster. 😉

(Not that speed is an issue at this point, but as a general rule the only time you set a value through a property is if you only got a reference to work with)

I used local variables here to show concept. I would have used a cluster array to keep up with what is going on. If you use a local variable I have had trouble with it not setting the tab control in the past unless I used the property node.

[Kev1823]

Hi All,

Thanks for your efforts in helping me out, I haven't been on over the weekend but shall go give it a try now to see how it works and let you know how I get on. Thanks again for the help! 🙂

Regards,

Kevin