I've attached my SubVI and a screencap of where it falls in a loop.
There's a handful of boolean conditions that use different combinations change the value written to the channels on a NI 9482 relay card. Depending on the value, things turn on and/or off.
The way it currently is, my SubVI works fine, but it A. uses a DAQ assistant and B. sits in my producer loop so it's writing that value every loop rather than just setting it and forgetting it until something else happens.
I started messing with event structures but couldn't really get anything to happen, and I believe my events are somewhat contradictory (depending on the written value).
Just throwing this up to see if there's an event based concept that might jump out at someone else which I'm not finding.
Based on what you wrote, I'd look into the State Machine Event structure. With all of those Boolean controls, that would be my suggestion.
I've reattached the screen shot. Yes, I need an option that doesn't lock up the UI.
Before that happens, you need to bring your Block Diagram down to a managable level so you can read everything. It's more than your resolution and monitor size can handle.
I think you'll find that studying the Simple State Machine that ships as a Project Template with LabVIEW 2014 worth a look. It incorporates an Event Structure within the State Machine. It is worth studying to at least read the documentation that NI provides. To do this, proceed as follows:
Once you've gotten the basic idea, do one more thing --
Now look at this Producer/Consumer method of handling Events -- the (Event) Producer loop stays idle until an Event (here a Front Panel Control interaction) happens, at which time it "does something" that is passed as Data to the Consumer Loop. Well, suppose you make the Queue a Queue of States of your State Machine, and made the Consumer Loop your State Machine, passing the next State in, not on a Shift Register, but on a State Queue (you'd dequeue it and pass it into the inner State Case Statement). This is called a Queued State Machine, one that I use a lot (a variation on it is to make the Queue a cluster having a "Message" (or State) and variant Data -- this is called the Queued Message Handler, an extremely popular LabVIEW Design Pattern). Note that now the State Machine also sits Idle until someone puts a State on the Queue. If you want to progress within the State Machine from State A to State B, simply bring the Queue wire into State A and use it to enqueue State B. If you have additional parallel loops (even some running as asynchronous sub-VIs), they can also enqueue States to your State Machine as long as they have access to the Queue (which they can easily get just by using a Named Queue and having the sub-VI open its own copy of the Queue using the same Name).
With eight years of LabVIEW experience, you are clearly ready to understand and appreciate the "Organizational Style" afforded by State Machines, Producer/Consumer Event Patterns, and the various extensions that result in the Queued State Machine and the Queued Message Handler. Once you start using these (more powerful) tools, there's no looking back ...
Bob, thanks for that. I'm so used to starting with blank paper that I didn't even know those options existed.