how can I watch for an alarm, then wait to see what happens before the save?

[Paul V]

I have resurrected an old project, thus using outdated software (LV6.0.2)... any help is awesome.

I am attempting to gather strain gage information on a piece of equipment. Ideally, when the strain gage level reaches a certain point, I would like to cause an alarm that alerts the user, gathers data for an additional xx seconds, then dumps all this information into a file. Thus saving the information leading up to the event, and the system response following.

Though I haven't figured out how to preset the file name, (working on that), my current hurdle is figuring out how to get LV to continue saving data after the initial alarm. I can dump the information directly to a file, but its the continuation that stumps me.

Any help is good help.
Thanx,
Paul

[altenbach]

It's a bit difficult without seeing the actual code. How is the current data accumulated during the run (e.g. built array in a shift register).

You just need to ensure that the data acquisition loop continues despite the error condition. When the alarm occurs for the first rime, get the tick count, place it in another shift register, and later subtract if from the current tick count in each iteration until the desired time has been reached. Now save the data and stop the VI.

If you don't mind, post a simplified version of your VI.

[Paul V]

>>If you don't mind, post a simplified version of your VI.

Due to my extensive self-taught knowledge of LV, simplified versions are all I can currently create. At the moment, I am trying to gather concepts for later final assembly, as I am an electrical engineering student working at an internship where I am the only EE on staff. Final Assembly date is early Sept.

How am I doing it?? Good question.. Still figuring that part out. Currently I acquire a sample of 83 points w/ rate at 5000. This was chosen as 1 complete cycle of 60Hz to remove unwanted noise. These 83 samples are put trough the 'mean' function, and scaled appropriately to allow accurate results from the 'Strain Conv' function, then processed to achieve accuracy in psi and sent to a chart for real time observations, and to a tunnel for indexing.

I would like to add an alarm to indicate when the output hits xxxx (roughly 15000), acquire an additional 10 seconds of information, then save this to a file.

Thus far I was planning on trying Sequence loops...
Frame 1: use a 'sequence local' to get the initial data to later frames, where the alarm would stop the first while loop.
Frame 2: continue sampling the data for xx seconds, send to another sequence local
Frame 3: gather both locals together, build new array, save this to a file... Hopefully with a time/date like stamp as a file name to allow it to run un-monitored for an extended period of time.

As this is a new venture, I have thus far not attempted frames 2 & 3 yet, working on that. I am guessing that the tick count you are referring to in your suggestion is from the iteration counter ('i' in a blue box), inside the while loop. I will work on that.

I also recently contacted CC for assistance creating a time/date stamp for the file name... do you think this could work? (didn't ask this specifically) and I still haven't figured out how to create a file path from this. (granted the whole file path thing is a mystery in general)

Plus.... when events happen, all data from the beginning of the aquisition run is saved, the longer the run, the longer the file. Is there a way to limit this to say.... the last 3000 samples? I think it would have something to do with creating an array xx long to start, then filling it, when the array is full the next point in the top will kick the last one out the bottom. (i think)

I have attached one of the most recent versions of my attempts, hopefully you can open it. Please note I am using LV6.0.2
Thank you sooo much for your help, (this is meant for EVERYONE). I feel lost. Everyone's direction and responses in all areas has been invaluable. Though I wish more would post in neutral formats, as there are many vi's I would like to glance at that I cannot due to version gaps.

[unclebump]

Do you have the DSC engine??

[Paul V]

Uncle,
DSC engine... hmm, doesn't ring a bell from wandering thru the manuals from LV or DAQcard. Current availabilities....
LV6.0.2 base package (No Analyse, Report Generation, Graphics/ Sound Functions... No digital filters (WAAAAA!!!!!))
DAQCard-6062E
Laptop

Paul

[altenbach]

---

@Paul V wrote:
Plus.... when events happen, all data from the beginning of the aquisition run is saved, the longer the run, the longer the file. Is there a way to limit this to say.... the last 3000 samples? I think it would have something to do with creating an array xx long to start, then filling it, when the array is full the next point in the top will kick the last one out the bottom. (i think)

---

Since you already use a chart, things are much simpler, because they already have a built-in FIFO buffer of defined size. Set the chart history lenght to 3000 and you have exactly what you need. At the end, just get the chart history data via a property node and save it. Voila! 🙂

The attached simple example (LabVIEW 6.0) shows one possibility on how to keep the loop running for a fixed additional time once a condition is reached. Modify as needed. Don't complicate your diagram with a complex set of stacked sequence frames.

[Paul V]

altenbach,
You rock!! It took a bit to digest what you did, I was considering the multiple frame version simpler, then it clicked, this approach is extremely straight forward.

I had initially started saving data with the History node, but due to discoveries when I started putting multiple samples into a single chart, having to bundle all into one brown hatched wire (cluster of 4 ( all singles like the input to the other chart previously discussed)), I was unable to wire the history to a 'write to spreadsheet file' since it was no longer an array. Thus my thoughts of changing it to an array, and indexing it as it hits the while loop, when the loop stops, sending it to a file. using your previous example, I can see being able to do this with the time delay, but in this case there would still be the case of limiting the overall output array size. Is there a way I could isolate the last 3000-ish samples from the double array, and only send that?
Attached is a slightly larger vi, with the top 3 calculations performing the same thing on different channels. I'm guessing there is a cleaner way to do this... I know its ugly. (thoughts??) you can see how i have been saving information, and your time delay will accomplish what i need in system response using this same model. but it doesn't work for limiting the size of the overall output.
what happens if i use another chart, hide it so it doesn't clutter up the front page, and simply take the history from that...(brainstorming with my keyboard...), I just get a long stream of mixed numbers... ( chan 1,2,3,4,and back to chan1, then 2..etc)Doesn't work!
Additional Ideas?
Thanks, Paul
LV6.0.2

[altenbach]

No, just setup a 2D array of fixed size for the buffer (4x10 in the example for troubleshooting, but you might want to set it to 4x3000 and delete the two buffer array indicators in the final version) Now simply replace rows as you go. When finished, split and reassemble so everything is in historical order before saving.

No, you don't need to duplicate all that code for each channel, use autoindexing and a simple boolean array to treat the last channel differently. I had to take out your subVIs but I let all the rest of the code nearly in place. I just simulate some noise. For better troubleshooting of the buffer operation, I add "i" instead of the last channel to the buffer so you need to change that back once operation is verified. (see attached, LabVIEW 6.0)

Let me know if this makes sense. 🙂

LabVIEW 7 and later have a few more tools to simplify these things. e.g. there is a "Collector" Express VI which does the buffering for you. (personally, I prefer the old-fashioned way ;))

Message Edited by altenbach on 06-07-2005 05:05 PM

[Paul V]

Then if I replace the boolean array with a numerical one, thus changing the case structure to a conditional (0,1,2,3,...), I should be able to continue this method to incorporate multiple signals, each of which may have a different method of calculation.... Is this mode of thinking correct?? That way all I have to do is change the overall size of the history buffer to accomodate the extra channels, and the simpler layout overall. (Thus allowing easier signal tracking when I have to show my boss how it works). I'm getting chills with the possiblities that you just opened up.

Thank you so very much, can I buy you a cup of coffee in appreciation??

[Paul V]

One last thing before I feel this requires a new topic. I have not been able to get the proximity sensor to display on the output chart, with everything else. Any ideas why this is being a problem? I know I've had charts displaying more than this number of output waveforms, but for some reason in this case it is not showing. The only thing I have changed thus far is placing a shift register to feed the prox signal through due to an error I was recieving regarding the tunnel feeding the prox chart did not have a connection on the 'true' state.
I am still trying to figure out how to allow an initialization of the strain gage voltage, but I believe that is possible using a similar, but smaller, history buffer to the one you already demonstrated.
Again.. Many thanks for all of your help,
Paul