03-24-2010 10:54 AM
Solved! Go to Solution.
03-24-2010 11:29 AM
The problem is that you can't even stop the program by hitting the stop button until you leave the tab, which is not a friendly user interface.
Event structures should just handle basic user events. Any given event case should not take a long time to run. While you are in the diagnostics tab, your code is stuck in that while loop. Although fixing the lock front panel allows you to do other things, the LabVIEW is just queuing up all of those other UI events (like Stop button value change) and can't handle them until the inner while loop stops and allows the outer while loop to iterate again.
You should have a parallel while loop to handle the waveform graph. You can use notifiers or queues or an action engine FGV (see Ben's Action Engine Nugget) to pass the starting or stopping of the waveform graph update to the parallel while loop.
03-24-2010 11:37 AM
03-24-2010 12:20 PM
I would use a state machine to "loop" through the states, and use an event structure in one of the states to handle the user interface, when user changes the tab control, it is diverted to a different state other than the state running the waveform graph, and enter back to that state when the tab control was changed back.
Since I cannot open your code with my LV8.6 at this station, I maybe far off.
Bryan
03-24-2010 01:08 PM
03-24-2010 04:21 PM
I think Tab>Value change>NewVal=Diagnostics would suffice instead of two case structures since it returns a boolean you could wire it directly to an enque element.
Also- You should check the displayed tab control once prior to entering the producer loop and enque either a start or a stop so that the operator does not need to change off the diagnostics page and re-enter it to start the first time-
Other than that- Pretty nifty and clean!