LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Digital Output frequency seems to be twice of the frequency generated by basic function generator

Solved!
Go to solution

Hi Labview forum,

I wrote a Labview program (attached below) to generate 3 PWM, square wave, signals that has the same frequency and right delay phase (so that when one signal is off, the other signal turns on. Then the next signal). Everything seems to work correctly except that the frequency of the generated PWM signals seems to twice as much as the frequency given to the basic function generator. Anybody has any idea as to why this is happening? Anyhelp would be greatly appreciated. 

 

Thank you!

0 Kudos
Message 1 of 9
(3,334 Views)

Hi waterox,

 

the (update) frequency of those digital output signals is determined by the wait functions in your loops!

 

Which hardware do you use?

When it supports (output) counters you should use them to output PWM signals.

When it supports hardware timed digital outputs you use this feature to output signals with accurate sample rates!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 9
(3,321 Views)

Hi GerdW,

I have a NI PXIe-1078 chassis, with NI-PXIe8135 embended controller. I'm using a SCB-68a connector pannel attached to PXI-6225 slot. 

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

Even with 1ms wait time, my for loop should not have taken 2 seconds to finish each iteration. The size of each of the array input is 1000. The for loop should be running around 1 second per loop, not 2

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

Hi waterox,

 

The for loop should be running around 1 second per loop, not 2

Why do you think so?

You have a loop that iterates 1000 times. In each iteration you write a value to your device - this takes time and probably more than you expect! Additionally you wait for a millisecond and check the execution time two times. (Why two times?)

 

To sum up:

- using DAQmxWrite with "1 Channel 1 Sample" is the slowest option you can use for this function.

- it should be even the wrong option as you want to set 3 channels, not just one!

- all timings on your PC are influenced by the OS - and Windows will influence your loop with a big jitter!

 

Recommendation: use hardware timing as much as possible, either counter outputs or hardware-timed DOs!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 5 of 9
(3,267 Views)
Solution
Accepted by topic author waterox

 

Fully agree with all GerdW's advice that hardware timing from your daq device will be much more reliable.  That said, part of what you're probably bumping into is a little quirk of the msec delay primitives.   Requests for 1 msec have long been particularly unreliable (though they *seem* to have improved in recent years, probably due to better OS support in Win 7 or something).

 

I made minimal mods to your code with comments to switch you over to a Timed Loop.  My quick testing showed it to be pretty good at hitting the 1 msec target loop period.

 

 

-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 6 of 9
(3,243 Views)

Hi Kevin, 

would you kindly save your adjusted program to Labview version 2012 (12.0.1) or older? Greatly appreciated.

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

HI GerdW,

Thank you for solidifying my suspicion. I thought that was maybe the case that cause the loop to run 2 seconds. This is a good lesson. I will follow your recommendations. Thank you! 🙂

 

 

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

Hi Kevin,

Your modified version worked. Thanks for your help!

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