Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I pause and resume analog output using DAQmx?

Solved!
Go to solution

I have a question.  This works for me as well with one caveat.

 

I am using the counter to control the sample clock of a digital output.  The internal output of the counter is wired to the source input of the DAQmx Timing VI.

 

I am doing this so that I can adjust the frequency of the counter (i.e. sample clock) on the fly.  I write new frequencies using DAQmx Write VI - Counter Freq. 

 

The issue is that when I Stop and Start the counter task (i.e. pause and unpause) the counter frequency reverts back to frequency selected when the virtual channel was first created (at DAQmx Create Channel VI - Frequency input). 

 

So the recent counter frequency value is lost.

 

Is there a way to resolve this?

0 Kudos
Message 11 of 17
(794 Views)

Can't test this now, but maybe try re-writing the new freq / duty cycle while the task is stopped and before re-starting it?

 

If that doesn't work, I remember being in a thread with some similar subtle and unexpected behavior.  Unfortunately, I couldn't seem to find it just now.  I'm also not sure it ever fully resolved.  But if my suggestion doesn't work, reply back and I'll search a little harder.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 12 of 17
(772 Views)

Thanks, I tried stopping the task and writing the frequency and received the following error.

 

BigApple0_0-1646608132642.png

 

I also tried using the Control Task VI to change the state manually and that didn't work either.  I got the same error.

 

Lastly, I tried just writing 0 as the frequency value and that didn't work either (apparently the frequency must be a minimum non-zero value).

 

 

I even tried adding a task wait and delays before re-starting the counter task and got the same error.  This almost seems like a bug or something.

 

 

0 Kudos
Message 13 of 17
(754 Views)

Your posted -200301 error is a known limitation and has been as far back as I can remember.  Not a bug that might be resolved in a different driver version or something.  Though I admit some surprise that stopping the task before changing the frequency wasn't enough to prevent it.

 

What's the specific situation where you define one pulse frequency but then need to change it before issuing any pulses?

 

Clearing the CO task and reconfiguring it should still work, but that adds quite a bit of overhead.

 

Can you post the version of your code that led to the -200301 error?   It'll be helpful if you use "File->Save for Previous Version" back to LV 2016 or so.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 14 of 17
(739 Views)

The specific use case is the same as the original poster.  I need to stop the waveform at the current sample and start it back up again where it left off.  The counter is used to change the frequency of the waveform on the fly.

 

I find DAQmx has a lot of quirks to get things working accurately.  I will try posting the code tomorrow.

0 Kudos
Message 15 of 17
(730 Views)

Speaking of quirks...

 

Some more forum searching showed that I ran into something at least very similar about 15 years ago.  The take-away message there was to change the counter freq using a DAQmx Channel property node rather than by calling DAQmx Write.  (Note: if you want to update both freq and duty cycle with a property node, you need the duty cycle to be higher in the property node and the frequency lower.  Properties are set in top-to-bottom order, and duty cycles are not applied until you write a frequency value, whether or not it's different from the previous freq value.)

 

My not-entirely-trustworthy memory tells me that calls to DAQmx Write *might* work for some devices (M-series maybe?), but not others.  Best to stick with the property node.

 

More searching yields conflicting info in another 15-year-old thread based discussing even older E-series hardware.   There I referred to advice from NI that the use of DAQmx Write was preferred over the property node.

 

All in all, it seems the suitability of using DAQmx Write may be dependent on DAQmx version and device model so again, it's probably safest to try the property node approach.

 

Please do still post the code though.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 16 of 17
(725 Views)

Thanks for the tip!  I'm going to give that a shot.  

 

Another thing that I'm wondering is if I can change sample mode from continuous to finite on the fly via a property node.  That way the counter will stop on its own.

 

This post gave me the idea where they advise to change the retriggerable setting from TRUE to FALSE in order to check the task done bit.


https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Qo9SAE&l=en-US

 

 I wonder if the same can be done with the sample mode property.

 

Edit: Heres an example that looks almost exactly like what I want.  It uses a property node like you mentioned.

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kHjoSAE&l=en-US


 

0 Kudos
Message 17 of 17
(722 Views)