The big TEC driver thread!

Quote:

---

Originally Posted by dnar

Ok Sleepless in Germany, I'll have a butchers hook over the next few days. Time to get drunk as it's my 47th orbit of Sol today. I would not like to see this finalised until V1.0 is nailed.

BTW, with your Maxim choice, take a look at pricing. The MAX233 is something like 3 x the cost of MAX232A.

---

Well happy birthday to you dude.... 47... those were the days my friend (I'm 52). Wish you all the best and I'll drink one on your birthday on this side of the Globe.

Jeah I did compare prices on the 232 and 233. Here the 232 is about 3€ and the 233 about 5€ max. (the site is down at the moment, can't double check!)

Sure we're gona nail V1.0 first, but I just couldn't see you striding on by yourself to V2.0. Maybe I'll just send both to ya for your sleepless nights.

Cheers!

Quote:

---

Originally Posted by dnar

Time to get drunk as it's my 47th orbit of Sol today.

---

HAPPY B'DAY dnar....
Have a drink on me...

Jerry

Happy birthday dnar

Cheers,*DZ
Ed

@dnar: Happy 47th, dnar! I'm only 4 years behind you ;)

@solarfire: Some suggestions for the schematics:

v1/v2 - Shouldnt we be monitoring the state of the LMD18200's overtemp line with the micro, not just with a LED?

v1/v2 - Could we add support for an RTD temp sensor, as well as NTC? They are more accurate, and the small ones have VERY fast responses. Not that much more expensive than an NTC therm.

v2 - Better to use a 10 pin header instead of a DB9 connector
v2 - Suggest a MAX231 instead of 233.. Cheaper, very common, same DIP pinout as max232, and only needs 0.1uf caps.
v2 - Remember to tie unused rs232 driver TTL inputs to ground, and rs232 line side inputs to -9v


I have a PCR reactor (VERY fine temp control, better than 0.01C) kicking around at work, so I'll have a look at how it drives its peltier for some more ideas.

Cheers,

Pete

Quote:

---

Originally Posted by lasersbee

HAPPY B'DAY dnar....
Have a drink on me...

Jerry

---

Thanks! I did.

Quote:

---

Originally Posted by Solarfire

Well happy birthday to you dude.... 47... those were the days my friend (I'm 52). Wish you all the best and I'll drink one on your birthday on this side of the Globe.

---

Thanks!

Quote:

---

Originally Posted by megaton

Happy birthday dnar

Cheers,*DZ
Ed

---

Thanks!

Quote:

---

Originally Posted by ogoun

@dnar: Happy 47th, dnar! I'm only 4 years behind you ;)

@solarfire: Some suggestions for the schematics:

v1/v2 - Shouldnt we be monitoring the state of the LMD18200's overtemp line with the micro, not just with a LED?

v1/v2 - Could we add support for an RTD temp sensor, as well as NTC? They are more accurate, and the small ones have VERY fast responses. Not that much more expensive than an NTC therm.

v2 - Better to use a 10 pin header instead of a DB9 connector
v2 - Suggest a MAX231 instead of 233.. Cheaper, very common, same DIP pinout as max232, and only needs 0.1uf caps.
v2 - Remember to tie unused rs232 driver TTL inputs to ground, and rs232 line side inputs to -9v


I have a PCR reactor (VERY fine temp control, better than 0.01C) kicking around at work, so I'll have a look at how it drives its peltier for some more ideas.

Cheers,

Pete

---

Thanks. All good suggestions. I thought the MAX232A was identical to MAX232 except for the 0.1uF caps. I am not expecting the bridge to get hot let alone warm, being a low Rds FET bridge.

Quote:

---

Originally Posted by ogoun

@dnar: Happy 47th, dnar! I'm only 4 years behind you ;)

@solarfire: Some suggestions for the schematics:

v1/v2 - Shouldnt we be monitoring the state of the LMD18200's overtemp line with the micro, not just with a LED?

v1/v2 - Could we add support for an RTD temp sensor, as well as NTC? They are more accurate, and the small ones have VERY fast responses. Not that much more expensive than an NTC therm.

v2 - Better to use a 10 pin header instead of a DB9 connector
v2 - Suggest a MAX231 instead of 233.. Cheaper, very common, same DIP pinout as max232, and only needs 0.1uf caps.
v2 - Remember to tie unused rs232 driver TTL inputs to ground, and rs232 line side inputs to -9v


I have a PCR reactor (VERY fine temp control, better than 0.01C) kicking around at work, so I'll have a look at how it drives its peltier for some more ideas.

Cheers,

Pete

---

Ok.. V1.00 is wrapped up as far as I’m concerned. To the LMD18200's overtemp question, we're all I/Oed out.

And for the RTD temp sensor in V1.00 would require more PCB-Space which is already bigger than I was hoping for. I also did a part cost assessment (Germany), without the PCB, and it comes to roughly 24€. Prices were sourced at hobby level suppliers. Attached are the V1.00 schematic, placement and rout doc’s. The Eagle files won’t be posted until dnar has implemented and tested the Software and confirms the build. If the build and R values confirm some of the trimmers may be replaced with standard 1% resistors.


Also attached, another prelim update of the V2.00 schematic and PCB-placement plan. I ended up using a MAX232A due to sourcing issues here of the MAX231 (special order?), the only supplier which had it stock had it priced 3 fold of the 232A. Can we live with the 232A?


As for RTD temp sensor in V2.00, I’ll have to take a closer look at that one.

Is there a particular reason why everyone is set on a 10 pin header instead of a DB9 connector for the RS232? The pads I’m using are for PCB-Edge mounting (see the Placement plan).


Cheers!


Hey Wayne! How’s the head doing there buddy?*retardo

Nice clean job on the PCB...
I would stay with the RS232 connector. They are easy
to find and cheap to buy and easy to wire..
And if you want to add USB all you need is a standard
RS232 to USB Converter Cable for around $2.00 that
will eliminate the use of extra PCB real estate for USB
connectivity.


Jerry

Quote:

---

Originally Posted by Solarfire

Ok.. V1.00 is wrapped up as far as I’m concerned. To the LMD18200's overtemp question, we're all I/Oed out.

And for the RTD temp sensor in V1.00 would require more PCB-Space which is already bigger than I was hoping for. I also did a part cost assessment (Germany), without the PCB, and it comes to roughly 24€. Prices were sourced at hobby level suppliers. Attached are the V1.00 schematic, placement and rout doc’s. The Eagle files won’t be posted until dnar has implemented and tested the Software and confirms the build. If the build and R values confirm some of the trimmers may be replaced with standard 1% resistors.


Also attached, another prelim update of the V2.00 schematic and PCB-placement plan. I ended up using a MAX232A due to sourcing issues here of the MAX231 (special order?), the only supplier which had it stock had it priced 3 fold of the 232A. Can we live with the 232A?


As for RTD temp sensor in V2.00, I’ll have to take a closer look at that one.

Is there a particular reason why everyone is set on a 10 pin header instead of a DB9 connector for the RS232? The pads I’m using are for PCB-Edge mounting (see the Placement plan).


Cheers!


Hey Wayne! How’s the head doing there buddy?*retardo

---

Hi mate, the heads is ok! I had a big sleep to shake this cold. Runny nose, sneezing all the time and it's 37c here!

I'll checked the files, all good. I did contemplate a separate Vin for the bridge. It could make sense to use 5V for small TEC's. BTW, with MAX232A I have always used non-polarised 100nF caps. I can't recall if this is recommended or not.

I prefer an IDC10 header for several reasons, the PCB size is reduced and you can locate the panel mount D9 away from the PCB easily. Personal preference, that is all. I feel temp monitoring of the bridge is not necessary as total dissipation should be minimal with low Rds FET's hard on or off. Those bridges are designed to switch higher loads at higher voltages than we would ever encounter. It will be interesting to test sans heatsink, as I feel that also won't be a requirement. Look at the Beer Keg controller, a tiny SMD switch, that did not even get warm in my tests to 4A at 12V...

On the subject of NTC etc, I have also used LM35 which provide an accurate 10mV/C. I have not used them in high speed applications however, so can't comment if they are more suitable than NTC in this application. I do like them for the fact you can epoxy the flat face to the heatsink for improved thermal bonding when compared to the curved facets of NTC thermistors.

I plan to spend some time on code for V1 this weekend.

I know you guys all ready have this stuff down to a sience and more than likly have any and all this infomation like the TEC contorler elec schematics and such, bt just in case you don't or some one like me needs it here it is, yes some of it was collected from PL's TEC thread.
I hope this will some what be helpfull to some member here. Enjoy!






Attachment 23682Attachment 23681Attachment 23674Attachment 23675Attachment 23677Attachment 23676Attachment 23678Attachment 23679Attachment 23680

Quote:

---

Originally Posted by dnar

I'll checked the files, all good. I did contemplate a separate Vin for the bridge. It could make sense to use 5V for small TEC's.

---

Unfortunatly this bridge's Vs is 12-55V which is why current limitation is essential!

Quote:

---

Originally Posted by dnar

BTW, with MAX232A I have always used non-polarised 100nF caps. I can't recall if this is recommended or not.

---

In the MAX232A datasheet 0u1 poled caps are used..

Attachment 23683

Quote:

---

Originally Posted by dnar

I prefer an IDC10 header for several reasons, the PCB size is reduced and you can locate the panel mount D9 away from the PCB easily. Personal preference, that is all.

---

Ok.. IDC10 header implemented

Quote:

---

Originally Posted by dnar

I feel temp monitoring of the bridge is not necessary as total dissipation should be minimal with low Rds FET's hard on or off. Those bridges are designed to switch higher loads at higher voltages than we would ever encounter.

---

Yeah.. I don't think so either

Quote:

---

Originally Posted by dnar

On the subject of NTC etc, I have also used LM35 which provide an accurate 10mV/C. I have not used them in high speed applications however, so can't comment if they are more suitable than NTC in this application. I do like them for the fact you can epoxy the flat face to the heatsink for improved thermal bonding when compared to the curved facets of NTC thermistors.

---

For the NTC's I have a 4mm bore between Diode and TEC 8mm into the mount, embedded in thermal compound.

Attachment 23684

this thread is like nuclear physics to me since 30 posts back, but i still do enjy it immensely!!!!!!!!

and a late "happy birthday" to mr dnar with my best wishes to him and his family *DZ

Quote:

---

Originally Posted by Solarfire

Ok.. V1.00 is wrapped up as far as I’m concerned. To the LMD18200's overtemp question, we're all I/Oed out.

---

Fair enough. It would be good policy to connect it up in V2, just because we can. I agree, it probably wont ever overheat under normal circumstances, but still, shit happens, and every info signal is useful when it does.

For the RTD, the PT100 platinum ones are quite cheap on epay, and have exceptional accuracies and (for the small ones that arent encapsulated) stunning response times. Additionally, they are the most linear direct temp measurement sensor known. Also, calibration is unnecessary, since the r versus temp is a known physical function of the dimensioning of (in this case) the Pt100 (platinum, 100 ohms) element. Apart from anything else, this means that one Pt100 sensor will to a very close tolerance, match the output of any other. There is some published standard somewhere that defines all this RTD stuff. Oh, and they are good over an incredibly wide range of temperatures.

Anyway, I think they are good ;)

Usually, an RTD has 4 wires attached, 2 for the DC current flow, and 2 (connected in parallel with the first 2 right at the RTD itself) for measuring the voltage developed across the RTD.

We could look at either a constant current source, or we could just use the supply voltage, pass it through a 1% or better series resistor, and use an A to D input to measure the current being supplied to the RTD. Then we measure the voltage across the RTD with another A to D input, do R=V/I in software, and then we have the RTD resistance, and hence the temp.

An alternative for when the RTD is close to the controller, and I2R losses in the connecting wires is negligible (this is probably the case here), is to just use 2 wires, and have a resistive divider made up of the RTD and the 1% or better series resistor. Then you AtoD the supply rail, and the RTD voltage (assuming the RTD is connected to ground), then do the rest of the calcs in software.

The upshot of all of this is that the hardware required to support RTDs is minimal, especially using the 2 wire method.

Using LM35s, and similar have a whole set of issues, calibration, linearity, resolution, temperature range, response time and thermal coupling. A little known fact is that most if not all these plastic TO92 or metal can TO15 packaged sensors do not readily couple thermally using their case!!! I was shocked to learn this too, since I have used the old TO15 can package several times, and just did what every one else did/does, i.e. clamped the can body to the surface to be measured, with some thermal grease.

In fact, the main thermal coupling mode for these sensors is via the metal leads!!

Hope this all helps...

Cheers,

Pete

Quote:

---

Originally Posted by ogoun

For the RTD, the PT100 platinum ones are quite cheap on epay, and have exceptional accuracies and (for the small ones that arent encapsulated) stunning response times. Additionally, they are the most linear direct temp measurement sensor known. Also, calibration is unnecessary, since the r versus temp is a known physical function of the dimensioning of (in this case) the Pt100 (platinum, 100 ohms) element. Apart from anything else, this means that one Pt100 sensor will to a very close tolerance, match the output of any other. There is some published standard somewhere that defines all this RTD stuff. Oh, and they are good over an incredibly wide range of temperatures.

Anyway, I think they are good ;)

Usually, an RTD has 4 wires attached, 2 for the DC current flow, and 2 (connected in parallel with the first 2 right at the RTD itself) for measuring the voltage developed across the RTD.

We could look at either a constant current source, or we could just use the supply voltage, pass it through a 1% or better series resistor, and use an A to D input to measure the current being supplied to the RTD. Then we measure the voltage across the RTD with another A to D input, do R=V/I in software, and then we have the RTD resistance, and hence the temp.

An alternative for when the RTD is close to the controller, and I2R losses in the connecting wires is negligible (this is probably the case here), is to just use 2 wires, and have a resistive divider made up of the RTD and the 1% or better series resistor. Then you AtoD the supply rail, and the RTD voltage (assuming the RTD is connected to ground), then do the rest of the calcs in software.

The upshot of all of this is that the hardware required to support RTDs is minimal, especially using the 2 wire method.

Using LM35s, and similar have a whole set of issues, calibration, linearity, resolution, temperature range, response time and thermal coupling. A little known fact is that most if not all these plastic TO92 or metal can TO15 packaged sensors do not readily couple thermally using their case!!! I was shocked to learn this too, since I have used the old TO15 can package several times, and just did what every one else did/does, i.e. clamped the can body to the surface to be measured, with some thermal grease.

In fact, the main thermal coupling mode for these sensors is via the metal leads!!

Hope this all helps...

Cheers,

Pete

---

Pt100 platinum resistance delta of a temperature window from 10°C – 30°C (10°C = 103.9 Ohms and 30°C = 111.67 Ohms) = 7.77 Ohms compared to 123k Ohms of the NTC currently in use. In view of 10°C – 27°C being the window of relevance for Laser heating/cooling applications and the up scaling necessary to effectively use a 10bit ADC Input any inaccuracies in the circuit will also be amplified by the same factor, leaving us worse off as with the 100k NTC.


An ideal sensor operating range would be 0°C – 50°C, response time <250ms. Temperature accuracy is less important than repetitive accuracy, since most tunings of laser thermal conditioning is done to achieve highest power output and/or wavelength stability. Of course having an accurate Temperature readout is good to have for statistical purposes such as data logging but it's not really necessary for set point control.


I’m all game for more accuracy but I just don’t see it realizable with a 7.77 Ohm resistance delta for a required temperature window of 10°C – 30°C (27°C). If you can find a suitable sensor with a resistance delta for the temperatures in question I’d be more than glad to implement it.


Cheers!

Happy belated birthday Wayne :) BTW is there a problem with your PM's, I've sent you several of late?

Now to the subject; I think this driver is what I'm going to need for my 12 combiner to keep everything in line. Without reading through the entire thread having just got home from a hell day at work; is this thing double ended i.e. will it control temp in both directions?

Cheers, Hugh Jassfan

Quote:

---

Originally Posted by Doc

Without reading through the entire thread having just got home from a hell day at work; is this thing double ended i.e. will it control temp in both directions?

---

It will both cool and heat :)

/Thomas

Quote:

---

Originally Posted by Doc

is this thing double ended i.e. will it control temp in both directions?

Cheers, Hugh Jassfan

---

Quote:

---

Originally Posted by Badpip

It will both cool and heat :)

/Thomas

---

The hardware accommodates "double ended" control, yes. You had me a bit fuzzled there for a second, I was thinking two girls with a wobbly double ended... err, back on subject. O_o

I will be implementing cooling only PID in the first instance, for the purpose of design validation. "Double dong control" will then follow. I am still thinking about the implementation of double control. Still trying to decided if 2 parallel PID's is the go or a single PID with polarity control. It's not trivial when you actually think about it. I really don't want to provide any form of band gap, but this may be necessary. Any one got any advice in this area?

Doc, I'll check my PM box. I thought we had exchanged a few a while back but not recently.

Quote:

---

Originally Posted by dnar

I really don't want to provide any form of band gap, but this may be necessary. Any one got any advice in this area?

---

I don't think you'll get around having more or less of a band gap due to the inert nature of a thermal control loop. This will mainly depend on how close the proximity of the diode, NTC and TEC are. Otherwise there will probably be heating/cooling oscillations going on. Has to be tested and if so this should maybe be an adjustable parameter in V2.0 since not everyone will have the same positioning of diode, NTC and TEC and therefore different reaction times.

Quote:

---

Originally Posted by Solarfire

I don't think you'll get around having more or less of a band gap due to the inert nature of a thermal control loop. This will mainly depend on how close the proximity of the diode, NTC and TEC are. Otherwise there will probably be heating/cooling oscillations going on. Has to be tested and if so this should maybe be an adjustable parameter in V2.0 since not everyone will have the same positioning of diode, NTC and TEC and therefore different reaction times.

---

Yeah, understood. I was talking about an implemented band gap.

I am concerned about switching from cooling to heating when the process swings either side of the set point.

I am thinking perhaps a band gap between set point and heating...

A few concepts I am thinking about, a couple of diagrams I knocked up to help consider the best way forward.

Attachment 23696
Attachment 23697

Quote:

---

Originally Posted by dnar

Yeah, understood. I was talking about an implemented band gap.

I am concerned about switching from cooling to heating when the process swings either side of the set point.

I am thinking perhaps a band gap between set point and heating...

---

You will need a gap between heating/cooling the questions is just how big; this mainly depends on how efficient the thermal control loop is setup. Cross that bridge when you get to it.


BTW, PCB and material is ordered. It will take about 8 days on the PCB’s and after I get them assembled I’ll get one to you and I’ll have one here so I can follow any possible issues or change necessities..

Quote:

---

Originally Posted by Solarfire

You will need a gap between heating/cooling the questions is just how big; this mainly depends on how efficient the thermal control loop is setup. Cross that bridge when you get to it.


BTW, PCB and material is ordered. It will take about 8 days on the PCB’s and after I get them assembled I’ll get one to you and I’ll have one here so I can follow any possible issues or change necessities..

---

Cool. I have started the new code tonight. Initially, heating will be disabled until I get it running well. I am thinking of an adaptive learning that will determine over a period of time when heating should be enabled, otherwise it will remain in cooling mode with the TEC off at minimum.

Rewritten my PI loop to full PID with floating point math. Just sorting the Timer PWM code now. I'll have code ready for when the hardware arrives.

BTW, I was planning to release the code under the GNU License (version 3). http://www.gnu.org/licenses/gpl.html

What are you planning re the hardware?

One more thing, we need a name for this project. Got any ideas?

Solar D-TEC (v1)?

EDIT: BTW, I just had a closer inspection of the LMD18200 spec sheet. I note:

Quote:

---

Pin 9, THERMAL FLAG Output: This pin provides the ther-
mal warning flag output signal. Pin 9 becomes active-low at 145°C (junction temperature). However the chip will not shut
itself down until 170°C is reached at the junction.

---

This bridge will shutdown just above the FLAG output threshold anyways.

Quote:

---

USING THE THERMAL WARNING FLAG
The THERMAL FLAG output (pin 9) is an open collector tran-
sistor. This permits a wired OR connection of thermal warning
flag outputs from multiple LMD18200's, and allows the user
to set the logic high level of the output signal swing to match
system requirements. This output typically drives the interrupt
input of a system controller. The interrupt service routine
would then be designed to take appropriate steps, such as
reducing load currents or initiating an orderly system shut-
down. The maximum voltage compliance on the flag pin is
12V.

---

If there is need to implement thermal shutdown, we could simply use this Open Collector output to clamp the PWM input. It would require a 560R series resistor from the MCU PWM output.

Gyus, no a band gap is never necessary. Just design the control loop properly. This works no matter how large or small the heat load is. Why spending so much effort on a technically ambitious design and then waste the potential in the last step.

Quote:

---

Originally Posted by RedlumX

Gyus, no a band gap is never necessary. Just design the control loop properly. This works no matter how large or small the heat load is. Why spending so much effort on a technically ambitious design and then waste the potential in the last step.

---

Don't worry, I have no intention of compromise. That is why I am planning for firmware before implementation. I am fairly confident after an 8 hours session of thinking, planning and modeling today I am on the right track now.

My thoughts are now on current limiting. The current monitoring signal is derived before the L/C LPF, so I have implemented a 2.5 x Nyquist frequency integrator in software to derive average current. I am using this to gain control the PID output. Not yet tested, but I feel my theory is valid.

At the end of the day, the source code will be available under GPL v3, so if your not happy with the results you have the choice to either contribute to development by providing patches or revisions, or if you feel so inclined branch the code or create your own project using the code.

Attachment 23732Here is my current logical diagram.

It would be extremely handy if one could open the loop in software and also have an interface for writing and reading the "open ends". Then determining the open loop response would be a snap, and that's necessary for properly determining the PID parameters. The direct cut-n-try method is quite painful and you are never sure whether you reached the optimum. Since the whole setup is digital anyway, why not make use of all of its potential.

Quote:

---

Originally Posted by RedlumX

It would be extremely handy if one could open the loop in software and also have an interface for writing and reading the "open ends". Then determining the open loop response would be a snap, and that's necessary for properly determining the PID parameters. The direct cut-n-try method is quite painful and you are never sure whether you reached the optimum. Since the whole setup is digital anyway, why not make use of all of its potential.

---

I have you covered here. As I mentioned earlier, a few nights ago I started an application that provides:

Display values: P_Term, I_Term, D_Term, PV
Display and edit: P_Gain, I_Gain, D_Gain, Integral Windup Guard
Real time values & graph: Setpoint, Temperature

This communicates with the MCU via RS-232 and permits on the fly tuning with gain's stored in EEPROM. You can also disable the PID loop and determine the step response.

This will be available in H/W v2 as it requires asynchronous communications.

Quote:

---

Originally Posted by dnar

Rewritten my PI loop to full PID with floating point math. Just sorting the Timer PWM code now. I'll have code ready for when the hardware arrives.

---

You’re a beast dude! I’m just glad I had such a competent partner on this little joint venture project.

Quote:

---

Originally Posted by dnar

BTW, I was planning to release the code under the GNU License (version 3). http://www.gnu.org/licenses/gpl.html

What are you planning re the hardware?

---

The hardware goes with the software, It’s a package deal..
Once the V2 is up and running I’ll probably do a couple of versions with an LD-driver (3A and 7A) on board.

Quote:

---

Originally Posted by dnar

One more thing, we need a name for this project. Got any ideas?

Solar D-TEC (v1)?

---

I put the following on the PCB “Solar D-TEC V1.00”

Quote:

---

Originally Posted by dnar

EDIT: BTW, I just had a closer inspection of the LMD18200 spec sheet. I note:

This bridge will shutdown just above the FLAG output threshold anyways.

If there is need to implement thermal shutdown, we could simply use this Open Collector output to clamp the PWM input. It would require a 560R series resistor from the MCU PWM output.

---

I added this plus a diode; I had to change the circuit on the flag out a little due to the LED on the flag out to keep the LED form being sinked on the MCU out during PWM lows. See the update schematic..


Since its weekend and the PCB-Manufacturer have not started production yet, I was able to re-upload the file, so the PCB is up to date.


In the V2 the flag out is going on an MCU-I/O, is that ok with you?

Quote:

---

Originally Posted by Solarfire

I added this plus a diode; I had to change the circuit on the flag out a little due to the LED on the flag out to keep the LED form being sinked on the MCU out during PWM lows. See the update schematic..

---

Dude, R25 should be inline with MCU pin 5 and the bridge PWM input... It's purpose was to current limit the MCU output when the o/temp protection kicks in... As it is now, the open-collector will only add 560R load to the PWM signal, but it won't stop it. No biggy on this release, I doubts it will ever trigger.

Quote:

---

Originally Posted by Solarfire

In the V2 the flag out is going on an MCU-I/O, is that ok with you?

---

Yeah cool.

Since this controller will cool and warm, I thought a good name could be "Solar-fire-n-ice". *retardo

Quote:

---

Originally Posted by dnar

Dude, R25 should be inline with MCU pin 5 and the bridge PWM input... It's purpose was to current limit the MCU output when the o/temp protection kicks in... As it is now, the open-collector will only add 560R load to the PWM signal, but it won't stop it. No biggy on this release, I doubts it will ever trigger.

Yeah cool.

Since this controller will cool and warm, I thought a good name could be "Solar-fire-n-ice". *retardo

---

Still got it changed, my fast is a little slow today.. was at one of them moist birthday partys last night..*retardo

cheers!

Quote:

---

Originally Posted by Solarfire

Still got it changed, my fast is a little slow today.. was at one of them moist birthday partys last night..*retardo

cheers!

---

Cool. Might have been easier if you had sent me the eagle file.

I did a little more planning and documentation tonight for the V2 firmware. I have added the variables that may be read or read/write from the RS232 port. I also documented manual tuning. If I feel brave once V2 is up and running, I would like to tackle an auto-tune feature.

I have prepared the GNU GPL v3 license covering the software.

Code:

---

Project: Solar fire-n-ice: An advanced bipolar PID software controller for Peltier devices.
Credits: This is a Photonlexicon community project http://photonlexicon.com
Hardware platform: Atmel ATTiny24/44/84 MCU
Hardware developers:
Frank Hill (Solarfire) VooDooI@online.de
Wayne Osborn (dnar) wayne.osborn@dnaresearch.com.au

@author Wayne Osborn wayne.osborn@dnaresearch.com.au, Copyright (C) 2011.
 
@see The GNU Public License (GPL)

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

---

Frank, you might want to look at the TAPR Open Hardware License. http://en.wikipedia.org/wiki/TAPR_Open_Hardware_License

Hi,
A few suggestions:

Can we also connect the overtemp line to an unused input on the v2 design? I know it is unlikely to ever be needed, but I cant think of a reason not to do it, since it should only need a pullup.

Are there any hardware issues with using this design over a wider temp range? I have a couple of ideas of where to use this, but will be needing up to +95C, down to -30C (using a +5C water cooled TEC).

Also, for a future (?V3) design, how hard would it be to drive 2 LMD18200 bridges, driving 2 TECs, but temp controlling the same thing, i.e. 2 TECs in parallel to boost the heating/cooling capacity?

Regarding the temp monitoring signal conditioning, could we add a header that has this type of pinout:

1. 0volts
2. Vsupply
3. (something like) 1-4volts temp out (from on board NTC sig conditioning)
4. 1-4 volts temp in (to MCU, maybe via span and zero adj?)

with a link on pins 3 and 4 for normal operation with the on-board NTC sig conditioning.

This way, for any more esoteric analog sensor signal conditioning, a small sub board/breadboard could be made to just do the sig conditioning for whatever sensor type it is for.

I realise that these suggestions are beyond what a diode or SS laser TEC cooler design needs to do, but if this little TEC controller works as well as I think it might, I can see it being used all over the place, as an easy, drop in module to temp control all kinds of stuff.

Cheers,

Pete

Quote:

---

Originally Posted by ogoun

Hi,
A few suggestions:

Can we also connect the overtemp line to an unused input on the v2 design? I know it is unlikely to ever be needed, but I cant think of a reason not to do it, since it should only need a pullup.

---

Hi Pete, Frank and I have have already agreed to do this on V2 once we have more I/O available.

Quote:

---

Originally Posted by ogoun

Are there any hardware issues with using this design over a wider temp range? I have a couple of ideas of where to use this, but will be needing up to +95C, down to -30C (using a +5C water cooled TEC).

---

Only from the perspective of op-amp gain and firmware. We have chosen to expand the range to provide greater resolution. Simple resistor changes and firmware calibration would all that would be necessary.

Quote:

---

Originally Posted by ogoun

Also, for a future (?V3) design, how hard would it be to drive 2 LMD18200 bridges, driving 2 TECs, but temp controlling the same thing, i.e. 2 TECs in parallel to boost the heating/cooling capacity?

---

Certainly a possibility, a simple slaved bridge.

Quote:

---

Originally Posted by ogoun

Regarding the temp monitoring signal conditioning, could we add a header that has this type of pinout:

1. 0volts
2. Vsupply
3. (something like) 1-4volts temp out (from on board NTC sig conditioning)
4. 1-4 volts temp in (to MCU, maybe via span and zero adj?)

with a link on pins 3 and 4 for normal operation with the on-board NTC sig conditioning.

This way, for any more esoteric analog sensor signal conditioning, a small sub board/breadboard could be made to just do the sig conditioning for whatever sensor type it is for.

I realise that these suggestions are beyond what a diode or SS laser TEC cooler design needs to do, but if this little TEC controller works as well as I think it might, I can see it being used all over the place, as an easy, drop in module to temp control all kinds of stuff.

Cheers,

Pete

---

It's all possible, if Frank does not feel so inclined then anyone can modify the design to suit their needs. I am releasing the source code under a GPL license, so it's free to modify etc. according to the GPL license.

With the exception of current limiting (need to tidy up the current limiting integration) I have tonight completed V1 firmware to suit V1 hardware. I have also made some corrections to the V2 logical diagram.

V1 Firmware
Attachment 23760

V2 Firmware (adds serial control)
Attachment 23761

EDIT: Frank, I have hit an issue with current limiting. As I had planned to current limit based on average TEC current - and remember the bridge current sense is peak current based on the PWM signal, I had (foolishly) planned to sample Isense at many times the PWM frequency and calculate the integral ( trapezoidal rule) of the instantaneous current samples. Alas, with this MCU I can only sample at 15K samples per second at full resolution.

This leaves only one other software option, as per Daves suggestion to use the analog comparator that uses AIN0 and ANI1 (which you have wired approproately) however using this method I can only implement peak limiting based on the PWM signal, not the low-passed analog signal presented to the TEC following the L/C filter...

I'll have another think about this, as I don't see how I can sucessfully determine the integral based on a comparative result... Ultimately I can see a solution uising the ANI0/ANI1 comparator that involves hardware integration of the current sense line. Perhaps R/C integration might do it. I'll await the hardware me thinks to solve this problem.

Current limiting in software sounds like a bad idea to me.
A bug in your software could lead to some fried TEC's ...

Quote:

---

Originally Posted by dnar

EDIT: Frank, I have hit an issue with current limiting. As I had planned to current limit based on average TEC current - and remember the bridge current sense is peak current based on the PWM signal, I had (foolishly) planned to sample Isense at many times the PWM frequency and calculate the integral ( trapezoidal rule) of the instantaneous current samples. Alas, with this MCU I can only sample at 15K samples per second at full resolution.

This leaves only one other software option, as per Daves suggestion to use the analog comparator that uses AIN0 and ANI1 (which you have wired approproately) however using this method I can only implement peak limiting based on the PWM signal, not the low-passed analog signal presented to the TEC following the L/C filter...

I'll have another think about this, as I don't see how I can sucessfully determine the integral based on a comparative result... Ultimately I can see a solution uising the ANI0/ANI1 comparator that involves hardware integration of the current sense line. Perhaps R/C integration might do it. I'll await the hardware me thinks to solve this problem.

---

I don’t quite understand that one. As far as I can tell from the data sheet of the bridge, the I_sens output is an RMS value of the momentary current on the bridge, right? Aside as stated in the datasheet “It should be noted that the recirculating currents (free wheeling currents) are ignored by the current sense circuitry. Therefore, only the currents in the upper sourcing outputs are sensed.” Which I don’t think we have to worry about since we’re not driving a motor.

I did several simulations of PWM 10-100% measuring current before and after the LC filter with the measured RMS values being equal (<1% delta) and linear to the PWM-Signal, only the peak of the AC ripple changing slightly in amplitude. So I think you can pretty much rely on the I_Sens signal within the tolerances stated. Due to the nature of the control loop I think changes in the PWM signal will be pretty subtle once stabilization has set in.

Suggestion:

with the current set point = 0 - 3A = 0 - 1023 ADC Increments

After power up/reset do an Initialization/self calibration, starting a current ramp of maybe 250-1000ms on the PWM-Out from 0% to X% while reading I_Sens. When I_Sens >= current set point then stop ramp and save to limiting variable PWM-Max out.
In normal operation cyclic confirmation of I_Sens <= current set point if not then redim. Herewith you have determined the max allowable PWM out in reference to the current set point.

Also if changes +/- 0.25-0.5% of the current set point occur (someone is turning the trim pot) then recalibrate. Maintain output for maybe 1s so current can be measured via DMM to confirm set point and then fall back into the PID loop.

Critical is the initial setup of the current set point, making sure to start at zero (trimmer min) before powering up!

Quote:

---

Originally Posted by FourDee

Current limiting in software sounds like a bad idea to me.
A bug in your software could lead to some fried TEC's ...

---

Where I work we do current limiting/control via software for all our Cranes (Terex-Demag) without issues. Of course software bugs are a no go, but once tested and debuged I don't expect any problems down that line, unless someone screws around in the software and puts a bug in it.:)

Hi Frank, count on loading ATtiny84's in the prototypes. The code requires 8Kb program flash.

Quote:

---

avr-gcc -mmcu=attiny84 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=20000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT main.o -MF dep/main.o.d -c ../main.c
avr-gcc -mmcu=attiny84 -Wl,-Map=Solarfire-n-ice.map main.o -o Solarfire-n-ice.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature Solarfire-n-ice.elf Solarfire-n-ice.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Solarfire-n-ice.elf Solarfire-n-ice.eep || exit 0
avr-objdump -h -S Solarfire-n-ice.elf > Solarfire-n-ice.lss

AVR Memory Usage
----------------
Device: attiny84

Program: 5118 bytes (62.5% Full)
(.text + .data + .bootloader)

Data: 327 bytes (63.9% Full)
(.data + .bss + .noinit)


Build succeeded with 0 Warnings...

---

I'll complete V2 soon, so we can see if it will fit, but I am thinking we may need to bump V2 to an ATmega16 or similar with 16Kb flash.

Quote:

---

Originally Posted by dnar

Hi Frank, count on loading ATtiny84's in the prototypes. The code requires 8Kb program flash.
I'll complete V2 soon, so we can see if it will fit, but I am thinking we may need to bump V2 to an ATmega16 or similar with 16Kb flash.

---

Ok. Do you think a ATmega168 will do for V2, it has a 16k flash and is pin compatible with the momentary V2 build?

Quote:

---

Originally Posted by Solarfire

Ok. Do you think a ATmega168 will do for V2, it has a 16k flash and is pin compatible with the momentary V2 build?

---

Hi mate, spot on, it has all the internal peripherals I require. Mega168 it is.

EDIT: Sorry I didn't realize V2 was already designed around 48/88/168. You have your shit in a pile.

Hey wayne,

did you catch the feedback on the current limiting issue 5 posts back?

Hi mate, yeah I read them and will leave this until I get the hardware to test for sure. In the following application note, figures 5 & 10 confirm my belief that the current sensing is instantaneous and not RMS, average or otherwise.

http://www.national.com/an/AN/AN-694.pdf

Worst case, I will simply implement "Max PWM" limiting OR a PV attenuator after the PID loop and ignore the sense signal. I like the thought of the later as one could essentially scale the output current to suit. I would prefer closed loop control, but that's in that perfect world that only women believe exists.

It may come down to hardware integration of the sense signal using an R/C network.

For now, I have implemented integration of 500Hz current sampling and will take it from there once I get a hardware test platform. And there lies the problem, sampling a 100kHz PWM current signal at 500Hz is just plain wrong! Hello aliasing errors!

I do like your idea of a POST (power on self test) current calibration run.

BTW, I just realised we have no protection for the MCU should the sense signal exceed 5V, which it could in a TEC short circuit condition (assuming the 12v supply can deliver the current)... We should add a series resistor on the sense line and a diode to clamp the ADC input at 5V maximum (plus diode Vfwd).

The code is complete and it compiles, so in the mean time I'll move on to V2 with serial control.

Wayne.

Frank, you work for Terrex Demag!

I don't suppose you can get your hands on the Terrex crane specifier software?

To save time with long hand calculations I have created quite a complex Excel sheet. It calculates point loadings based on maximum imposed ground pressure, lift load, crane weight, lift radius, outrigger fulcrum, wind sail forces etc etc and flags warnings up, but I would really like to look at the official software if possible.

Sorry for the the thread raid :o

Following this thread with great interest and anticipation BTW.

Ian

Quote:

---

Originally Posted by Doc

Frank, you work for Terrex Demag!

I don't suppose you can get your hands on the Terrex crane specifier software?

To save time with long hand calculations I have created quite a complex Excel sheet. It calculates point loadings based on maximum imposed ground pressure, lift load, crane weight, lift radius, outrigger fulcrum, wind sail forces etc etc and flags warnings up, but I would really like to look at the official software if possible.

Sorry for the the thread raid :o

Following this thread with great interest and anticipation BTW.

Ian

---

Yeah Doc, I'm with Terex-demag for 15 years now in R&D and production control/Testing. I know the software you'r talking about but I don't know how it is distributed. I'll check into it. It's actually more of a costomer tool. I take it you know a little about cranes? I do software, electroncis and testing here for mainly mobile telescopic cranes from 40-1000t. Bringing the R&D into the production process.

Quote:

---

Originally Posted by Solarfire

Yeah Doc, I'm with Terex-demag for 15 years now in R&D and production control/Testing. I know the software you'r talking about but I don't know how it is distributed. I'll check into it. It's actually more of a costomer tool. I take it you know a little about cranes? I do software, electroncis and testing here for mainly mobile telescopic cranes from 40-1000t. Bringing the R&D into the production process.

---

Yeah, I'm a contracts manager for a building company, but I'm also one of the our company's two crane APs

http://www.photonlexicon.com/forums/...ighlight=crane

Quote:

---

Originally Posted by dnar

It may come down to hardware integration of the sense signal using an R/C network.

For now, I have implemented integration of 500Hz current sampling and will take it from there once I get a hardware test platform. And there lies the problem, sampling a 100kHz PWM current signal at 500Hz is just plain wrong! Hello aliasing errors!

I do like your idea of a POST (power on self test) current calibration run.

BTW, I just realised we have no protection for the MCU should the sense signal exceed 5V, which it could in a TEC short circuit condition (assuming the 12v supply can deliver the current)... We should add a series resistor on the sense line and a diode to clamp the ADC input at 5V maximum (plus diode Vfwd).

---

Using an RC filter/integrator on the current sense line seems to be the way the app note and other designs seem to work. Shouldnt be too hard to whip something up either passively, or using the other half of the LT1013 (used for the optional NTC output voltage at the moment). Adding diode clamping would also be trivial in this case. By using an op-amp, the roll-off can be improved, for better antialiasing and thus higher sample rates, but I suspect I am stating the obvious ;)

Cheers,

Pete

Quote:

---

Originally Posted by ogoun

Using an RC filter/integrator on the current sense line seems to be the way the app note and other designs seem to work. Shouldnt be too hard to whip something up either passively, or using the other half of the LT1013 (used for the optional NTC output voltage at the moment). Adding diode clamping would also be trivial in this case. By using an op-amp, the roll-off can be improved, for better antialiasing and thus higher sample rates, but I suspect I am stating the obvious ;)

Cheers,

Pete

---

Hi Pete, you all agreed mate.

OK..I'm still majorly missing something here. Looking at the datasheet, were seening that the current sens is actually part of the current running thru the load, in this case a motor as we can tell by the slight saw tooth shaped signal. Meaning the sens signal is effected by the load, right?? In our case our sens signal is allready being filterd thru our LC filter, right????:confused:

Quote:

---

Originally Posted by Solarfire

OK..I'm still majorly missing something here. Looking at the datasheet, were seening that the current sens is actually part of the current running thru the load, in this case a motor as we can tell by the slight saw tooth shaped signal. Meaning the sens signal is effected by the load, right?? In our case our sens signal is allready being filterd thru our LC filter, right????:confused:

---

Nope. Current sense is on the input side of the L/C LPF, which is is going to reflect a completely different current waveform than is present on the TEC side of the LPF!

Don't fret, we'll sort it once the hardware is here.

Quote:

---

Originally Posted by dnar

Nope. Current sense is on the input side of the L/C LPF, which is is going to reflect a completely different current waveform than is present on the TEC side of the LPF!

Don't fret, we'll sort it once the hardware is here.

---

OK. This should work..

All the parts are here just waiting on the PCB's...

Quote:

---

Originally Posted by Solarfire

OK. This should work..

All the parts are here just waiting on the PCB's...

---

Hi mate. I have never used zeners for this type of application, rather a diode tied to VCC and current limit resistor (R101).

Also, your circuit provides no control of the capacitor charge time constant. Are you considering your design as a current to voltage integrator? If so, the 4k3 would not be necessary as it's only function was to convert I to V.

I think the below is what is needed, I calculated the R/C time constant of R100/C100 for 0.022mS (PWM f / 2.5 = 40kHz).

Attachment 23799

What do you think?

If anyone is interested, here is the program c file for V1 hardware (header files not shown). Still not complete, only current limiting omitted until I play with the hardware.

Code:

---

/*
Project: Solar fire-n-ice: An advanced bipolar PID software controller for Peltier devices.
File: main.c - Main Program.
Hardware platform: Atmel ATTiny84 MCU
Hardware version:  1.xx
Hardware developers:
Frank Hill (Solarfire) VooDooI@online.de
Wayne Osborn (dnar) wayne.osborn@dnaresearch.com.au
Credits: This is a Photonlexicon community project http://photonlexicon.com

@author Wayne Osborn wayne.osborn@dnaresearch.com.au, Copyright (C) 2011.
 
@see The GNU Public License (GPL)

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

// ***************************************************************
// Includes
// ***************************************************************
#include "main.h"
#include "stdlib.h"
#include "avr/eeprom.h"
#include "avr/io.h"
#include "avr/interrupt.h"
#include "avr/wdt.h"

#define _VERSION      0x0100

// ***************************************************************
// Global variables
// ***************************************************************
float        P_Term;                // (P) Proportional term
float        I_State;            // (I) Integral running state
float        I_Term;                // (I) Integral term
float        D_Term;                // (D) Derivitive term
float        P_Gain;                // Proportional gain
float        I_Gain;                // Integral gain
float        D_Gain;                // Deriviative gain
float        PID_Gain;            // Master PID Gain (pot)
int16_t        iError;                // Error value
uint16_t    uiLastInput;        // Previous error value
uint16_t    uiNTC;                // NTC raw ADC value
uint16_t    uiSetPoint;            // Setpoint as ADC value
int16_t        iPV;                // Process variable (PID output)
uint16_t    uiISetPoint;        // Current Limit Set Point
uint16_t    uiSparePot;            // Spare pot value
uint16_t    uiCurrent;            // Bridge current
uint16_t    uiTimerPID;            // PID Timer value
uint16_t    uiTimerInhibit;        // Inhibit Timer value
uint16_t    uiTimerReadPots;    // Read physical potentiometers timer
uint16_t    uiTimerISense;        // Current sense timer
uint16_t    uiTimerStatus;        // Status LED update timer
uint8_t        uiTimerPIDInt;        // PID Timer timeout flag
uint8_t        uiTimerInhibitInt;    // Inhibit timer timeout flag
uint8_t        uiTimerPotsInt;        // Read pots timer timeout flag
uint8_t        uiTimerISenseInt;    // Current sense timer timeout flag
uint8_t        uiTimerStatusInt;    // Status LED timer timout flag

// ***************************************************************
// Timer 1 overflow interrupt service routine (1002Hz) creating several synthesised timers
// ***************************************************************
ISR(TIM1_OVF_vect)
{     
    TCNT1 = _TIMER1_LOAD;
   
    // ***************************************************************
    // PID Timer (20mS)
    // ***************************************************************
    if (uiTimerPID) uiTimerPID--;
    else
    {
        uiTimerPID = TIMER_PID;
        uiTimerPIDInt = TRUE;
    }

    // ***************************************************************
    // Read Potentiometers Timer (1000mS)
    // ***************************************************************
    if (uiTimerReadPots) uiTimerReadPots--;
    else
    {
        uiTimerReadPots = TIMER_POTS;
        uiTimerPotsInt = TRUE;
    }

    // ***************************************************************
    // Current Sense Timer (40mS)
    // ***************************************************************
    if (uiTimerISense) uiTimerISense--;
    else
    {
        uiTimerISense = TIMER_ISENSE;
        uiTimerISenseInt = TRUE;
    }

    // ***************************************************************
    // Inhibit Timer (1000mS)
    // ***************************************************************
    if (uiTimerInhibit) uiTimerInhibit--;
    else
    {
        uiTimerInhibit = TIMER_INHIBIT;
        uiTimerInhibitInt = TRUE;
    }

    // ***************************************************************
    // Status Timer (250mS)
    // ***************************************************************
    if (uiTimerStatus) uiTimerStatus--;
    else
    {
        uiTimerStatus = TIMER_STATUS;
        uiTimerStatusInt = TRUE;
    }
}

// ***************************************************************
// Program and MCU initialisation
// ***************************************************************
void init(void)
{
    // Setup physical port direction
    DDRA = PORT_A_DIR;   
    DDRB = PORT_B_DIR;   


    // Crystal Oscillator division factor
    CLKPR = 0x00;    // No divisor, run at 20MHz

    //Analog Comparator Control and Status Register
    ACSR  = 0b10000000;        // No comparator

    // ADC Control and Status Register A
    ADCSRA = 0b10000111;    // ADC Prescaler = 128

    // ADC Control and Status Register B
    ADCSRB = 0b00000000;           
           
    // Disable digital input buffers on utilised ADC channels                     
    DIDR0 = 0b10001111; 
   
    // Timer/Counter Control Register A (PWM control)
    TCCR0A = 0b10000111;    // Fast PWM on OC0A, Set OC0A on Compare Match, count down from OCR0A to 0
    OCR0A = 0x00        ;    // Initialise to 0% PWM
   

    // Timer/Counter Control Register B (Timer with interrupts)
    TCCR0B  = 0b00000100;  // CPU Clock = 20MHz, prescaler = 256;
    TCNT0  = _TIMER1_LOAD; // Counter load value
   
    // General Interrupt Mask Registe
    GIMSK  = 0x00;        // No external interrupts

    // MCU Control Register
    MCUCR  = 0x00;               

    // Timer/Counter 0 Interrupt Mask Register
    TIMSK0  = 0x01;                  // Timer/Counter0 Overflow Interrupt Enable

    // Watchdog Timer initialization
    wdt_enable(WDTO_1S);
 
    // Initialise program variables
    iError = 0; 
    uiLastInput = 0; 
    iPV = 0;
   
    // Enable interrupts
    sei();
}

// ***************************************************************
// Initiate an ADC sample for a specified ADC channel and return the ADC result
// ***************************************************************
uint16_t Read_ADC_Sensor(uint8_t Channel)
{
    ADMUX = Channel; 
    SETBIT(ADCSRA,ADSC);
    //Wair for ADC to be ready
    while (bit_is_clear(ADCSRA,ADIF));
           
    //Read the ADC
    SETBIT(ADCSRA,ADIF);
    return ADCW; 
}

// ***************************************************************
// PID loop update processing
// ***************************************************************
float UpdatePID(uint16_t uiTarget, uint16_t uiInput)
{
    float WindupGaurd;

    // Calculate the error
    iError = uiInput - uiTarget;   
       
    // Update the Proportional term
    P_Term = P_Gain * iError;

    // Update the Integral term with windup protection
    I_State += iError;
    WindupGaurd = WINDUP_GUARD_GAIN / I_Gain; 

    if (I_State > WindupGaurd) I_State = WindupGaurd;
    else if (I_State < -WindupGaurd) I_State = -WindupGaurd;
    I_Term = I_Gain * I_State;

    // Update the Derivative term
    D_Term = (D_Gain * (uiInput - uiLastInput));
    uiLastInput = uiInput;               

    // Now return the PID result
    return  P_Term + I_Term - D_Term;
}

// ***************************************************************
// The main loop. All processing is timer based
// ***************************************************************
int main(void)
{
    init();    // Program initialisation
         
    while (TRUE)
    {
        // ***************************************************************
        // PID Update Timer timeout
        // ***************************************************************
        if (uiTimerPIDInt)   
        {     
            uiTimerPIDInt = FALSE;
            // Read the Sensor ADC
            uiNTC = 1023 - Read_ADC_Sensor(ADC_TSENSE); // Convert the temperature sample from 0..1023 to 1023.00 as the sensor slope is inverted.
            // Update the PID loop
            iPV = UpdatePID(uiSetPoint, uiNTC);

            // **** Current Limiting to go Here ****
            // Removed until hardware performance is terermined
            // *************************************
            if (iPV > 0) SETBIT(PORT_OUT, TEC_DIR);        // Positive PV, set direction control
            else CLRBIT(PORT_OUT, TEC_DIR);                // Negative PV, clear direction control
            OCR0A = abs(iPV);                            // Set the PWM to the absolute Process Value
        }   

        // ***************************************************************
        // LD-Inhibit Timer timeout
        // ***************************************************************
        if (uiTimerInhibitInt)   
        {             
            //Reset watchdog
            wdt_reset();
            uiTimerInhibitInt = FALSE;
            // Update the Inhibit output if out of range
            if ((uiNTC >= (uiSetPoint - INHIBIT_RANGE)) && (uiNTC <= (uiSetPoint + INHIBIT_RANGE)))
            {
                // Within +/- 2.5c enable laser modulation
                SETBIT(PORT_OUT, LD_INHIBIT);
            }
            else
            {
                CLRBIT(PORT_OUT, LD_INHIBIT);
            }
        }   

        // ***************************************************************
        // Read Set Points Timer timeout
        // ***************************************************************
        if (uiTimerPotsInt)   
        {     
            uiTimerPotsInt = FALSE;
            // Read the Tuning Pot ADC
            PID_Gain = Read_ADC_Sensor(ADC_TUNE);
            // Read the I Set Pot ADC
            uiSetPoint = Read_ADC_Sensor(ADC_ISET);
            // Read the T Set Pot ADC
            uiISetPoint = Read_ADC_Sensor(ADC_TSET);
        }   
       
        // ***************************************************************
        // Read Bridge Current Timer timeout
        // ***************************************************************
        if (uiTimerISenseInt)   
        {     
            uiTimerISenseInt = FALSE;
            // Read the Bridge Sense ADC
            uiCurrent = Read_ADC_Sensor(ADC_TSENSE);
        }   

        // ***************************************************************
        // Update Status Timer timeout
        // ***************************************************************
        if (uiTimerStatusInt)   
        {     
            uiTimerStatusInt = FALSE;
            // Update the under/over temperature LED's.
            if (uiNTC - ADCPERC < uiSetPoint)
            {
                SETBIT(PORT_LED, LED_UNDER);    // Under Temp LED ON
                CLRBIT(PORT_LED, LED_OVER);        // Over  Temp LED OFF
            }
            else if (uiNTC + ADCPERC > uiSetPoint)
            {
                CLRBIT(PORT_LED, LED_UNDER);    // Under Temp LED OFF
                SETBIT(PORT_LED, LED_OVER);        // Over  Temp LED ON
            }
            else
            {
                CLRBIT(PORT_LED, LED_UNDER);    // Under Temp LED OFF
                CLRBIT(PORT_LED, LED_OVER);        // Over  Temp LED OFF
            }   
        }
    }
}

---