CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

The problem here is that screen processing is very fast, so you won't acumulate 2 steps, it'll process them almost in real time.
Instead of hacking around, apply the time diff method to the encoder functions, increasing the steps by 2 instead 1, that will trigger the big step in the widgets processing .
Well, before modding widgets.c, I changed it few weeks ago. I'll revert some code to make it work, let me check that tomorrow.

[Cuboy]

The problem here is that screen processing is very fast, so you won't acumulate 2 steps, it'll process them almost in real time.
Instead of hacking around, apply the time diff method to the encoder functions, increasing the steps by 2 instead 1, that will trigger the big step in the widgets processing .
Well, before modding widgets.c, I changed it few weeks ago. I'll revert some code to make it work, let me check that tomorrow.

It's more like 1 fast- 2 slow- 1 fast kind of thing. If you want them to accumulate over a period of time, it's just increasing the time differential so when a fast increment is detected, the next ones are also read as fast increments, so it will be more like fast-fast-fast-some time-slow.

Will wait for tomorrow and see what is reverted.

It's a little bit hacky in the sense that I'm taking the existing code (rotate increment with a click) and using it in my case. I'm not doing much.

I see what you're saying, you want incremental changes to be "constant", so when a big increment is made, all the next increments are big increments until timeout. Will play with it a little more and see if I'm able to make it.

Thanks.

[DavidAlfa]

What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.

I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope
Keep it up

[Cuboy]

What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.

I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope
Keep it up

I got it there, or almost there, I just need to tweak some things and it will be it.

Surely the video of the example helped a lot.

Thank you, at least i understood i was doing it the wrong way.

[Cuboy]

What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.

I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope
Keep it up

I think now it's on point, much better than before.
It behaves just like in the video.

https://youtu.be/w0nZCK7B-0U?t=1382

[Tugo]

Nice testing
Huh, why do I remember everyone complaining with the 1q0 pid settings?

Thank you. I finally did something good 

What did you mean by "1q0 pid settings"? What is that?

[DavidAlfa]

110* 
Before It was 40..60 kp or something like that.
People complained about stability issues after that.

[Tugo]

110* 
Before It was 40..60 kp or something like that.
People complained about stability issues after that.

Aha, ok 
But it wasn't me complaining. I have different PID settings for different tips. In case I will have time I will check the one with the lowest Kp that wasn't working above 50... or even 45. It is a tip problem. At least on mine!
I followed your advise on how to set PID settings and it worked great so I didn't even try default settings just the ones I tested that worked for me.
That is even why I suggested PID settings to start with are 45-0-0 and do that for every tip you have.

[DavidAlfa]

Added big step support at the encoder / widget core  level (Like it was ages before).
I had to remove that and use the click and rotate thing because I had found some kind limitations back then. I don't remember why. Or maybe a very silly mistake .
This firmware has had a lot of back and forths due that. First hittting a wall, remove/disable the feature to keep it working, and then restore the feature when the workaround was found.

Cuboy, your way depends on how quick/often the screen is processed, so it might behave differently in 36MHz and 64MHz speeds, also it will only work in the main screen.
Now everything in the system works that way. I must confess I never liked the click and rotate thing...
I committed directly through the web while I figure out how to make git working again.
Simple user/password was deprecated and git token is not working for me, neither ssh keys.

Check out the commits:
widgets.c
rotary_encoder.c

[Cuboy]

Added big step support at the encoder / widget core  level (Like it was ages before).
I had to remove that and use the click and rotate thing because I had found some kind limitations back then. I don't remember why. Or maybe a very silly mistake .
This firmware has had a lot of back and forths due that. First hittting a wall, remove/disable the feature to keep it working, and then restore the feature when the workaround was found.

Cuboy, your way depends on how quick/often the screen is processed, so it might behave differently in 36MHz and 64MHz speeds, also it will only work in the main screen.
Now everything in the system works that way. I must confess I never liked the click and rotate thing...
I committed directly through the web while I figure out how to make git working again.
Simple user/password was deprecated and git token is not working for me, neither ssh keys.

Check out the commits:
widgets.c
rotary_encoder.c

That is something I didn't understand yesterday, but now it makes sense, the higher the frequency of the screen is processed, the faster you will need to rotate to make a big step (Is that right?). And yes, it would only work for the main screen.

In the code, there's something i dont understand which is abs(state->Diff) > 1, what is exactly that?
The code in rotate_encoder.c is almost the same logic as I used (You're using the last step, which is pretty much what I was trying to do).

Trying this new build works the same as it did before which is nice. And now we have fast encoder rotation for everything.

As you see, in the click and rotate thing i just made few lines of code, not much. It was just the hours going around the code trying to understand what was happening.

Thanks.

[DavidAlfa]

Re_Get function computes how many steps have passed since the last call and writes it to Diff var.
That way you won't lose steps if the processing is slow.

Diff can be positive or negative, depending on the direction.
I need to know the step number, regardless of the direction, that's why abs  (absolute) is used.
Check rotate_encoder.h for RE_State_t structure description.

Yes, there aren't many other ways.. store the time and compare it, nasa science
You don't exactly know how often the screen update is called,  the screen drawing will take more or less time depending on the widgets, causing a lot of jittering.
You needed 80mS because the whole screen is dma-erased and redrawed when the main screen is changed, it's faster than clearing and redrawing each widget, and needs to be done because some widgets slightly overlap, so updating only one would partially erase other nearby widgets.
But if I changed or removed a widget, that time would change, also if the CPU was faster or lower.

Working at the encoder level, you know it's called every 1mS, no matter what.

[Cuboy]

Re_Get function computes how many steps have passed since the last call and writes it to Diff var.
That way you won't lose steps if the processing is slow.

Diff can be positive or negative, depending on the direction.
I need to know the step number, regardless of the direction, that's why abs  (absolute) is used.
Check rotate_encoder.h for RE_State_t structure description.

Yes, there aren't many other ways.. store the time and compare it, nasa science
You don't exactly know how often the screen update is called,  the screen drawing will take more or less time depending on the widgets, causing a lot of jittering.
You needed 80mS because the whole screen is dma-erased and redrawed when the main screen is changed, it's faster than clearing and redrawing each widget, and needs to be done because some widgets slightly overlap, so updating only one would partially erase other nearby widgets.
But if I changed or removed a widget, that time would change, also if the CPU was faster or lower.

Working at the encoder level, you know it's called every 1mS, no matter what.

Well, we managed to get it working so great job

Now I need to find something else to put my head into, do you see anything that needs changes or could be better implemented? Btw closed the pr request.
As per temperatures, have you thought of anything? Do you have enough feedback to make changes or still?

[DavidAlfa]

I don't feel it's been tested enough...
Though you and Tugo did a great job, I need the same thing from more users.
By the other hand, others say they've been always happy with the settings.
See the problem here? This is plain stadistics, and I have very little feedback to get something clear
Otherwise the mindfucking will continue. Have you seen how many builds and commits are out there just for testing?
If I keep that route something's gonna explode in my head  .

[Cuboy]

I don't feel it's tested enough yet...
Though you and Tugo did a great job, I need the same thing from more users.
By the other hand, others say they've been always happy with the settings.
See the problem here? This is plain stadistics, and I have very little feedback to get something clear
Otherwise the mindfucking will continue .

Let's wait then.

If anyone wants to see some feature or has any suggestion please ask for it, I will be glad to try and implement it.
I'm really happy we got fast-slow rotation, seems like a great feature (even though David didn't like it at first, he wanted clicky rotation  )

[DavidAlfa]

It wasn't that I didn't wanted it. I was just burned out, not willing to spend a single minute on that 

[Tugo]

What are you 2 doing with slow/fast rotate?! 
I guess I will have to DL, compile and see for myself   

David, yesterday I forgot to write down something it was in my head (I know that also happens  ): is it possible that somebody could be having problem with spikes because of a switch power supply on the PCB and/or something that has to do with a power supply on the board? I have Ksger but I don't have problems and my PCB has linear power supply. Could that be a case here?

[DavidAlfa]

Anything can happen, but how am I going to know?
To develop a firmwar both developer and testers need a decent level of knowledge.
If certain people are geting noise, while others doesn't, the next step is looking at the signals to find out what's going on.
Ex. comparing waveforms from ksgers stations behaving different. I can't do that for you guys.
Sure, I can try different filtering methods, but it's purely based on trial and error, very slow and time-consuming.

[wickated]

i guess 08-11 is with so-called old pid ?
so i set to
default filter 75%
10/0.1/x2
120/100/2/0.5/-1
no overshoot on liftoff, fast recovery, fast startup. almost double of the speed when tinning coin (near 7seconds, metcall level of power delivery!) 

bug with stand mode is so hard to catch, just added rc. i guess there is some timer related thing that overlaps 500ms timer of stand pin reading, cuz it should wait for 500ms pin state, but sometimes it beeps very very fast twice or more and bug occurs. there is even no jbc users here so i wont ever bother 

maybe i tweaked pid a bit wrong but it works ok and reliable. much better than old defaults of 20/5/2 or smth

p.s. no noise with up to 10% filter

p.p.s my big donut transformer is on delivery now, so ill build very new station soon with cool big gx20 plugs for reliable connection. ksger based board for sure 

[DavidAlfa]

I tried the new pid again. Definitely not putting it back, adjusting it is **** difficult, extremely sensitive to tip changes, the old is much easier to tune.
The spikes and such are usually filter-related, but also high KD will cause them.
This time I tried a different adaptative threshold filtering, which helps with the noise but also with fast temperature trasients.
I'm actually pretty happy with it, heating up from cold to 360 hits 363-364 and goes down to 360 peacefully.
Of course, here the people will report wild stations attacking the user and running around the room!
I'm still unable to use Github... Will make test builds and upload them here.

[Cuboy]

I tried the new pid again. Definitely not putting it back, adjusting it is **** difficult, extremely sensitive to tip changes, the old is much easier to tune.
The spikes and such are usually filter-related, but also high KD will cause them.
This time I tried a different adaptative threshold filtering, which helps with the noise but also with fast temperature trasients.
I'm actually pretty happy with it, heating up from cold to 360 hits 363-364 and goes down to 360 peacefully.
Of course, here the people will report wild stations attacking the user and running around the room!
I'm still unable to use Github... Will make test builds and upload them here.

Use github desktop, more easy, just clone and ready to play with it.

[DavidAlfa]

Use github desktop, more easy, just clone and ready to play with it.

I know, but I used the integrated eGit module until now ad I liked it a lot more. Cloning doesn't require user login, the problem comes when commiting.
I think I finally found decent pid/filter values, most people might not realize how hard it is, this time it took 4 hours between setting the pid, new filters and debugging/finding good values!

Edit:
After the 5th... 6th time... I lost the count... finally the damn thing started working with my git user token!
I was about to...

I added +0.5ºC to the user setpoint to make the display more stable. Ex. 350ºC->Set adc for 350.5ºC
The display will show 350 between 350.0 and 350.9, reducing a lot the dancing between 349 and 350ºC.

New builds available!

(Flies away )

[AndyC]

Nice! Tested on the KSGER 3.1. PID and filtering works with standard settings.
Found something though, after exiting the debug screen, the setpoint remains the debug screens setpoint.
The graph does not follow the setpoint either, see pictures.
Also I got an error: "settings.c line 125"

More testing tomorrow, good night.

[DavidAlfa]

Yep, my fault. It exited to settings screen before, now goes to main, and there was a check I forgot to update.
That error means there was no free memory left to allocate a buffer to save the settings.
The checking issue also caused a memory leak, not freeing up the pid plot buffer on exit, so if you entered 3-5 times to the debug screen, it probably ran out of memory, causing the error.
For 32F103, I need to enter debug screen ~35 times for that error to happen, I would never have that issue unless I had a very long day debugging!

Don't use the debug screen for now, it's already fixed (or I think so) but I'll wait for more feedback before making new builds.
You can't imagine how useful the error reporting feature has become

[Cuboy]

Yep, my fault. It exited to settings screen before, now goes to main, and there was a check I forgot to update.
That error means there was no free memory left to allocate a buffer to save the settings.
The checking issue also caused a memory leak, not freeing up the pid plot buffer on exit, so if you entered 3-5 times to the debug screen, it probably ran out of memory, causing the error.
For 32F103, I need to enter debug screen ~35 times for that error to happen, I would never have that issue unless I had a very long day debugging!

Don't use the debug screen for now, it's already fixed (or I think so) but I'll wait for more feedback before making new builds.
You can't imagine how useful the error reporting feature has become

Can you post a photo of your debug temperature screen? Just to see how stable is for you. I'm testing it.

Can you change fast increments to 10º and slow ones to 1º by default? I think that's better than 20º and 10º.

[DavidAlfa]

Sure, that's a simple thing.
Asking that, let me guess... are you getting spikes reaching nuclear fission temperatures?

About my debug temperature screen:
360ºC, SET=1790
AVG oscillates between 1787-1793, staying at 1790-1791 most of the time.
RAW (unfiltered) continually moves between 1782 and 1797.
PID plots are completely flat once the temp is reached.