[hairykiwi]

in reply to: Setpoint Profiles (for Reflow et al) #3822

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

[hairykiwi]

in reply to: Setpoint Profiles (for Reflow et al) #3820

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.

[hairykiwi]

in reply to: Setpoint Profiles (for Reflow et al) #3818

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.

[hairykiwi]

in reply to: Proportional control calculation #3786

Thank you both – now I think I understand why my osPID controlled coffee machine occasionally appears to go into meltdown mode.

While this ‘meltdown mode’ is a useful test of the over-temp thermostat in the coffee machine, it can definitely also result in an unsafe situation arising – especially if the coffee machine operator is my wife who doesn’t care how it works, just as long as it works as expected – think scalding hot, steamy-water sputtering out after the operator has failed to check the input temperature is within the expected range…

Now, I can see why bumpless transfers are required for running profiles smoothly, but they clearly do nothing for helping create a nice espresso safely. If you agree with that, I’d be happy to have a go at hacking the firmware so that bumpless transfers are only available when running a profile.

As I’m currently using my osPId Controller for both coffee machine and reflow soldering duties, I think I might qualify as a suitable guinea pig :geek:

It would be useful to have a short discussion before I make any (potentially poorly thought out) changes though, so please do share your thoughts and ideas.

[hairykiwi]

in reply to: Thermocouple grounding #3977

I ran into this exact same problem late last year. I discovered that powering the osPID through its front mini-USB socket using a USB recharge wall-wart effectively isolated the osPID power supply from mains earth. It’s not ideal, sure, but at least it allowed me to make some way better coffee.

For reference, I used the following Type K thermocouple drilled out (very carefully – the copper washer is so thin it needs to be punched rather than drilled) and mounted by one of the existing 3 mm tapped holes in the boiler: http://uk.rs-online.com/web/p/thermocouples/6212287/

deejay1272 – which isolated thermocouple did you use and where did you buy it?

[hairykiwi]

in reply to: osPid front end 3870e68 compile problem #3897

I just discovered Brett already posted the solution to this problem in the following thread:
viewtopic.php?f=4&t=266&p=407#p407 (The one dated Mon Apr 30, 2012 5:19 pm)
In it, he says, ‘…you’ll need to copy the “profiles” folder to the folder containing your processing.exe’

After some searching, I still don’t understand why the methods getMainFilePath() or getFolder(), which appear in the code linked to in my previous post, are not available in processing version 2.0b3 (Java). Any ideas?

– Hamish

[hairykiwi]

in reply to: osPid front end 3870e68 compile problem #3896

I’m experiencing the same problem. ragaRew’s solution works, but maybe this shed’s some light on the source of the problem.

in osPID_FrontEnd.pde (in a folder D:osPID_FrontEnd)
I inserted

System.out.println(System.getProperty("user.dir"));

just before:

    String curDir = System.getProperty("user.dir");

Then, (click run and) in the processing IDE console window, just before the null pointer debug message(s) it prints your ‘user directory’:

D:Processingprocessing-1.5.1 – i.e. the location of processing.exe

So it seems that the “user.dir” is the directory of processing.exe, not the sketch (osPID_FrontEnd.pde) folder.

Perhaps the getProperty(“user.dir”) needs to be replaced with either getMainFilePath() or getFolder() method?
as detailed here:
http://processing.googlecode.com/svn/trunk/processing/build/javadoc/everything/processing/app/Sketch.html#getPrimaryFile%28%29
But using Processing v1.5.1 those methods are not recognised – and Processing is completely new to me.

I’ll try and find a solution, but Brett will be way more up to speed on this stuff than me.

BTW, thanks Brett/Lim – I’m really enjoying playing with osPID for controlling my Rancilio Silvia coffee machine. Will post some pics of that real soon.

[Author]

Posts