LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Duty cycles skipped over when increasing by 1% increments?

Solved!
Go to solution

Hello,

 

I appreciate you reading my post. When varying the duty cycle of a square waveform by 1% increments (0-100%), I'm unable to access 37% and 74%. These two numbers are multiples, so I suspect there is something I'm misunderstanding.

 

For some reason, selecting 37% results in 38%, and selecting 74% results in 75%. All other duty cycles are accurate when selected (including 36%, 38%, 73%, and 75%). In effect, 37% and 74% are skipped over. All duty cycles were measured with an oscilloscope.

 

Sampling rate is 1,000,000 with the number of samples set to 100. This achieves the desired waveform frequency of 10,000 Hz (measured with oscilloscope to be 10.00kHz, as expected). Rate and samples were chosen to enable 1% duty cycle increments from 0-100%. But 37% and 74% are not accessible. Why is this?

 

Thank you for your help!

 

Capture.PNG

0 Kudos
Message 1 of 9
(495 Views)

Rounding errors, possibly?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 9
(472 Views)

Thanks for your response. Do you know where the rounding errors might be occurring or how to test this idea? Or perhaps a workaround? All duty cycles measured with the oscilloscope were within 0.02% of their expected value (0-100%) besides 37% and 74%.

 

I'm using a NI USB-6259 device if that's relevant. Thank you!

0 Kudos
Message 3 of 9
(467 Views)

The problem is in the square wave generation, as you can easily test (see picture). However, since the core code is a inside a dll, there is no way to tell what's happening.

 

altenbach_0-1627262095319.png

 

Of course using the square wave tool to generate 100 points where a percentage is 5 and the remainder is zero seems like a trivial array operations. No need to complicate things, right. Try it! 😄


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Message 4 of 9
(447 Views)

Thank you, altenbach! Your example elegantly illustrates my issue. I successfully generated a single period of the desired waveform using arrays. My question now is how do I continuously write this period at 10kHz to my DAQ’s analog voltage output? I think my VI is only writing the period once as opposed to writing it 10,000 times per second. I’ve looked through countless other posts and tried learning without success. Any help would be much appreciated!

 

Capture2.PNG

0 Kudos
Message 5 of 9
(391 Views)
Solution
Accepted by topic author Big_Blue

The simplest "solution" would be to keep the original code and just replace [Y] of the waveform before sending it to the hardware.

(Assuming that the original code was working fine otherwise). Most likely you can even replace the other elements of the waveform with simple known values, completely eliminating the square wave monstrosity. 😉


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Message 6 of 9
(380 Views)

That did the trick, thank you, altenbach! I was able to get everything running using the array waveform and DAQ Express.

 

With that working now, I would finally like to replace the DAQ Express with a predetermined, initialized output channel. Would you be able to comment on why my VI (pictured below) isn't working? The signal was correctly being written using DAQ Express (checked with oscilloscope), but nothing is happening now. I was able to select the desired AO channel from the dropdown menu.

Thank you!

Capture4.PNG

0 Kudos
Message 7 of 9
(324 Views)

Hi Blue,

 


@Big_Blue wrote:

Would you be able to comment on why my VI (pictured below) isn't working? The signal was correctly being written using DAQ Express (checked with oscilloscope), but nothing is happening now. I was able to select the desired AO channel from the dropdown menu.

"Nothing" happens? You don't even get an error message?

Did you probe/debug your VI?

 

How should we help when you attach just an image? We cannot debug/run/edit images using LabVIEW!

 

I guess you should not start the AO task before writing data into its buffer.

Why do you even call DAQmxStart when you set the AutoStart flag at DAQmxWrite?

Best regards,
GerdW


using LV2020 on Win8.1+cRIO
0 Kudos
Message 8 of 9
(311 Views)

Issue resolved using this shipped NI example:

Help»Find Examples»Hardware Input and Output»DAQmx»Analog Output»Voltage - Continuous Output.vi

0 Kudos
Message 9 of 9
(251 Views)