Leaderboard

This sounds like a circular buffer for looking at the last X loops. A simple RMS might be sufficient, but it's unclear what anomaly you'd be looking for. Tim

I didn't examine the diagram in depth, but your requirements and questions suggest a "quick-and-dirty data acquisition vi" will not adequately meet your needs. Personally I'd refactor into a event-based producer/consumer design. Labview includes a "Producer/Consumer Design Pattern (Events)" template that is a good starting point. (File -> New... -> From Template -> Frameworks -> Design Patterns) The template's consumer loop is set up as a simple message handler. At first glance it sounds like a state machine in the consumer loop will fit your needs better. I posted an example of how to implement a simple event based state machine here. Skip the Entry, Exit, or Transition actions if your state machine doesn't need them. I strongly suggest sitting down with paper and pencil and creating state diagram that defines the core behavior you're looking for. It should include: States: Uninitialized, Standby, Acquiring, Exit, Error, etc. These five states are probably sufficient for this app. Add new states if needed. Transitions: Decide which transitions are valid and draw an arrow connecting the states. For example, it doesn't make sense to transition from the Uninitialized state directly to the Acquiring state. Triggers: Triggers are actions that cause a state transition. List the triggers next to the transitions. Guard Conditions: These are conditions that much be true for a transition to take place. Guard conditions are contained in square brackets following the trigger. Getting the state diagram right will go a long ways towards simplifying the coding part of your application. Here's a quick example state diagram based on your requirements.

Just glancing at the screenshot... You can use the File Dialog VI. All channels collected will show on the graph. The values can be cleared using a local variable or a property node. This will concatenate the two arrays, but only the current value. You would need to use a shift register to store that concatenation and then add to it on each loop. A better way may be to open the file to save and then keep writing to it during the acquisition (and may be the only way to do this in a long term DAQ). Before you configure the DAQ, or at least before the DAQ start. Yes. No as the data flow has the stop set after the while loop has terminated and is not in a loop itself.