search

Ralim / IronOS

Open Source Soldering Iron firmware
https://ralim.github.io/IronOS/
GNU General Public License v3.0
7.28k stars 723 forks source link

iron heats up in `[S and O]` - mode without being moved #696

Closed discip closed 3 years ago

discip commented 4 years ago

This is a [Bug Report]

Thank you in advance kind regards

Ralim commented 4 years ago

@discip

You are on the right track for the movement timer. If you sit the unit stationary the movement timer should not updated. its the timestamp as of the last movement, so whenever you move it should update; and when the unit sits still it should stay static.

If Auto start is set to either S or O, the iron should start heating up only, if it gets moved.

In S mode iron should heat up to sleep temperature, then when the iron is moved it should jump to the final temperature.

Out of curiosity, are you plugging in the unit while holding it and then setting it down - or are you powering up a power supply that would not cause cable movement?

discip commented 4 years ago

@Ralim Good afternoon, Yes, I am aware of the behavior of the S mode. I put the iron stationary and I am very careful about the cable as well, so there is no movement, that could trigger the accelerometer.

paulfertser commented 4 years ago

@discip so what Move values are you seeing? I have "20" here if I'm trying to be a bit careful when giving it the power and checking right after it boots. Both S and O work as expected. But it's on TS100, not TS80. Also, what sensitivity do you set it to?

paulfertser commented 4 years ago

The Move value shown is the timestamp of the last movement detected. So no wonder it's related to the time.

paulfertser commented 4 years ago

@discip , please enable "detailed soldering screen" and "detailed idle screen" and retry.

discip commented 4 years ago

@paulfertser I am seeing different values dependent on the model.

I am using the detailed screen for both. - TS80P TS80
values 13 & 20 37, 39 & 46
sensitivity 7 7
paulfertser commented 4 years ago

So you plug it in and it goes to full soldering mode right away, without showing Sleeping etc, do I get it right? Also, do you have logo enabled (I do). And what are your sleep and standby timeouts?

discip commented 4 years ago

@paulfertser No, it does not go to full soldering mode right away. It first shows "Sleeping ..." and almost immediately after that starts to heat up.

On the TS80 there is no logo, but I have never changed anything regarding the logo, I only flashed @Ralim's. firmware.

On the TS80P there is a logo.

paulfertser commented 4 years ago

For me it also shows Sleeping... and starts to heat up to 150 C (which I set as sleeping temperature in the settings) and it continues to show Sleeping and to keep 150 C. That's in Auto S mode. To what temperature does it heat up for you?

discip commented 4 years ago

I am mostly concerned about the O mode, since it is the mode I use. And in this mode it should keep sleeping, until it is moved.

But the S mode does not work for me either, because it heats up even beyond the configured sleep temperature.

One more thing is, if the S mode is selected it should display Sleeping ... and heat up to the desired sleep temperature in the background.

paulfertser commented 4 years ago

@discip, thank you for the clarifications. For me O mode doesn't start heating at all, and S mode heats up just to 150 C (which matches the settings), in both cases after power on I see "Sleeping..." for as long as I do not move the iron. I also have logo enabled which might probably make a difference (by adding a few seconds delay at the startup). And probably my TS100 vs. your TS80 is also playing a role. To sum up, unfortunately, I can't reproduce and thus can't really help, but I hope our conversations helped to clear up the details and probably @Ralim will now be able to see it.

discip commented 4 years ago

@paulfertser Thank you for your investigation and willingness to help.

Kudos for that. Please keep it that way. 👍

Ralim commented 4 years ago

@discip It does sound like your iron is reading a higher vibration than the sensitivity level and therefore thinking that it should exit the sleep modes.

Is this a regression compared to previous firmware versions? I might need to just delay the accelerometer readings to let them stabilise a bit more if so.. 😅

discip commented 4 years ago

@Ralim In terms of stability and functionality it is definitely a regression, at least for the TS80, because this worked flawlessly after @firebie hast solved 'my problem (#571)'. On the TS80P it did not work yet, so I think it is not correct to call it a regression.

Thank you for your time. 👍

Firebie commented 4 years ago

The idea was to pre-fill movement data array with initial accelerometer readings:

        datax[currentPointer] = (int32_t) tx;
        datay[currentPointer] = (int32_t) ty;
        dataz[currentPointer] = (int32_t) tz;

        if (!accelInit) {
            for (uint8_t i = currentPointer + 1; i < MOVFilter; i++) {
                datax[i] = (int32_t) tx;
                datay[i] = (int32_t) ty;
                dataz[i] = (int32_t) tz;
            }
            accelInit = 1;
        }
Firebie commented 4 years ago

Wrong idea, checked wrong commit :-(

discip commented 4 years ago

@Firebie I somehow knew, that i could count on you. 😁

Kudos for investigating on that! Highly appreciated! 👍

Is there any chance, of checking, if your assumption is right? 😉 I would love to test compiled versions of firmwares, which were alternated in the way you suggested! (If only I knew, what exactly has to be changed!) 😩

Firebie commented 4 years ago

Try this: TS80P_EN.hex.fix.1.zip

discip commented 4 years ago

First of all:

Thank you!

But unfortunately this did not solve the problem. 😔

discip commented 4 years ago

@paulfertser I know it is off topic, but since this is not crucial, i did not want to open a new issue on that. It is about the blinking frequency of the 'scroll bar': To me it seems somewhat hectic. 😅 Would this take much effort, to make it slower?

Firebie commented 4 years ago

Try this: TS80P_EN.hex.fix.2.zip

discip commented 4 years ago

No, this did not work either. Now even the Sleeping... on power up is gone. Just to verify we are talking about the same: I am testing, having the 'O' mode enabled.

Firebie commented 4 years ago

Ver 3: TS80P_EN.hex.fix.3.zip

discip commented 4 years ago

Nope, sorry sir, but still not there. But it shows now the Sleeping... again.

Firebie commented 4 years ago

Just to be clear - it shows that it sleeps, but heats up to normal soldering temp?

discip commented 4 years ago

Yep! And all that, without being moved!

Thank you again for working on the solution for this!

Unfortunately I have to go to bed now. 🥱 So testing will be resumed tomorrow, if you are still willing.

Firebie commented 4 years ago

When it shows sleep, it has to show also current tip temp. Which tip temp it shows in your case?

discip commented 4 years ago

@Firebie Sorry, unfortunately I have to revise my last answer from yesterday. 😔 It clearly was to late. Despite having read you post twice, I misunderstood your question. The correct answer is: It shows Sleeping... on being plugged in, but shortly after that, skips it and starts heating up (without the Sleeping... indicator).

The tip temp is 26°C.

thanks & kind regards

Firebie commented 4 years ago

Ver 4: TS80P_EN.hex.fix.4.zip

discip commented 4 years ago

@Firebie

You are incredible!

For O mode this works at first glance. Let me test it on different scenarios and then I will report back.

ps: Could you please provide the TS80 build as well?

Thank you very much.

discip commented 4 years ago

Sorry I celebrated to early. 😔 Connected to my computer 5V it worked, but for 12V PD it failed.

discip commented 4 years ago

However at least S mode works now as intended. 👍

Firebie commented 4 years ago

Ver 5 (TS80) - delay 2 seconds: TS80_EN.hex.fix.5.zip

discip commented 4 years ago

Refering to: TS80P_EN.hex.fix.4.zip

For S mode it only works, if: current tip temp is greater than sleep temp or if current tip temp is much smaller than sleep temp.

Firebie commented 4 years ago

For sleep modes (stayOff - O mode) we have next code:

            currentTempTargetDegC =
                    stayOff ?
                            0 :
                            min(systemSettings.SleepTemp,
                                    systemSettings.SolderingTemp);
discip commented 4 years ago

Sorry, I do not really know, what I am supposed to do with this information.

What I can say though: V5 for the TS80 works as intended for both modes!

So I propose, to let me test this (V5) on the TS80P as well.

Firebie commented 4 years ago

Ralim was right, we need a delay before we start reading data from accelerometer. In V5 it is 2 seconds. V6 - no changes from orinal code (origin/master) except delay for 2 seconds: TS80_EN.hex.fix.6.zip TS80P_EN.hex.fix.6.zip

discip commented 4 years ago

Thank you @Firebie! 👍

This seems to work! For both 'S'- & 'O' mode & TS80 & TS80P

The only thing I noticed while Sleeping... is active, the iron does delay the negotiation for 12V as well, because it does that a bit later than usual.

Firebie commented 4 years ago

Power check added earlier (before 2 seconds delay): TS80P_EN.hex.fix.7.zip

discip commented 4 years ago

May I ask for the TS80 build as well? 😊

Firebie commented 4 years ago

Sure TS80_EN.hex.fix.7.zip

discip commented 4 years ago

Sorry for being undecided, but I think it is actually even better, to delay the heat up 'speed' (By delaying the power check.) even after the triggering of the accelerometer.

Because when you pick the 'S' mode you do not want to start soldering right away. So it would be better in terms of wear of the tip (That is why I prefer 'O' mode over 'S' mode.) and in terms of power draw (hence money).

If I am wrong, I am very appreciative for being corrected. 😀

paulfertser commented 4 years ago

It is about the blinking frequency of the 'scroll bar': To me it seems somewhat hectic. 😅 Would this take much effort to make it slower?

Not much effort but the code will get a bit more complicated and less maintainable IMHO. But that's not something for me to judge.

Firebie commented 4 years ago

TS80P_EN.hex.fix.8.zip

diff --git i/workspace/TS100/Core/Threads/MOVThread.cpp w/workspace/TS100/Core/Threads/MOVThread.cpp
index 4ef12c21..355af584 100644
--- i/workspace/TS100/Core/Threads/MOVThread.cpp
+++ w/workspace/TS100/Core/Threads/MOVThread.cpp
@@ -45,6 +45,12 @@ void startMOVTask(void const *argument __unused) {
    postRToSInit();
    OLED::setRotation(systemSettings.OrientationMode & 1);

+   if ((PCBVersion == 1
+       || PCBVersion == 2)
+       && (systemSettings.autoStartMode == 2
+           || systemSettings.autoStartMode == 3))
+       osDelay(2000);

    lastMovementTime = 0;
    int16_t datax[MOVFilter] = { 0 };
    int16_t datay[MOVFilter] = { 0 };
discip commented 4 years ago

@Firebie

Kudos for being so friendly & obliging!

@paulfertser

But that's not something for me to judge.

Neither do I want to arrogate to be able to do so. But, if no one minds, I would like to have it blink slower. So, I am officially making a request for this to be implemented. 😁 Unless somebody has a reason for this not being done.

Since this is solved, I am closing this issue.

Firebie commented 4 years ago

Change for delay for accelerometer has to be review/merged by Ralim first.

discip commented 4 years ago

Yes, I am aware of this. 😊 And I am confidently looking forward to this being done. Are you going to make a PR for this, or is this not necessary?

Firebie commented 4 years ago

Ralim is invited here to review the changes, if they are ok, I will create PR.

Ralim commented 4 years ago

Thank you all, @Firebie solved this before I even got back around to looking into this after work 😅 @discip If you need, you can easily use the artefacts that are generated from the merge for other irons should you need to. https://github.com/Ralim/ts100/actions

discip commented 4 years ago

@Ralim Thank you. @Firebie upgraded my knowledge regarding this topic, after having encountered accelerometer issues last time.