LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Digital waveform output duty cycle glitches

Solved!
Go to solution

I'm trying to use a square wave converted to digital output to actuate some solenoids but seeing some issues with the duty cycle on the digital waveform. The frequency of the output will always be on the order of 1 Hz and duty cycle only needs to be adjustable to integer values. I've attached a simplified demo below, which shows the analog to digital output VI I was originally using; the problem with this VI is that if I choose a duty cycle that's not an integer multiple of my samples for the waveform I get glitches. If I use the boolean array to digital VI this issue disappears in my simplified code, but in my actual program the issue reappears.

Digital waveform data demo.png

 

This image shows the analog waveform that's generated as well as the resulting digital output.

50% duty cycle MSB first.png

 

In the digital waveform you can see that the 50% duty cycle is sometimes applied over only one loop iteration (~.2s) rather than over 1s, though the actual load curve shown in the bottom chart seems to suggest that LV is ignoring that glitch (somehow). As I mentioned, the glitch goes away if the duty cycle is an integer multiple of the samples/loop. Loop timing is dicated by other I/O at 2000Hz/400 samples per loop and 100 Hz/20 samples per loop (rather large VI otherwise I'd include it). Obviously I could change these to get 50% as a multiple but this doesn't solve the problem if the user needs to adjust from there.

 

Can anyone point me in the right direction here? I'm sure there's some easy/stupid solution but I can't seem to get it.

Thanks!

0 Kudos
Message 1 of 5
(3,870 Views)

My first guess would be that data is being prepended when it should be appended, so the data is essentially being flipped on each write (i.e. you are probably seeing samples in the following order: 31-45, 16-30, 1-15 -- or perhaps something more like: 15-1, 30-16, 45-31).  

 

It probably looks the way it does because whenever there is a change in state that isn't right on the edge of a waveform packet of data, you'll see the actual reversal, whereas with a solid packet of all 1's or all 0's, you wouldn't actually notice anything.

 

Paul P.

Applications Engineering

 

Highest Regards,

Paul
0 Kudos
Message 2 of 5
(3,823 Views)

Thanks for taking the time to reply. The idea that it is prepending makes sense from what you've said. Maybe I'm just being especially dense, but I don't see how I can resolve that though. Any tips?

Thanks.

0 Kudos
Message 3 of 5
(3,817 Views)
Solution
Accepted by topic author johnnyfear

You could try switching the A and B waveform inputs on the Append Digital Samples VI.  It looks like A should be the data coming out of the shift register (the original data) and B should be the data appended (the new waveform) anyway, at least conceptually.

 

Paul P.

Applications Engineering

Highest Regards,

Paul
Message 4 of 5
(3,813 Views)

Ah, that's easy enough (and obvious enough, duh). That did fix the issue shown on the digital waveform chart, and explains why the "glitch" wasn't reflected in the actual load curve. The problem that remains, though, is that while I can get things working properly in this stand-alone case, I still get the erroneous duty cycle if my samples per loop iteration isn't an integer multiple of my duty cycle. I'll try to dumb down the main VI enough to post here while not stripping too much to alter its actual performance.

Thanks again for the help.

0 Kudos
Message 5 of 5
(3,808 Views)