Save data triggerd by a randomly occuring threshold value

[Dipstick]

I need to monitor a constantly varying torque signal (+-10V) during a 10 day process cycle. I need to store data at 5kHz but have no idea when, during the course of the process the torque value will go over the threshold/trigger value (but I know it will). I obviously can not leave the cDAQ running for 10 days at 5kHz !!!

Once the threshold is reached I would like to continue to store data for a period of time afterwards, however the torque value may well drop below the threshold buring this period.

I have read in data from a short test we did and used this as the input to the many programs I have tried, but no matter what I try I can not manage to keep the data being writtern to file, once the torque value drops below my threshold value. It would be nice but not necessary to have a few seconds of data from before the threshold was hit also!

I will be using a cDAQ with a 9201 module. I also have two displacement sensors which will also be fed into the 9201 and should be logged at the same time.

Any help would be welcome, thanks,

[tbd]

---

Dipstick wrote:

I need to monitor a constantly varying torque signal (+-10V) during a 10 day process cycle. I need to store data at 5kHz but have no idea when, during the course of the process the torque value will go over the threshold/trigger value (but I know it will). I obviously can not leave the cDAQ running for 10 days at 5kHz !!!

---

Hi,

      I'm not familier with cDAQ, but with a PCI or USB DAQ device I'd code this as a continuous acquisition and do a "real time" signal analysis to decide whether to store or not.  The logic could "buffer" as much data as needed to have pre-trigger history.  When a trigger is detected, then startup a logging process with auto-generated filename.  On every trigger, set a logging-end-time (perhaps with a Global), and if logging loop reaches that end-time then logging stops - but if another trigger occurrs during logging, then logging just keeps going until the new end-time.

Will post an example shortly!

Cheers.

[tbd]

Hi Dipstick,

      This (attached) is only intended to show the idea expressed above.

Cheers!

Message Edited by tbd on 10-25-2008 12:15 AM

[Dipstick]

Thanks for this tbd, I had tried with two while loops but nothing like your program. I still clearly have a lot to learn.

Sad though it is, I have my cDAQ here at home and will try your solution out tomorrow (Sunday !!!) as I need to be up-and-running by next week. I will let you know if I have been able to run it. cDAQ as we know it here in Europe is USB based (so maybe we are talking about the same thing - the modules are housed in the same chassis as the Compact Rio). Normaly I use DAQmx Vi's to do my "simple programing". Once again thank you.

[Dipstick]

Hello again tbd,

I have I must admit been struggling with your program a bit. I have not done so much Labview programing. I was not sure what the timed loop added so to simplify things for me I took it out (sorry!).

I have attached my modified version (!) which seems to work ok. I also modified the output to be a text. I added a signal generator so it can be run without out being connected to the cDAQ. I think I only have one problem left, how to get a real timestamp into the first column. 

I have looked at and tried merging some of the ideas on this webpage but nothing seems to work. I realy need a timestamp as our analyists will want to run the data through an FFT.

Can you help please.

[tbd]

Hi Dipstick,

      You were right to change the simulated "DAQ" loop - though I don't remember using a "timed-loop"(?):smileywink:

Re: Time-stamps;  At a DAQ frequency of 5KHz, scans will always be 200uS apart.  An accurate relative time-stamp might be automatically generated for every sample (in a loop, just start with 0 and increment by 200us), though,  I'd be inclined to put this DAQ frequency in a "header" area of the data-file - when the file is first opened - your post-processing FFT routine could read/incorporate it.  By the way, do you need timestamps to correlate samples across data-files within a "run" or between Runs?.

Cheers,

[Dipstick]

Hello again tbd,

I told you I had not done much Labview programing ("timed-loop"- oops!)

I have no idea how to include the DAQ frequency in a header file, (I had one half days Labview training a few years ago and have "just been left to get on with it since"). I have seen the header info icreated in the express write to file vi., but cannot use that Vi due to it's inflexibility! Your loop idea is a possibility, so I'll give it a try.

For the first test using this program the timestamp is just as an time increment per second rate.

Later I need to add 2 (TTL) encoders and want to see the difference in time between the rising edge signals, of one encoder too the other. Basicaly this is to try and see the anglular difference from one end of a torque shaft to the other (Torsional stiffnes). The scanning/sample rate then will be much higher of course and the time stamp will need to very accurate.

[tbd]

Hi D.,

      Before I forget (again) I'm using LV 8.5.1 and can't open your [LV 8.6] LLB!  Please open the top-level VI and do File\Save for Previous Version, and re-attach.

Although I can't see it yet, you mentioned writing the data as text.  One way to get the Frequency information (5KHz) into the file is simply to write the DAQ frequency, converted to a string, at the beginning of the file.  This could be done in the "Open" case of the .Log VI, immediately before the first data-array is written.  The FFT post-processing previously mentioned could expect this info.

We can also/alternatively create a timestamp (column 1) for each sample - probably simply - but I'd like to see what you have so far and go from there.

Cheers!
 

[Dipstick]

Here is the 8.5 version

[tbd]

Hi,

     Here's an LLB where the logging VI adds a timestamp (1st column) to every row.

It goes against my grain to put this synthesized data into the original data-record when the essential information - sampling-rate - could be written on the first line of the text-file!

There's an alternate logging VI in the LLB, it shows what I mean.

Cheers!