Data collection issue

[try_guy90]

Hello, 

I have written a VI that collects data continuously into a circular buffer and is supposed to record all of the points in the buffer to an excel file at an impact trigger. I am currently using the waveform limit scalar comparison VI to execute the trigger (using the boolean output), but upon testing the project, the trigger will not register for some reason. 

Is this because the comparison VI does not register the failure fast enough? Also, can anyone reccommend an alternative that would respond faster to use in its place?

Thanks,

Guy

[GerdW]

Hi Guy,

faster than what? How fast does it need to be?

- Can you attach a VI?

- Can you supply typical data?

- What sample rates do you use?

- What exactly are you trying to do?

[try_guy90]

My mistake, I completely forgot to attach my VI. 

I'm recording data at 10kHz. I have no typical data yet because there was no system to do this kind of collection implemented before I started this VI, but the accelerometer will stay hovering around zero until an impact (a physical tank will be dropped onto a concrete surface), which should show a few data points around 20gs. 

I hope that helps!

[Bob_Schor · Accepted solution]

Thanks for posting the code.  It shows fairly clearly the source of the problem.

I, personally, like the Event Driven State Machine model that you are using, but you need to remember that a State Machine can only be in one State at a time.  In particular, if any State takes an appreciable amount of time (both User State 1 and Wait for Event take at least 0.1 sec, a "long time" in data-acquisition-speak), you can miss things.

What you want/need is parallel Loops, a.k.a. the Producer/Consumer Design Pattern.  We had a similar situation involving a trigger, a "pre-event buffer", and wanting to save data.  Here's how we handled it:

• We had two buffers -- a Pre-Event buffer suitable to save data before the trigger, and a Post-Event buffer big enough for "playing catchup" (we probably set it to -1, as empirically it stayed small, 4-6).
• We had a VIG/FGV that remembered if we were in the "Pre-Event" or "Post-Event" stage of saving data.  We started in Pre-Event.
• We had a Test for Trigger State.  If it went True, we set a "Start Saving" Notifier.  In either case, we then called "Get a Sample".
• Get a Sample took a sample and, depending on whether we were Pre- or Post-Event, put it on the Pre- or Post-Event Queue.
• We had a parallel loop waiting on the Notifier (so it was basically "paused" until an Event occurred).  Once it fired, it meant that the Producer loop just switched from Pre-Event to Post-Event, that the Pre-Event Queue was ready to be processed, and when we were finished, we needed to process the Post-Event Queue until we'd processed sufficient data.  Processing the Pre-Event Queue is easy -- flush the Queue and use its elements.  Similarly, processing the Post-Event Queue is also straight-forward.

Note -- it's been 4-5 years since I developed this system, and realize I'm missing some details.  I think we needed to fire the Notifier after Get a Sample, passing information about whether we were in a "No Trigger Yet" State, a "First Trigger" state, or a "Waiting for Godot" (meaning processing as much Post-Event data as required) State.  I'm also forgetting  how we handled filling up the "Pre-Event" buffer -- did we ignore Triggers if we didn't have sufficient "Before" data?  I don't recall.

But, again, the trick is that saving the data into a Queue (the Producer) runs in a different loop than the process of emptying the Queue (the Consumer), so that the Emptying process doesn't interfere with the Acquiring process.

Bob Schor

[try_guy90]

Thank you for your thorough answer. 

Your explanation makes sense to me. I will implement it to the best of my ability and then mark your answer as a solution. The issue of the pre-event buffer not being filled shouldn't affect the test I am running, since the VI wil lrun for several minutes before triggering. 

Thanks again!

Guy

[try_guy90]

Quick question:

I have the VI built (and attached), but I am a little stuck on one part. The signal that changes the recording from the pre- event buffer to the post-event buffer does not stay true long enough, since it is dependent on the event trigger (which turns false before the record time is up). I want, essentially, a true signal wired to the case statement labeled 'A' that remains true until the final frame of the sequence structure (only there to force the sequence of recording to excel) has completed, at which point ideally it would change to false. I can use a property node at the end of the third frame to force the false value, but I don't know how to keep the case statement at the true case until then.

Thank you!