CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

Check process input function in main screen.c
/drivers/gui/screens

Always check ***screen**_setup function, each screen has it's own, where all the handlers are declared.
Not easy because there's a lot of hacking to make the different main screen functions, it uses a custom process input function, overriding the default one.
Otherwise it would be extremely easy.
You won't be able to set sleep/standby modes neither select tips unless you code your own method.
But is not up to me, spend some days studying the firmware and figuring things out.

Let me be clear about this, I can help a bit, but I won't be teaching how to handle every single bit of the code.
Being open source means "as it is", not free unlimited hours of support.

[Cuboy]

Not easy because there's a lot of hacking to make the different functions work, it's not the widget doing the work.
You won't be able to set sleep/standby modes neither select tips.
Check process input function in main screen.c
Drivers/Gui/screens
But let me be clear, I can help, but I won't be teaching how to handle every single bit of the code.
Being open source means "as it is", not free unlimited hours of support.

I know, I will try to do it and see if I'm able to do it.

I need to understand pieces of code still, but thank you anyway.

[DavidAlfa]

Damn, I always hit post instead preview and then someone quotes me before I finish the message

[dark_hawk]

Here's is your bug report from 6 days ago:

The one before 11-8:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3623522/#msg3623522

The 31-07:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3623645/#msg3623645

[Cuboy]

Damn, I always hit post instead preview and then someone quotes me before I finish the message

I've been looking at the code for a little.

Is Widget_SetPoint the widget where the temperature is drawn?

Thanks.

[tatel]

Some people doing drama, deciding to go away, should realize they're hurting themselves, I don't need help for fixing my own for my own station, and I don't care about bugs for features I don't use (That's why these bugs happen), it's them who aren't going to get any fixes

Still cheating yourself... please note that just two persons noticed the regression, and only one bothered to reinstall an old FW version and posted the pictures that show you were wrong. If not for that, you'd be still chasing your own tail. So maybe you should think again who is hurting not just himself... this is the main reason that convinced me I'd be better doing it my own way.

It's easier to deal with C pointers than to deal with a guy unable to acknowledge he could be wrong.

[DavidAlfa]

Damn, I always hit post instead preview and then someone quotes me before I finish the message

I've been looking at the code for a little.

Is Widget_SetPoint the widget where the temperature is drawn?

Thanks.

Yes

[Cuboy]

Read the *** operation guide .
I really hate those silly questions everytime because lazy people don't want to read!
Rotate while pressed to use big step.

My bad, I skipped that line it while reading through it for the 3rd or 4th time but I'm glad the feature was already there so thanks for that.
Gotta say though, if I could blow as much hot air as you do on a regular basis, I wouldn't need a soldering station.

Your suggestion was added for the temperature increments, i'm waiting for David to review it.

[wickated]

located "stand only" bug
happens when i change tip with jbc stand so both stand and no iron are triggered. i know, there is no additional pin for tip change shutdown.

[DavidAlfa]

Nice work Cuboy. I already answered your pull request so you fix a little thing.
Wickated, and what happens next? Goes into standby instead of run mode?

[wickated]

Wickated, and what happens next? Goes into standby instead of run mode?

yep, cycles through instasleep(on stand)-stanby instead of stanby-run. encoder dont pull out of this state.

[DavidAlfa]

Encoder doesn't wake the station in stand mode, it wouldn't make sense.
But should be able to force standby/sleep modes. Neither does when the bug happens?

Btw, cheap clone jbc handles are just crap. They can't stand that power.
Check ou how the contacts have become purple/blue... They made that shitty cut downs, causing hot spots.

[Cuboy]

Nice work Cuboy. I already answered your pull request so you fix a little thing.
Wickated, and what happens next? Goes into standby instead of run mode?

Added the little fixes, i was wondering why the signs weren't showing correctly at the end, that's why...

[DavidAlfa]

I didn't test the code, just saw it, like in The Matrix... and told you the issue 
I thought it would be better that you learned a bit how it goes, and finished your own work 
The current code is a lot cleaner and much more intuitive than before!
I think anyone with some C knowledge should be able to easily mod it.

Remember that screens are dinamically created and destroyed. You won't see the real ram usage at compile time.
So when adding a new screen or adding widgets, you should debug the memory allocation.
You have a define in main.h to enable that. After that, add the variable max_allocated to the variables watch window or live variables.
It holds the max ever allocated value since system boot. Run through all screens, menus, and then check the value.
You can also check the current allocated memory by reading mi.uordblks.
They get updated afer every malloc/calloc/free call.
The system reserves 4KB for the heap. The current heaviest screen is system, with 1.83KB usage.

[Cuboy]

I didn't test the code, just saw it, like in The Matrix... and told you the issue 
I thought it would be better that you learned a bit how it goes, and finished your own work 
The current code is a lot cleaner and much more intuitive than before!
I think anyone with some C knowledge should be able to easily mod it.

Remember that screens are dinamically created and destroyed. You won't see the real ram usage at compile time.
So when adding a new screen or adding widgets, you should debug the memory allocation.
You have a define in main.h to enable that. After that, add the variable max_allocated to the variables watch window or live variables.
It holds the max ever allocated value since system boot. Run through all screens, menus, and then check the value.
You can also check the current allocated memory by reading mi.uordblks.
They get updated afer every malloc/calloc/free call.
The system reserves 4KB for the heap. The current heaviest screen is system, with 1.83KB usage.

That's a nice hack right there, thank you! 

[wickated]

Encoder doesn't wake the station in stand mode, it wouldn't make sense.
But should be able to force standby/sleep modes. Neither does when the bug happens?

enocder also shifts to stanby-sleep only

[DavidAlfa]

What do you expect shifting to? You should already know he encoder ledt-rotation it's  for entering low power modes.
You can't enable any higher power mode with the encoder while in stand mode, in any case you need to remove the stand.
If the sleep/standby timer expired while the handle was put, you need to put the handle in for a moment to reset the state.
You are not supossed to use low timeouts for stand mode, that's more like a safety timeout, as you normally put the handle in and out all the time.
If by any reasons the handle is forgotten or doesn't make contact with the stand, the timeout will be still counting, entering sleep/standby.

Stand mode works perfectly here. I can remove and put the tip a thousand times.
Of course, it goes into sleep when there's no tip, showing NO IRON error.
Do you want to exit sleep mode when you dont have tip? Does that make any sense tyo you?
It returns to normal mode when the tip it's plugged back.

Please take seriously what I said, make proper reports. Not just "hmm it does something strange".
Test it, what, when and how it happens and then report. Otherwise I'm gonna start blowing hot air again .

[Cuboy]

The only usability feature I'd like to see is when turning the encoder fast, I want it to make bigger steps for numerical values. Ie: if I turn the encoder at less than 5 clicks/sec then it increases by 1. If it's faster than that, then it increases by 10. IMO, it would help a lot when manually entering calibration values.

Do you like the feature? Any feedback?

As per testing the new version (which none of the core code has changed) I see that testing temperature plot, with BC3 it's a little spiky (that is in 450ºC), less stable, even at 320º or 180º you can appreciate some oscillations. For me, the "new PID" algorithm was on point, what is the feedback of other users regarding the new PID algorithm? I have seen some comments here that it was less accurate and had more spikes but for me it's inverted.

Logically, it would make sense that new PID is better than the old PID, because it has more accuracy. More variables are taken into count, which makes much more sense. But I could also be wrong, I don't really know.

Take this as an opinion, i don't care about accuracy as long as it works, we're talking about constant 4-degree oscillations at max power (450 ºC).

[DavidAlfa]

Stop blaming the pid, there were a lot more changes in filtering, also in the PID values. You can have 100 pid algorithms, all will do terrible with the wrong settings.
I won't move a finger until you all test the other versions and propery report which one worked so amazingly well.

[Cuboy]

Stop blaming the pid, there were a lot more changes in filtering, also in the PID values. You can have 100 pid algorithms, all will do terrible with the wrong settings.
I won't move a finger until you all test the other versions and propery report which one worked so amazingly well.

Okay okay testing testing.

[Cuboy]

Tested version 10-08-2021

Cal settings are the same in both actual version and 10-08-2021.

250: 1110
350: 1799
450: 3500

The image is from 10-08-2021 version

Honestly, i tought it was better, but it seems worse.

[dark_hawk]

Tested version 10-08-2021

Cal settings are the same in both actual version and 10-08-2021.

250: 1110
350: 1799
450: 3500

The image is from 10-08-2021 version

Honestly, i tought it was better, but it seems worse.

Test the 31-07 or the 2-8 Please

[Cuboy]

Tested version 10-08-2021

Cal settings are the same in both actual version and 10-08-2021.

250: 1110
350: 1799
450: 3500

The image is from 10-08-2021 version

Honestly, i tought it was better, but it seems worse.

Test the 31-07 or the 2-8 Please

Will test right now

Edit: 2021-08-2c  (Last build before switching to new PID) testing

Same cal settings, real temp is 230 while as the other it was around 450.

[DavidAlfa]

Cal settings have nothing to do with the pid. As I said, don't calibrate every version, it's he same thing, just restore the values from a previous calibration.

[DavidAlfa]

Tested version 10-08-2021

Cal settings are the same in both actual version and 10-08-2021.

250: 1110
350: 1799
450: 3500

The image is from 10-08-2021 version

Honestly, i tought it was better, but it seems worse.

That's exactly what pissed me off.
People saying "old was better".
David rolls back. Huh not better.
David restores again.
Hmm old definitely better.
David rolls back again.
No ,not good.
David throws the soldering station 100m alway, crunches the computer table, eyes injected in blood...
Damn it, test the damn versions and stop losing my time!

Try the oldest first. But again, if I only get feeback from 2 people, restore the code, and then I get feeback from 10 guys saying it's worse... 

I'm taking the break now. Will come back in a few days... And see what's going on .