The big TEC driver thread!

[LaNeK779]

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

[ogoun]

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

[Solarfire]

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!

[Doc]

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

[Badpip]

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

[dnar]

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

Cheers, Hugh Jassfan

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.

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.

[Solarfire]

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.

[dnar]

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.

[Solarfire]

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..

[dnar]

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:

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.

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.