PID/PWM for temperature control in a box

[HessenMob]

Hi,

This topic seems to come up quite often, but so far previous threads havent helped me too much:

I need to keep the temperature in an insulated box constant for a few hours. I use a PT100 probe to measure the temperature and a 10W heating element to heat the box interior.The output of the PT element is a voltage and I would like to use PID to feed a setpoint voltage (which corresponds to some temperature) to the heater using PWM. The PWM signal would close a solid state relay in the circuit and thus provide the heater with a current to start heating.

I am using a PCI 6221 card and external power supplies. Right now, I have the PT100 voltage coming in on AI 0, and the pulse being fed out at AO 0.

The closest I have gotten to getting some sort of signal is using PWM-Analog output.vi, which I have modified by replacing the proportional node with the PID.vi from the LabView 8.5 toolkit. I have played around with it for a while, but I'm not even sure this would be a right approach to read in the PT100 voltage and control the PWM signal to the heater. 

Any suggestions? vi's? My version is attached below...

Has anyone done something similar?

I would really appreciate some help!

Thank you

[nathand]

You're on the right track.  Here are a couple of suggestions:

1) Do all the temperature work in temperature units.  Scale the analog signal coming from your PT100 to a temperature, and provide an actual temperature as the setpoint to the PID function.

2) Your 6221 has 2 counter/timer channels which can output PWM signals.  This is simpler than generating a PWM signal with an analog output.

3) Set your output range to 0-100%, since there's no meaning to a negative duty cycle.  Remove the EGU to Percent function.

4) Make sure you know how to tune your PID loop.  For a slow system like a heater, look at Cohen-Coon tuning or the Ziegler-Nichols open-loop method which is documented in the PDF help for the PID toolkit.  It's pretty easy to do, just make sure you get the units right  (be careful, the I and D parameters expect times in minutes, not seconds).

[HessenMob]

Hi nathand,

Thanks for the quick reply!

I am going to incorporate your suggestions and let you know how it goes.

Thanks

[HessenMob]

Does anyone else there on the forum have any suggestions?

[HessenMob]

Hi nathand,

I have incorporated some of your suggestions, but some more questions have arisen in the process (as seems to always be the case):

1) The PT100 element is in a wheatstone bridge circuit. As mentioned, I measure a voltage drop across the wheatstone bridge and previously have fed this voltage into the PID loop. You suggest to convert the voltage to a temperature, which I can do in theory. How do I then tell the AI channel (which measures the voltage drop across the bridge) to use the corresponding temperature instead?

2) I have changed the output to the counter. See attached vi below. I had to take out the DAQmx Write node because it gave me an error otherwise. To keep it in, I would have to give another set of setpoint and frequency controls...

3)Done and done.

4) I have not attempted this yet, but will fiddle around and see how it goes...

Thanks again for any input, I appreciate the help!

[nathand]

I was suggesting that in your LabVIEW code, do the math to convert your voltage drop into a temperature.  The AI channel stays the same, it's just the input to the PID loop that changes.  The PID process variable and setpoint both need to be in the same units (of course), and it seems to me it will be simpler if those units are temperature rather than voltage.

You need to change DAQmx Write to a counter instance and set it to frequency so that you can change the duty cycle on the fly.  Eliminate the Compute Square Waves function, the counter does that for you.

In the interest of simplicity, you could also remove DAQmx Wait for Next Sample Clock and replace it with a simple wait.  You're controlling a relatively slow process so you don't need your loop to run very fast.

[HessenMob]

Hi,

I have made some changes, including using now the  PWM-Counter Output.vi. 

I do get a signal, as the picture below shows, but there are some errors which come up and the setpoint value I input is very strange.

1) I still have to make the voltage to corresponding temperature conversion, but for right now just inputting a voltage value as a setpoint (this range is 0 - 0.04[V]), the setpoint immediately recalculates that value and gives me 10E-18 value or something similarly rediculous as a value. Anyone see this before?

2) I took out the "In Range and Coerce" function in the case structure, since this would literally coerce the PID output to be the "output high" value of the PID Output values. As a result of that, I suddenly started seeing a signal int he picture.

3) I replaced the  "DAQmx Wait for Next Sample Clock" as suggested by nathand, and put a Wait instead. I do get an error every now and then:

Error -201021 occurred at DAQmx Write (Counter Frequency 1Chan 1Samp).vi:3

Possible reason(s):

Measurements: Write recovery could not complete before detecting another Sample Clock pulse.
Reduce the Sample Clock rate, increase the frequency of the generated pulse train, or set Write Recovery Mode to Poll.

Task Name: _unnamedTask<3985>

Any way around this? Where is the Write Recovery Mode, and what is Poll? I did fiddle with the frequency and such, but I dont know how to give it a lasting solution.

My vi is attached below, as well as a screen-shot of what I get with the vi.

Suggestions are welcome of course!

Thanks!

[nathand]

You're making some parts of this too complicated.  There's no need for DAQmx Timing on the analog input and definitely no need to tie the input sample clock to the counter output.  For the counter, set DAQmx Timing to an Implicit instance and the mode to Continuous Samples.  Simplifying the timing should eliminate the errors.  Also, why do you have frequency set to such an enormous value?  You'll be fine with a frequency of 1Hz or so.

You're getting the "ridiculous" setpoint values because of the way you configured the input limits for the setpoint control.  If you look at the properties for it you'll see that the "increment" value is set to 1.  This means it only accepts multiples of that value, so when you put in 0.03 (for example) it rounds that to 0, except that some quirk in the rounding algorithm combined with the implementation of floating point numbers leads to a value that is very close to, but not exactly, 0.  Make the limits more sensible (or just check of the Use Defaults" button) and that problem will go away.

[HessenMob]

Hi nathand,

Thanks for the reply and the suggestions!

Again, I have changed some things, this time using a little sub-vi PID, which I use instead of the PID.vi given with the 8.5 toolkit. By using this vi I can actually get a signal, however tuning is (as always, I'm assuming) a tricky business. I have gotten rid of the DAQ Timing on the analog input and made the counter timer to continuous sample. Thanks for pointing out the settings to change the 'rediculous' SP values.

The real problem I see now is that even if the PID output is greater than the SP (if I squeeze the PT element for instance), the pulses are still being generated (I have CTR 0 OUT hooked up to an oscilliscope instead of the heater for now). In fact, I suspect that the counter is just outputting the pulse signal set in the DAQ Create Channel (in this case 1Hz, 0.5 duty), since the pulses dont change frequency or duty cycle at all. I have no idea why it isnt updating with what is being output by the PID (turning off the signal if above the SP etc).

Also, the PID output (in red on the images attached) is incredibly noisy. If I were to read purely the PT100 signal voltage (in a separate vi I have) this is very smooth. Any ideas how reduce the noise of the signal of the PID output, or is this normal?

Thanks! Suggestions are welcome of course!

[nathand]

I haven't had problems with the PID loop from the toolkit; I suspect your problem is somewhere else.

Unfortunately I don't have access to an NI card with a counter/timer on it right now to write some sample code, but since you have an oscilloscope available, a good start would be to make sure you can vary the duty cycle by wiring it to a control on the front panel rather than to your PID output.

Once you have that working, start looking at the rest of your code.  Does the "equal within tolerance" function ever return false?  In the screenshot it looks like you set your output range between 0.4 and 1.04, but then when you write to the counter duty cycle you divide by 100 - is that what you meant to do?  Your duty cycle will never go over 1% that way.  Also, there's a DAQmx property node for setting the frequency and duty cycle.  I think DAQmx Write is the correct way to do it, but if that doesn't seem to be working, try the property node.