I think the problem is you are focused on "How" you do something, rather than on "What" you want to do. Also, the very slippery concept of Time (which LabVIEW, in my experience, handles far better than most other programming languages, having a whole palette of Time Functions and a few Time-related Structures ("Event").
So here's the deal: An Event Structure is designed to mostly stand idle, and when some significant Event happens (the most common, in a LabVIEW context, is the User changes a Front Panel control), a specific (usually tiny, very fast) bit of code "does something".
But What you want to do is to get responses from your Controllers. You may want to start or stop them at some "time" (event) during the running of your program.
Fortunately, LabVIEW is a Data Flow language, which means it can "talk and chew gum at the same time" (= Parallel Processing). You can have two loops -- one containing an Event Structure, which just responds to changes in Controls, and a While Loop around a Case Structure that acts as a State Machine and does what you tell it to do. [It's a tiny bit more complicated than that -- you need a mechanism for the Event Loop to tell the State Machine "what" to do (which means you need to "invade" the independent While Loop running the State Machine to say "Your State has changed to Something Else", which (for me, at least) is most elegantly accomplished by a Tag Channel Wire (which, although it is a recent and "semi-advanced" construct and topic, would be ideal to introduce at exactly this point in an "Introduction to LabVIEW" course to get the idea and importance of Time as a key LabVIEW concept and entity.
Well, I think I'll call it a night.
Bob Schor
