03-05-2022 04:25 PM - edited 03-05-2022 04:28 PM
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?
03-05-2022 10:12 PM
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
03-06-2022 05:11 PM - edited 03-06-2022 05:21 PM
Thanks, I tried stopping the task and writing the frequency and received the following error.
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.
03-07-2022 07:35 AM
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
03-07-2022 05:50 PM
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.
03-07-2022 06:59 PM
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
03-07-2022 07:12 PM - edited 03-07-2022 07:51 PM
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