REQ: Example of Dig Pulse Train where PWM varies.

[hecmar.arreola]

Hi!

I'm setting up a temperature controller.  I want to use the counter output of my DAQmx compatible device to create a PWM signal that drives the relay to my heater ban.  A PID controller VI will be used to set the PWM value (0-100%) of the counter output.  I have attempted this several times now, and my resulting code was always buggy to say the least.  Issues I've run into:

1. PWM Counter output does not allow 0 or 100% output. As a matter of safety, 0.0000001% or whatever is just not close enough to 0.

2. "Task not complete" errors when trying to change the PWM value for the "DAQmx Write - Counter Freq 1Chan 1Samp".

I've been through the examples provided by NI for setting up PWM in LabVIEW, but I can't find a good example of what I am trying to accomplish. 

Attached is probably my best (error prone) attempt.  The DAQmx stop/start VI's within the conditional blocks are my attempt to get a 0% output. I get error #2 on my list a lot with this code.  Also, the observed output doesn't always seem to be correct...

I'm tempted to use a quad-packaged opamp to make a PWM circuit that is driven by the Analog Output.  Sadly, diving into analog seems a lot simpler than working out my program errors.  Perhaps my approach is way off.  Any help would be greatly appreciated.

Thank you for your input.

-Nic

[jdpowell]

There's another conversation going on about the same issue (USB 6210 temperature control using thermocouple feedback) that you might want to look at.  

Do you really need the hardware-timed PWM output?  You can turn your power on and off in a simple software loop running at a few Hz (and if your heater relay is mechanical rather than solid-state, you don't want to turn it on or off more than once per second or you will wear it out).  

-- James 

[hecmar.arreola]

Well, the DOs are all used in conjuction with other tasks in my project (driving solenoid valves).  It would be a little complicated to tap into my DO DAQmx Task to perform this operation that is seperate from all my other DO operations.  (It would be, in some sense, breaking my design pattern there... but I will think about it some more).

It also seems like there are these built-in counter things on my multi-functional DAQ device from NI.  Part of their advertised function is to "easily" make a PWM pulse train.  If it were as simple as I would have expected it to be based on the specification NI published about the device I am using, this should all be a rather trivial matter.  But it is not.  Frankly I can wire up a quad-packaged OpAmp in a lot less time, and I'm thinking I'm going to go that route...

My Heater Ban is driven using a SSR.

I will go through the link you provided to see if I can find any answers.  Thanks for your input.

[jdpowell]

Well, I hope you have a good reason to use a design pattern that breaks if you add one thing, or to use hardware with not one single spare DO channel.  I also need to control solenoid valves, run heaters under PID control, etc., etc., and I make sure to use design patterns that are as scaleable and modular as possible.  The users of my software are constantly asking for yet-one-more solenoid valve to control, or detector to monitor, or temperature to control, and it's good to be able to add them in a few minutes.  

I suspect, BTW, that DAQmx is relatively easy to use to set up hardware PWM pulse trains; however, if you don't need the precision or speed of hardware PWM, a software solution may be simpler.

BTW what is a "heater ban"?

-- James 

[hecmar.arreola]

Heater band.  Ever spell anything wrong before?  I have.

[hecmar.arreola]

Ok.  It looks like my hardware allows me to run 2 seperate DO DAQmx tasks simultaneously.  I thought I wouldn't be able to based on problems with trying to do this with Analog Inputs in the past.  That will make writing the software a lot easier as I can have my temperature controller code running in a seperate thread than my state machine code.  Thanks for your help.

[jdpowell · Accepted solution]

I believe that's because the Analog Inputs on most DAQ hardware is multiplexed, meaning there is only one ADC shared by all the channels, thus one can't have two independent measurements going on.  Similarly, if a complicated task requires counters (and there is often only two of those) then you're limited in what can be done at once.  But simple DO tasks should be very independent of each other, since they don't tie up common resources.  In a way, DAQmx makes things too simple, since it's not always obvious what hardware resources each task is monopolizing.

No offense on the "heater ban" thing.  When you used the phrase the second time I wondered if it was a special type of equipment that I wasn't familiar with.

-- James 

[hecmar.arreola]

Ok, here is what I ended up with.  Some troubleshooting/performance testing items are still in my block diagram but the thread plays nicely with my other DO thread which drives my state machine.  It works very nicely.  The way I'm handling the Digital Waveform array creation could probably be done in a more conservative way...but since the thread is only executed once a second there is not much of a CPU load to worry about.  One negative side effect of this code, however, is that it will only work on "buffered" DO (I think)...so that is fine for my M-Series targets....I'm going to have to re-think it when I face similar trials with an E-Series target.

[nathand]

---

1. PWM Counter output does not allow 0 or 100% output. As a matter of safety, 0.0000001% or whatever is just not close enough to 0.

2. "Task not complete" errors when trying to change the PWM value for the "DAQmx Write - Counter Freq 1Chan 1Samp".

---

You can get the PWM outputs to work the way you want, and you'll then be able to run your code on any DAQmx device that has counter outputs.  Two tricks:

1. As I think you discovered, stop the DAQmx task in order to set the output to 0.

2. In order to set the frequency and duty cycle while the counter is running, you use a different function than you use when the counter is not running.  If I remember correctly, you need to use DAQmx Write when the counter is not running; when it is running, use a DAQmx channel property node (dig around a bit and you'll find the properties for frequency and duty cycle).  I have no idea why this is necessary but it works.  In my code I wire the output of "DAQmx Is Task Done?" to a case structure that determines whether to use the property node or DAQmx Write to set the frequency and duty cycle.  I don't have a copy of that code write now but if I can find it in the morning I'll post it.

[hecmar.arreola]

Thanks nathand!  I would really appreciate that.  My immediate needs are met by using a buffered DIO pin.  However, most of my applications run on hardware that does not have buffered DIO but does have counters.