Home Forums PID Control / Tuning Setpoint Profiles (for Reflow et al)

Viewing 6 posts - 31 through 36 (of 36 total)
  • Author
    Posts
  • hairykiwi
    Participant
    Post count: 7

    Earlier this year, in order to solder the prototype OTM-02 PCBs, and never having done any reflow soldering before, I spent a few days, (quite a few) experimenting with an osPID Controller connected to a Lloytron E833WH hotplate and later, an Elgento E048 mini-oven.

    Clicking on the image above redirects to a dropbox folder containing the full-res screen captures, data and profiles used in the trials. I confess the process wasn’t exactly super-methodical or well documented – in fact I probably used the method least approved of by control engineeers (‘trial and error’, aka SWAG) nevertheless, I’m really happy with the final result.

    After persevering far too long with the hotplate, I gave up on it; largely due to it’s huge thermal mass – it was far too brutal and too easy to over or under control.

    I also gave up on PID control, but not the osPID Controller – it really is an awesome bit of kit. Instead, and largely inspired by the down-to-earth advice (KISS, essentially) of MikesElectricStuff in his video: Some random hints for quick hand SMD assembly, I created a couple of new profile types which enable programmatic control of the osPID Controller’s Output:
    – Type 4: step-output-period – set the power Output (%) to a specified level for a specified period.
    – Type 5: step-output-until_crossing_temp – set the power Output (%) to a specified level until a specified Input temperature is attained.

    The Firmware and Front-End needed to use these profile types can be downloaded from the following github repos:
    https://github.com/hairykiwi/osPID-Firmware.git
    https://github.com/hairykiwi/osPID-Front-End.git
    There are no pre-compiled editions (executables), so Processing and ControlP5 do need to be installed. Instructions for installing are included in the Front-End README.

    Type 4, was the first step on the learning curve towards creating Type 5. I wouldn’t recommend Type 4 for use in a reflow soldering profile, but it may be useful for some other applications.

    Type 5 embodies a lot of the simplicity of Mike’s, and no doubt other’s, approach to reflow soldering – know how your oven responds, control it with a variac (or in our case the osPID Controller + SSR) and achieve consistency by timing – with the huge benefit of being able to express that directly in a profile, and without any of the hassles involved with determining PID values. That’s not to say there’s no effort in setting up an oven for reflow soldering using Type 5 profiles, just that it’s possibly way more intuitive.

    I’ll post again soon with a few more thoughts and observations from the trials.

    In the meantime, here’s the latest Type 5 based RHOS reflow profile for the Elgento E048 oven:

    Elg-025     //(X = N/A) PID = X | X | X | OP WINDOW = 5.0 Sec | ROHS profile for Elgento E048 9 litre 800W two-bar oven - from ASDA online UK
    5, 100, 140 //Step Output to 100% until crossing 140°C - (effective) End of J-STD-020 ramp 1
    5, 50, 190 //Step Output to 50% until crossing 190°C - (effective) End of J-STD-020 ramp 2
    5, 100, 217 //Step Output to 100% until crossing 217°C - A 'Place-marker' - enables buzz at BEGINNING of critical heating phase
    127, 0, 1 //Buzz for 1 second - START stopwatch to monitor compliance with critical phase of J-STD-020 profile
    5, 100, 245 //Step Output to 100% until crossing 245°C - temp determined by experiment to account for approx 8°C of overshoot to 253°C)
    5, 0, 217 //Step Output to 0% until crossing 217°C - A 'Place-marker' - enables buzz at END of critical phase
    127, 0, 5 //Buzz for 1 second - signal to open door && - STOP timing if monitoring compliance with critical phase of J-STD-020 profile
    5, 0, 0 //Step Output to 0% until crossing 0°C

    The same profile as it appears in the Front-End:

    And the result:


    Super-smooth, but not perfect – the Output blip that occurs during the second buzz (around the 6 min mark) shouldn’t be there, but neither is it significant enough to worry about. The 5 second buzz could be reduced to 1 second, (it’s only a signal to ‘stop timing’ when cross checking compliance with the JEDEC J-STD020 profile – and/or a door open signal) but equally, I should be able to implement a proper fix fairly soon.

    Deusjevoo
    Participant
    Post count: 3

    @hairykiwi wrote:

    I’ll post again soon with a few more thoughts and observations from the trials.

    Curious how it’s going?
    And the more thoughts and updates on it if possible?

    Regards,

    hairykiwi
    Participant
    Post count: 7

    Hi Deusjevoo,

    Thanks for the prod. 😉

    Unfortunately I haven’t done any more reflow soldering since making the first PCB with my osPID + Elgento E048 mini-oven. I can’t recall the full extent of the “more thoughts and observations” I previously promised to write, but here’s a good start…

    I took a look at your thread on a similar topic – viewtopic.php?f=10&t=577 – and it reminded me that in the earlier stages of my testing, I experienced exactly the same symptoms you described:
    Where a Type 1 ‘ramp’ is followed by a Type 2 ‘wait’, and where the actual ramp rate achieved exceeds the desired rate, the system must first cool to the temperature specified in the wait profile, before the sequence can continue. Not at all ideal for reflow soldering. Furthermore, IIRC, I found that if I reduced the PID settings in order to achieve, or stay below the rate desired for the first ramp in a reflow sequence, (to avoid the above situation) those settings were not as aggressive as they could have been, to ramp up the temperature at the desired rate during the second ramp – the actual reflow phase.

    These experiences were certainly another factor that lead me to give up on PID control and create the Type 5 ‘step-output-until_crossing_temp’ profile I described in my earlier post. The only(?) scenario where a Type 5 profile would fail, and could be a problem, is if the power output it specified is insufficient to ever achieve the desired crossing temperature. I think that kind of ‘envelope limit’ is easy enough to determine and avoid by testing over a range of output power settings however.

    Similarly, (but probably not identically to your situation) I also experienced the undesirable, potentially dangerous, situation you described:
    When the actual rate exceeds the desired rate, in the mid to top end of the working temperature envelope especially, an out of control situation can occur.

    I say “probably not identically” because in the following example, the best I could find right now, you can see the compounding effect of integral wind-up (I believe) AND system thermal inertia (for certain). I no doubt removed the test piece at 260degC, before it was incinerated – hencewhy the PID Input continues to fall despite the Output being nailed at 100% after the (approx) 340 second mark.


    PID settings fail to control the desired temp (PID input)

    I’m really not sure if, or how, a true PID system could protect against an imminent ‘run-away rate of change’ situation; not without augmenting the PID with some kind of system model. In this respect, it would be interesting to hear some thoughts on system protection methods from a PID expert/Control engineer – Brett?

    Regarding bugs, there are two in my osPID controller that I would like to work on:
    One is my creation: The output blip you see in the last image of my previous post. It’s minor, so working on a solution is low priority, sorry.
    The other is more annoying, and possibly a firmware bug:
    After using the osPID for controlling some equipment, (eg a coffee machine) then either ‘recommissioning’ the osPID controller to run a reflow soldering profile, or, significantly changing the Set Point directly to control another system, (eg an incubator running at 30degC) and then, reverting the Set Point back to control the coffee machine, it appears the second time the Set Point is changed, control of the the coffee machine temperature initially fails and the result is thermal runaway; caught only by the machine’s own thermostat protection. The work-around I use to rectify things is to change the osPID controller to manual mode, reduce output to zero, restart it, re-enter the same SP and PID settings a second time (or make a 0.1 incremental change – something that won’t affect the system – to ensure the change to the variable is effected) before reselecting auto mode.

    These work-around steps are not absolute, just as best as I recall, but they’ve certainly been needed more often than not.

    The other setting I’d really like to see exposed directly on the controller is the ‘Relay Output Window’ from the Configs tab of the osPID_FrontEnd software. This setting has an enormous influence on stability and having easy access to it would help in situations where you don’t otherwise need to connect up a laptop to make the change.

    Cheers.

    reserve
    Participant
    Post count: 7

    hello together,

    I finally got my ospid yesterday and after some tuning I get fantastic curves (in this case i opened the door a bit too late):

    I wonder why I get some temperature drops? I tried various K-Type and i get always these measurement-errors. Does anyone else get these errors?

    Greetings from germany,
    Tobias

    hairykiwi
    Participant
    Post count: 7

    Hello Tobias,

    That’s a really nice result!

    What oven are you using? And what Profile and PID settings did you use?

    I had a few occasional glitches in my temperature measurements similar to yours – see the screen captures in my collage, above. I don’t remember the exact cause(s), but I suggest checking the thermocouple terminations for loose connections into the osPID, and the sensor end for a loose or poor weld. After accidentally cutting off the welded probe one time, I carried on testing by twisted the two Type K wires together. It worked for a while until the twisted wires began oxidising, as best as I recall. I don’t think I ever had problems with the firmware in this respect, so I really do think it’s more likely to be a physical connection issue.

    Let us know what you find out.

    Hamish

    reserve
    Participant
    Post count: 7

    @hairykiwi wrote:

    What oven are you using? And what Profile and PID settings did you use?

    It is a modified Severin TO 2035 with an additional 1500W heating element at the top, so now it has 3000W.
    Also I modified the firmware (io.h) a bit, to use both relais at the same time.
    Here is the profile:

    JedecPB		//first row is Profile Name
    3, 40, 0 //Step Setpoint to 40, wait 0 seconds
    2, 0, 0 //Wait for PID Input to cross setpoint
    1, 100, 60 //ramp setpoint to 100 over the course of 60 seconds
    2, 0, 0 //Wait for PID Input to cross setpoint
    1, 140, 90 //ramp setpoint to 140 over the course of 90 seconds
    2, 0, 0 //Wait for PID Input to cross setpoint
    1, 220, 80 //ramp setpoint to 220 over the course of 80 seconds
    2, 0, 0 //Wait for PID Input to cross setpoint
    1, 50, 150 //ramp setpoint to 50 over the course of 150 seconds
    2, 0, 0 //Wait for PID Input to cross setpoint
    3, 0, 0 //Step Setpoint to 0, wait 0 seconds
    127, 0, 5 //buzz for 5 seconds

    And my settings:
    Kp: 15
    Ki: 0.02
    Kd: 0

    To the temperature drop problem: I don´t think there is any loose connection outside or inside the osPID. I tried 3 different thermocouples and all of them had these little errors (randomly, some curves worked fine without an error, others with more than 5 errors). Also I can´t reproduce these error by wobbling the cables and/or osPID… It’s random…
    Nevertheless i will check the solder points inside the osPID.

Viewing 6 posts - 31 through 36 (of 36 total)
  • You must be logged in to reply to this topic.