cDAQ software PWM options

[douwe123]

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

[GrantFishburn]

Hi Douwe,

I have two questions for you about this.

1. With regard to option (3), were you always seeing that sawtooth wave?
2. Are there any changes being made between writing to the CurrWritePos property and the TotalSampPerChanGenerated?

[douwe123]

---

@GrantFishburn wrote:

Hi Douwe,

I have two questions for you about this.

1. With regard to option (3), were you always seeing that sawtooth wave?
2. Are there any changes being made between writing to the CurrWritePos property and the TotalSampPerChanGenerated?

---

1) Yes, the sawtooth pattern is ongoing.

2) The CurrWritePos and TotalSampPerChanGenerated properties are only being read, not written to. The only activity is that about every second, 1000 samples are written using the DAQmx Digital Write vi.

[GrantFishburn]

Hi Douwe,

I believe that you should be able to modify the continuous counter output. However, you will be limited to how many tasks can be run on your cDAQ chassis.

How Many Different Tasks Can Concurrently Run on a CompactDAQ Chassis Gen II?

http://digital.ni.com/public.nsf/allkb/5E0B829E50ADE1BC86257AC50062B2D2

[douwe123]

@GrantFishburn. I'm not sure what you mean here. I'm not using counters.

[douwe123]

Ok, just to continue with the story. I ran a test where I kept writing to the digital module and tracked the low and high points of the TotalSampPerChanGenerated. This test was done with a cDAQ-9184 chassis and a 9401 module.The results are below. It looks like the high point is always slightly less than 3*2^32 and the low point is always slightly greater than 2*2^32. So for this system I guess I'll use those as the "turnaround points" to keep track of the actual total samples generated.

8589939948	12884850892
8589940434	12884871051
8589941998	12884871939
8589943441	12884872100
8589945784	12884880705
8589947655	12884881058
8589949142	12884882199
8589969892	12884882314
8589974406	12884882458
8589976052	12884883220
8589978157	12884883429
8589986258	12884886486
8589988726	12884888337

[GrantFishburn]

Hi Douwe,

Sounds good, we'll see how those compare to the actual samples