This post outlines some of the options for generating a PWM signal using cDAQ hardware without using counters and hopefully others will be able to provide further insight, options, and details.
For my application I need to generate a PWM signal at 1kHz and update the duty cycle about every second. We need to control 30 signals, so we decided to use a 9477 digital output module with a cDAQ-9184 Ethernet chassis. Our system needs to operate for a long time (6 months) without interruption, which means we need a reliable solution. Considering the high channel count, we decided against using digital output modules that can use counters and PWM features (which would have been much easier).
Since we obviously can't write each sample individually at 1kHz, all the options send a 1000 sample array to the digital module to be generated at 1kHz (set with the timing vi). A new 1000 sample array needs to be written to the module every second. If the new array is written faster than once a second, excess data will be in the buffer and there will be a lag between a change in the duty cycle and the actual output. If the data is written slower than once a second, there will be a buffer underrun error and the Task will stop. Below are some options for performing such a task.
Option 1) The most appropriate method would be to set the output buffer size to 2000 samples and use the DAQmx write vi to write the 1000 samples. The DAQmx write vi will wait until there is sufficient space in the buffer to write the 1000 samples and then write the samples. Unfortunately, setting the output buffer size to 2000 has no effect when using the cDAQ 9184 chassis. Apparently there is a 12Mb onboard buffer that is used to its maximum capabilities, regardless of what is specified in the output buffer size property node. This means that the DAQmx write vi will run many times without pausing until it fills up the 12Mb buffer. When the 12Mb buffer is full, it starts running once a second. This creates an enormous lag in the system and is not really functional
Option 2) Write the 1000 sample array at 1Hz using a software timed loop using the Wait Until Next ms Multiple function. In this case the system is relying on the software (Windows) clock to be synchronous with the hardware (cDAQ) clock. If the Windows clock is faster, the buffer slowly fills up. If it is slightly slower there will be an underrun error. The hardware clock specification of the cDAQ 9184 chassis is 50ppm, which is 130 seconds every month.
Option 3) Create and manage a homebrew "buffer" by keeping track of the current write position in the task (CurrWritePos property node) and the number of samples generated by the task (TotalSampPerChanGenerated property node). In this option, the WritePos and SampGen properties are monitored and if the SampGen value is within 1000 of the WritePos, write another 1000 samples to the task. This option works, but has at least one caveat.
I tested this setup to see what would happen when the values of the property nodes got large (I don't like surprises when my actual system is running). The CurrWritePos property kept increasing as expected up to a value of 1.66E11 when the test was terminated. The TotalSampPerChanGenerated property node did not behave as expected. This value incremented up to 1.289E10 at which point it dropped down to 0.8590E10 and start incrementing again until it reached 1.289E10. It kept incrementing using this same sawtooth pattern.
Option 4) Start and stop a task that only writes 1000 samples each time. This method does not buffer the data and wouldn't lead to a continuous PWM signal.
Conclusion, Option 3 is the only the only way I can get my system to work, I just have to account for the unexpected sawtooth pattern of the SampGen value.
I have asked NI how best to perform this PWM task and haven't really received satisfactory answers. They were unaware of the inability to specify the output buffer size on the cDAQ hardware and they were not aware of the sawtooth pattern of the TotalSampPerChanGenerated property.
This is as much a way of documenting my findings so that others can learn from them as a request for further insight on continuous digital sample train generation on the cDAQ platform.
tldr: Generating continuous software timed PWM signals with cDAQ is a pain. The best method (I think) is to use the CurrWritePos and TotalSampPerChanGenerated properties to keep track of when to write the next batch of samples. The SampGenerated property does not always increment; it has a sawtooth pattern.
Regards,
Douwe