LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Retriggerable vs Hardware Restart Sampling

Solved!
Go to solution

Hi all,

 

I am trying to set up analog and digital channels to read data any time a common trigger occurs (wiring the trigger of one task to the other via "Get Terminal Name with Device Prefix.vi".

 

I believe I have decent handle on this, but upon going though examples I found two possible ways to do this.

One example accomplishes this with a simple trigger and by using a property node to make it retriggerable, then read data in a loop.

 

The other uses the control task vi to commit the settings to hardware, and actually starts and stops the task inside each loop.

 

Does anyone have any insight as to key differences, or for what uses one might be more useful than the other?

 

Thanks again to all homies.

 

Download All
0 Kudos
Message 1 of 9
(3,470 Views)
Solution
Accepted by beefcake

Hello Beefcake,

 

The retriggerable property node allows for hardware determinism in responding to the next trigger. All you have to be concerned with is the rearm time (on the order of nanoseconds) of the trigger circuitry to respond to the next trigger. If the rearm time is less than the frequency of the incoming trigger event then you will not miss any trigger events and thus not lose any data. With the exception that any subsequent trigger that occurs while you card is generating or acquiring based on the previous trigger will be ignored.

 

Utilizing the start and stop functions create a software liability in resetting the task to respond to the next trigger. There is a chance you will miss the next trigger if the task is not configured quickly enough. The DAQmx Control Task alleviates this issue somewhat by committing the task but does not fully correct for the problem that you might miss a trigger (during the time it takes to call the DAQmx Start and send a software trigger to the device to begin the acquisition or generation) and be unaware of it. If your device does not support this feature there is a workaround if your device has two counters. Please take a look at this whitepaper for more information and the workaround.

 

More reasons to utilize the retriggerable property node vs. starting and stopping your task.

  1. This feature is only supported on X Series Devices, and Counter Tasks.  
  2. This feature is not supported for Reference Triggers.

Best Regards,

 

Izzy O.

Applications Engineer

National Instruments

Ni.com/support

Message 2 of 9
(3,443 Views)

Thank you very much for your explanation, that was very helpful.

 

I am awaiting the arival of an X-series device, so the retriggerable property would probably be my best bet.

 

However, if I want to attain pretrigger samples, I should not use this, is that correct? Perhaps that's a case to use the commit task situation?

 

Thanks

0 Kudos
Message 3 of 9
(3,426 Views)

Yes if you wish to attain pretrigger samples then you would have to utilize a reference trigger which is not supported while having the retriggerable property node set to true or having a continuous acquisition. If you attempt this you will run into the error shown below. 

 

Untitled12.png

 

Thus the DAQmx Control Task (Commit) VI will be your best option when utilizing reference trigger in order to start the acquisition as quickly as possible in order to avoid missing triggers. 

 

Best Regards,

 

Izzy O.

Applications Engineer

National Instruments

www.ni.com/support

 

0 Kudos
Message 4 of 9
(3,409 Views)

Thanks for your help, this really cleared it up!

0 Kudos
Message 5 of 9
(3,394 Views)

One last question-- I believe I had this working a couple weeks ago when you explained, but now I am receiving Error 200278, trying to read a sample beyond the final sample. I have looked up the topic and found usually the best solution is to configure your task for continuous sampling, but this is not what I want to accomplish. Do you have any advice or direction to offer?

 

thanks again

0 Kudos
Message 6 of 9
(3,350 Views)

Can you share your code? I don't have the hardware to test it right now, but I believe you could receive that error if you are acquiring a finite number of samples, and attempt to read more samples than that. For each trigger occurrence, how many samples will your hardware read (based on the sample rate and timing), and how many data points are you trying to read in your code?

0 Kudos
Message 7 of 9
(3,346 Views)

Hi there,

 

I'll spare you the agony of my actual code--it's very much specific to my files and paths and such, but even in the example code attached, I am now reading the error.

 

Default settings on the vi: 10k sample rate, 1000 samples/channel, Dev1/ai0 input, PFI0 trigger. Using USB-6363. Can't get it to work on the real device or the simulated one even, and this is just the sample code. My actual code is pretty much exactly the same so if we can figure out why I cant get the sample code working for me it'd help.

 

The error says I'm trying to read sample 1,000 or whatever I set my samples per channel to be. I've tried increasing the buffer as well--that just gives me the same error but that I'm trying to read sampel "Whatever the buffer size is"

 

thanks

 

 

0 Kudos
Message 8 of 9
(3,340 Views)

Hello beefcake,

 

I reproduced your setup with the attached VI and Measurement & Automation Explorer tasks picture attached and could not reproduce the error you were seeing. The only time I encountered this error, which was expected, was when I set the task to finite acquisition and turned off the Start Trigger and Retriggerable Property Node. Could you provide more details as to how you are encountering this error?

 

Regards,

 

Izzy O.

Applications Engineer

National Instruments

www.ni.com/support

 

 

0 Kudos
Message 9 of 9
(3,330 Views)