From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Single Sample Analog Output without using the analog input clock for a hardware timed loop?

Solved!
Go to solution
Solution
Accepted by argolds

Thanks, but truth be told I benefit quite a bit from participating too.   Nothing like needing to explain something to help clarify one's own thinking.  Plus, you never know when and where the next useful tidbit might show up.

 

Anyway, figured I'd backsave (to LV2013 - so I could re-open it and make sure it was ok) and repost.  It isn't much different than the example, but if we need to compare notes, it's better to have exactly the same code instead of almost.

 

 

-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 11 of 13
(791 Views)

SOLVED!

 

The short answer was that I needed to use DAQmx Wait For Next Sample Clock.vi to make the loop, in effect hardware timed.

 

But I cannot use the DAQmx Timing (Sample Clock) vi because I use a GPS disciplined DDS to create a backplane clock of 18 MHz.  I use this frequency because it divided evenly into electrical power nominal frequencies of both 50 Hz and 60 Hz.

 

I have attached a further modified LV 2014 example using the DDS (it can be used with an onboard clock and 20 MHz PLL Frequency so you can try it without a GPS card/antenna if you have a timing card such as a PXIE-6674T).  I had to replace DAQMx Timing.vi with the property node because instead of referencing a timing source, I need to reference the timebase source and rate.

 

Note, I know that using a Star bus is more accurate than using a trigger, but I have issues with the Star bus because different PXI chassis route different star busses to different cards so using the Trig signals is more portable.

 

Kudus to Kevin!

Message 12 of 13
(781 Views)

Thanks for posting, I learned a little something new from your use of the DAQmx Timing property node.  I don't often explicitly configure the timebase but whenever I have, I've always configured the integer timebase divisor property explicitly and then queried for the resulting sample clock rate.  (Coincidentally, I happened to do just that in a very recent thread.)

 

It would have been more straightforward to do it your way by simply configuring the (requested) sample clock rate and letting DAQmx find the nearest integer divisor for me.  I just had never tried it to see that it could work.   Probably a holdover from first learning the technique in the pre-DAQmx days when I'm pretty sure you *did* have to define the integer divisor.   I had found a way that worked and stopped looking for better ways.

 

 

-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 13 of 13
(773 Views)