Sending PWM through a relay

[clearchris]

Re: Sending PWM through a relay

GC: I think we agree. The only difference is that people think I'm running the RPIZW to have a local interface (which I guess it could, but I won't be using it except for increased processing power and wifi), when it's strictly going to be feeding the GCODE to the MCU and running the octoprint web service. Any administration, coding, etc, will be at a desktop or mobile phone running to the octoprint web service.

[clearchris]

Re: Sending PWM through a relay

Duplicate post.

[Curious.George]

Re: Sending PWM through a relay

GC: I think we agree. The only difference is that people think I'm running the RPIZW to have a local interface (which I guess it could, but I won't be using it except for increased processing power and wifi), when it's strictly going to be feeding the GCODE to the MCU and running the octoprint web service. Any administration, coding, etc, will be at a desktop or mobile phone running to the octoprint web service.

Think about it...

If your "device" (be it an oven controller, DSO, LA, etc.) is connected to your internet, then you CAN have a "local interface" anywhere/everywhere that you have (or CAN have) a computer.

So, if you happen to be "working" out by the oven and want to monitor its operation, you drag out a laptop and set it next to the oven and open a window into the oven's controller. If you are NOT interested in the oven's operation, you just don't open that window (or, don't drag out the laptop).

[clearchris]

Re: Sending PWM through a relay

In case anyone was interested in an update, I have the hardware together, and the software about 50% there.

Here's the electronics on my bench, ready to be wired to the oven.


And here's the first pid tune. Temperature is a bit shaky, after the pid tune, I'm getting 0-7C overshoot. I need to take the noise out of the thermocouple first. If that doesn't work, I might have to replace the max6675 (I found it in my box...) with something a bit more modern. On the plus side, that was with only 25% of heating capacity, I only had the lower resistive elements on and the fan on. The ceramic insulation really helped out. The down side is that cooling may become an issue, the oven now holds heat for a long time.

[goontron]

Re: Sending PWM through a relay

Way Underdamped

Still impressive!

[clearchris]

Re: Sending PWM through a relay

Yeah, I think it's error from the noisy thermocouple, messing up the pid tune. This was just a dry run, so I have probably almost an extra meter of thermocouple wire hanging on there acting an an antenna for stray signals. I'm going to trim that and wire it up in the morning. I think that should help quite a bit. I have worked with these max6675 in refrigerators in the past, and I don't remember them being quite this noisy. You would think they would receive some noise from the compressors... Now that I think of it, I always ran software SPI, and I ran them slow. This one is running hardware SPI, and at the default, it's a bit faster. I may have to slow down the clock.

[Curious.George]

Re: Sending PWM through a relay

And here's the first pid tune. Temperature is a bit shaky, after the pid tune, I'm getting 0-7C overshoot.

This is usually indicative of lag in the loop. That may be a true "delay" (in sensor or actuator) or an effective delay (e.g., thermal mass of heating elements).

I can't recall if you have true proportional control or just on/off. In either case, it might help you troubleshoot the system if you can superimpose the actual control signal on the plot. I.e., you'd be able to see if the process was "coasting" past its setpoint or if the controller wasn't adequately anticipating response.

If you can get actual coefficients out of the controller, there are tools that you can use to model the loop to see how tweaking those could improve your response.

[clearchris]

Re: Sending PWM through a relay

The plot thickens!

I have another thermocouple, just a cheesy, plastic jacket "waterproof" (it's not at the end) typek thermocouple. I left it long, and tested. Lots of noise. I cut it short to about 1' long, I had only 0.1c movement, great improvement. Can't put it in the oven, it's guaranteed to melt.

So I cut my oven type-k thermocouple short. Still a lot of noise. The oven thermcouple is stainless braid jacket with two seperate high temp wires in the braid. It's also mounted in the oven, and the oven is connected to ground. If I tie the thermocouple shield to ground on the arduino, I get +/-0.1C temperature stability. Are there any downsides to doing this?

[clearchris]

Re: Sending PWM through a relay

Making progress! This is what it's supposed to look like when you do a pid tune in klipper. Look at that nice steady temp holding afterwards (ignore the gap, I borked it up and had to reset).

Garbage in, garbage out. Nicely tuned thermocouple, much better results!

[sam_sam_sam]

Re: Sending PWM through a relay

I have ask you a question about this setup

Are you turning on and off the heater or are PWM the output I know you have mentioned that you trying to PWM a contactor but my concern is how long will your contactor last doing this

[clearchris]

Re: Sending PWM through a relay

Klipper looks like it drives the SSR with PWM. If it's not PWM, it's switching it pretty quick. The SSR line out is connected to the line side in (not coil) of four relays that independently switch four heaters. I'm switching the relays based on which heaters are to be used, but it's doing the temp control through the SSR. Here's the process:

SSR off, relays off, in that order
configure relays for required heaters, some on, some off
switch SSR (with pwm?) to feed voltage through all configured relays which do not change
If the heater configuration needs to change, repeat process

I don't think this design is putting much, if any, strain on the relays. The relays might actually last longer like this, because the relays are never going to switch on or off while power is applied. And we all know that sparking during make/break is the main wear on a relay.

I could have done this with 4 SSR, or maybe fewer, but I like this design. The relays are dirt cheap, and you can get one nice SSR with a big heat sink to switch, instead of 3-4 fake foteks with a small piece of aluminum as most ovens are done. If you see in the picture, I have a carlo gavazzi 25A SSR driving this. It's a legit SSR that I feel comfortable driving at 25A, at least for a reflow session. Actually this whole project has been dirt cheap.

toaster oven: found on neighbors curb
4 relay board: from stock, a few bucks originally
arduino: chinese clone, $3
arduino shield: $2
max6675: Probably $7 10 years ago
thermocouple: from stock, $3
carlo gavazzi relay: ~15$ over 10 years ago. It failed, tossed in box, pulled out and repaired because I needed a SSR
big relay heat sink: don't remember
ceramic insulation: $16 from grainger
high temp silicone: $6 home depot
raspberry pi zero: ~15 from sparkfun
OTG usb adapter: a few bucks
Two halogen light sockets: ~$3 each from china
two halogen lamps, 500w: from stock since my halogen lamps busted
high temp wire (2mm^2 IIRC): ~10 I think, from china
hardware
electric box, switch, plug, cord, terminal strip, usb charger: no clue, had in stock
hardware, threaded inserts for protecting cords entering/leaving the oven

I'm sure there's something I'm forgetting, but that list is pretty close.

Plus, the most important reason why I went with this design: I ordered cheap SSRs from china (not fotek) before chinese new year, then covid happened, etc. I gave up on ever receiving them and designed this out of stock I had on hand.

[clearchris]

Re: Sending PWM through a relay

More testing. 75% heat, lower resistive heater with both upper and lower 500w halogens. I started out going for 200C without any pid. Ramp up was quicker than I expected, and hey, nothing lit on fire, so after checking on it, I went for 250C. I sure like the slope of those lines. I don't think I'll have any problem running lead free reflows (not that I will, I'm all about the Pb). I'll have to tune things a bit and make a reflow profile, but I can easily see starting the preheat/dryout with top and bottom resistive heaters (getting them good and hot) and when it's time for the reflow swapping over to the halogens for a quick burst of heat to get to liquidus, hold for 30, and back down again.

Maybe I go full blast with all heaters, cut the resistive heaters at liquidus, hold with the halogens and ramp down with the halogens. Since the profile has to run in 8 minutes, the oven isn't soaking up as much heat as I thought it would. Cooling shouldn't be a problem.

Though admittedly, this is an unloaded test. I don't think a board is going to add a lot of thermal mass though. And these are air temps, not top of the board temps.

Tommorrow I'm going to have measure the resistance of the heaters and do some math. The oven was rated for 13a, and I added two 500 watt elements which puts me over a 20a circuit, barely. If I downgrade to 400w bulbs, or maybe a 350 on top and keep the 500w bottom, I could squeak by at a touch above 19a. I don't know how much I trust the labels on any of them though. I really want to be able to run this from a standard 20a circuit.

I need to fashion some shields for the halogens too, at least the top one, I can't actually look into the oven when they are on, it's like staring into the sun.

Also need to start writing some gcode and see how it all works.

I love it when a plan comes together.

[sam_sam_sam]

Re: Sending PWM through a relay

Thanks for sharing this information I was hoping that you went this way

But let us know if you get the G code to work correctly the you want it to work

I might do something similar for my board heater but use a Ender 3 controller but use a 1000 watt controller that I used for a battery spot welder transformer controller but the electronic version of and see if this concept will work or not ( ? Mark )

Here is the link to where you can one or just see what it looks like

https://www.mpja.com/Hot-Air-Rework-...info/34737+TL/
The one I use most often is the version that has the hot air gun and the soldering iron ( in one unit) which is very hard to find now there is a newer version but I do not know if it uses the same controller or not )

Or I might use a ZD-939-L temperature controlled hot air gun controller which has very good controller stability surprisingly enough for it cost but weather or not I get the same exact results doing this setup remains to be seen ( now I might have to use a bigger SSR setup )

[clearchris]

Re: Sending PWM through a relay

I don't know that I would use klipper for a hot air station or a soldering iron unless you have a repeatable process where you need to ramp, etc for a very specific and repeated application. If you open it up, you can see what the MCU is, and there are people who have replaced the stock firmware with a better custom made solution. The problem is that there are many different variants of what looks like the same basic iron/hot air station, many more than you would think. There are a few firmwares up on github. They report great results.

I don't think you need to replace the guts of either with an SSR, most of these devices have an optocoupler and a triac, which is basically what is in an SSR.

[Curious.George]

Re: Sending PWM through a relay

Making progress! This is what it's supposed to look like when you do a pid tune in klipper. Look at that nice steady temp holding afterwards (ignore the gap, I borked it up and had to reset).ATTACH]211640[/ATTACH]

Unless you can see the "control" signal on the graph, there's nothing to say that it's not "holding" just because the enclosure isn't "leaking".

What you want to see is the control and the sense before you can attest to the performance of the controller.

It still seems like there is a lot of lag -- when the heating elements are turned on, they overshoot, considerably. (again, without seeing the control signal, you can't tell if this is because they are being commanded to remain on or if they just "coast too far", once engaged.

[clearchris]

Re: Sending PWM through a relay

GC: The first part of that graph is the software measuring the system, overshoot is expected and a desirable part of the measurement. The second part of the graph overshot a smidge because I didn't turn on the pid controller. You see the signal drop to zero because I took it offline and reconfigured it with the pid parameters. After that, the temperature overshoots a tiny bit because of the heat already in the system, but after that it holds solid.

I don't have anything on the graph to show the controller clicking on and off, but I did build an led into the arduino that will turn on when the heater is engaged. Yes, there is an LED in the SSR that performs the same purpose, but the one on the arduino is considerably brighter, it's much easier to see.

[Curious.George]

Re: Sending PWM through a relay

GC: The first part of that graph is the software measuring the system, overshoot is expected and a desirable part of the measurement.

Most autotune algorithms work by disabling the "real" control loop (replacing it with bang-bang control) and letting the process (that's your oven) deliberately oscillate. This produces what are termed the "ultimate period" and "ultimate gain" of the process -- how the process behaves in the absence of any tuning.

So, the oscillation you see in the beginning is the process's "ultimate period" (1/frequency) manifesting during the auto-tune.

The magnitude of that oscillation is the ultimate gain (scaled).

From these two parameters, you can come up with some "moderately aggressive" values for the proportional, integral and derivative gains that the controller should use.

In certain processes, you can compute these from a single oscillatory cycle.

[The hazard in universally applying these techniques is that any OTHER disturbance that comes along will confuse the tuning algorithm -- the tuning algorithm CREATES the artificial disturbances that cause the process to oscillate and rely on that exclusive interaction]

Note that you can tune to compensate for DISTURBANCES (oven door being opened, oven leaking) or for SETPOINT changes. (I alluded to this in an earlier comment).

If you tune for disturbances, then your process tries to maintain the "best" control (that is possible for that degree of "aggressiveness") holding things constant.

But, the loop may respond suboptimally to changes in the setpoint! (which many processes require). You want to tune differently if you want the controller to "settle" on a new setpoint rapidly (vs. holding a setpoint indefinitely).

The second part of the graph overshot a smidge because I didn't turn on the pid controller. You see the signal drop to zero because I took it offline and reconfigured it with the pid parameters. After that, the temperature overshoots a tiny bit because of the heat already in the system, but after that it holds solid.

Again, there's no way to tell if it's "holding solid" because it is actively BEING HELD at that value.

[I'm not saying it ISN'T "being held"; what I'm saying is that you should be looking to see how much "work" the controller is doing during these times to determine how much faith you have in its performance. The only practical way to gauge that "work" is to watch to see when the controller is actually "exerting control"]

I don't have anything on the graph to show the controller clicking on and off, but I did build an led into the arduino that will turn on when the heater is engaged. Yes, there is an LED in the SSR that performs the same purpose, but the one on the arduino is considerably brighter, it's much easier to see.

So, the take away from my comment should be: WATCH THE LIGHT to see if it's "doing anything". This isn't scientific but, rather, intuitive -- if its "doping something" and the results LOOK good, then assume it's DOING THE RIGHT THING.

[clearchris]

Re: Sending PWM through a relay

Yep, my LED is definitely flickering, it's definitely not operating in bang-bang mode.

So here's a question.

Can pid tuning account for the non-linearity of the heating process? I.e. as the setpoint gets hotter, the element needs to be left on longer for each 1c increase in temp?

My use case is that the oven will have many purposes. The most common one is baking my filament for the 3d printer (yes, it's hygroscopic and needs dehydration periodically), and that operates around 120F-160F. The temp is floating a few C hotter than the set point because I did the pid tune at 100C. Now I can just use different pid parameters for different setpoints, but that somehow seems... inelegant.

[Curious.George]

Re: Sending PWM through a relay

Yep, my LED is definitely flickering, it's definitely not operating in bang-bang mode.

OK. I can't see it, from here... :>

So here's a question.

Here's an answer: blue

Can pid tuning account for the non-linearity of the heating process? I.e. as the setpoint gets hotter, the element needs to be left on longer for each 1c increase in temp?

Yes, and no.

First, understand what the three terms -- Proportional, Integral and Derivative -- try to address.

All (effectively) operate on the "error" term -- the difference between the observed process value and the desired setpoint for that value.

The proportional term applies "control" to a degree ("strength") proportional to the current error; the farther "off" the process is from the desired setpoint, the more "correction" it tries to apply.

But, getting that "proportional gain" exactly correct at a variety of operating points is virtually impossible. It's like knowing exactly how hard to hit the brakes while driving WITHOUT WATCHING TO SEE HOW CLOSE YOU"RE GETTING TO THE HAZARD! So, with just a proportional term, you expect the process to settle out at some operating point that's "not quite" the desired setpoint. There will be an offset (or, the loop will "hunt" forever oscillating above and below the setpoint because it always overcompensates -- gain too high).

The integral gain (this is a misnomer, in the classical model, but easier to understand in these terms) acts on the ACCUMULATED error term. I.e., you add up error terms continuously and apply an amount of control based on the "current accumulation" -- defined by the integral gain.

So, in the case where the proportional-only controller settles in at some point that's not quite what you desired (setpoint), there is a persistent error term -- the difference between where you ended up and where you WANTED to end up. If you keep accumulating (integrating!) this error, the accumulated value will grow and grow. If you apply an additional amount of "control" based on this accumulation, you will end up closing the gap between what the P-only controller was able to do and "desired".

When you get to the actual set point, the error will become zero and the integrator/accumulator will stop growing.

[Get the integral gain wrong and the loop will ALSO oscillate -- see how tuning can be tricky?]

Note that the integrator can have "accumulated" a shitload of error by the time the process actually closes the gap to the setpoint. So, it can overshoot -- too much "control".

The Derivative term acts to predict the future. If, for example, it sees the error shrinking, it can start throttling back the control that the P & I terms would otherwise be applying -- to limit the amount of overshoot.

[The old, round, classic "Honeywell" thermostats implemented this "look ahead" feature with an "anticipator" that would preheat the THERMOSTAT in anticipation of the heated household air! So, as the thermostat called for heat, the anticipator would start throttling back on that. Most anticipators were not set correctly. :> ]

OK, now, to your question.

Having "decent" values for the three gains means the loop will TEND to settle at the setpoint, EVENTUALLY. How quickly it attains that setting and how closely it maintains it (as well as how EFFICIENTLY it does this... every action costs energy!) depends on the values and how the system's characteristics may have changed -- at your current "operating point".

By way of example:

Imagine you have your thermostat in your dining room. Assume it's ttuned perfectly -- the furnace promptly brings the room temperature to the desired setpoint and maintains it there, closely.

Now, imagine the outdoor temperature plummets to -26F (coldest I've ever experienced) and the wind picks up (exacerbating any air leaks in your house). You would expect the furnace to have to work harder to maintain the same indoor temperature, right? It would take longer to get to a desired setting -- more control effort. And, it may have to be active more frequently.

This is because the characteristics of your SYSTEM -- your furnace+house+outdoor environment -- have changed. The control loop may not be operating optimally in that set of circumstances.

But, assuming your furnace can generate more BTUs than your walls LOSE, you expect the temperature to eventually settle down and the furnace click off -- even if it may click back on a minute later to adjust to the losses of the past minute!

Now, assume you close the doors to the dining room, isolating it from the influence of the other rooms (thermal loads) in the house. When the furnace eventually turns on, it will probably overshoot the desired temperature -- because there's so llittle air volume compared to the capacity of the furnace! Again, the system's characteristics have changed. You need to retune for those new conditions.

The same is true if you move outside of the "typical" comfort range that the HVAC was sized for. Try to cool your house to 50F and it's just not going to happen (if the outdoor temperatures are 100F). Or, heat it to 110F (if the outdoor temperatures are -20F).

"Plants" (furnace/air conditioner) are "sized" to fit the typical needs of the particular home. The refrigeration unit that your grocer uses to keep his produce fresh is DESIGNED to operate at a different range of temperatures. Using it in a home would be counterproductive -- bigger is not necessarily better.

My use case is that the oven will have many purposes. The most common one is baking my filament for the 3d printer (yes, it's hygroscopic and needs dehydration periodically), and that operates around 120F-160F. The temp is floating a few C hotter than the set point because I did the pid tune at 100C. Now I can just use different pid parameters for different setpoints, but that somehow seems... inelegant.

It all boils down to the QUALITY of "control" that you want.

Do you care if the loop overshoots the setpoint considerably when operated at a different point? Or, if it takes longer to get TO a setpoint?

When you cook/bake/roast, you often preheat the oven. This, despite the fact that the oven's temperature controller will bring the temperature to the desired setting, EVENTUALLY. But, the cooking/baking/roasting times that you have expect the item to be in an oven AT that temperature... not one that will eventually GET to that temperature!

In the case of baking, the time spent waiting for the temperature to attain its desired setpoint can ruin the item -- because baking is all about chemistry and chemical reactions (which run at different rates based on temperature).

If I'm drying my clothes, I really don't care how long it takes for the dryer to get up to temperature. Or, just how hot it actually gets (as long as I'm not drying some delicate synthetics).

Bottom line: PID isn't a panacea. It's just a tool that you have to decide how best to apply, based on YOUR criteria.

[Curious.George]

Re: Sending PWM through a relay

I'm not sure my example was explicit enough... <frown>

Tuning at a particular operating point just says "that's the 'best' performance you'll likely get from the controller when paired with that system at that operating point".

It's not a guarantee that you'll get "acceptable" control!

Again, imagine trying to heat your house to 110F in the winter. It ain't gonna happen with the typical plant in a home.

So, you may or may not be able to use your oven+controller for the various uses you envision (e.g., you won't be able to melt diamonds!). You need to either design for a particular application/usage or MEASURE how well it performs and see if that is acceptable to you.

You want to get a feel for the capabilities of your system before you start "applying" it (you wouldn't even try to tow a motor home up Pike's Peak with a VW bug!)

[Everything is always "data" in my world!]