CFW for KSGER/Quicko STM32 Soldering Stations

[dreamcat4]

Just to add... it help to power your controller (+24v rail) from a current limited bench psu. It is another helpful way to avoid fire

here also you can see in the picture how to implement floobydust diode mod for -Ve spike / esd protection. For the mosfet at least. Not sure what it should looks like for op amp.

[floobydust]

A clamp diode across the heater protects the mosfet and TC op-amp from -ve voltage spikes. A 30V mosfet running off 25V... doesn't take much -ve to blow it.
But that extra diode doesn't give protection with JBC tips though, they have that separate TC input. So another diode is required unless the op-amp happens to have them built-in. No mention of that on the SGM8551 datasheet.

Can you explain your "r2" "r3" on the controller boards in your repo.
I did schematics for OLED-3.0 and OLED-3.1 to post in a new thread but you are calling one "2.1S r3" which seems confusing. I know there are many variants of these boards, a few different clones out there.

[cosmin1]

If the LED does not come on, then the LED or op-amp input is shorted, or there is an open-circuit.
Check your soldering of the resistor - 1MEG cannot damage anything here. The LED must come on when the heater mosfet is on. If you ever short the heater to GND the mosfet can get damaged and short.

Solved this time too. Chinese quality resistors...
When soldered the 1Meg resistor to R8, the R8 terminal peeled off. I only saw it only under microscope.
Replaced the R8, soldered a 10Meg pullup resistor and now everything's fine.

Be careful with these boards, if you need to resolder the resistors... they have very very thin terminals and they peel off immediately.
In the end i replaced several resistors because of their poor quality.

[chollm]

ok... this means that i shall need to disable / remove all of the references to git lfs in the repo. Then re-upload it.

The operation is too complicated to do tonight, it will have to wait until tomorrow. I'll let you know when it"s done. Or you can press the button to watch the repository to get an email alert.

Thank you.

[dreamcat4]

ok... this means that i shall need to disable / remove all of the references to git lfs in the repo. Then re-upload it.

I'll let you know when it"s done.

Thank you.

OK done. It's currently at 366mb.

Can you explain your "r2" "r3" on the controller boards in your repo.
I did schematics for OLED-3.0 and OLED-3.1 to post in a new thread but you are calling one "2.1S r3" which seems confusing. I know there are many variants of these boards, a few different clones out there.

r = revision. Because there are so many revisions.

The one you are referring to was based upon the Ve2.1s r2 pcb design. But then the mid section has been redesigned. So purely in terms of what they were revising and taking from an existing design, it is in fact a further revision of that one. That is why it was labelled as 2.1s r3.

The problem is that there's 2 other completely different looking 'v3 x' designs.

So to at least keep that adjacency, and connection I can rename that one as "v3.0 r0"... How about that? It's really the best I can make of a bad situation here. Not my fault.

 

I'll make the change later today, and upload your new schematics to it's new folder in github. Is that OK ?

We still need the original schematic file, to edit and make better schematics of all the other derivations. This includes publishing schematics of all the possible mods on these boards. The need for it has only grown stronger over time. As predicted we are struggling in that area.

I think it would make things a lot easier then, for other people to trace their boards out and when they see they deviate from your schematic, to make corrections into the schematic. By editing it / tweaking it. So each revision can have it's own properly correct .sch file (or whichever reasonable format, kicad etc.).

My policy for managing this content, see "Disclaimers Section":

https://github.com/dreamcat4/t12-t245-controllers-docs#disclaimers

Bearing in mind these are clone stations, so I avoid publishing information there taken directly from original / official JBC stations. Only the chinese clone products. You have to draw a line somewhere.

[cosmin1]

So to at least keep that adjacency, and connection I can rename that one as "v3.0 r0"... How about that?

I say it's the best way, since both black versions support v3.0 firmware, but still they are different.
First revision (with STM32F101) supports both v2.0 and v3.0 firmware.
Second revision (with STM32F103) supports only v3.0 firmware. This version will shift image to the right if the display is the "small version" 128x64 pixels. If it's the normal display (132x64), all will be ok.
Here is the schematic for black boards "v3.0 r0" and "v3.0 r1" we drawed with floobydust. Only the MCU is different between them. Hope this helps you for the database. 

[dreamcat4]

Great.... if anybody else has a more 'sane' version naming scheme, then it's not a bad idea to field it now.

for example instead of using a sequential number, an alternative might be to use a character from the alphabet. So that they can then be rev'd ontop of that.

For example:

rev-a, rev-d, rev-g

Can then:

rev-d1
rev-d2

I didn't think of that before, because i had already used the letter 'r' to denote 'revision' instead of 'v' for 'version'.

If i can get some more feedback there, then it would make it more justifiable for me to change the current numbering scheme to something else like that. And also check to make sure that it can adequately cover for all the most commonly seen models.

[floobydust]

The biggest part of the problem is the stores advertise: a soldering station version, a controller S/W version, a controller H/W version, and the PCB silkscreen version is usually different too.

I would not use the terms 'revision' or 'version' to tell different builds apart - there are a few different PCB versions and builds from different shops. They are compatible with each other to a large extent. That's the best part about Communism the "People's Soldering Iron" is a standard lol. I have the STM32 I/O assignments for at least five controller boards and they are almost identical.

i.e KSGER Store advertises "V2.01 2019" reporting "HW Version 2.0" but ships out OLED-3.0
"V3.1S 2020" reporting "HW Version 2.0" but is OLED-3.0 with no silkscreen name.

[Bozog]

So I have had a good play with PID settings and have found it is fairly easy to tune them for any given setpoint, the problem is if you change the temperature even 30°C or so from the tuned setpoint it becomes completely unstable and requires retuning, which renders boost and sleep mode pretty much useless.

Now I know pretty much nothing about PID control, but it would seem we need some sort of setpoint compensation, or maybe I have missed something blindingly obvious?

[floobydust]

In your prev. video, it looks like a software bug.  Is that fixed?

As soon as the heater is off 0%, the displayed temperature makes big jumps. Setpoint is 300°C.
Heat is off and displayed temperature falling 303° (6%), 305° (1%), 325° (0%)... falling to 296° then heater on (100%) and display jumps down 46°, 48°, 87°, 313° (65%). The measured temperature should not have bad readings.

If those bad readings get into the PID, then the integrator term can wind up and cause overshoot afterwards.
When you edit PID settings, setpoint or gains I would reinit and clear the I term as well as the digital filters for all PID.

[Bozog]

In your prev. video, it looks like a software bug.  Is that fixed?

As soon as the heater is off 0%, the displayed temperature makes big jumps. Setpoint is 300°C.
Heat is off and displayed temperature falling 303° (6%), 305° (1%), 325° (0%)... falling to 296° then heater on (100%) and display jumps down 46°, 48°, 87°, 313° (65%). The measured temperature should not have bad readings.

If those bad readings get into the PID, then the integrator term can wind up and cause overshoot afterwards.
When you edit PID settings, setpoint or gains I would reinit and clear the I term as well as the digital filters for all PID.

Yes it does seem like a software bug, but it does seem to work ok if you get the gains right at a certain setpoint, but then if you change the setpoint it does the same sort of thing as in the video although not so bad.

In the video when the temperature is dropping from 325°C it the pid should start ramping up the output at 305°C but like you say nothing happens until 296°C which isn't right.

[DavidAlfa]

As I said before, ensure that the delay time is enough. And try other tips.
What are your pid settings?
Try increasing the PID time in setup.h.
Too quick might make this. Try 100mS.
Anyway I don't trust the PID algorithm used. I found so much bugs that it wouldn't suprise that it was wrong.
However my Jbc was perfect, +-3°C in all times.
Enter the debug menu and compare the adc1 with the adc1 raw readings.

Lastly, I can say a lot, but if you don't give feedback, it's useless...

The project is stopped, as I blew my mosfet last week(again) hooking the oscilloscope,  the alligator clip loosened and fell over the connections.
Waiting for new AliExpress mosfets...

This beast heats crazy fast!

[Bozog]

Yeah thanks for that, I will try the pid delay and see what happens. I also tried setting the adc time to 900us, it made no difference. I will do some further investigation tonight, will also stick the scope on there(I'll make sure the clip stays on, oops;) to rule out a hardware issue, you are using the original MCP6002 op-amp I take it?

I can get the iron to stabilise at 300°C with the pids set at around 24 10 0 but as soon as you adjust the setpoint its starts doing silly things.

I also tried turning the filter off in setup.h, that didn't seem to make much difference either.

[DavidAlfa]

Yeah, I'm using all the original hardware.
I don't know right now how the PID time is set in the last update. As I usually play with it... So every update might be different, as this is still in development.
Does it still do the weird behavior of the temp going almost to zero?
I doubt it's a measure problem, the readings look to be clean, no spikes...
The PID decides to keep pushing...and somehow it causes a big hysteresis.

As I said, exactly that happened to me with two tips that had terrible heat transfer. The original fw lied a lot, you set 360 and could reach 380-390, then go down to 330, but always displaying 360!
And, the same: I could set the PID for one temp but changing  it +-50°C made it crazy again, it got worse over few days, until it suddenly died. I didn't even use it for soldering!

[Bozog]

Ok I see what is happening, the adc delay set to 900us does in fact help, the weird behaviour with the temp going to zero happens when it is set to 100us
1. This is a genuine Hakko T12 tip, you can see a slight fuzz @ 900us where the adc is sampled
2. This one is a chinese tip that came with the Quicko, settles much much faster
3. I'm guessing it is easier said than done to sample the adc just before the pwm pulse where the temperature value is more stable, rather than just after?
It still doesn't work very well with the Hakko tip even at 900us, but the chinese tips seem to work fine.

[floobydust]

It's OK to lose a few msec while reading temperature. You have to wait because the heater is still hot and the sensor reading some of that heat, the mosfet to turn off etc.  Or take the reading before switching the heater on.

For S/W development I use a thermocouple simulator. A known voltage source with divider resistors and potentiometer to dial in a desired uV and test software to see how it behaves at the limits and with changes etc.
Could modify it to tolerate 24V (heater) power and then it would bolt up to a T12 controller.

[Bozog]

Yeah it seems it would be better to take the reading before the heater switches on.

I'm just wondering why the chinese tip work much better than the genuine hakko, incidentally the hakko tip also makes a noise maybe it is just defective?!

[DavidAlfa]

So my suspects were close! 300uS seems ok. But we'll have to try more tips to find a safe value. Maybe 500uS.
Your theory would work only in low pwm duties. How do we do that in a 9x% pwm?
If we do so, we will also need to measure the time since the pwm went down. Again, we will have wait.
But it'll be much more complicated. You can't delay the PWM output easily, pwm doesn't work like that.

Actually this is the method:
First, we set the maximum PWM value:   20.000uS period - ( ADC time(~30uS) + Delay time(~300uS) ) = 19.673uS
So at max PWM output we will always have the time for measuring.

This is how a PWM cycle works:
The PWM counter starts at 0, output goes high.
When the counter reaches the value in pwm value register, output goes low and the timer compare interruption triggers.
I use the interrupt to start a secondary counter that acts as delay. When the delay counter resets, automatically starts the ADC conversion.
The ADC conversion ends and generates an interrupt. The PWM is about to start, but we can measure the rest of the values. We start another conversion, just for the voltage and ambient temperature.
The counter continues (pwm off time) until reaching the PWM period register.
The counter resets and a new PWM cycle starts.
By now the ADC should have finished the secondary conversions. It disables, waiting for the next trigger from the delay counter.

This method has the advantage of being easily adjustable. We can modify the delay timer as we wish.
It works totally isolated from the main program, so it's much safer. A mistake causing a stuck loop won't leave the pwm calculation unattended, risking at burning your tip.
The max PWM will be 98.3%. It's ok! I can tell you that the stock fw, even the original PTdreamer one, heat slower because they take a lot of measurements and use higher pwm frequency.

Also, as we take measurements every 20mS, it should be pretty stable. What could be the max temperature variation in 20mS? Maybe 5ºC?
The only issue here is the delay. As you can see in the waveforms, it gets perfect after 300uS or even less depending on the tip.

Maybe we could add a second transistor and switch the heater to ground to quickly discharge the output. As long as we wait enough time to not  shoot-through...
But again, why that much if we only need to wait!
The Hakko probably has higher inductance, mainly due the use of thicker heating elements and more turns?

[Bozog]

The trouble is, it still doesn't work right at 900us with the hakko tip because even then the temperature reading jumps +20°C when the output goes to 0%

Maybe there is a hardware fix to remedy this, but I haven't thought of what it is yet, I did try a flywheel diode on the element but it made no noticeable difference

Edit: an easy way to get the hakko tip to work better would be to have a minimum pwm duty of 1%

[DavidAlfa]

Are you telling that this only happens with the Hakko?
Try to get some waveforms with the tip off, ex. set the temp to 400 and then suddenly set it to 200. To see what the TC output is.
Did you set the PID time higher yet?

[Il_Marco]

Maybe adding 1MOhm pullup resistor that some ksger PCB have at the TC input would help in any way to stabilise TC reading faster?

[DavidAlfa]

I didn't notice before. It's the amp output, right?
Can you check at the heater pin? Or the mosfet source, whatever is easier.

[Bozog]

Yes only the genuine hakko is a problem, the chinese tips work nice. With the hakko the slightest overshoot which puts the output at 0% sets it off in a vicious cycle because of the temperature drop when the pwm restarts. Haven't tried the pid delay yet, haven't had much time to play with it tonight

Yes I have been measuring the opamp output!

4. chinese tip @ opamp o/p for reference to previous ss
5. chinese tip @ opamp o/p, while switching from 0% pwm to pwm on, you can see there is a slight increase in temperature - reducing the risk of overshoot.
6. hakko tip @ opamp o/p, while switching from 0% pwm to pwm on, you can see there is a significant drop in temperature, which of course over ramps the pwm and causes overshoot and hence vicious cycle.

Can't remember which way around 7 and 8 are, but these are across the heater (still with flywheel diode btw), but you can just see a slight turn off negative voltage spike in one (the hakko I guess) I'll try without the diode tomorrow.

The hakko tip seems to have some sort of capacitive effect going on.

and yes tomorrow I will see what happens with a 1 meg pullup too.

note: 0v is at the bottom on the first 3, and in the centre on the last 2

[DavidAlfa]

Hmm definitely weird. Tomorrow will try setting the min pwm to 0.5% or so.
But I'd like to understand the cause.

[Bozog]

Hmm definitely weird. Tomorrow will try setting the min pwm to 0.5% or so.
But I'd like to understand the cause.

Yes, me too, I am guessing the opamp doesn't much like negative voltage spike from the heater, further investigation required.

On a side note I think the opamp protection diode D1 in your schematic must be a 3v3 zener to protect the opamp input from the heater 24v