07-27-2011 04:24 PM
I am having a hard time understanding why my VI only allows two specific tab clicks every time I run it.
Should I be using shift registers with the "initializing" Tab Controls on the left of the VI before it enters the loop?
No matter what I do, it will allow me to change the tab controlled pane two times and then it will not react to anything.
Once I have reached my maximum alloted, two clicks, then the main Cycle abort button will not react either.
Kind of stumped... Any help would be greatly appreciated.
07-27-2011 04:32 PM
Event structures so seldomly exist outside of a while loop, that let's just say they should never be outside of a while loop. Once you trigger one of your event structures, that is it. Create a New VI with the User Interface Event Handler Template to see what should be going on.
Next we'll have to talk about wiring a control to its own Value Property.
07-27-2011 04:34 PM
Does not look like your event structure are in a while loop, meaning once the execute once, they will never execute again during the same run of the program.
I would recommend to only use a single event structure. You can add several event cases to handle all your events.
(Of course we canot see the entire code, so please attach the VI if this does not solve your problem)
07-27-2011 08:47 PM
WOW,
you realize that two of your event structures are running in parallel with the while loop- and they will only execute once? One event- one event execution event. The construct "finishes" done! it won't look for another event.
Take a look at the shipping examples or the P-C QSM (events) template.
Your efforts are not bad, but, show a lack of LabVIEW basics- Dataflow is a different Paradigm- (AND REALLY POWERFUL) but you do need to understand what happens when you use constructs that "break data flow" like locals, globals, and event structures and read the caveats in the LabVIEW help file to get grounded in "best practices"
CAVEAT:
I've probably "broken" most of the "best practices" guidelines- Intentionally! but I wanted specific things from LabVIEW that I knew would happen without race conditions. 99.995% of my code does not violate the "best practice" rules. I write a lot of LabVIEW- It gives me room in that 0.005% to do "interesting" things.
07-27-2011 08:54 PM - edited 07-27-2011 08:55 PM
There is a more efficient way to enable all your pages than what you are showing on the left side of the program. Instead of essentially duplicating the same code 4 times, just use one instance. Get rid of the Index Array and feed the array of references into a for loop with autoindexing enabled.
Advantages: 1. Less code. 2. If you later add another page, you don't need to duplicate all the code again to enable that page. The reference to it is already in the array.
07-28-2011 08:40 AM
All great stuff! I am obviously having a hard time getting away from the concept of variables driving my thought process.
Originally, when first dealing with Event Structures, I believe that I found out that the event requires the event to occur at least once when inside of a loop so I found the solution was to pull it out of the loop. From what I think that you are saying, it has to be in a loop otherwise it won't be picked up consistently? The VI does recognize when the cycle start button is pressed and it is not inside the loop so I guess I still don't understand the breaking point there.
I will work with the advice given and update tonight after trying it out. Thanks again for the advice. I am trying to stay away from using variables due being told that it is bad practice. Key now for me is to figure out how to execute code selectively based on where on the screen the user is without locking up the program by 1: putting an event structure inside a loop that may never be triggered, or 2: putting an event trigger outside of the loop that is running. Does that accurately sum up what youa re seeing I am violating?
07-28-2011 08:44 AM
vi attached for ref...
I realize that there are MANY other issues with the VI, just working on a few concepts now out of that batch of issues...
07-28-2011 09:17 AM
You need to look into state machine architecture. This will help you organize your program and help git rid of some of the really bad programming problems that you seem to have. I will try and take some time to show you what I mean if I can get some time from work.
07-28-2011 10:30 AM
OK here is the start this should be the same code that you had. It can grow from here. I will try and explain it later. I need to go right now. Look it over nad we can go from here.
07-28-2011 10:52 AM