Announcement

Collapse
No announcement yet.

Sending PWM through a relay

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #21
    Re: Sending PWM through a relay

    Originally posted by clearchris View Post
    redwire: Well, we do PID control at least on 3d printers with heaters.
    I think you're going to find tuning the control loop will be nontrivial -- there's a lot of lag in your system. You might find each time you "change the (thermal) load -- open the door, add/remove boards -- that the system wildly overshoots (underdamped). Or, takes forever to reconverge at the setpoint (overdamped). As the goal is to maintain a specific temperature, the other issues may prove to be of relative insignificance.

    Comment


      #22
      Re: Sending PWM through a relay

      Well, I think that my use case is a bit simpler. I'm not planning on running a business with this, just repair boards and occassional board assembly. I can't think of a case where I run more than one board a day, so I can start from a cold oven, close it, run the profile and let fully cool. If I thought I'd run it more than once a day, I'd strongly consider a vapor phase oven. Those look completely awesome.

      Comment


        #23
        Re: Sending PWM through a relay

        Originally posted by clearchris View Post
        so I can start from a cold oven, close it, run the profile and let fully cool.
        Then you'd likely want an overdamped loop. This will take longer to reach it's setpoint but will not overshoot (so you won't have to worry about how FAR it overshoots).

        The downside is that if your profile is "open loop" (i.e., temperature X for N minutes), it may not get to a particular temperature before the profile calls for a new setpoint change.) OTOH, if you modify the controller to WAIT until the new setpoint is attained before "starting the timer", you could end up sitting at the "wrong" temperature for too long.

        [Temperature control isn't "trivial"]

        Comment


          #24
          Re: Sending PWM through a relay

          Well, it will be PID controlled, so I'd be surprised if I see a lot of overshoot. There's a lot of flexibility in making the gcode profile if I'm able to get the oven working with klipper. My main concern is making sure there's enough heat to hit the temps that it needs to in the time specified.

          Here's the list of available commands for klipper.
          https://github.com/KevinOConnor/klip...ocs/G-Codes.md

          Comment


            #25
            Re: Sending PWM through a relay

            Pretty happy with how this is turning out. With the fan on, I was easily getting 1C per second from cold to 200C. It slowed a bit after that, took a while to get to 230C. Strangely, I cut the power to the elements and the fan, and the temp immediately shot up to 270C. I'm not exactly sure what happened there, maybe the heat rose? I'm not actually using the thermocouple shown in the pic yet, I had a different one hooked to my meter and it was about midway in the toaster, about where I would expect a pcb to be.

            I bent a piece of stainless to mount the bulb holder and used two threaded rivets to snake the power through without fear of cutting the wire. Rivets aren't clamped down or sealed yet, so there's two holes in the top of the box still and no insulation. If I insulate it, I probably won't even need the second halogen bulb, though two halogen bulbs would probably hit the peak faster and cool quicker than using the resistive heaters.

            Attached Files

            Comment


              #26
              Re: Sending PWM through a relay

              Originally posted by clearchris View Post
              Well, it will be PID controlled, so I'd be surprised if I see a lot of overshoot.
              You don't understand control theory.

              A PID controller implements the following equation (with special caveats that are too numerous to describe, in detail, here):

              Code:
              out = Kp * error + Ki * sum(errors) + Kd * difference(errors)
              where:

              Code:
              error = process variable observation - setpoint
              and "out" is the signal that you are using to control your heating/cooling elements.

              YOU have to pick values for the CONSTANTS Kp, Ki and Kd. This is called TUNING the loop.

              If Kp is too high, the system oscillates (over and undershoots) -- a small change in observed variable from desired setpoint (i.e., a small ERROR) causes a large change in "output". If Kp is too small, the system struggles to attain the desired setpoint (too little "control" for a given error signal).

              Ki determines how well the controller closes the steady-state gap between desired value and driven value. I.e., with Kp alone, you can end up with a fixed offset in your loop; Ki gradually eats up that offset driving the error to zero over the long term.

              But, too large a Ki and it causes the loop to overshoot, then undershoot as it tries to close the gap "from above", etc. -- another oscillatory mechanism.

              Kd is an anticipator -- it looks at TRENDS and tries to compensate for them ahead of time. Usually poorly implemented and thus another oscillatory mechanism.

              [You will likely end up with a PI controller as Kd is a real chore to get right]

              Ideally, you want to tweak ALL THREE variables so that your "system" approaches its steady-state condition with minimal over/undershoot and oscillation. This is called critically damped. If the controller rushes towards the setpoint and overshoots (badly), it's underdamped. If it struggles to reach the setpoint slowly, it's overdamped.

              There is considerable science involved in setting these values. And, a sh*tload of "art" (experience). Typically, you introduce a "disturbance" to the system (i.e., throw a cold mass in the oven) and tweek the constants to obtain a desired observed performance. (There are controllers that can "self tune", to some degree).

              There are lots of hacks that can be brought to bear to improve the performance of the controller. E.g., if you introduce a LARGE thermal mass, the temperature will likely fall, considerably. This will result in large "error" terms. Your heating elements will lag in their ability to compensate so these errors will persist for some time. As a result, the "sum(errors)" will keep growing which will cause the Ki term to have a disporportionately high effect on the loop. (this is called "integrator windup") Many loops place limits on this lest it add another oscillatory behavior (it takes time for the system to "reset" that accumulated error which means it overshoots the OTHER way)

              My point is, don't magically expect that having a PID controller is going to give you good control -- and, most often, far from OPTIMAL control. If the loop can't keep up with the demands of your profile, then your profile is essentially meaningless.

              (e.g., if you expect to preheat at XXX degrees for 5 minutes -- but, the controller takes 4 minutes just to respond to your opening the door -- then the board will not have experienced the desired thermal soak before moving to the next step in the profile. The next board you try may exhibit entirely different behavior -- based on its thermal characteristics)

              Lots of existing literature on the subject. Start at https://en.wikipedia.org/wiki/PID_controller for a brief (!) overview

              Comment


                #27
                Re: Sending PWM through a relay

                Well, I hate to do this to you, you really sound like you know all the vagaries of PID control. But really, with klipper, I push the button, after giving it a target set point and it runs a PID tune for me. It saves off the three pid values, and uses it the next time I turn on the heaters. Honestly, I have never bothered to learn the PID algorithm because it works so darn well out of the box.

                Here's a pic. The first temperature rise was manually setting my printer bed to 100C. Pretty good, it was holding within 3c. It has been a while since I ran a pid tune, and I had changed my default temperature, so it was time. I run the pid tune at 100c (I think my last one was at 60c), the software cycles the temp around 6 times, I accept the changes (off screen). I manually set the temp back to 100C. It overshoots to 100.8c, then comes back down to 100.1c and bounces between 99.9c and 100.1c. Pretty good for "I push the button."

                Now, what you say is true about large thermal masses, I honestly don't know if a large board vs a small board is really going to make a lot of difference in the thermal mass in relation to the heating capability of the oven. If it does, I could certainly run a pid tune with a large object and later a smaller object and save the values, using them selectively based on the size of the board.

                There are a fair number of custom reflow softwares out there, but when I looked, they are pretty tightly linked to specific hardware implementations. Going with klipper, it's a more general purpose (though the author would disagree, 3d printers only) software that supports many boards, probes, configurations, and has many, many features. It's truly overkill for this application, but that's what I like about it. Nearly every feature I could think of is already supported and well tested, and I know it well because I use it on my 3d printer. If klipper doesn't support it, there are well documented frameworks for implementing a custom gcode (I may have to make one or two before this is over.) And octoprint (works with klipper) supports an insane amount of plugins.
                Attached Files
                Last edited by clearchris; 03-19-2020, 10:05 PM.

                Comment


                  #28
                  Re: Sending PWM through a relay

                  Usually a small tiny thermocouple (not in a thermowell) is used.
                  The one in the pic thermocouple looks big which means it has high thermal mass (slow responding) with some conduction heat loss to the oven side wall. If it's right over a heater, when you unplugged things the heaters take time to cool, loss of fan means a thermocouple gets that extra heat for a short time. I think that's why it climbed up. Not sure what you actual temp sensor looks like.

                  Comment


                    #29
                    Re: Sending PWM through a relay

                    Yeah, the loss of the fan was what probably did it, but it wasn't really close to any heater, it was as close to dead center as I could get a loose wire with the door shut.. It was a tiny thermocouple that came with my meter, looks like a k-type.
                    Attached Files

                    Comment


                      #30
                      Re: Sending PWM through a relay

                      Originally posted by clearchris View Post
                      Well, I hate to do this to you, you really sound like you know all the vagaries of PID control. But really, with klipper, I push the button, after giving it a target set point and it runs a PID tune for me. It saves off the three pid values, and uses it the next time I turn on the heaters. Honestly, I have never bothered to learn the PID algorithm because it works so darn well out of the box.
                      The coefficients (assuming the controller only uses the three "classic" ones and doesn't support bumpless transfer, integrator windup, etc. features) will change based on the operating point. (Note that the operating point is deliberately changing based on your profiles) The "system" that you are controlling hasn't been designed for its specific purpose but, rather, thrown together with the controller expected to magically fix its shortcomings.

                      So, you may find that the loop works well at a particular temperature/mass mixture but performs poorly at another. E.g., the effort ("amount of control valve action") required to raise the temperature 1 degree at 50C will be significantly different than at 100C. Likewise, the heat loss/cooling at those points will differ. I.e., the system being controlled is non-linear.

                      You may also find that the setpoint changes introduced by the "profile" lead to a loss of control at those points in time, depending on their magnitudes. A change in the setpoint effectively looks like a disturbance in the process variable. E.g., raising the setpoint 5 degrees looks like someone might have just opened the door (causing the temperature to "fall" by those 5 degrees).

                      You can design a controller to recognize the difference between these scenarios (because it can see that it's setpoint is changing if it watches the set point's value and not just the "error" term). A smart controller can even dynamically adjust the gain (and deadband, windup, etc.) parameters based on the current value of the setpoint to compensate for the dynamics of the process.

                      Here's a pic. The first temperature rise was manually setting my printer bed to 100C. Pretty good, it was holding within 3c. It has been a while since I ran a pid tune, and I had changed my default temperature, so it was time. I run the pid tune at 100c (I think my last one was at 60c), the software cycles the temp around 6 times, I accept the changes (off screen). I manually set the temp back to 100C. It overshoots to 100.8c, then comes back down to 100.1c and bounces between 99.9c and 100.1c. Pretty good for "I push the button."
                      How "good" the controller is working isn't evidenced by the size of the numbers -- without knowledge of what the system's inherent response is. One thing we often do is disable our controls to see if we're actually improving the process's inherent control or making it worse (yes, a controller can overact and make things worse than they might otherwise be in its absence).

                      You should look at particular profiles to get an idea as to how a particular set of tuning values works FOR THAT PROFILE. (assuming you can save/restore them from secondary storage). E.g., if a profile calls for operating at an elevated temperature, you would want to know how the controller works AT that elevated temperature. Likewise, how it then adapts to a different preheat/cooldown temperature (if it is too lsow to cool down, you may need to deliberately alter the profile to compensate for its sluggishness -- or, increase the size of the vent/fan in your oven).

                      Good luck!

                      Comment


                        #31
                        Re: Sending PWM through a relay

                        That's an interesting point, I hadn't considered benig able to run the same pid settings for the whole profile.

                        Here's kind of what I was planning (assume fan on for all).
                        Initial Preheat: Resistive heaters only. (more uniform slow heat)
                        Dryout Phase: Resistive heaters only.
                        Ramp Up to Reflow: Resistive heaters + halogens (all the heat!)
                        Hold at Peak: halogens only (fast acting heat only)
                        Ramp Down: Halogens only if needed, controlled door open if needed

                        Each time different heaters are enabled, the setpoint will be different and the pid coefficients will need to be different. If the fan is on or off, different pid coefficients will be required. It would be very cool to implement a controller that has more flexibility and isn't tied to a setpoint though.

                        On the plus side, my other lamp holder just arrived, I ordered it before CNY and pretty much gave it up as being lost or not shipped. So now I have 2300 watts of heating if needed. That should be more than enough for even larger boards. My SSRs arrived also, so I'm not tied down to my SSR + relay design, but I'll probably go with it anyway.

                        All I need now is to get some insulation, fab a box to hold the electronics, and configure/develop the software.

                        Comment


                          #32
                          Re: Sending PWM through a relay

                          Originally posted by clearchris View Post
                          That's an interesting point, I hadn't considered benig able to run the same pid settings for the whole profile.
                          Think about the two situations that you have to address:
                          - steady-state
                          - profile transitions

                          In the first case, you want the loop to compensate for "leakage" (in the oven) while you're operating at a specific temperature setpoint.

                          In the second case, you want the controller to figure out how to get from setpoint A to B "adequately" (for some definition of "adequate").

                          It's relatively easy to tune the controller for "good/optimal/adequate" control at a specific setpoint (unless you are nearing the extremes of the operational capabilities of your "system" -- too high a temperature to be able to compensate for leakage (insulation) or too low a temperature to keep from "overcooking" things. In steady state, you typically won't have large disturbances (unless you keep opening the door!)

                          The tuning challenge lies in how you get the controller to operate over a wide(r) range of conditions with "good" performance. So, while you might have great control at setpoint A and B -- using different loop coefficients -- you may have poor control during the transition between them (cuz A's coefficients are good "in the vicinity of A" but you leave that vicinity as you approach B!)

                          [The problem comes from the nonlinearity of most controlled systems]

                          In these cases, your loop will typically see a larger "disturbance"... the change in the setpoint manifests as a huge "error" that the loop has to "fix".

                          If the controller implements bumpless transfer, the transition can be more manageable (basically, you try to compensate for the HUGE integrator term that is caused by this big AND PROLONGED "error".)

                          If you're writing code to fiddle with the coefficients dynamically, you might want to look at changing them before -- or after -- the setpoint has been changed (see which gives you better results). Or, pick yet another set of coefficients that you use JUST for the transition.

                          As I said, initially, tuning the controller is usually a non-trivial exercise. Often, you design the controller AND the "system" (being controlled) in concert so that you can anticipate the sorts of control problems that will manifest in use.

                          E.g., on one device where the "air content" (heat, humidity, flow rate) is strictly controlled, the user has to push a button prior to opening the door. This gives the controller the knowledge that the errors that it is seeing are "exceptional" and not "typical process variations". So, all of its "math" doesn't get screwed up by that large blip in the process variables.

                          Comment


                            #33
                            Re: Sending PWM through a relay

                            Long ago I was into the osPID open-source PID controller using that for a reflow-oven. It's abandoned now but still good stuff. It's a custom Arduino incorporating small LCD, pushbuttons, output relay and thermocouple amp. There is a PID library, autotune PID library http://ospid.com/blog/download which has code, schematics.

                            One problem I had is the Maxim MAX6675/MAX31855 thermocouple IC's are sensitive to hum, noise and especially RF from cellphones. So the readings would jump around. With the reflow-oven firmware, it simply looks for oven temperature to get to the profile temperature point and then jumps to the next stage. So temp readings 130,132,151,133, would cause S/W to prematurely jump past preheat and go to soak It just needed a timer or averaging added to the conditional and an RF filter for the hardware.

                            To revisit the project, I would use an ESP8266 or ESP32 and WiFi it so I don't have to babysit things, no USB.
                            But I know of no way to draw graphs using HTML, so the ESP could generate a webpage with a graph of temperature. Didn't want to use some 3rd party IoT site for that.

                            The Arduino project also includes AutoPID which makes that portion easy.

                            Comment


                              #34
                              Re: Sending PWM through a relay

                              Originally posted by redwire View Post
                              One problem I had is the Maxim MAX6675/MAX31855 thermocouple IC's are sensitive to hum, noise and especially RF from cellphones. So the readings would jump around. With the reflow-oven firmware, it simply looks for oven temperature to get to the profile temperature point and then jumps to the next stage. So temp readings 130,132,151,133, would cause S/W to prematurely jump past preheat and go to soak It just needed a timer or averaging added to the conditional and an RF filter for the hardware.
                              In general, you want to know when the loop has "stabilized" at the setpoint and use THAT point in time to start the "profile timer" (e.g., preheat at X degrees for M minutes). The expiration of the timer should cause the setpoint to advance to the NEXT step in the profile.

                              This is predicated on knowing that the loop will stabilize "reasonably quickly". If underdamped, it will "ring" at the transition. If overdamped, it will be sluggish reaching the new setpoint.

                              If you can reach INTO the controller, there are lots of indicators that you can leverage for your "in control/stabilized" signal:
                              • abs(error) less than some value (e.g., operating WITHIN the deadband which effectively takes the controller out of the picture -- "no control needed, here")
                              • integral term below some value (you're integrating errors)
                              • derivative term goes to some small value (very little change happening, now)


                              Note that you can also change how you process the instantaneous error; e.g., if you measure the derivative of the process variable INSTEAD OF the error term, then the sudden changes in the setpoint don't appear to be huge changes -- derivatives -- in the error term)

                              And, of course, how/where you measure the process variable plays a huge role!

                              To revisit the project, I would use an ESP8266 or ESP32 and WiFi it so I don't have to babysit things, no USB.
                              But I know of no way to draw graphs using HTML, so the ESP could generate a webpage with a graph of temperature. Didn't want to use some 3rd party IoT site for that.
                              Skip the HTTP service entirely. Just push raw data out a serial port (or TELNET connection) and use some external app (e.g., Excel) to draw your pretty graphs.

                              Comment


                                #35
                                Re: Sending PWM through a relay

                                Redwire: I have experienced this max IC jitter. To solve it, you put a small ceramic cap across the thermocouple, and it's pretty solid after that.

                                No one likes the graph I posted above? I think octoprint is pretty slick... Looks a lot better when I'm not taking a cell phone picture of an lcd screen too.

                                Comment


                                  #36
                                  Re: Sending PWM through a relay

                                  Octoprint server runs on a Raspberry Pi or Beaglebone or PC etc. something with Ethernet? For me that's too much to need a PC/laptop and usb connection to the oven controller, something that only has one-in one-out.

                                  MAXIM thermocouple-to-digital IC's suck, I had to add the lone cap but also needed two ferrite beads. Because the IC's have stupid diagnostics (shorted to VCC, shorted to GND) which means the thermocouple must be floating. Most in thermowells connect to the tube housing.

                                  Comment


                                    #37
                                    Re: Sending PWM through a relay

                                    I have a RpiZeroW ready to go. I think it may have ran me $12. It's actually smaller than my arduino.

                                    I haven't run into that issue with any thermocouple I have used so far, but I haven't tested the one I just installed. You may have saved me a bunch of time.
                                    Last edited by clearchris; 03-21-2020, 07:54 PM.

                                    Comment


                                      #38
                                      Re: Sending PWM through a relay

                                      Originally posted by redwire View Post
                                      Octoprint server runs on a Raspberry Pi or Beaglebone or PC etc. something with Ethernet? For me that's too much to need a PC/laptop and usb connection to the oven controller, something that only has one-in one-out.
                                      But you're not going to be twiddling any "knobs" on a "front panel". You're going to use it by defining a profile (did you want to have a numeric keypad and some bizarre set of "codes" to set up, store, and recall profiles? and a graphic display to view the temperature history AT the oven??).

                                      Run a semi-permanent cable to your "shop computer" and just load that app when you want to interact with the oven. Treat it as a computer peripheral instead of as an appliance.

                                      Comment


                                        #39
                                        Re: Sending PWM through a relay

                                        Curious: GCODE is actually a very, very old spec that runs most CNC equipment. And you are exactly right, there will be no knobs, buttons or displays on the oven. It's all going to be handled through octoprint and the gcode profiles. And yes, gcode is pretty bizarre, it's not what anyone would use if they were constructing it today, but it's what everyone uses because it's a legacy tech that just kind of still works.

                                        Comment


                                          #40
                                          Re: Sending PWM through a relay

                                          Originally posted by clearchris View Post
                                          Curious: GCODE is actually a very, very old spec that runs most CNC equipment. And you are exactly right, there will be no knobs, buttons or displays on the oven. It's all going to be handled through octoprint and the gcode profiles. And yes, gcode is pretty bizarre, it's not what anyone would use if they were constructing it today, but it's what everyone uses because it's a legacy tech that just kind of still works.
                                          That was my point. You need a "high level" interface to program the oven. Adding that TO the oven is just silly as it commits lots of resources to a low usage task.

                                          Instead, you would want to leverage an existing "high resource" tool -- a PC -- to do that work at a higher level of abstraction (so you're less likely to make a mistake in the programming).

                                          That leaves you with a "transport" issue: how do you MOVE the information back (and forth!) to the oven from the PC.

                                          One way is to write a memory card (SD, etc.) and physically carry it to the oven, insert it and press START. The oven can store any observations made during the process on that card -- which can then be examined LATER, when the process is complete and the card removed and returned to the PC.

                                          That requires a minimalist interface -- insert card, press START, wait for light to turn off to indicate process complete. But, gives you no way of interacting with the process.

                                          I like having "headless" devices that I can talk to from ANY machine on my local internet. This lets me apply higher level tools to those activities. And, decouples the user interface from the actual process/mechanism. E.g., let the oven sit out in the garage (low cost space) while I can sit in my office and work on other activities WHILE it is doing its thing. Yet, still be able to monitor and control it.

                                          Comment

                                          Working...
                                          X