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!
Solved! Go to Solution.
Rounding errors, possibly?
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!
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.
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! 😄
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!
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. 😉
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.
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?
Issue resolved using this shipped NI example:
Help»Find Examples»Hardware Input and Output»DAQmx»Analog Output»Voltage - Continuous Output.vi