Which architecture for hour long timed loop with front panel responsiveness

[MrHappyAsthma]

I am having trouble envisioning how to plan out this application.  I originally was going to use an Event Driven Architecture with a Queued State Machine to parse Front Panel UI changes and respond accordingly.  (Something like the solution found here).

My problem is that in my consumer loop, one of my states involves an hour long datalogging loop.  If I implement the button to start dataloging into my State Machine, it will get held up while the datalogging takes place.  Naturally, this would prevent any more events from being de-queued and handled by the State Machine.  Is there a way to handle this without holding up my consumer from processing the other controls that get queued by my Event Structure?

I figured I could crudely solve the problem by having two producers/consumers with one for the hour loop button, and another for the more instantaneous events.  But I figured there is probably a much more elegant way to handle this.  Any suggestions?

**TL;DR - Basically, how do you encorporate a state machine which should have a state with a REALLY long and time-consuming loop without holding up events being queued.

[RavensFan · Accepted solution]

Datalogging should be done in its own loop with the data passed by a queue.

You can have multiple queues and multiple consumer loops if you need to.

[MrHappyAsthma]

Would using a Notifier to a third loop work?

I.E. something like this:

[Event Loop - queues events]

[State Machine Loop - dequeues events & notifies datalog]

[Datalog Loop - when notified, start logging]

[pjr1121]

When doing long scans, I break my datalogging loop into multiple states (begin, read value, continue?, stop....) this allows me to interupt the datalogging loop in response to user events. Say you started the scan with an incorrect setting; you wouldn't want to wait the full hour to try again, nor would you want for force crash LabVIEW to stop the loop.  The begin phase initializes any required arrays/controls the read value takes in a small number of data points (lets say 10 or 60 seconds worth) and places them in a shift register array then proceeds to the "continue?" state.  Here we check for any indicators (set by the event structure loop in response to use events) that would require us to stop prematurely. If non are found, read more values.  The stop phase is entered when the measurement is complete or a user event requires it.

This allows allows for the easy addition of added features in the future (lets say you want to change an applied voltage bias in your sample every 10 min) by having the "continue?" state direct the process.

[MrHappyAsthma]

I ended up taking Ravensfan's idea and making the Datalog loop separate.

prj1121 brought up a good point, which I already have implemented, however it is too slow during the dataloging to handle other events between states.