newbie question on triggered measurement

[tiger1981]

Hi Labview gurus:

It might be a really simple question for you guys, please provide some advices.

Here's my measuring scenario: I need to monitor a sensor output which is a voltage signal (to AI0), I only need to get the voltage reading whenever I receive a trigger signal from another pin (to PFI0). I would like to save it to a .txt file with info. about the voltage value and the time stamp for every measurement. With a simple while-loop and DAQ assistant, I can get the measurement to start when a trigger is detected on PFI0, however, the measurement will keep on running after that. Instead, I want the system to measure one voltage value, then wait for the next trigger signal. I'm pretty new to labview, so it will be greatly appreciated if someone can point me to the right direction. 

Thanks alot.

Shao

[crossrulz]

You should setup your task to be a single sample.  In the DAQ Assitant, Acquisition Mode should be "1 Sample (HW Timed)" and you can setup your trigger in the Triggering tab.

[tiger1981]

Thank you so much for the quick reply. I did follow your advice and played with different acquisition mode. What I found was if I set it to "N sample" and set the trigger in the triggering tab, it will collect N samples then wait for the next trigger to come and then collect N samples again, which is kinda like what I wanted, but N cannot be 1. If I set to "1 sample (HW timed)", everytime it received a trigger, the while loop will just continously run and I will get an error 209802, I have already set the trigger line to only trigger at 1hz. and tried to keep the VI as clean as possible, why at "1 sample (HW timed)" the while loop will keep on running instead of just wait for the next trigger??  

Attached is the simple VI I used, thanks in advance!!

[fromm8]

Here, the explanation for hardware-timed single point sample mode: HW-timed

Regards

[tiger1981]

---

@fromm8 wrote:

Here, the explanation for hardware-timed single point sample mode: HW-timed

Regards

---

hi, thanks for the link, this helped clear the subject alittle bit. However, the main question does remain, when I use "single sample HW timed", I assume that the while loop will wait for the HW trigger before it finish current iteration. However, when I run my VI, even though I set the HW trigger at 1hz, the while loop just keep on running as fast as it can, and didnt wait on the HW trigger at all. thanks!!

[crossrulz]

That error says that you are missing samples.  Are you sure your sample clock is running at 1Hz?

[tiger1981]

---

@crossrulz wrote:

That error says that you are missing samples.  Are you sure your sample clock is running at 1Hz?

---

Hi crossrulz, thanks alot for your reply. Previously, I was using "1 sample (HW timed)" sample clock type set as internal, that error always occur at the 100th iteration. After seeing your message, I set the sample clock type to "external" and use the same line as the "start trigger", it is running fine at very low trigger frequency now. I still get the same error message when I run at over 100hz, it is probably an issue with processing not being fast enough. I still have couple questions that I couple you can help answer:

In "1 sample (HW timed)" aqusition mode, 

1. In "timing setting" under "configuration" tab what does that "rate(Hz)" mean, especially if I use external clock type at "advanced timing" tab.

2. Under "trigger" tab, what exactly is the "Start Trigger", if DAQ assistant is placed in a while loop, should the VI check for this "trigger" in very iteration or only at the very begining?

3. Under "advanced timing", can I still use internal as sample clock type? I want the data acaquisition to get one sample point only whenever it receives a trigger, but what to finish that acquisisiton as soon as possible. So my initial thinking was still using internal clock for actual data reading, but only start this everytime it receives a trigger at the trigger line (if each iteration will wait for the trigger signal). In the real application, my trigger will not be uniformly distributed in the time domain, I may receive a trigger at time 0s then another at 0.1s, and another 0.5s, it may not be a good "clock" source.

I tried to find those answers through online search and labview help doc., but had no luck, if you can point me to the right resource, it will be greatly appreciated as well. thanks!!

[crossrulz · Accepted solution]

Ok, after reading through that link given above about 1 Sample (HW Timed) I think what you really want is Continuous Samples with the sample clock set to your external clock.

Apparently there is no buffer with the 1SHWT (I'm making it short hand there).  If you miss a sample, you get the overflow error.  This tells me either your loop is way to slow or your clock is going faster than you think.  By going with the continuous samples, you won't have to worry about that.  You can just grab as much data as you want and save the bunch into the file.  This will make things work a little more smoothly.

[tiger1981]

---

@crossrulz wrote:

Ok, after reading through that link given above about 1 Sample (HW Timed) I think what you really want is Continuous Samples with the sample clock set to your external clock.

Apparently there is no buffer with the 1SHWT (I'm making it short hand there).  If you miss a sample, you get the overflow error.  This tells me either your loop is way to slow or your clock is going faster than you think.  By going with the continuous samples, you won't have to worry about that.  You can just grab as much data as you want and save the bunch into the file.  This will make things work a little more smoothly.

---

Hi crossrulz,

thanks alot. that solved the problem, I still couldnt go as fast as I would like (I wanna be able to run at at least 10kHz). but at least at lower rate, it's working fine. BTW, can you please give some hint on the questions above? Or point me to the right direction, I really would like to know what does it mean with each setting. Thanks alot.

[crossrulz]

There's a section in the DAQ Assistant that is supposed to provide help.  When you put your cursor over a setting, it should explain what it does.