I'm learning LabView and until I have started making applications I couldn't see how complicated it is.
I have tried to do VI to choosing in sequence some parameters. After many attempts to solve the problem, the VI it's working wrong all the time. Could you give me some leads how to do that? What architecture should I choose?
The idea is:
- after start VI only Page1 is visible and active
- when conditions for Page1 are correct we could push Next button and go to the next page
- Page 2 is visible and active and so on
- When we achieve Page4 (should be called "Summary page"), that ist summary page, which I not prepare yet
- in any moment we should have ability to go to any page using tabs
The problem is:
- the next buttons are grayed when I select previous page
- there are some problem with reliability, sometimes I push next button and nothings happen or page is visible but not active
I'll be glad about any suggestions.
Solved! Go to Solution.
both problems with the "Next" buttons are because you selected the wrong switch behaviour. Use "Latch when released"...
Maybe you should redesign the whole VI.
- It's not a good idea to create several event structures in one VI.
- You don't need a big case structure with one case per tab page, it can all be handled in just one event structure.
- I would prefer making buttons/pages disabled&grayed out instead of making them invisible (UI experience...)
GerdW has a very good point. You could move the event structure outside of the case structure. Also, having a while loop inside another while loop isn't indicated.
What you could have is just a event structure and a case structure, all inside of a single while loop. And with the event structure outside the case structure, you could have a wire that changes the states and not a local variable (it's recommended to use those only when you have no other options, because not using them can spare you a lot of headaches when it comes to data flow and race conditions).
What I would use for such an application (and I would try to make it as modular as possible), is producer-consumer architecture, having the event structure in the producer and the case structure in the consumer. Something like this. You could also find some examples for programming GUIs in LabVIEW Examples Finder, under Build User Interfaces
Great thanks for this answers.
Rares, this article you send me is really helpful and idea of queued state machine overwhelmed me. But don't you think that sophisticated architecture is to complicated to my "tab control.vi" which is actually subVi (in preferences I set it as a dialog box) for my main app (which I don't have yet). This subVi should gather me some operator informations mainly from the barcode scanner and confirm at each page with "Next" button to allow to download a proper program into PLC through OPC server.
Maybe the queued state machine is good for main VI - processing data in background and gathering informations for next batch, but how in that structure popping up dialog box could function - probably in the same way as SubVI1 and 2 in example from article. Am I right?
So even if my program isn't too complicated should I use this structure shown in article to my mainVI and subVIs like this in attachment in my first post?
Using a queued state machine would be the "text book" way of doing it. As always, there's more than way for achieving your goals. If you are more comfortable with a simpler architecture and if you don't plan on doing anything complicated with your VI, a simple event structure and a case structure will work just as well.
But for future references, if you are going to design a more complicated program that has a GUI, take a look on the reference architectures and examples in LabVIEW.
I' trying to fit QSM to solve my problem, but I have some problems with how to manage queues. If I wont to stay in "Check Page 1" state as long as I push "OK button" what is the best way to stay in the same state. If I simply put "Check Page 1" to the queue inside my case structure, I have trouble with manage OK Button without flush queue.
As a first step, you need to get rid of these extra event structures on the lower loop. Event structures always need to be ready to fire and cannot be buried inside case structures. They do not follow dataflow, so they will queue events even if they are temporarily unreachable by program flow, and since your events are set to lock the front panel until the event completes, your front panel can be easily locked up irreversibly by an innocent control change. UI intereactions need to be handled exclusively in the upper loop.
A lot of your code seems random and illogical. What's up with all these waits and timeouts that seem to duplicate functionality? Why are you resetting partNo an foamNo every 125ms to a blank string? It seems several code parts are constantly fighting each other.
Thanks altenbach for your post. It is very constructive.
I have changed my program and now it works as it should. It of course requires some cosmetical improvings, but it works. QSM is complicated for someone like me, who started with LabView.
FYI resetting partNo an foamNo is required to prevent from typing this values from keyboard and instead of it use barcode scanner. Barcode scanner works like paste function. Value just shows up in control.
I didn't know how to go to this same state many times - it is required for Key Focus all the time on proper controls. So I use timer to go periodically to cases depending on in tab I use.
Great thanks for your help,
One thing bothering me. What about non-user events. For example: I'm communicating with PLC through OPC using Data Binding. I'm monitoring boolean which represents flag in PLC that is set to 1 when data from PLC are available. How to handle that kind of event. If I will check in Idle mode if boolean is 1 and then run case "Process PLC Data", this case will run until PLC flag is set to one. But I need just one time to run it.
And what about event control / indicator change but not in due to user activity. Local variables dosn't work in that case. Probably property node with value sign. Will work in that case, but I don't now if I should program in that way.