Soak stage too short

[pastaclub]

As can be seen in screenshots (e.g. this one, heaters are a bit slow and the actual temperature curve lags behind the intended profile.

In the current implementation this leads to a soak phase which is too short. In the Lead217 profile, the specified soak stage is from 90s to 180s with the temperature raising from 150C to 175C, i.e. a 25C increase over 90s. The actual (measured) temperature reaches 150C only with a delay, yet the device soon heats more to transition to the reflow phase. It's not soaking long enough, and the temperature rises too quickly, which is not good for the components.

As a simple remedy, I suggest syncing the actual curve with the profile up to a specified temperature, for example 90C. That means that during the pre-heat stage, whenever the temperature is measured, the profile is shifted on the time-axis so that the actual temperature matches the temperature specified in the profile. For example, when the heater is slower, the profile will be shifted right in the screenshot, until reaching 90C. At 90C both curves are crossing. From there on, the behavior would be just as before.

[dukeduck1984]

I have tested all 3 profiles. For Lead 217, the actual temp matched the profile pretty well (of course there was a bit of lag initially) until the reflow stage where it failed to reach the peak temp of the profile. For Lead 138, there was quite a lot of overshooting in preheating, which I believe was caused by the setting of the 'preheat_until' value which was too high for such a low temp profile. For Lead 183, as you have seen the picture, it's almost perfect.

The lag only happened at the beginning of a 'cold start', in which case it needed some time to catch up with the profile, but after that, the rate of heating up at full throttle was well enough to meet the requirements of any of those 3 profiles. My oven rated 800 watts, and only costed me about 12.5 EUR, I guess any oven on the market can be as good in terms of the rate of heating up.

So in my point of view, it's mainly a parameter tuning issue. In the current version, the inner timer which is used to look up the corresponding target temp in the profile will be reset to zero when the actual temp reaches the low end of the profile (that's also when the 1st red dot shown on the plot), this is the moment when the temp control logic starts to sync the actual temp with the ideal profile.

I have a few proposals:

1. Get rid of previsioning & overshoot_comp which are the concepts I 'borrowed' from X-toaster, but after some tries, I don't see them very helpful, and on the contary it probably makes things more complicated.

2. Get rid of sensor_offset, and replace it with preheat_until by which I mean put 'preheat_until' into GUI where the users can have easier access to (also minimal changes in the code). As this is a home project, I guess most users don't have a bar to test their sensors' against, so the 'offset' won't be much useful. However, for different profiles, users may need to set different 'preheat_until' accordingly.

3. Allow each profile has its own indenpendant PID params and 'preheat_until' settings. Again, as a home project, I suspect people will change the type of the solder paste from time to time, most people probably just stick to one or two models. In this case, they can spend some time fine tuning the settings until they are satisfied with the result, and don't have to worry about messing around with the params whenever they need to switch to the other type of solder paste.

[pastaclub]

For Lead 138, there was quite a lot of overshooting in preheating, which I believe was caused by the setting of the 'preheat_until' value which was too high for such a low temp profile.

My first thought was defining preheat_until as a percentage, relative to the melting temperature. But after some thinking, I believe we should define preheat_until as an absolute value in the profile instead of the config. It could be optional (and default to 75C or so), so that other adafruit-style profiles would still work without changes.

2. Get rid of sensor_offset

I thought that sensor_offset is required for calibrating the temperature sensor? If so, we should keep it. But in any case my MAX6675 already reports correct values without any offset, so I set it to 0.

Or did you mean to keep sensor_offset and only make preheat_until configurable in the GUI instead of sensor_offset? That would make sense... but I still prefer having preheat_until in the profile.

3. Allow each profile has its own indenpendant PID params

I'm not so sure about that. Theoretically the PID params should describe the behavior of the heater & measurement, so they should be independent from the profile. Once the ideal values are found, they should work well with any profile. The current problems your described probably arise from less-than-optimal PID values. Unfortunately I have no clue how to do PID tuning.

I suspect people will change the type of the solder paste from time to time, most people probably just stick to one or two models. In this case, they can spend some time fine tuning

Yes, I agree. Most people probably use only 1 or 2 solder pastes.

But I'd like to make additional profiles for other purposes, such as one for baking components (get rid of moisture), and one for constant reflow (for reworking on the hot plate, e.g. replace components). That should easily be possible.

[dukeduck1984]

• Probably preheating_until can be calculated by the rate of heating up required at 'starting' stage, AND the low end temp of the preheat stage. For Lead 138, it's required that the temp needs to go up from 30 to 90 degree in 90 seconds, that's 0.67℃/sec, however, for Lead 183 & Lead 217, the rate is 2.33 & 1.33 respectively. This probably explains the massive overshooting in Lead 138 given the same preheating_until settins at 75. Maybe we can try preheating_until = low_end_temp_of_preheat * 0.33 * that_rate, which will give us 19.8 & 66 for Lead 138 & 217 respectively. I will test on my oven to validate it.

• I agree to keep sensor_offset but move it to the config file, since this is not what you will change very often.

• Regarding PID params, I guess it's because in our use case the temp change is so dynamic. The heater itself is not very responsive in the first place, and it's responsiveness is not linear - during the 'cold start' and when it's getting close to its upper end of working power, it's slow. And given the fact that the reflow profile can differ quite a lot one from another, it's very difficult for single one set of PID values to work flawlessly for different profiles.

[pastaclub]

We could have a look at how 3D printers do PID auto-tuning, since the temperatures are in a similar range. I run RepRap firmware on my printer and the tuning works very well. I found the snippet of source code that does the tuning. It's also well documented within the code: Pid.cpp

[dukeduck1984]

Auto tuning is great, but the major differences need to be considered: 1. the thermal inertia is so much smaller for the 3D printer; 2. the working temp of the hot end and the heated bed are constant.

[pastaclub]

I tuned my PIDs and improved the behavior a lot, but one fundamental problem that always remained is that the heater takes a while from the start until the measured temperature curve rises, so the actual curve always lacked behind and that made it very hard for the PID do react properly in the soak stage.

I solved this by making a simple change to the profile (so far only Sn96.5): I added 15 seconds of delay at the beginning (with temperature 30C). Due to the preheat-until setting, the heater goes on as soon as the start button is pressed. It takes about 10-15 seconds for the heat to reach the sensor. Once this delay has passed, the measured temperature starts rising and the profile curve also starts rising, so both are perfectly in sync. This makes the job much easier for the PID.

Your machine would probably also benefit from this. It's not ideal to have this delay in the profile... it would be preferable to have an option in config.json to configure the delay and then have it added upon loading the profile, but that's for a future version :)

As there were no further issues with beta2, I merged beta2 back into the master. This delay change is in the new branch release-dcb. If you want to try it, I can cherry-pick it into beta2.

[dukeduck1984]

I got you. Your plate needs a bit longer to warm up (to achieve a higher rate of heating up), so extra time is needed before the temp control logic starts to sync with the target temp. Definitely I agree that it's preferable to have it in the config than change the profile file. As soon as the chart is about to draw the 1st point (and sync with target temp), it will wait until the set delay time is passed.

My oven is ok, as I sealed the chamber of the oven, as well as wrapped it with thick ceramic fiber cotton, so the soak stage is just fine once the PID is properly tuned.

[dukeduck1984]

I added a pre-delay warm-up to deal with either the heating element is too slow (not powerful enough, which is my case) or the thermal inertia is too great (which is the case of your plate). Below is the effect of a cold start from 20 degree, now both preheat & soak curves are followed nicely. The preheat_until in config.json is used to set the goal temp for the pre-delay warm-up - which is still 75 now. Also I commented out both previsioning & overshoot_comp in the code, as so far I don't see much use of them, I plan to delete them from the config.json as well.

The update has been pushed to beta2. I have tested the code for several runs.

[dukeduck1984]

preheat_until setting might be not necessary, it can be set to 70% of the start temp of preheat stage, just a thought.

[pastaclub]

I merged this into my branch and will test. This is definitely better than defining a delay in the profile (since it's related to the machine and not to the solder paste).

I also merged two commits from my branch back into beta2: one with an option of enable the integration term of the PID in all stages, and another one that renames two profiles, e.g. the profile name for Sn42/Bi57.6/Ag0.4 was changed from "Lead 138" to "NoPb 138" since it doesn't contain any lead.

[pastaclub]

With the latest code, my machine always reads the temperature as 0.0 degrees :(
(yes, I am using the release-dcb branch, but I compared it to beta2 and it's almost identical now, except for config.json and one more commit about a temperature multiplier, but that one worked before). Not really sure what causes this since I don't see anything suspicious in the code that could cause this error.

[dukeduck1984]

That's strange. I didn't make any change on temperature measuring.

[pastaclub]

Yes, the most plausible explanation would be that my thermocouple got disconnected, but it's all mounted within the enclosure and I didn't even open it, so there was no mechanical force on it. I will keep investigating.

[dukeduck1984]

@pastaclub Did you get a chance to test it? Any feedback? :-)

[pastaclub]

No, I still had the software freezing (with relatively recent code) and then the new problem with the thermocouple reading 0.0 degrees. I'm planning to test it with a different ESP32 on Bibbbi's PCB, but haven't ordered the PCB yet since I want to order more different PCBs together to save on international shipping. I'm a bit worried about running into more problems with that PCB since it doesn't seem well supported and I'm not sure how the touch is supposed to work as the pins are not connected. We'll see...