User Tools

Site Tools


picoReflow

More and more semiconductors are produced in packages (the chip's case) which have become impossible to hand solder with a solder iron. The switch from through-hole (THT) to surface mount technology (SMT) has actually made hand soldering much easier (although still many believe the opposite to be true) but now we are faced with BGA and other packaging forms which only have contacts on the bottom of the chip.

In order to be able to work with these chips, a reflow solder process is needed. So we've built our own DIY reflow oven, using a Raspberry Pi as a universal, web enabled, PID Reflow Oven Controller driving a convectional hot air oven originally designated for gastronomy/bakery purposes.

Since it's all open-source you may also use it to build a kiln controller, the world's most sophisticated pizza oven controller and experiment with temperature curves for fresh/frozen pizza and has also been reported to be used in other lab/production processing systems and autonomous climate testing.

Remember:
Never put food into an oven that you have used for reflow soldering purposes.

  • Raspberry Pi
  • Supported SPI driven Cold-Junction K-Type Thermocouple converter:
    • MAX31855
    • MAX6675
  • GPIO driven Solid State Relays (230V heating/fan)
  • PWM driven MOSFET (12V cooling)
  • Python control daemon (running on the Pi)
  • HTML5/Websocket OS independent multi user web-client
    • Live Monitoring & control
    • Browser based Profile/Curve Management + Slope Calculator

At this point (although still only a PoC-Demonstrator) the software is a fully functional PID controller and even incorporates a simulator, so you can try, play and extend the software without the need for real hardware. If the daemon doesn't find a thermocouple, it will automatically switch into simulation mode. It's still a little bit hackish and the interface could use a little more care but when we get time we'll throw some of it against progressing this further.

EKA KF412

The EKA KF412 is an entry level “professional” hot air oven produced by Teknoeca srl in Italy and was chosen to be used as a lab/reflow oven because the hot air (convectional) temperature transfer seemed preferable to infrared and its maximum temperature rating of 300°C compared to 250°C found on many other ovens in this class.

Attribute Value Photo
Size 540 x 450 x 405 mm
Power 2.6 kW @ 230 V
Temp. Max. 300 °C
Weight 21 kg
Capacity 4 Trays (330 x 260 mm)

The original control knobs/switches have all been removed and the heater and fan each have been equipped with a zero-cross detecting solid-state relay. The relays have been mounted on the bottom sheet metal of the oven, to act as heatsink for the SSR (if necessary).

First tests with an ATmega based reflow controller have proven the capabilities of the oven to meet the ramp up and maximum temperature demands of an average reflow profile. However, due to the insulation of the oven chamber which increases its thermal inertia, simply turning off the heat will not result in cooling down. After passing the maximum reflow temperature, a quick but controlled cooldown is necessary in order to bring the solder paste back into a rigid state. Simply opening the door cannot be a solution for three reasons:

  • Opening the door will produce vibrations at the point in time when the soldering paste is in the most fluid state which in turn could result in bad joins or even move parts out of placement.
  • The oven has no way to control the temperature anymore in order to meet the reflow profile.
  • Autonomous operation is impossible.

The software already drives a second GPIO that is for cooling. A radial fan will be mounted on the back and blow fresh cold (room temperature) air into one of the two metal pipes that come out of the oven chamber in the back. This will give the Raspberry full control over both heating and cooling and should provide the quickest and most reliable process with a DIY convectional reflow oven. We still need to figure out some kind of valve so that hot air cannot escape from the oven through the cooling system.

Oven Monitoring

Temperature Measurement

We performed tests with N4148 diodes as temperature sensors (hackish, simple and cheap approach) but it soon became clear that a reliable reflow controller would need reliable temperature measurement. The diodes were changing their characteristics too quickly and each one had a different/unstable compensation curve. More research finally led to K-type thermocouples as a solution.

MAX31855 Hardware Setup

The Maxim MAX31855 Thermocouple-to-Digital Converter (MAX6675 upgrade) performs cold-junction compensation and digitizes the signal from a K-type thermocouple. The data is output in a signed 14-bit, SPI-compatible, read-only format. It resolves temperatures to 0.25°C and exhibits thermocouple accuracy of ±2°C for temperatures ranging from -200°C to +700°C.

We have used a Adafruit MAX31855 breakout board, which was sponsored by Watterott Electronic to help our research efforts but you can also easily hack your own adapter and try to sample the chips.

MAX31855 RPi PIN Rev1 Rev2 Schematic
Vin NC NC
3Vo P1-1 3V3
GND P1-9 GND
DO P1-11 17
CS P1-13 21 27
CLK P1-15 22

Please check if you have a Rev1 or Rev2 Raspberry:
P1-13 is GPIO 21 on Rev1 but GPIO27 on Rev2. Since we only have Rev2 boards, the code is set to GPIO 27 by default.

Software

The picoReflow software uses the luckily already published, open-source MAX31855 python library to get the temperature from the chip.

Sensor configuration & placement

Door State

The door state (open/closed) is also covered by a microswitch connected to a GPIO (P1-12/GPIO18 & P1-14/GND) and will return the door state back to the webclient.

Oven Control

Some parts, cables and connections in the oven will carry and expose live 230V. It should be obvious that you make sure, that the oven is unplugged before connecting the control SSR or Triac to prevent electric hazards.

Heating

Load Wiring

Signal Wiring

SSR connected to P1-23

PullDown Connection (default) PullUp Connection (alternative)

The default configuration has historically been to use the PullDown config, which results in an inverted control logic: When you pull GPIO23 low, the heater is switched on and when you pull GPIO23 high, the heater is switched off.

Please keep in mind that you'll have to have some script/code in your setup that makes sure that GPIO23 is pulled high as soon as the system has booted (to be sure the heater is off) or change your setup to PullUp configuration instead, if you don't want to worry/bother.

Cooling

MOSFET connected to P1-19

Fan

SSR connected to P1-21

In the current software implementation is a 200°C cut-off for the fan. As soon as the temperature rises above it, the controller will disable the fan in order to minimize vibrations while the solder paste is in fluid state. We will have to A/B test if this is necessary or not but for now it's implemented.

Software

Although picoReflow seems to become ever more popular and is working fine, it has its limits in terms of flexibility and use-case adaptability: It was only modeled and catered to the parameters and constraints of a reflow soldering process.

With the help of a lot of people giving feedback and using picoReflow in the wild, it was easy to see that a more flexible, modular and powerful approach would be needed to become a fully autonomous, multi-module governing/monitoring bot for any DIY appliance. She calls herself governess but she's still not ready for anything yet but it's progress. More appliance/module/driver/task modelling/linking will be required. It has to be totally data-driven in order to offer any useful flexibility.

With the switch to angular/ionic2 almost everything that had been done in angular1 in the meantime was useless and had to be re-implemented, a few concepts prevailed though and a rough client mock is the only thing that has been done so far while waiting for angular/ionic2 crowd to settle a bit into stable before cracking the tough nuts. So far a lot of the desired features are already mocked or in the process of implementation but the server will need to be a complete re-implementation as well. So, as long as it's only me I can only do so much in this time. Any helping hacker brain with python and/or angular2/ionic2 skills or the will to acquire them (learning by doing) is invited to join and help, we have all the tools & infrastructure needed to do remote hackathons as well.

Screenshots of new the interface (Profile-Editor)

Profile Editor: Temperature Curve Profile Editor: Circulcator Curve

Dependencies

We've tried to keep external dependencies to a minimum to make it easily deployable on any flavor of open-source operating system. If you deploy it successfully on any other OS, please update this:

Currently tested versions

  • python2.7
  • greenlet-0.4.2+
  • bottle-0.12.4+
  • gevent-1.0+
  • gevent-websocket-0.9.3+

Ubuntu/Raspbian

$ sudo apt-get install python-pip python-dev libevent-dev
$ sudo pip install ez-setup
$ sudo pip install greenlet bottle gevent gevent-websocket

Gentoo

$ emerge -av dev-libs/libevent dev-python/pip
$ pip install ez-setup
$ pip install greenlet bottle gevent gevent-websocket

Installation & Usage

Clone the sources from github

$ git clone https://github.com/apollo-ng/picoReflow.git

Create the initial config and start the server

$ cd picoReflow
$ cp config.py.EXAMPLE config.py
$ ./picoreflowd.py

Point your browser to 127.0.0.1:8081

Repository & Issue Tracker

Screenshots

Running Reflow Job

Curve editor

With the curve editor you can change existing and create new temperature curves. Just drag the points in the graph to the position you want and drop or use the text fields below to enter specific values manually. The resulting slopes are calculated automatically for convenient datasheet comparison.

Simulation

In order to get more realistic temperature values during software development and testing, without actually having to run or even have an oven, we have implemented a temperature simulation module which is active automatically, when no temperature sensor is found.

Parameters

The following thermal parameters are the basis to simulate the energy flow from the heating element through the oven and finally into the environment.

Parameter Unit Example value Explanation
T_env °C 25 Environment temperature
C_heat J/K 100 Thermal capacity of heating element
C_oven J/K 2000 Thermal capacity of oven
P_heat W 3500 Heating power
R_oe_nocool K/W 1.0 Thermal resistance between oven and environment (cooling disabled)
R_oe_cool K/W 0.05 Thermal resistance between oven and environment (cooling enabled)
R_ho_noair K/W 0.1 Thermal resistance between heating element and oven (circulation disabled)
R_o_air K/W 0.05 Thermal resistance between heating element and oven (circulation enabled)

Calculation

Every \Delta t the following calculations are performed:

Thermal energy flowing into the heating element:

Q_h = P_heat * \Delta t

Temperature change of heating element by heating:

\Delta T_h1 = Q_h / C_heat

Temperature change between heating element and oven:

P_ho = (T_h - T) / R_ho

\Delta T_1 = (P_ho / C_oven) * \Delta t

\Delta T_h2 = - (P_ho / C_oven) * \Delta t

Temperature change between oven and environment

P_oe = (T - T_env) / R_oe

\Delta T_2 = - (P_oe / C_oven) * \Delta t

Temperature of oven and heating element at this timestep:

T = T_old + \Delta T_1 + \Delta T_2

T_h = T_h_old + \Delta T_h1 + \Delta T_h2

picoReflow in the Wild

This project already has inspired a couple of people who are using this concept and free software stack for their own purposes:

DIY Reflow Toaster

Ararpi Reflow Oven

Moore Bros Composite Oven

moore-bros-composite-oven-with-picoreflow-hardware

A custom built oven to bake carbon composite parts.

WiFi/Raspberry Pi pottery kiln controller

Discussion

John
2014/01/29 21:05

I would like to try this out but being new to the Pi I'm unclear just where to out the modules to get it running in demo mode. I looked for information on where to put everything but didn't locate any. Can you give us a little guidance?

Thanks

chrono
2014/01/29 21:12

Oh, well, we put it out but we didn't expect feedback so soon :) The docs are still a bit lacking. If you can join us on IRC (#apollo on freenode) it would be easier to answer specific questions.

Otherwise I would ask you kindly to give us a little time to draw up some graphs/schematics and take some pictures of the prototype cabling so that it will be much more clear. For now we just wanted to put the software out and start documenting the rest. Now that there is clearly communicated demand we have a reason to focus on it :)

The demo mode needs no hardware (not even a pi). You can just run it on your computer as long as you have python and the python modules installed as documented in the repo.

John
2014/01/31 03:03

I was wondering if controlling the heating elements with a PWM triac driver to control the heat is worth the extra effort or just staying with stright ON/OFF control.

I'd like to know more on how your venting the oven. Since the oven your using is not available in the US could you post a few pictures so we can get an idea how you vent that oven so we get some ideas to use when modifying ones we can get here?

chrono
2014/02/07 15:23

Given the thermal inertia of the oven (very slow), there is no need for fine and granular control. Switching on and off in second intervalls is more than enough. However, a Raspberry Pi controlled triac setup would be interesting nevertheless, maybe for people having trouble sourcing zero-cross solid state relays. Have you ever tried it?

The venting isn't finished yet. Fortunately our oven offers two metal pipes which go into the back of the oven chamber right above the fan/heater element, behind the backplate. As soon as we open the oven again I'll take a picture. The original function was to allow moist air to be pumped into the oven for some bread/gastro related baking technique I suppose :) I guess drilling two holes and pushing copper tubes in there will give the same effect.

John
2014/02/07 16:24

I kinda figured that. I've got a triac design on the boards that is I2C controlled. It forced air called with its fan. I've not built it yet however so maybe I'll look at building it.

My thoughts are to have a I2C micromatch connector on the back of the oven that the Pi connects to. All of the interfacing will be done through it including the thermocouple interface, solid state relay interface and the cooling fan. I'm putting the design together now. Should only require very minor changes to your software to use it.

chrono
2014/02/08 11:49

Sweet :) We're eager to see what you cook up with it :) The software should be relatively easy to adapt to other use cases. Maybe you'd like to join us on github so that we can use the benefit of the collaborative tools like the issue tracker and of course you're always welcome to join us on IRC for a more real-time discussion :)

Jan
2014/04/28 08:08

Hi,

I tried to install your Software, but got a error msg when i tried to start the Server. I had to edit picoreflowd.py on line 10:

— 10 from geventwebsocket import WebSocketHandler, WebSocketError — to — 10 from geventwebsocket.handler import WebSocketHandler 11 from geventwebsocket import WebSocketError —

Then it runs perfectly ;) I like your Software, great idea ;)

I searched for the “EKA KF412” and was really shocked about the price, at least 611,- Euros in Germany. Then I searched for an alternative and found the “Bartscher AT110”.

Size: 460x570x460 mm Power: 2.7 kW @ 230 V Temp. Max.: 300 °C (about 3 min to get 180°C) Weight: 20 kg Capacity: 3 Trays (325 x 265 mm) completely made of stainless steel

for about 350,- Euros.

I will have my the next Days, then i will test if its fast enough ;)

Greets Jan

chrono
2014/04/28 09:01

Yeah, there have been some changes with the python deps, so depending on which distribution/python version you are running this may happen. Especially gevent-websocket :) But glad to hear you could fix it yourself. I guess those are the same issues we had with the PiGI - Raspberry Pi Geiger-Müller Interface software, we probably will backport the framework for picoreflow as well, to have better interface features and less hassle setting up.

As for the ovens, yeah, that's some old industry with all the old bullshit like having insane prices, so that the sales reps can generously shave off 50% when you talk to them. The Bartscher looks like a good alternative too :)

For the 3D Printer I have asked http://www.unifrax.com/ if they would supply sample material of their paper/felt insulators, this might also be a good material to wrap the oven chamber inside the case to achieve steeper heat-up ramps.

Looking forward to hearing about your progress…

Jan
2014/04/30 14:25

I just tested my Control Board. Why do you set the GPIOs to “1” when heating and Fans are “OFF” and not “logically” when they are powered “ON”. I use S216S02 and S202S02 for driving the AC Lines and i trigger them directly from the GPIOs. They only need 8mA to Trigger on and have an 4KV isolation, so there is no Problem to trigger them directly ? I changed this in my Version of your Software.

The MAX31855 works great! I had to order some more, because it came directly from Mouser USA, so when anybody needs one or two pieces, contact me ;)

My Oven has not arrived Yet … :(

chrono
2014/04/30 14:47

We've set them up as sinks IIRC, so a 1 will pull it high (turning off) but that was just for testing. I haven't had the time to make a full wiring diagram, that would explain things better. There is no predefined way of doing anything anyways.

I'd like to have something people can “just copy” - give a complete wiring diagram and have the software run with that out of the box. And anyone who is able to grasp the underlying concepts should also be free to implement it however they choose, like you did :) For example: The cooling fan might be a 12V model that's controlled by a N-type MOSFET connected to a PWM output of the PI to have more control over the airflow instead of just turning on/off.

Jan
2014/05/04 00:03

Ok, I got the Oven now. I testet it and i think is does not heat up fast enough. The temperature rises only with 0,55 °C/Sec.

It reached 210 °C after 5:30, I think its too lame. How fast does you Oven heat up ?

The second Problem ist, that the MAX31855 does not show the correct temperature. I tested this with two other thermometers and both showed “much” higher temperatures then the MAX31855. Maybe the Thermocouple is the Problem. Do I need a special thermocouple for the MAX31855 ? I use one from -65 bis +400 °C (Greisinger GTF300 GS Typ K)

Kurt
2014/09/18 23:46

Have things pretty well set up, but for some reason I get random “MAX31855Error: Thermocouple short to ground” errors, with 2 different MAX31855 breakout boards. As far as I can tell, there's nothing shorting, all good connections, etc.

What I'd like to do is ignore that and continue running, however once that occurs, the program quits recording the temperature until I kill picoReflow and start it again.

Is there a way to tell it to just keep going, or even close just restart the max31855 part of the program when that happens?

Specific error:

Exception in thread Thread-2: Traceback (most recent call last):

File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
  self.run()
File "/home/pi/picoReflow/lib/oven.py", line 185, in run
  self.temperature = self.thermocouple.get()
File "/home/pi/picoReflow/lib/max31855.py", line 41, in get
  self.checkErrors()
File "/home/pi/picoReflow/lib/max31855.py", line 78, in checkErrors
  raise MAX31855Error("Thermocouple short to ground")

MAX31855Error: 'Thermocouple short to ground'

chrono
2014/09/21 07:03

That sounds like an annoying problem. I've never seen this error before, since the error message is not generated by our code, I would assume, it's coming from the max31855 lib. So I wonder, when I read the error message: Is your thermocouple sensor (the point where the two metals are welded together) hanging in free air or is it touching anything (maybe conductive?).

I'll have a look into our code and check if we can fail more gracefully. In the meantime, could you apply this patch and test if doesn't fail until I get a chance to reproduce the issue?

diff --git a/lib/max31855.py b/lib/max31855.py
index 38ac170..583d4b0 100644
--- a/lib/max31855.py
+++ b/lib/max31855.py
@@ -75,7 +75,7 @@ class MAX31855(object):
             if noConnection:
                 raise MAX31855Error("No Connection")
             elif shortToGround:
-                raise MAX31855Error("Thermocouple short to ground")
+                #raise MAX31855Error("Thermocouple short to ground")
             elif shortToVCC:
                 raise MAX31855Error("Thermocouple short to VCC")
             else:

I've opened issue #2 on github and already pushed a branch with a possible fix. But be advised, it's not tested, since the dev picoreflow pi was retasked to carry the PiGI longterm test.

scott
2014/11/23 19:46

This is great! I've been pouring over the code trying to convert it to a ceramic kiln controller. To do so, I need to change the time scale from seconds to minutes. I would assume that I would be able to add a *60 scale to where the code reads the profiles, but cant seem to see where to input it. Any tips? I'm fine with the code running in seconds (even if its a bit overkill for the thermal inertia my kiln has), but I would like the display and profile input to be in minutes. A 12 hour run on the kiln becomes a bit silly in seconds :)

Thanks for your help and awesome code!

chrono
2014/11/23 20:00

Do you mean in the python or in the UI part of the code? We've opted for the most efficient integer SI unit for storage and calculation, which are seconds. The UI part was originally designed for Reflow Curves, which are short enough to be displayed in seconds for curve/datasheet comparison. However, in your case, I can see that keeping the legends and UI stuff in seconds would be more than a bit silly, when you're going over several hours.

If you have a github account, I'd love if you would open a new issue, so we and possibly others can keep track of this issue (history and solutions). If not, don't worry about it, I would leave the data in seconds as it is, I think the solution rather lies in the datapoint/legend aggregation of the plotting framework we used and maybe a couple of *60 in the javascript for the curve detail panel. I'll have to have a look into the code and will come back to you, either here via comment (don't forget to subscribe) or via github, if we have a new issue :)

thierry
2015/07/21 21:21

Hello, and thanks for this project that I will use to bake clay to 1000 ° c .

I run picoreflowd.py

I run in the browser http://ip:port/picoReflow/public

Start

The regulation is done but my browser is 100% occuped . I can not see the curve.

At the end of regulation I have to stop the terminal so we can see the curve after 5 minutes .

Is this normal?

thank you

chrono
2015/07/22 08:52

Hi Thierry, that is also a sweet use case. Live graphing needs a bit more CPU/RAM than other webapps but it has never really been an issue on tested desktop (chromium/firefox) or even mobile browsers (android) for the original (reflow soldering) use case.

Which browser (Version?) are you using?

And since you say you want to do clay is it save to assume that have jobs running for more than 15 minutes? The current implementations does not yet reduce the datapoints over time, so long jobs gather quite a lot of metrics, which the browser has to keep in memory and needs more CPU power to draw.

thierry
2015/07/22 21:42

Hi Chrono,

I used Midori 0.4.3, the RPI is slow but it works.

If I use firefox on PC, I have “Error1 status WebSocket not available”.

I saw this but I do not understand what should I do? https://github.com/apollo-ng/picoReflow/issues/4

ozindfw
2015/09/14 16:45

Howdy Chrono,

I see that there is a 12 V output for a cooling fan. I'll be using an oven I have on hand. Does the EKA KF412 incorporate a cooling fan, or did you add something? How does cooling air enter the unit? Is it pulled from outside and circulated in the over, or is it circulated in a wall? The back wall of many ovens is ventilated and can use forced air to accelerate cooling.

chrono
2015/09/15 11:07

Ahoy,

the old picoreflow software was developed with only our setup in mind but released nevertheless, to give others inspiration and stuff to copy from.

The EKA KF412 originally has a heating element and a built-in circulator fan at the backside (as most modern ovens in any kitchen do). The idea was to reflow with circulating, hot air instead of the cheaper infrared radiation transfer types, because IR will heat black IC packages more than the metal of the pad.

Additionally, the oven has two pipes in the back, the original use case was obviously to pump in moist air (there seem to be some bakery related oven workflows that require pumping in moist air for the process).

So after insulating the oven, to easily reach ramp up temperatures, we were confronted with the problem of ramp down slopes. Simply turning off the heat didn't do much, since the insulation holds the temperature in the oven pretty good. The idea was to use a 12V radial fan and pump room temperature air into the oven through one of those pipes in order to give the PID regulator full control over the whole temperature regulation process (heating AND cooling), according to what target is specified in the curve.

This is also modularized and already covered in the new software I hope we'll be able to release soon. About 45% of it is done and currently most of available time is going into it, so you can expect something more flexible/usable pretty soon :)

ozindfw
2015/09/15 20:16

Thanks for sharing. I want to get picoReflow running and will probably transition to picoPID when you do a functional drop on that. I'll try to help with something. Docs or whatever.

Oz, In DFW (The Dallas - Fort Worth area in Texas)

chrono
2015/09/16 11:21

If you have python or javascript skills (or deem this a good opportunity to acquire them) you are always welcome to join development. As soon as the basic framework and application scaffold is somewhat more stable, the code will be available on github to make decentralized and distributed collaboration easy.

Testing will become more of an issue soon, to iron out obvious code bugs and usability/workflow issues. Any help in that department would also be greatly appreciated :)

Tomik
2015/11/09 16:58

Hi, I really like what you are doing. I am currently on lookout for reflow oven controller - I was able to acquire good microwave owen with grill which I am in the process to convert to reflow oven. I has two heaters, convection fan, door switches (well of course, it is microwave oven) and very nice stainless steel interior. And it looks that your project could be good fit. But I am really not big fan for basic SSR switching for PID controlled heater, I think that phase control with zero crossing feedback is much better. (For example it is what Andy Brown with his Android controlled reflow oven controller uses.) But I have been searching internet and come to conclusion that it is not so easy to do with RPi because of system overhaul. Do you think that your new controller will be able to incorporate this control method?

chrono
2015/11/10 09:46

Ahoy, thanks for stopping by and dropping some feedback. Again someone with a slightly different use-case/system/ideas, great :)

Our current picoreflow PID implementation is working fine with SSR's (with built-in zero-cross detection) and switches at only about 1Hz. The thermal inertia of even the smallest viable reflow oven is more than big enough to get away with that approach and still have good regulation.

However, the final verdict, after analyzing all your feedback, was simple:

It's impossible and probably even ignorant to assume that we can foresee each and every use-case someone might have, only to waste time creating a compromise laden solution that tries to offer something compatible to each one's project but isn't trying to cater to a specific use case.

Therefore, the solution was to stop and create something new from scratch, current working title “Governess” - someone or something you can give the (high-level) job to control/govern basically everything in either open- or closed-loop scenarios. Inputs, Controllers, Governors (P/I/D, BangBang etc.) and Schedulers are completely modularized and can be connected to each other. All in such a way, that it makes it easy for a hacker mindset to wire/set-up and even possible for any end-user to use/change. While keeping the system itself platform and use-case agnostic.

Being it a grid-power driven reflow-oven/kiln, using 12V MOSFETs to drive PET extruders to make 3D Printer filament or have a fully automated closed-loop growing station for indoor agricultural purposes, right down to having specific wave-lengths of light for a typical plant at a certain state for a given length of time to improve yields and cut down energy waste (LEDs FTW).

The new client is a HTML5/android+cordova hybrid based on angular-ionic so that we can have pseudo-native android apps. The basic framework of the new client is finished, as is the first version of the profile-editor. The next sprint will include the device-editor (where we actually wire everything up, so that we can assign any sensor/actor/GPIO to any controller/governor/metric collector) and a new modularized server. First public release is slated for the end of the year, where I've blocked at least 14 days for another governess sprint. Anyone willing to help is always welcome.

Unfortunately, I'm not the world's most gifted programmer, which means I've got to fight through a lot to get the things done, and that takes more time :/ Hopefully, once the basics are set up and we can release a simple but fully working demonstrator, more people will engage and help with modules and extensions and, of course, ironing out all the inevitable bugs :)

I've uploaded two screenshots of the new interface, showing the new Profile-Editor, where two curves are used to control the temperature and the circulator (turn it off when the solder-paste reaches post-flux state to remove vibration) as an example.

If the venerable PI is too little for you in terms of processing power, the Odroid C1 has proven itself as a viable alternative, see picoPrint 3D Printer

Rush
2015/12/04 11:02

Hi,

I tried the picoreflow and found two bugs.

1.I think after canceling an active reflow process, all values should be reseted. When I start the same profile again, the controller starts at the point where I have canceled the first process….

2. The soldering profile is locked to the duration of it, right ? What happen if I have an oven that is slow? Does the reflow process stop before reaching all the setpoint ?? Wouldn't it be better to lock the process to the setpoint so the process itself yould take a little bit longer?

chrono
2015/12/07 09:22

Yeah, it was just PoC code to get our use-case working and as such is full of bugs and has even more shortcomings for other people with different setups. Hence the move towards something more modular like governess. I hope I can start the next sprint next week to have an open (and published) basis for further development since there is clearly more demand than expected at first :)

Hendo420
2015/12/07 02:27

Any chance you have some PID auto tune code I can use to tune my device? My Temps are fluxuating by up to 8c. My xmt7100 PID temp controller doesn't fluxuates by 1 degree once autotuned. I'm looking for a way to do that with picoreflow. Can you help?

chrono
2015/12/07 09:15

You mean the current picoreflow PID parameters give you +/- 8°C fluctuation? What kind of device is it and how did you set it up? Even though we have no auto-tuning build in, this seems way off and never happened in our setup.

That is something on the roadmap for governess - autotuning in general to find the max slopes a certain device can ramp up/down and specific autotuning for certain controllers/governors - PID in particular. Unfortunately, although an important feature, it has to be put on hold until the basic framework of governess is up and running on server- and client-side, so that we have a convenient structure to work our feature requests into.

Therefore there is no code for this yet. If you want to help, you may have a look into https://github.com/MarlinFirmware/Marlin or some other 3D Printer Firmware code, or maybe https://code.google.com/p/autoquad/source/browse/#svn%2Ftrunk%2Fonboard for startes. There are a lot of projects out there that make heavy use of PID/Kalman systems, I'm pretty sure there is plenty to copy and learn from, once we start digging.

Hendo420
2015/12/07 17:06

I'm using picoreflow to heat a heater coil. The heater coil has a K type thermocouple built into the end of its coil.

I'm not using it for a reflow oven. I found another cool use for it. :D

I was hoping you would have a way to autotune so I wouldn't need to write my own PID autotune program. Sounds like I'm going to need to put some elbow grease into this problem. lol

The default PID parameters are meant for a slow to heat reflow oven. My coil heats very fast, it reaches 450c in about 60 seconds. Would you have a recommendation for starting PID parameters for my use case?

chrono
2015/12/14 09:45

Ahhh, right :) Awesome. And of course the thermal inertia of this particular setup is likely to be much smaller. Since I have never gotten a chance to build a similar setup, I have no starting values to give, which I could back with empiric data.

So my recommendation would be to test values we can find in a similar setup as a start (before we can get something like autotuning done). A 3D printer extruder would actually seem like a good starting point to me in terms of regulation precision, element size and operating temperatures.

This might contain something of value, I haven't had a chance to work through it, but it may be worthwhile:

http://home.hit.no/~hansha/documents/control/theory/tuning_pid_controller.pdf

Also, a while ago I've submitted configs for our 3D printer to Marlin FW, have a look into Configuration.h line 211ff:

  #define DEFAULT_Kp 12
  #define DEFAULT_Ki 0.84
  #define DEFAULT_Kd 85

Maybe they'll just work out of the box, maybe some more tuning will be needed. In any case, I guess heavy testing can also be a pleasure :)

Chris
2016/03/17 05:23

Hendo,

I am working on a pi based nail right now. Curious as to what route you took? You can contact me at [email removed to protect privacy]

DV
2015/12/13 20:09

Hi,

I tried this on a Black & Decker with two elements on the top and two on the bottom, total power 1500W without fan but I opened the door in sync with the “cool” signal. It appears to heat up too slow but when it reaches the set temperature it overshoots and once cooled it cannot recover fast enough. I played a bit with the parameters but it doesn't seem to anticipate the reach of the set temperature to adjust the duty cycle.

Can you recommend some parameters for a 1500W toaster oven?

I'll try to install a fan to see if it can follow the ramp better.

Maybe a good idea would be to keep the heaters always on and control the temperature from fan speed until it reaches the max temp.

chrono
2016/01/26 19:09

Yeah, I've seen that in tests too. Our oven already came insulated with fiberglass and aluminium foil around the heat-chamber. When the door is closed tight and a good seal is made, it could do any reasonable reflow ramp-up, with reserves.

This “fix” also creates the problem on the cool-down ramp :) The insulation increased the resistance between ambient air and the oven, so we can heat up faster because we loose less energy to the ambient air. But when we stop putting in more energy, the thermal resistance (K/W) is too high for any reasonable cooldown. Hence the need for an ambient air inflow system, to give the governor full control (up&down) of the temperature :/

I'm not sure about this assumption, but I don't know enough about your particular oven. Pictures? Links? You're speaking of two-elements at top and bottom; our convection air oven doesn't have any of these. The heating element is shielded in the back surrounding the circulator fan. IIRC these in-oven heating elements you've described radiate a considerable part of their energy through IR and not hot-air/convectional transfer. So it might even make no difference and darker parts would heat up faster then the rest anyways.

As ever so often, only playing and trying will tell how it's going to be in reality. Try getting some data from it with a couple of more test runs, different insulations, parameter and place the sensor on a dummy PCB without parts and a dummy PCB with some black IC casing and measure the case temperature.

ozindfw
2015/12/13 20:44

I've seen similar challenges with temperature ramp rates. My oven is a convection type and so includes a stirring fan. This is a big help.

I've added insulation to the top and some of the walls of my oven, added shiny aluminum foil as a reflector to the interior sides and back, and aluminum reflective tape to much of the door window. Each has helped a little. It's not the reliable 3 degrees C per second ramp I'd like, but it's about 2 and is generally good enough. I also open the door to cool. Mine started out at 1 Degree C/Sec.

The insulation I used was pink fiberglass commonly available in home centers and hardware stores in the US. A small bundle is $6-7. The foil I used was a house brand heavy aluminum foil, and the tape is “high temperature” tape intended for heating ducts. I applied it outside the window on the door and just left enough of a slit (3-4 cm) to see the object of my reflow affection.

Oz, In DFW (The Dallas - Fort Worth area in Texas)

chrono
2016/01/26 19:09

What OZINDFW said :)

DV
2016/02/09 04:04

I think my oven is this one or very similar:

https://www.wayfair.ca/Black-and-Decker-Toaster-Oven-TO1675B-BND2812.html?

It has some metallic shields around the heaters so I hope it converts IR to heat. before it hits the parts.

whatnick
2015/12/17 01:43

Hi,

I adapted picoReflow a while ago to run on my eeePC using a USB multi-meter for temperature measurement and an Arduino+Relay driver to control SSR's. You can see the screenshot here:

picoreflow-usb-multimeter-arduino-reflow-pizza-oven-hack

http://4.bp.blogspot.com/-braRA5gyo2E/VJGi7riMj9I/AAAAAAAAJ-c/ldrwwaWR9LM/s1600/20141218_011457.jpg

Currently working on deploying it on BeagleBone Green.

Cheers,

whatnick

chrono
2016/01/26 19:29

Awhh, awesome hack, I love it. And thanks for caring enough to share a picture so that we know it happened :) That's the true power of open-source in action: Not that we just get stuff for free, but we get the ideas and sources, so that we can hack around, learn, change and adapt it to our very specific needs. Fuck yeah :) Please keep us updated, great work.

Dragos State
2016/01/07 20:53

Hi Guys,

I am building a paint curing oven and i'm trying to adapt picoReflow to be used with it. (The temperatures are higher and the times are longer). Rest of the process is similar.

The heating elements will be a combination of electrical 380 V and Infrared (30 kW).

I just got the Pi today, installed it everything worked fine. But i think i found 2 problems:

- I can't delete a profile from the graphic interface you have to delete the json

- It does not seem to run on the raspberry pi. When i press run it stops after a few seconds because there are no sensors present. When i press the simulation button it freezes.

chrono
2016/01/26 19:39

Yes, there is a problem with the GPIO/Sensor detection, that never came up in dev, since we were developing on our laptops and deployed on a configured system. Currently it breaks on a pi without sensors, because the check routine has a bug.

To test, if this fix may work for you too, try commenting out the whole block of gpio and temp sensor check routines, so that it goes into sim mode even if GPIO are present (which they are on the PI). For longer runs, the same constraints as already mentioned above imply: The original concept never included long runs, so there was no automated data point reduction. Long runs create lots of datapoints which all have to be transferred to and cached and finally rendered by the browser. You could try to look into the PiGI code, the problem has already been addressed there and it should be easy to adapt, since both implementations are quite similar.

That delete bug is news to me, AFAIK that should work. Maybe try to revert to one or two commits back, to make sure it's not a regression. Can anyone else reproduce? Can you change and save the profile from the editor? are the file permissions ok?

chrono
2016/03/13 11:59

Seemingly fixed with c790a842a0ebd8d740ea184d327050ab8e002bcf, all hail bogdanstate.

Pf@nne
2016/01/24 16:17

Hi,

good job and nice looking WEB-IF!

I wat to use the picoRelow to control my pimped Pizza oven.

So I have some questions about the software:

The heating paraneters are onle for simulation, ist this right? The reflow heating control uses a PID regulator?

How to use the door-open function, I connect a switch (closed when door closed), between GPIO18(Pin12) and GND. How to use the cooling function? How to prevent that the hot air gets out of the oven while heating? You need somthing like a flap?

I alo got some problems with the software. Starting the WEB-IF and run the given profiles runs fine,

2016-01-24 17:11:03,042 INFO picoreflowd: Starting picoreflowd
2016-01-24 17:11:03,063 INFO oven: import MAX6675
2016-01-24 17:11:03,072 INFO oven: init MAX6675
2016-01-24 17:11:03,121 INFO picoreflowd: listening on 0.0.0.0:8081

but always I make some changes or create a own profile the WEB-IF crashes.

2016-01-24 17:14:12,475 ERROR picoreflowd: Could not write, /root/picoReflow/storage/profiles/leadfree.json already exists
2016-01-24 17:14:12,482 INFO picoreflowd: GET command recived
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/usr/local/lib/python2.7/dist-packages/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "./picoreflowd.py", line 127, in handle_storage
    except WebSocketError:
NameError: global name 'WebSocketError' is not defined

I hope, that you can help me.

Greetings Pf@nne

P.S. How to set code markers?

chrono
2016/01/26 20:13

The first thing that comes to my mind when I read “Could not write” is: Have you checked the file permissions? Maybe they're screwed up for some reason and the user running picoreflowd has no write permission to it.

What exactly do you mean by heating parameters? The PID tuning parameters are for real world, as are the profiles. The only thing just for simulation is all the heat transfer/resistance math to have a closer test-setup to real world hardware during development, without the need to actually have it.

The door sensor is just a GPIO. You need to wire up and configure either as pull-up or pull-down and adjust your inputs accordingly. You could run the simulator, that would make it clear. When the regulator sees that the current temperature is below the set point for this point in time on the curve, it enables the heater. When the temperature is above, it turns off the heater and turns on the cooler instead (on a different GPIO). That blows ambient air into some intake to decrease the temperature.

And, yes, I'm also worrying about loosing too much hot air during ramp-up through either the air-inlet or the obviously also necessary outlet where hot air can escape during blow-in while cooling down. I haven't found a sweet solution yet, all suck in one way or another. A mechanical valve, that is getting opened by the inlet air, might open the outlet as well. On the other hand, we might ultimately just put some RC-Servo into the mix as well and feed it some PWM to open inlet/relieve valves when cooling down.

Dragos State
2016/01/26 21:20

Yes i can save or modify the profiles.

I looked in the picoreflow.JS and at the deleteProfile function it says:

// FIXME: Add cmd for socket communication to delete stored profile

maybe something is missing

chrono
2016/01/27 16:25

Hmm, I've probably implemented the button and “feature” in the client but then it was never finished in the backed :/ Funny, that no one else caught it yet :)

Pf@nne
2016/01/27 17:18

With Google Chrome everything runs fine! No profile writeerros anymore!

What exactly do you mean by heating parameters?

that means the heat transfer/resistance, so they are only for the simulation.

What about cooling with 12VDC-PWM-Control? Is this feature available now or are you still in process?

Are you able to post a heating curve with full power without fan? I like to compare your curve, to check my power reserves.

Greetings from Hamburg

chrono
2016/03/17 09:06

Yes, at the moment all heat transfer/resistance math is for simulation only, to have a somewhat realistic model of how the system would behave in the real world. In the future these formulas might also be used for auto-tuning so that the controller would test-run the hardware and measure these values and create a hw profile so that it could even predict if a certain temperature profile can work with that hardware or not.

PWM based cooling is not implemented in picoreflow but it's part of the roadmap for governess, as a controller plugin.

I can't create a real-world curve ATM because the oven has not been unpacked after the loss of last basecamp, but it might be needed in the near future so I would have to anyways, could you specify a little more what you need exactly? Remember, you can always hack your config and set control values to something far out of range to inhibit or force fan/cooling.

ARARPI
2016/03/16 12:45

Hi!

http://ararpi.simplesite.com

Here is my realization of reflow oven. I need to do thermal isolation inside oven and cooling system, I propose that you see enhancement side of my page.

I mainly use my oven for PCB soldering, perhaps photoresist and soldermask baking 70 C.

This is fantastic, I mean this side of yours!.

chrono
2016/03/17 08:50

Ahoy, that's a very nice and clean setup, looks awesome and good job with the documentation. Is there any reason why you have decided to put out all links as text only? Not only is it uncomfortable for humans to follow them, but it also inhibits search engines from relating the content properly, so that you would also benefit to have an established link relation to reflow ovens and more people would find your project when searching for reflow ovens.

Hmm, photoresist and soldermask baking sounds also very interesting, need to look into that as well :)

Thanks for sharing.

Chris
2016/03/17 05:06

Hello,

I just stumbled onto this project looking for a MAX31855 implementation with a k-type thermocouple. This is exactly what I was looking for, except I don't need a fan or cooling, so I am excited to hear about picoPID. I am not experienced in python or java, but would be happy to help if you are in the testing phase.

Thanks, Chris

chrono
2016/03/17 08:54

That's great to hear, having people who are willing to offer time to test stuff is invaluable. Don't worry too much about not knowing stuff, just clone the code and play around with it, it's software after all. So whatever you break, because you don't know any better yet, will give you a learning experience and you can always revert back to your last working state to try again without any risk or costs.

ararpi
2016/03/18 19:08

I have no own homepage now, only this experimental. I was testing this “made your own homepage free”. http://fi.simplesite.com. This free simplesite side does not allow any other internet addresses than their local ones in one's homepage, so they are not links, only text. Here my typing error was missing 'http:+' in my Web URL.

I have not yet tested high temperatures yet, due lacking heat isolation. When using lower temps the system tracks quite well going upward in temperature, but cooling is not so good, especially faster cooling.

I want to hear your opinion of this my idea of this heat resistant vent system. When cooling fan starts the air pressure opens these small vents allowing cool air to go into oven interior.

Perhaps this is not cooling enough, so I'll need also automatic door opening(servo or solenoid), when cooling fan starts. Sounds complicated this door opening?

If you want to see one vent goto my Web URL http://ararpi.simplesite.com and “enhancements”

chrono
2016/03/22 08:56

Yeah, I saw that and fixed the URL in your last comment. It's a shame that this service provider has this stupid link policy, really, in 2016, people should know better, to not restrict the web like that.

Your observation seems consistent with the current status quo: Getting up is easier done than getting down in a controlled fashion. I like your vent approach, because it is very simple and easier to do than complex venting mechanics/actors. It should be more than enough (IMHO) because ambient air will unlikely be more than 35°C, so its transfer ability will be huge and should easily match any down-slope.

I don't like the door approach, since it will always bear the risk of causing some hard to control vibration, which may lead to an increase of process failures.

Moore Bros.
2016/03/23 18:37

Hi Chrono,

My brother and I build custom composites, mainly boat parts and skis but some research equipment too. We've normally used traditional wet lay up techniques but we're expanding our capabilities to use pre-pregs as well.

While we've decided to hold off on building our own autoclave we are currently constructing an oven to cook off parts in. Much like a solder reflow process, the temperature profile is absolutely critical. Usually something like ramp at 3F/min up to 275F and hold for 60 minutes.

Our plan is to use a modification of the picoReflow system to drive the oven. We're not going to need the door switch or cooling capabilities as we can get away with just taking the top off the oven and the internal circulation will always be on.

As this is the first foray into the world of physical computing for this pair of mechanical engineers; we'd like to day thanks for sharing all that you have.

We'll be sure to drop in a picture or two after we get this all up and running.

chrono
2016/03/29 07:17

Ahoy there, boating/sailing would have been my other occupational choice in live but for now I'm stuck with Hackerspaceship-Crafting. Don't worry too much about which world you're coming from though. If we can manage to share and combine our ideas/experience/skills, then we can only win because today everything is needed together: Mechanical, Electrical, Software etc. Isolated specialization will probably follow the road of the dinosaurs.

Open-Source makes this easy, even if you're no computer/software expert (because you used your time to gain skill in composite materials) you can just grab the code, pop the hood and start fiddling and tweaking stuff. A curious hacker/engineer mindset is usually enough to get started and you'll always learn something new.

None of my in-use education/skill-set has been provided by the system (i.e. schools/university etc.). I can do what I do only because other people were willing to share their resources and knowledge online, so that I could copy, play and learn from it. Seems only natural to close that circle by adopting the model and sharing everything as well. Looking forward to seeing your solution in action.

Moore Bros.
2016/03/28 15:36

Crammed everything into a box and it seems to work just fine. Currently we're just driving one SSR to control our heater; the default PID values seem to work just fine with ~2 second cycle pulsing the heater on and off.

Just enough time for the heater's squirrel fan to spool up.

I think I might have sourced the wrong SSR, at first the heater was on by default and turned off when the computer called for heat; inverted some logic and things are awesome.

Trying to get my head around how to monitor an array of thermocouples.

Ideally we would have one sensor buried under the part while the others monitored the oven. We'd drive the oven up to our desired hold temp, wait for the buried sensor to catch up to to the oven's environment, and then hold for a set time.

Probably over my head but we'll give it a try anyway.

https://www.facebook.com/moorebroco/posts/857892380986032

Thanks again for putting all this out here.

chrono
2016/03/29 07:51

Awesome, great to read you're already up and running.

Technically, software and hardware should be able to cycle much faster but the slow switching frequency has been chosen for two reasons:

  1. It's unclear - and there was no usable reference material online - how the grid will react to high frequency SSR switching and what consequences and risks that may bring.
  2. The thermal inertia of even the smallest practical oven is in almost all cases so large, that faster switching will not make any considerable regulation difference. (The 0420 use-case or any other vaporizer/smoker is a different story)

As for the output inversion, that's not an issue with your SSR, that's just a question of wiring and control. The SSR can be wired to be either “driven” or “drained”:

Driven

Pi GPIO → Current Limit Resistor → SSR → GND

Drained

5V → Current Limit Resistor → SSR → Pi GPIO

Driven use case is straightforward, non-inverted; Set the GPIO to high, it puts out 5V and enables the SSR. Drained is inverted because you have to pull the GPIO to low in order for the SSR to engage (you close the loop to GND through the GPIO). When the GPIO is high the SSR is off.

This has become a config option, thanks to the work of Rob Shaw, and is something that depends on individual implementation and drained config is actually default, as you've already figured out and fixed yourself. Good job.

As for measurement, I was thinking in the same lines. A sensor that only measures the air temperature in the oven might show something different than a sensor attached to the object. Since it's often impractical or unfeasible to attach stuff to the product, I though about building a mock. In terms of SMD reflow, just a small standard PCB with some components and the thermal sensor fixed to that small PCB. It might be off a little bit since it has different volume/mass/size but should it should still give a better indication of how the actual material/process is behaving and give a better baseline reading for the governor.

It would be great if you could post/upload pictures somewhere else, I'd love to link/embed it here but I've got no FB account and actually have every FB network blocked in order to avoid undue tracking and conserve network bandwidth.

Thanks for coming back and sharing what you're doing with it - greetz to Rhode Island (Always makes me think about me, myself and irene :))

Moore Bros.
2016/03/29 19:36

Sorry about the FB link, bad habits we're still trying to break.

https://www.dropbox.com/sh/zfndgfs5oiclgul/AAA2b3pHNh0wS27rzVllnIR6a?dl=0

Use and abuse photos as you like.

Thanks a bunch for the extra information.

We've been using a similar SSR with an off the shelf PID top drive some large resistive heating pads (~2.3kW/piece) and can say that reason #1 for the slow frequency has some valid concerns. Lights tend to flicker when we cook off skis with them…

For our first run we've got a script set up monitoring a second thermocouple that'll email us when the underside of the part gets up to temp. Our plan is to have one profile ramp and hold the temp till the script pings us and then start a second profile to hold the temp for the extended duration.

First things first though, need to cut the mold and build the part to cook….

Thanks again!

Coop
2016/06/12 01:46

Hi

I would like to use your project to control a kiln for heat treating knives. Is it possible to re scale the temperature values on the graph. I need to get the knives to 1500 f to 2000 f .

Thanks

chrono
2016/07/12 18:30

Everything is possible with open-source systems, even if it's not there yet you can change it yourself. I'm not sure how we set it up originally anymore but IIRC the graph should show what you give it in the profile. If it doesn't, just have a look into the sources https://github.com/apollo-ng/picoReflow/blob/master/public/assets/js/picoreflow.js

I've merged AndyRawson's PR so that you guys who still prefer non-metric units have it easier. Governess is also coming into shape slowly, the client already feels like a usable app. Once the last scaffold/mock of the app is done, work on the server can begin to let it actually control and govern stuff.

chrono
2016/07/12 18:51

Ah, I was wrong it seems, because it has been implemented in the last PR:

  • Changed the graph to auto scale to the profile

So, thanks to AndyRawson's work, that should just work with current picoReflow master.

Renato
2016/09/12 11:19

Hi, i also build an oven for curing composite parts. The heat is being produced by two heating plates of a 3d printer. 1.) My first question is, is it possible to change the time in minutes instead of seconds and if yes, how?

2.) The heaters are not so fast with building up the temperature, so i often get the “run complete” message after a short while. the information giving on the terminal is something like temperature sensor not working. We thing its because of the range of the PID Factor (-1/1C) We think the range should be wider, or? what we would need is a range that looks like this: 10min to 30 C Holding 30C for 60 min 10 min to 40C Holding 40C for 60 min 10 min to 50C Holding 50C for 60 min 10 min to 60C Holding 60C for 60 min 10 min to 70C Holding 70C for 60 min 10 min to 75 Holding 75C for 60 min and than back in the same steps to 20C

Can you please help. Thank you in advance Best regards Renato from Hamburg/Germany

chrono
2016/09/12 18:47

Ahoy Renato,

1. Time management has always been one of the shortcomings of picoreflow, there have been a couple of patches submitted and merged, trying to make it a bit more usable with longer runs. Have a look in the commit log to see if there is anything you may use, adapt or change to your liking. I haven't tested the last couple of commits due to lack of time and focus on governess.

2. This is weird, I don't seem to remember putting that in. It reads like a plausibility check, i.e. “I'm heating but the temperature doesn't change so something must be wrong, better shutdown now…”. Ah, found it:

https://github.com/apollo-ng/picoReflow/blob/b26a461c3f5d474387c690b41ddc00d15537c708/lib/oven.py#L107

You may want to comment out the runaway protection and see if that is the culprit in your case.

The sensor log in your pictures also looks quite noisy and erratic. Just guessing here but since the heatbeds are DC consumers and the SSR is an AC switch it seems like you've connected the heatbeds to the be quiet! 12V PC power supply and use the SSR to switch the power supply?

I've never tried that approach before and all picoreflow implementations out there have been using AC heaters (AFAIK). And I'm really not sure how the AC/DC converter of the power supply will react to constant on/off switching (usually they don't like it too much and that might produce heavy switching noise).

In this setup it may be better to leave the power supply connected to AC and use a mosfet driver circuit with high power mosfets to switch the 12V DC rail instead (like 3D printers usually do).

After having a look into our Marlin Firmware, these are the PID settings we're using for a similar heatbed (but DC controlled and with higher switching frequency - you will have to play around and experiment):

    #define DEFAULT_bedKp 103.37
    #define DEFAULT_bedKi 2.79
    #define DEFAULT_bedKd 956.94
renato
2016/09/12 15:57

Hi me again, i just reproduced the error. So the text is:error reading sensor, oven temp not responding to heat.

Here is a dropbox link to some pictures of my oven build and the picture of the screen with the error https://www.dropbox.com/sh/5akv6viwfnw1l7d/AADnOGfBZ6EJ7kNTB15Wjejja?dl=0 Hoppe you can help.

Andy Rawspn
2016/09/17 03:04

Renato, I had the same problem. It is the emergencystop pull request which is very nice but may need to be tweaked for ovens with different thermal inertia.

Open the file lib/oven.py and find

  if temperature_count > 20:

and change it to something like

  if temperature_count > 100:

Just adjust that number up if it still fails.

renato
2016/09/17 23:49

Hi Andy, thank you ans also thank you Chrono. because i can not program at all, only some HTML Basics, i am really thankful for explanations like “go to… and change….” now to some questions is in the example 20 and 100 time in seconds? and if the temperature has to be hold at the same C degree for 60 minutes, should i put 3600 ?

or is it possible to delete the whole emergency stop ? if yes, whit which line i should start and at which one i should stop deleting the text?

next question is, where do i have to go to change seconds in minutes, so the change appear on the screen of my TV and also the program runs with the change?

i work with a box and not with an oven, so there is no door. is there any affect of the program, because its always on “door open”? I hope these questions are not to stupid for all professionals here. Thank you in advance, best regards from Hamburg/Germany renato

chrono
2016/09/20 17:59

No worries, it's usually easier than you think, you obviously have enough brains to wire all of this up, so you can play around in the code as well.

The easiest way to start would be to follow Andys suggestion and edit line 117 in lib/oven.py (https://github.com/apollo-ng/picoReflow/blob/b26a461c3f5d474387c690b41ddc00d15537c708/lib/oven.py#L117).

3600 seems reasonable for a start when you want to dwell for 60 minutes. Theoretically you could also simply comment out the self.reset() call, so that it wouldn't abort your run, no matter what.

Please remember, these safety measures are there for a reason so if you hack around and change/disable them, don't let your setup run unattended without testing thoroughly :)

Original:

if(pid > 0):
     # The temp should be changing with the heat on
     # Count the number of time_steps encountered with no change and the heat on
     if last_temp == self.temp_sensor.temperature:
         temperature_count += 1
     else:
         temperature_count = 0
     # If the heat is on and nothing is changing, reset
     # The direction or amount of change does not matter
     # This prevents runaway in the event of a sensor read failure                   
     if temperature_count > 20:
         log.info("Error reading sensor, oven temp not responding to heat.")
         self.reset()
 else:
     temperature_count = 0

will become this:

if(pid > 0):
     # The temp should be changing with the heat on
     # Count the number of time_steps encountered with no change and the heat on
     if last_temp == self.temp_sensor.temperature:
         temperature_count += 1
     else:
         temperature_count = 0
     # If the heat is on and nothing is changing, reset
     # The direction or amount of change does not matter
     # This prevents runaway in the event of a sensor read failure                   
     if temperature_count > 3600:
         log.info("Error reading sensor, oven temp not responding to heat.")
         self.reset()
 else:
     temperature_count = 0

As for the rest, all of the released projects here are open-source and not apple closed IP ecosphere idiocracy pushing solutions for a reason:

It's important to me that people get all necessary building blocks in an open and free manner but have to make an effort to do the final bits on their own - because in the process they will inevitably learn something which in turn will empower themselves and yield more freedom and less dependency on commercial solutions to create whatever they want to.

So, play around, even if you think you don't know what you're doing, read the comments, look stuff up on the net while trying to solve a particular problem within the codebase.

It's like learning a new language, much more effective when you're in that country and have to use it to buy bread instead of sitting at home and reading a book about it.

rami
2016/10/21 01:42

Hi Martin! Guten abend. Ich nicht sprechen sie deutsch, aber ich haben nur eine klasse im… highschool? Ha.

Do you mean you set the count to 3600 in an effort to “ignore” the temperature not changing (error: oven not responding to heat) for a full 1 hour while you test things out? I never used the simulation function of picoReflow since it seemed like things worked otherwise. Regardless, the default time step is 0.5s, so a count of 3600 steps not responding to heat would only be 30 minutes.

I have gotten a pottery kiln to work extremely well with picoReflow and might be able to lend some help. For a pottery kiln the default time step of 0.5 seconds to check on the temperature and make a control decision is _way_ too fast. Checking every half second in the world of a 12 hour bisque firing is pretty meaningless. Because of that I changed the following line in oven.py from:

  def __init__(self, simulate=False, time_step=0.5):

to

  def __init__(self, simulate=False, time_step=10):

Which makes the oven check the temperature and make a control decision (on/off) every 10 seconds, rather than 0.5. This also helps with data aggregation/stability issues others had reported on looong runs. The temperature still updates in real time at the top left, but the clock at the top and the on/off of the SSR will only update every 10 seconds instead. You can adjust this to suit your needs, obviously.

If by “dwell” mean a “hold at temperature” you simply need to make a profile for a run that has the same temperature for two time steps that are one hour apart, if that makes sense. Feel free to clarify what you meant and ask me if there's anything I can help with, I'd love to be of some assitance!

rami
2016/10/21 01:46

My pottery kiln also has no door and has no issues with the door open function in the program. I have had no issue with JUST an SSR and Thermocouple/thermocouple reader, with no cooling pin or door state functionality being used. The only issue would be if one of those GPIO pins (set_cool?) was being used by some other project on your implementation, I imagine.

Martin
2016/09/23 17:33

Hello from Germany and by the way, excusion for my broken english. After a period of looking for a raspberry pi kiln controller for my glass fusing and pottery kiln, i found this wonderful projet side of Yours. My MAX31855 board is still on its way from china, so meantime I tried to get the simulation started. I had the same problem as renato mentioned before, so i set the count to 3600. In the simulation, the white line stays on the bottom, and in Terminal, i see, that the oven info tells me: running at 0.0 deg C. I guess, thats not the right behavior, but what can i do? Will you please give me a hint? Thanks a lot

chrono
2016/09/28 07:56

Ahoy Martin, please don't worry about your english proficiency, most of us are not native english speakers but it is the best way to keep the exchange of information and knowledge accessible to all people instead of putting up artificial barriers like national languages.

Sorry for not coming back sooner but due to the last move the old prototype isn't rigged up again so I have no good way to test and without ability to reproduce it's very hard to remote-debug your issue. Ram has been doing extensive ceramic/pottery work, maybe he can jump in?

I've ordered a PI3 board to have a new picoreflow/governess HW testbed for support and further development. We've seen issues with some 31885 boards and erratic measurements but the sim should actually be working all the time. Maybe we're having a regression that's been triggered by the changes to the the last changes, hard to say at this point.

Schoenen Gruss ins Bergische-Land, wo Elefanten aus schwebenden Fahrzeugen in Fluesse fallen. In der Gegend bin ich aufgewachsen :)

VanJaime
2016/09/28 17:17

Is it possible to implement the same principle to a Toaster. This is a school project… I'm not an expert in the area. However, I would like to know from the experts what might change in terms of settings / hardware if I want to use a toaster like this:

https://amzn.com/B00CXMO02W

Thanks!

chrono
2016/09/29 08:21

Always remember, with focus, determination and the help of the internet almost anything is possible. However, before I go into the details of your question, you've mentioned, that this is a school project and you consider yourself not an expert; I'm not one to patronize or discourage anyone at any skill-level or age to engage in new/challenging projects because only by doing so we can really learn something.

Having said that, if you have a good physics teacher, try to involve him, if not, think - and be aware of the hazards and risks before going further, in particular: Fire and Electrocution. Hacking stuff is fun, but only as long as you don't burn down the house or get seriously injured or die in the process.

  • Don't rush things, don't fumble around in the system when it is connected to mains.
  • Take the time to double-check your setup before you connect it to mains.
  • Keep your distance when you do your tests and have some means to quickly disconnect it from mains if something goes wrong, like two extension cords you can pull apart from a safe distance.
  • Test and operate your toaster on a non-flammable surface and keep anything remotely flammable at a safe distance.

And to dig right in, yes, of course you can hack a toaster and control it with picoreflow. The first thing you probably have to do is to bypass the built-in timer (most likely some bi-metal thermal switch) and use a 110V AC SSR (Solid-State-Relay) to control the heating wire instead. Or leave it in and set it to maximum, that'll give you a built-in safety but may interfere with your use-case.

Since you didn't elaborate what you actually want to achieve with this setup, you'll have to think about where you want to place the temperature sensor to be as close to the object you want to heat.

Also, keep in mind that most of these toasters are built as cheaply as possible (capitalism, fuck yeah) so I'd be very wary about how long I could put energy into the system (in terms of time) before the whole thing starts to break down or melt. Before you disassemble it, set the timer on it to maximum and let it run while timing it, that should give you a good baseline how long you can safely run it.

I just realized I never put up an example schematic how to wire the SSR/AC part, I'll try to draw something and add it as soon as possible for reference.

VanJaime
2016/09/30 21:41

Chronos,

Thanks a lot for your reply. It's been very helpful. I just order all the hardware and I'll be posting my progress for the project.

If you can post the SSR/AC Schematic that'd be great.

Thanks.

ozindfw
2016/10/08 19:17

I'm thinking about doing a temperature controller board for the Pi. It will be more than the PicoReflow needs, but there is no reason to stuff the parts you don't need.

What I'm considering is a board that you flip the Pi over and mount to that provides all the interface and power to the Pi. I also intend to make the board suitable for stacking, so you can get two times of everything if you need.

It's likely to be a significant departure from the current design. As an example I will probably use a Microchip MCP9600 thermocouple interface. They are cheaper and far more flexible than the Maxim parts. I'll write a driver to support it. I'll also probably provide spots for two to four parts, though again you'd only need to stuff one. The MCP9600 provide four configurable alarm outputs. I've not idea what to do with these, but I'll break them out to a connector in the theory that if I don't they will be essential for some reason.

Similarly, I'll probably make a lot more I/O available as an option. I plan to put two 8 bit output drivers and two 8 bit inputs one the SPI bus for a total of 16 I and 16 O. I'll write a a driver and if you only need the basic I/O you'll only need to stuff one part for each direction you need.

Since most of the applications seem to use higher input voltages anyway, I'm considering a small switching supply to power the PI and I/O. The open question in my mind is do I just supply the Pi, or provide enough additional capacity for some external stuff. If so, how much?

chrono
2016/10/09 13:06

Great, that is something more suitable for governess anyways, I was thinking along the same lines to have some board that offers more ports/flexibility for all kinds of control/governing use-cases. Here's a screenshot of the latest appliance setup page:

I'm still not happy with it and want it to be even more modular - but that resulted in a lot of abstraction and modelling under the hood to still have something people can just use with a browser and without being a fucking rocket-scientist.

No more messing around in config files and since governess should be completely modular we can plug and combine any kind of driver module to any kind of appliance we want to build. The choice for the MAX31855 was amde at the time for two reasons: Lack of better options and availability of breakout-boards you can buy almost anywhere on the planet, even at Amazon. I'd be happy to see more options since it seems the 31855 (or at least some batches) are sometimes prone to noise issues.

If it isn't too much to ask, please consider releasing your board as open-source hardware as well and if you haven't yet, please give kicad (>4.0) a try, so that we can all directly use the schematic/layout files without having to fall-back to proprietary software like eagle.

But I'm just an average guy and for the time being alone with all of it and have to keep the dayjob to survive so progress is much slower than I'd like it to be. So anyone fit in python or angular, please join the development team.

As for power, phew, hard to say. I'd go for broke and leave room for extensions since even the history of this project has shown, there will always be people coming up with new ideas that weren't covered in the original planning, so leaving that extra room for future development ideas really won't hurt.

ozindfw
2016/10/09 13:30

Sorry, I though I'd said I'd planned on making everything available. Schematic is already started in KiCAD and layout will be done there. I'll post KiCAD files, Gerbers, and BoM on GitHub. If you want to set up a project off the Apollo-NG Github I can maintain it there. I also plan to make it 'hobby friendly” - SO parts instead of QFNs, etc.

Looking at parts last night I will probably end up using the TI ADS1118 for the thermocouple converter. It's half the cost of the MCP9600 and two channels. I'll need to add the thermocouple look up tables, but that's no big deal. NIST has public tables for most types of thermocouple. Easy support for more than one type of thermocouple was one thing I wanted, and this makes it easy.

chrono
2016/10/09 18:12

Awesome. Maybe you've mentioned it earlier and I've forgotten but that's great news. I've already sent you an invite to the Apollo-NG GH group, so that you can join and maintain stuff on your own instead of working with PRs. If you have a name for the baby I can create a new repo for it.

ADS1118++. Have you checked if there's already some wiringpi/python implementation for it or do you want to create it from scratch?

Let's hope NIST didn't taint those tables like they did with the EC curves :)

chrono
2016/11/30 19:46

How are things going with the ADS1118? I'm currently mocking the input plugins of governess and wanted to add the ADS1118 to the V1.0.0 driver list but I still could only find an Arduino implementation, nothing for python. I haven't looked at the arduino code yet, but I guess it may serve well as a reference for a python re-implementation.

https://github.com/dhhagan/ADS1118

VanJaime
2016/10/08 20:41

I got all my hardware. Or at least, I guess all the required Hardware.

-Raspberry pi2 ver B (All libraries loaded) -MAX31855 Thermocouple (All connections done according graphic) -Solid State Relays (Where should I connect the relay?)

I need some help figuring out where to connect the thermocouple on the RaspberryPI - Toaster.

I don't have the electrical expertise but if someone can show me the right path I can get some help from the electrical department at school.

Thanks in advance for your kind help.

chrono
2016/10/09 12:06

I've finally had the time to create a couple of schematics and added them to the heater section above. If you're unsure, you can always test your setup with just a LED and a resistor (similar to the basic raspberry pi gpio example). That way you can see how the output behaves before you actually connect GPIO23 to the SSR.

I'm not sure about your thermocouple question. Do you mean where to place the thermocouple itself, how to connect it to the MAX31885 or how to connect the 31885 to the Pi?

chrono
2016/10/09 18:28

To the person that appears to be coming from Finland, almost everyday, checking up on governess progress:

Thank you for your patience and continued interest.

I wish I was smarter but as it is, I often have to brute force through some complicated abstracts/models and that takes time when you're not that smart and have to do it all alone :/

Since Angular2 is finally released now, we can expect Ionic2 to follow up. They're currently on 2.0.0-rc2, as of 7 days ago after a long period of no further updates. There are a lot of breaking changes again, once that settles I'm going to refactor to Ionic2 2.0.0 final and start working on integrating I18N support. As soon as that is in place the client scaffold should be finished and work on server/modularization can begin.

VanJaime
2016/10/13 21:39

chrono Thanks for posting the SSR schematic it is highly valuable.

Now I have a doubt. Following the default pulldown connection I see that the GPIO 1 (identified as P1-1) is been used by the 3 DC+ connector from the SSR and the 3vo comming from the MAX31855. Is this correct?

This is the SSR I got! it looks different from the one in your picture. Would this work?

https://amzn.com/B00E1LC1VK

Thanks for your help.

VanJaime
2016/10/14 15:50

Chrono, I found confusing your explanation about the pullDown and pullUp config:

At the beginning, you said “The default configuration has historically been to use the PullDown config…”

and at the end of the paragraph… “change your setup to PullUp connection instead if you don't want to worry/bother.”

The default config is pullUp or pullDown???

Which GPIO should be used for a default config? it seems like GPIO 1-1 is been shared by SSR and Thermocouple.

“The default configuration has historically been to use the PullDown config, i.e. when you pull GPIO23 low the heater is on and when you pull GPIO23 high the heater is off. Please keep in mind that you'll have to have some script/code in your setup that makes sure that GPIO23 is pulled high as soon as the system has booted (to be sure the heater is off) or change your setup to PullUp connection instead if you don't want to worry/bother. ”

Thanks for your response in advance.

chrono
2016/10/20 06:11

The default setup is PullDown. If, like with your toaster, there is a risk of hazard, it might be prudent to make sure the SSR is never enabled, except when requested by the software.

AFAIK, Pi GPIOs pull down when rebooting and keep them down until toggled up by some init script or picoreflow - which creates the unfortunate situation that a Pi reboot will actually enable the SSR (in PullDown configuration) and the heating element will be online for as long as something pulls the GPIO up (script/picoreflow run) or the appliance burns/breaks down…

TL;DR: From the perspective of the whole appliance, PullUp configuration with the Pi is inherently more safe and easier to maintain because of less layer-8 dependency.

The GPIO is always the same (23) - what changes is the direction of the current that flows through it. In PullUP GPIO will emit 3.3V → SSR → GND. In PullDown it will sink (close the connection to GND) ← SSR ← 3.3V. Pin 1 is not a GPIO pin, it's 3.3V, which is needed by the MAX31885 and also for the PullDown configuration.

You should make it habit to always at least try to lookup and x-reference any information you can find. Apart from people spreading misinformation there's also always a chance of simple errors/mistakes which could already have been replicated by others. Verifying takes a little of our time but it's always an opportunity to either learn something new or verify something we've heard/seen before. https://www.raspberrypi.org/documentation/usage/gpio/

Nick
2016/10/26 21:15

Hello Chrono,

Thanks very much for providing this project, great work.

I have built a small reflow oven using a very cheap toaster oven bought from Aldi, it cost £19. I have resorted to using infrared heating elements as they provide tighter control of the temperature, time will tell whether they cook the IC's or not :) .

I am very interested in testing Governess , can you let me know when it will be ready download and try?

Thanks once again.

Nick

chrono
2016/10/27 22:08

Ahoy Nick,

thanks for leaving feedback. I'd assume it will work for most cases. There are countless IR based DIY reflow oven builds out there and industrial production lines have been using it for a long time.

After all, it's a matter of risk mitigation/management. The more ghetto we go, the higher the chance of failure becomes, obviously. However, it seems we can hack together a lot now, due to more or less realtime global knowledge and information transfer and use whatever cheap means we can locally source to actually build. In the end, the thing that counts is that we could enable ourselves to do more with longer reach, because we worked together and shared our results, experiences etc.

As for governess, splendid, even though programming help would be much more effective right now - the time will come when some very early PoC demonstrator will be in dire need of people who will actually try to use and play with it in order to get the workflows right. Feedback from people right then will be essential, when it's still early enough to make even bigger changes and improve upon those test results.

It would be just foolish to assume that the scope of one hacker could cover any possible use-case other people might cook up…

If you want to be kept up-to-date you can subscribe to this comment thread, the RSS feed or, if you have a github account, just add a watcher for the governess repo.

RC-Migration of governess is almost finished and should be merged back to master very soon. Hopefully, by the time the ionic team will drop RC status to final release so that we have a more settled basis to go forward. The client is slowly gathering features but there are still a couple of show killing bugs/problems which are being tackled currently, either by refactoring or working upstream to get it right in the first place.

Renato
2016/11/14 03:34

Hi Chrono, iam still testing around with my oven for carbon parts.I found the following problem: if the target temperature is for example 60C and the sensor temperature is 60C, the heating stays on till the sensor temperature is 61C. Also when the temperature is falling, the heating starts at 59C. If i would like to change this, that it stops heating at exactly the target temperature and start to heat again at 0,1C under the target temperature, where can i change this?

The next problem is: when the whole process runs for about 2 hours, than after about one hour the countdown is not able to handle the seconds. It starts to stop the seconds countdown and after lets say 3 to 5 sec it jumps to the right time, then after a while the browser freezes. When i close it and start the browser again it catches the right temperature and countdown after lets say 20 seconds and everything runs ok again. But for my carbon parts its gonna have to run up to 16 hours. Do you thing the raspberry has not enough RAM or is the software unstable? Best regards Renato By the way are you german too?

chrono
2016/11/19 09:04

Thanks for reporting back, it helps a lot in the development process of governess to iron out these issues in the foundation of the system and not by hacking around afterwards. As for picoreflow, you'll have to dig into:

https://github.com/apollo-ng/picoReflow/blob/master/lib/oven.py

In order to make it more sensitive, add some debug log code to the run, set_heat, profile and pid functions so you get a better understanding of the actual numbers, comparisons and what's really going on there.

PicoReflow was built a long time ago and has always been a PoC Demonstrator, to evaluate the feasibility of using cheap platforms like the Pi and open-source software, as a basis to empower people to build their own DIY appliances - but was solely focused on SMD reflow.

It was shared in this state because the target group was not the general average user but other hackers/fabbers, who would understand its limitations and could use it as basis for inspiration, refactoring and customization.

As most PoC Demos, it's inherently insecure and buggy, specially when the dataset grows during long time runs. There is no built-in mechanic to change/reduce the sample rate while collecting and also while displaying the chart in a browser. When we take a sample every second and run for 16 hours we'll end up with over 50.000 datapoints to display. Unreduced, this many metrics are a heavy burden for any browser on any platform.

Additionally, the client was done with the technology of its time (jquery+bootstrap) which is quite bloated, slow and a pain on mobile (in hindsight).

RamRam has been doing extensive long-time work with ceramics, see if this helps: comment_04fba2e82797cec19e908b97b5b5b6d5

Which Pi version are you using? The first two generations of Pi's are single cores and - depending on OS configuration - could also become troublesome over a longer period of time. During our development, we never had these issues simply because the process of reflow soldering never exceeded 10 minutes - so we've never tried. A Pi 3 should be no problem at all because the python server itself really is neither a CPU nor Memory hogger.

I've grown up in germany, I've lived all over germany (except the east), I speak german but it's been a long time since I actually felt, that I am “german”. I don't believe that holding on or (trying to - brexit lol) go back to the idea of nationalism will be a peaceful way to the future.

Renato
2016/11/19 10:13

Hi Chrono, thank you for your reply. I am using a Pi 3. and about german i was not asking because of any nationalistic thing, we are all human beings, I don't care about skin colour, religion or sexual orientation as long as you give other people the respect they deserve. I just asked because I wanted to know if I could write in german to make my issues more understandable. Best regards Renato

chrono
2016/11/19 11:11

Right, neither do I :) I still pefer to keep the content of the wiki in english so that more people can benefit from it. If you want to have a chat in german, you can always feel free to jump into the german IRC channel #apollo on darkfasel.net or use the webchat if you don't have an IRC client set up.

Stefan
2016/12/13 11:12

Hi Chrono,

iam collecting ideas/project-info with the goal to eventually build/modify an oven for smd re-flow-soldering.. your project seems really nice :-) i have tried to find a price info for the EKA KF412 oven. the only price i found was ~750Euro. and for me that is to much :-) - i know the infra-red ovens are starting at 30/60Euro - but i think the convection variation is the better technology.

do you know any smaller convection-oven that could also work? i think the uncommon point is the 300°C mark?!

sunny greetings stefan

chrono
2016/12/13 12:41

Ahoy Stefan,

these were basically the same parameters when I originally started my reflow oven. I've been looking a while back then and I've found a couple of gastronomy/bakery suppliers and websites reselling them. There were some cheaper one's but I just didn't like how they looked and I'm kinda picky about that ;) Finally I found another website offering the KF412 for a considerably lower price so I grabbed that.

I would like to supply you with links but as this was such a long time ago, I don't have any to supply you with anymore.

Convection Transfer, Circulation and Temperature up to 300°C were my base specs because I always try to leave more headroom for the parameters I can control to keep risk of overall project failure lower. Especially when I tackle new projects I know nothing about (like building a reflow oven).

Even though we both agree that convection transfer is the better alternative, with a bit more care and profile tuning, IR should still yield results as industry and countless other DIY solutions have proven, albeit with a slightly higher risk of loosing product, due to overheat conditions in ICs.

My max. temp constraint was based on the fact that I like to be able to let systems run unattended, so they headroom to 300°C was mostly risk mitigation (accidentally burning down the house while running by itself) and also to have more headroom on the rising slope, because it was likely that an oven designed to work up tp 300°C would have no trouble getting to 240°C fast enough to stay within the reflow spec of most parts.

I hope that explains my choices a bit better, to give you the freedom to make your own choices. Don't be afraid to go low-tech/ghetto-style in your approach, I'd think it's totally fine to invest very little money and see how far you can get with that and gather experience while you're at it. You can always buy and wire up a new oven when you really don't get the results you desire.

Also sunny greetings, probably due to the same wind and fön conditions, from 80km south-west…

chrono
2016/12/13 12:51

A little update on governess development:

governess has been slated as the primary project for the last half year and there has been made a lot of progress. The Ionic2 team is about to release RC4 (at least that's what the current branches/commits indicate). I was hoping they would get to a release much sooner in order to avoid refactoring big parts of governess's code base for all the breaking changes.

Currently the third iteration of refactoring is going on (back where it started on the appliance editor). I've been using countless real-world control/governing systems, reverse-engineered how they worked and tried to see if I could apply their regulation/io scheme to governess. These “test-runs” on the model have helped a lot to determine if the model, workflow and UX elements are actually making it possible to build virtually any kind of appliance with it.

This has lead to the 4th generation of the model which, I think, seems ok to serve as a basis for 1.0.0. I'll hopefully be able to use the upcoming holidays to finish a PoC Draft of the client by the beginning of they new year to focus on getting the server part going. Thanks to all for your valuable feedback, ideas, questions, PRs and general support and interest to keep its development alive.

Adrian Brentnall
2017/01/21 22:22

HI Chrono

Just discovered picoReflow - looking to use a Raspberry Pi to control a glass-fusing kiln. In glasswork, our schedules tend to be described as 'rate / target temperature / hold time' - as opposed to picoReflow which (if I'm understanding it) is programmed as 'target time / target temperature'.

I understand that you're concentrating on governess. Will governess have the option of being programmed in 'rate / temp / holdtime' format? - which would be much more familiar to us glassworkers.

I know it's just simple maths to convert between the formats, but it's not unusual in glasswork to need to 'tweak' the hold time at the top 'process' temperature, which would have a knock-on effect on subsequent target times…

Thanks

Adrian

chrono
2017/01/21 23:07

Ahoy Adrian,

thanks for leaving feedback. I'm currently deep into re-modelling everything in governess to become way more flexible and modular but of course I'm confined to workflows and processes that I have experience with or at least a little base knowledge about. The current model abstract looks like this:

Now, given my limitations, feedback from others will help greatly to make governess truly modular and flexible. I'm not quite sure that I understand your glass-fusion workflow correctly, specifically rate and holdtime of your given function. I've got a couple of other different processes where I'm struggling to find a simple solution to make the process easily abstract- and configurable - so reflection and discussion would be great.

If you could describe your fusion process with more details about which factors are relevant for you and how you feel they should be controlled/governed, it would be awesome. Also, if you could provide models/ideas how you as user would like to program/input your specific variables would help me a lot.

As of now I'd guess we'll need a new PID Temperature governor plugin which has to be tailored to your use-case. Since governess plugins, tasks and appliances are meant to be shared eventually, we'd only have to come up with a solution for glass fusion work once.

chrono
2017/01/21 23:43

Could this describe your needed process? Where Rate is your DeltaT to the previous setpoint in °C/s (min/max constraints?). Is Holdtime a function of reaching a certain temperature and then holding it for a certain period of time in order to let “it fuse”? Basically, if the oven and its DeltaT would be known, it could easily be expressed using the original set time/ set target function, but it would require manual fiddling and tweaking until the process is optimal.

If I imagine it right, you'll want basically a timer based system, when a given temperature plateau is reached, it should stay there for the defined hold-time so that the process is less dependent on timing but more on actual temperature triggering the next step?

Adrian Brentnall
2017/01/22 08:51

HI Chrono

Thanks for the fast reply!

I did a little work last night and programmed a real-life glass fusing schedule into picoReflow - it's here http://www.inspired-glass.com/page2.html

Timings along the bottom are in hours:minutes - temperature scale is in centigrade.

You can see the 'hold' sections - which are reasonably easy to input, as sections with a ramp of zero, and a duration of whatever the hold time is.

The part of the schedule that actually 'does the work' of melting (fusing), bending, or tacking the glass is the little plateau at 800c - which can be anything from zero minutes to an hour or so. The slow cool and hold from 500c to 420 is all about annealing the glass (removing stresses). The final cool-down from 420 to ambient is usually done simply by turning off the control and allowing the kiln to cool naturally - after you're through the annealing phase then the ramp-down rate isn't critical - so a 'do no control but keep logging temperature' segment would be useful here.

The commercial glass kilns I've seen tend to be programmed in terms of three parameters per segement - target temperature, ramp rate (degrees per hour) and hold time (which can be “zero” to hours).

As it stands, picoReflow is certainly adaptable to glasswork - once you've done the simple maths to translate from 'absolute time in the process' to 'ramp rate' - and I plan to give it a try on my large kiln just as soon as I get the suitable Pi-friendly relays to drive the 40A contactors.

I wonder if this makes it chear how we glass folks operate?

Any questions - please ask.. - and 'well done' on picoReflow. Can't wait to see 'governess'!

Thanks

Adrian

chrono
2017/01/22 09:19

Thanks for taking the time to describe it, I think I have a much clearer picture now. I guess a feature like that would also be a welcome addition for the pottery folks and what I could learn from discussions about their cones/glazes.

Obviously, as you have managed to do as well, we can create many use-cases “manually” on the time axis but that leaves two things wanting:

  • Having to calculate and adapt our curves manually is not the most efficient way to go about it.
  • When controlled only by the time curve, holdtime can be tricky to adjust manually because with the current governing implementation it will start when the set-curve reaches the holdtime starting point but depending on thermal inertia and other unique hardware factors, the actual temperature may not really reflect that and may incidentally cut hold-time short (which currently would require to manually prolong the hold-time in the time-curve to reconcile)

I'm happy that you could make it work with just picoReflow and will try to use your feedback and adapt a “three parameters per segment” input workflow and see how I can model it UI and process wise. It's always good to have new models to verify process adaptability.

Adrian Brentnall
2017/01/22 09:32

HI Chrono

Thanks for the reply.

You said

“When controlled only by the time curve, holdtime can be tricky to adjust manually because with the current governing implementation it will start when the set-curve reaches the holdtime starting point but depending on thermal inertia and other unique hardware factors, the actual temperature may not really reflect that and may incidentally cut hold-time short (which currently would require to manually prolong the hold-time in the time-curve to reconcile)”

Trying to understand this…. - not sure I do <g>

Some of these hold times are quite critical (+/- a minute in the case of the 'process' hold).

What I was hoping to do next was to run a logging program to see what the _actual_ time/temperature profile looks like - while the kiln is being controlled by my current (commercial) controller.

It may be far less 'ideal' than the programmed schedule!

We'll see.

Thanks

Adrian

chrono
2017/01/22 09:46

I've added (sorry for the crudeness :)) a green line that may represent how the temperature will follow the curve in reality. The last segment has a quite high DeltaT and we see that in this case it cannot transfer enough energy in time to reach the segment plateau when we expected it. So currently, you'd have to run your curve to get the actual metrics of your particular kiln/process to see where reality will not follow your curve and make the hold-time longer (basically adding the time difference between reaching defined and actual temperature).

I'm not sure this is even going to be a problem for you at all, long-term processes seem to suffer way less since thermal inertia is less of a problem when the process runs for more than just a couple of minutes.

Adrian Brentnall
2017/01/22 11:01

HI Chrono

No problem with the crudeness <g> - perfectly understandable.

So, in my commercial controller, my 'hold' time would start when the temperature setpoint is reached. Are you saying that, under the current scheme with pico. - the holdtime will start at the preset time, regardless of the actual measured temperature?

If so - that needn't be a big problem - as it's known in the craft that fusing schedules aren't absolute, and will need 'tweaking' in terms of holdtime and temperature for a specific kiln, and will also vary depending on the type, size and colour of the glass being worked.

Or, in other words, “suck it & see” <g>.

What would be useful (and is present in pico) is the ability to save those tweaked schedules with meaningful names - so, rather thank having to remember, for a particular item, 'tweak the top temp down from 800 to 780 and reduce the hold from 15 mins to 8' - I could just call up the saved “fused glass fuchsias” schedule.

Pages 17, 18 of this pdf

https://hotkilns.com/sites/default/files/pdf/Genesis_Manual_3-3-16.pdf

Give an idea of how commercial controllers do it…. by glassing standards this particular box represents the leading edge - most controllers in use at the moment are far simpler (in terms of UI) - and run 7-segment displays and 3 operation keys - like this one I'm currently using

http://www.bartinst.com/kilns/3

The ability to add/adjust timings/temps 'on the fly' is also handy in some situations…

Thanks

Adrian

chrono
2017/01/22 11:28
Are you saying that, under the current scheme with pico
the holdtime will start at the preset time, regardless
of the actual measured temperature?

As the PID governor of picoReflow has no concept/knowledge of hold-time, yes, that is so. Reflow-Soldering didn't really force us to think in those terms so it's still kinda simple & dumb.

Or, in other words, “suck it & see” <g>.

That's the best spirit to work with it currently :)

What would be useful (and is present in pico) is the ability to save
those tweaked schedules with meaningful names

That was the basic idea with the profiles back then, so that you'd only have to figure out the curve for one specific process and could re-use it N-times after final adjustments productively, without worrying too much.

For governess this is supposed to go one step further, not only profiles (which are now called tasks) but input, controller, output and whole appliance configurations can be managed, copied, altered through the UI but they're also supposed to be shared within the governess eco-sphere, so that you could publish and share your appliance or task configuration for a certain color or process with others.

With that everyone can benefit from the time savings of not having to figure out the base parameters again but can concentrate on tweaks for the local appliance.

Also, I'd really like to have some sort of auto calibration and auto tuning, so that governess can run some autonomous tests on herself, to figure out her hardware limits and set those as constraints to warn the user during task editing, if the wanted slope is actually possible with the supplied hardware.

Manual override for automated tasks has already been covered and is a configuration option so that you can manually “nudge” the governors regulation input in case you're not happy with the result and want to interact directly instead of aborting, editing and re-running (which may mean a loss of product for some processes).

Adrian Brentnall
2017/01/22 12:06

HI Chrono

OK on the 'hold' thing. Am I right in thinking that I can 'fake' a hold by having a segment with the same end-temperature as the previous segment - the only slight flaw being that it's all time-dependent, rather than being triggered by achieving a set temperature?

As to the 'sharing' of profiles/tasks/setups - in the glass world that'll be fairly specific to a given kiln/glass/etc - so might not be so usefully 'shareable'. Fusing schedules are published and shared, but usually carry the caveat that they will need adjusting for specific instances.

It's a bit of a black art!

Many commercial kilns are based on 'ceramics' kilns - and are made from various sorts of firebrick, which means that the kiln has a significant thermal mass, and so takes longer to heat and cool.

There's a trend towards using fibre insulated kilns (like my homebrew one) - and so can heat and cool much faster (possibly faster than is 'good' for the glass!)

Quick question - if I run pico. as a data logger - without allowing it to actually control the kiln elements - will that let me log a firing cycle that's controlled by my other controller? I had the idea of doing this, with the schedule I showed you in the link, and seeing 'what actually happens'.

Then I'd re-wire things so that pico. was now doing the control, and run it all again…

Would that work, or would pico get upset?

Thanks again for your help

Adrian

chrono
2017/01/22 12:50
Am I right in thinking that I can 'fake' a hold by having a segment with
the same end-temperature as the previous segment

I'd even think simpler, let's assume fusing at 800°C shall hold 800°C for 300 seconds after 800°C is reached but we see that our kiln takes longer to actually reach 800°C. Let's further say that our test run has shown that it takes 100 seconds longer (Difference between defined and actual) - we would just have to push the second datapoint of the 800°C plateau (the end setpoint in the profile) 100 seconds to the right (add 100s). That should match the required hold time perfectly.

the only slight flaw being that it's all time-dependent,
rather than being triggered by achieving a set temperature?

Exactly.

Regarding insulation, Insulfrax seems to be a great alternative as well, we've been using it small-scale very successfully as 3D printer heat-shield

As for sharing, yeah, probably all of these kinds of processes could be considered “black art” since all of them require that we have to put our mind and time to it in order to get it right. There is no fits-them-all-everywhere-everytime solution. The idea of governess and sharing what we have is not meant to mitigate the “black art” portion of it, but to make it easy for newcomers to the specific art to have something to start with where we know that other people already achieved results with it.

Quick question - if I run pico. as a data logger - without allowing it to
actually control the kiln elements - will that let me log a firing cycle
that's controlled by my other controller? I had the idea of doing this,
with the schedule I showed you in the link, and seeing 'what actually
happens'.

Yeah, sorry, totally forgot about that because I wanted to propose it anyways. Just create a profile and set two points, one at 0|25°C and one at 7200|25°C (or whatever end time you set your commercial controller). Or you could just use your already created curve as a reference to directly see where it might be off. Then you can just start the picoreflow job and the other controller. That should work even without having an SSR/Heater connected and picoReflow should record and display the curve regardless of no/not active heater.

Adrian Brentnall
2017/01/22 15:06

HI Chrono

All understood - thanks!

Yes - your insulation material is a close relative to what I'm using.

I'll set up a simple profile in picoReflow, and log it while the old controller is in charge of things - might make for an insteresting graph!

Will report back

Adrian.

Dragos State
2017/03/05 15:42

Hello,

One qestion: What does the toggleLive (The Eye logo) button suppose to do,

I can't seem to find the function it calls to in picoreflow.js

Thanks

Dragos

chrono
2017/04/20 13:29

phew, you got me there… I'm not sure what the idea was behind it. I was probably aiming to have the ability to see (or not) what the last “live” curve looked like, so that one has a better reference when adjusting a certain profile to the real world capabilities of the hardware in use.

It probably never got hooked up, since it was such a “little” feature that it wasn't done while we were doing the heavy lifting of getting it to work as a whole.

gev
2017/05/10 16:30

Hello, does anyone try to use picoreflow with nanopi neo. It working perfectly in simulate mode, I got the warning “Could not initialize GPIOs, oven operation will only be simulated!”. I install WiringNP, but I dont know how to modify “lib/oven.py” to replace RPi.GPIO. Thanks for helping

chrono
2017/07/26 15:59

Sorry for the late reply, it's been very busy unfortunately. I've never tested the nanopi (don't have one). It's probably just a matter of re-assigning PINs so you need to figure out where the PINs are and play around with the settings in config.py. When in doubt, connect some LEDs to the outputs instead, so that you can visually confirm if it worked or not.

Andrius
2017/07/26 15:44

Hey Chrono, Thanks for sharing this amazing work!

I'm not familiar with Raspberry. So my question is: Would it work as standalone unit with a touch-screen display for raspberry. Or I can control it only by web-server?

Regards, Andrius

chrono
2017/07/26 15:56

If you run an X server, which is running a browser you could connect a touchscreen to your PI. Experience has shown that the PI is great to control low level stuff but quickly gets unresponsive when overloading it with high level stuff like Browsers/Web-GUIs etc. Since this seems to be a re-occurring issue, I'll keep it in mind for governess, so that the API of the server can serve the governess web client as well as some ultra minimalistic GTK/QT UI, which can run on X.

MrBishop
2017/08/30 02:51

playing with the idea of making easy to use easy to solder board. keeping the picoflow build on a pi-zero-w super clean. i'd be happy to share the pcb design. make it open. make it free to download. https://cdn.discordapp.com/attachments/335964799731105795/352280119060201472/unknown.png https://cdn.discordapp.com/attachments/335964799731105795/352280187800649735/unknown.png

Travis
2017/10/22 16:01

So I have been attempting to get this to work using a raspberry pi3 and have edited all the required pins to work with my oven that has four heating elements (2 top and 2 bottom) everything works the way I expected it would so now I am trying to get the program to run at reboot so it can be a completely headless system and not need any interaction on startup but none of the normal methods seem to be working. A crontab log gives this

2017-10-22 15:30:34,234 INFO picoreflowd: Starting picoreflowd 2017-10-22 15:30:34,250 INFO oven: import MAX31855 2017-10-22 15:30:34,256 INFO oven: init MAX31855 2017-10-22 15:30:34,273 INFO picoreflowd: listening on 192.168.1.55:8081 Traceback (most recent call last):

File "./picoreflowd.py", line 219, in <module>
  main()
File "./picoreflowd.py", line 215, in main
  server.serve_forever()
File "/usr/local/lib/python2.7/dist-packages/gevent/baseserver.py", line 360, in serve_forever
  self.start()
File "/usr/local/lib/python2.7/dist-packages/gevent/baseserver.py", line 304, in start
  self.init_socket()
File "/usr/local/lib/python2.7/dist-packages/gevent/pywsgi.py", line 1450, in init_socket
  StreamServer.init_socket(self)
File "/usr/local/lib/python2.7/dist-packages/gevent/server.py", line 127, in init_socket
  self.socket = self.get_listener(self.address, self.backlog, self.family)
File "/usr/local/lib/python2.7/dist-packages/gevent/server.py", line 138, in get_listener
  return _tcp_listener(address, backlog=backlog, reuse_addr=cls.reuse_addr, family=family)
File "/usr/local/lib/python2.7/dist-packages/gevent/server.py", line 229, in _tcp_listener
  sock.bind(address)
File "<string>", line 1, in bind

socket.error: [Errno 99] Cannot assign requested address: ('192.168.1.55', 8081)

Any ideas would be appreciated it seems as though the system is starting up and binding and then trying to bind it a second time for some reason

chrono
2017/10/22 16:17

Uhm, crontab? picoreflow is meant to be run as a daemon, so you need some systemd/upstart/sysinit script to start it up at boot time. See https://github.com/apollo-ng/PiGI/blob/master/software/init.d/pyGIserver

Running it in cron is a bad idea, because it will try to start multiple instances of picoreflow, which won't work since they all would try to open the same socket:

socket.error: [Errno 99] Cannot assign requested address: ('192.168.1.55', 8081)

Comment text

Please type the letters you see on the left into the box on the right:

  ____   _      __   __  ___  ____    _  __
 / __ \ | | /| / /  /  |/  / / __ \  / |/ /
/ /_/ / | |/ |/ /  / /|_/ / / /_/ / /    / 
\____/  |__/|__/  /_/  /_/  \____/ /_/|_/