PWM Duty Cycle Offset due to hardware limitation? NI-9472

[pallen]

Testing an NI-9472 using PWM code based on example found at link below. 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000x1P0CAI&l=en-CA

Measured output appears to be indicating an offset in Duty Cycle timing that increases linearly as PWM frequency increases.   

NI-9472 has rated output rate of 100uS   

Testing appeared to indicate a 17% difference in commanded Duty Cycle at 1kHz Frequency, and roughly twice that at 2kHz.  

I believe this module should be capable of 10kHz output.  Is this kind of difference in measured Duty Cycle likely a limitation of the module's output rate? 

Any feedback very much appreciated!

[Kevin_Price]

This Q's been hovering here a while so I'll offer up a couple guesses.  Not totally educated but not purely WAGS either.  Caveat: I don't have any specific detailed knowledge about the 9472 module.

Are *all* duty cycles biased the same amount in the same direction for a given PWM frequency?  Or do you have a particular frequency you need to generate and certain specific duty cycles to try to hit?

Here's some of my thinking:  the 9472 is apparently rated for DO output at 100 usec intervals.  Maybe DAQmx takes that into account when you try to route chassis counter PWM out through the module.  If so, then it can only work with interval times that are an integer multiple of 100 usec.

    Your low and high times for a 1 kHz PWM would then need to be 1-9 such intervals each.  Duty cycle would have to be some multiple of 10%.  So if you ask for 25%, you'd actually get either 20% or 30% due to limits of discretization, an error of +/- 20% of the target.

    Similarly, PWM at 2 kHz restricts you to 1-4 100 usec intervals each and duty cycles that are a multiple of 20%.

Now that doesn't sound *quite exactly* like the symptom you described, but it's a direction of thinking that might help explain things.  Perhaps the reality is that DAQmx *doesn't* account for module speed limitations and tries to generate much finer duty cycle resolutions with its internal counter.  Then as the signal passes through the module, the timing gets discretized a little differently than the 100 usec the spec guarantees to be possible.  After all, the device would be designed to have some operating margin compared to the spec.   Maybe you get different limitations for rising vs falling edges even.

So the whole thought is kinda half-baked, but it seems pretty plausible to me that discretization is playing an important role here.

-Kevin P

[pallen]

Hi Kevin, 

Thanks for your reply! 

The "offset" of the measured Duty Cycle was always biased in the same direction, (longer On time) and the offset grew nearly linearly as Frequency was increased.  

Increasing the Duty Cycle would also slightly increase the offset time at a fixed frequency.  

This particular customer was willing to upgrade their hardware for better performance, so I asked if NI Support could test to see if they found the same offset with the 9472, and if it improved with the 9474. 

NI Support was able to confirm the offset we were seeing on the 9472, and confirm that the customer would be able to achieve their desired frequency with the 9474 with improved Duty Cycle accuracy.  

For now, I implemented an Offset Lookup Table that can be used to "tune" the output with enough accuracy to satisfy the current round of requirements.