LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Triggered Logging

Solved!
Go to solution

Hey Everyone,

 

I am encountering a particular problem regarding the logging of data after a certain trigger condition has been met.

 

My task is to log some data based upon a particular triggering condition, the data to be logged should be the data preceding (e.g. 1 sec prior) and all the proceeding (e.g. 1 sec after) the trigger point.

 

So far, I have browsed the forums and my current VI is based on the solution listed here: http://forums.ni.com/t5/LabVIEW/Log-data-before-and-after-occurance-of-a-Trigger-Condition/m-p/32095...

 

The above solution makes use of the 'Queue' function and I am unsure if I am utilising it in the correct fashion.

 

As it stands my problem is that, I can indeed log data when the trigger is met, but I am unsure as to how to continue this logging for a certain amount of time (e.g. 1 second) following the occurence of the trigger.

 

I would be be very greatful if anyone could provide assistance. I have provided a copy of my developed VI as reference 🙂

0 Kudos
Message 1 of 14
(4,734 Views)

I think I would use a Producer Consumer architecture here.

 

Have you producer loop constantly acquiring data and a time stamp (t) to your Queue.

 

Then the Consumer loop will just wait until it is triggered (t).

 

When triggered the consumer loop will save the data from t-1 second through t+1 second to disk.

========================
=== Engineer Ambiguously ===
========================
Message 2 of 14
(4,712 Views)

Many thanks for your reply! 🙂

 

I have tried to implment the producer/consumer architecturte with my queue but am unsure of how to implement the timestamp functionaility you suggested...

 

Please find attached a copy of my producer/consumer VI.

0 Kudos
Message 3 of 14
(4,687 Views)
  1. Do not use the Lossy Queue function, just use the simple Enqueue Element function
  2. The Dequeue Element function should be in the Consumer loop, but not in the case structure
  3. Delete the Wait function from the Producer loop. The DAQmx Read function already does your timing (produces 10 samples at every 1 second, so the producer loop will iterate once per second)
  4. Remove the Waveform chart from the Producer and put it into the Consumer
  5. Send a Time Stamp value "attached" to the 10 samples from the Producer to the Consumer loop.
  6. Not really clear what you want to do in your Consumer loop. That Dynamic data conversion function is just silly. Why do you use the triggered data logging Express VI? As I see, you just wanna start data logging when the Mean value of the 10 data samples gets larger than 0.1 ? And stop data record, when the Mean value gets smaller than 0.1?

edit: you also connected the two loops simply with a Array wire, which is totally wrong. You will not get data passed between the two loops. Think of data flow principles! Use the Queue to broadcast data from the top loop to the bottom!

 

0 Kudos
Message 4 of 14
(4,668 Views)

This can give you some idea, but still work to do on it, good luck!

(this is a snippet, you can save it and drag and drop onto a block diagram)

 

Edit: After reading your full post, I see you wanna save data 1 sec before and 1sec after the trigger condition occured (trigger condition is when the difference between the actual Mean value and the previous one is larger than 0.1??).

I let you work on this part further. You need to work on the logic, and also store the 10 samples for t-1 in a shift register. When the condition is fulfilled, you save the 2 seconds of data (20 data samples) into the text file... Try it yourself, and if something looks bad, post your code here...

 

edit2: it also needs clarification, whether you wanna save data for t-1 and t0, or also for t+1? 🙂 In the second case you need to save 30 data samples in the file...

 

ProducerConsumer Trigger-3_mod1_BD.png

0 Kudos
Message 5 of 14
(4,652 Views)

Many thanks for the reply Blokk! (2nd thread so far 🙂 )

 

Your highlighted points proved to be very useful and I learning how to 'attach' timestamps to the data was really enlightening.

 

I have looked into implementing your suggestion with the shift registers, but after undergoing numerous changes I am none the wiser.

 

Therefore, I tried to implement it through timers. I thought about using a delay or a relapsed time.

 

I have attached a copy of this timer version of the trigger logging as reference.

0 Kudos
Message 6 of 14
(4,620 Views)

Does not look correct. You put the elapsed time Express VI there, but that consumer loop iterates once per second. So it does not make any sense in this way. Also you do not need to specify the maximum Queue size, delete the value 10 at the "Obtain Queue" function.

 

You need to use the shift register way, and create a logic when a trigger condition happens, you save the previous iteration, the actual iteration, and the next iteration data. Try to think about, how to do this...The elapsed time Express VI is not useful here!

0 Kudos
Message 7 of 14
(4,614 Views)

Hi Blokk,

 

Your tips concerning the shift register proved to be really helpful and I have managed to finally implement a trigger that saves data from the past second as well (happy days!).

 

I will try implementing the t+1 data logging as well tommorow (in addition to making some corrections to the time stamps display).

 

For now, please find my current VI attached 🙂

 

P.s. please excuse the 2 different file saves. It was just a method in which I compared the data to see if my code was working as it should.

0 Kudos
Message 8 of 14
(4,598 Views)
Solution
Accepted by topic author Anexe

Just better avoiding that evil dynamic data in LabVIEW!

Here I show you a possible way how to save the three data blocks. Note that, this solution might create overlapping, when there are consecutive trigger conditions appear. But you can improve the example further. I also created a subVI for the data saving, more space this way (Save_data.vi)...

 

subVI:

 

Save_data_BD.png

 

Consumer loop:

 

TriggeredQueue  Logging-1_mod_2_BD_falsecase.png

 

TriggeredQueue  Logging-1_mod_2_BD_truecase.png

Message 9 of 14
(4,588 Views)

I am not sure why you would need to use the shift registers.

 

All the data is already in the Queue, let is stay in the Queue until you need to save it, don't unload the Queue into shift registers then save the data from the shift registers. That seems rather redundant.

 

You have a time stamp and you know (or should know) the time then the save command is sent (t)

 

Once you get the save command start de-queing data from the Queue and just save the time span you want (t-1 through t+1) and then clear the queue for next time.

 

 

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 10 of 14
(4,583 Views)