-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Made changes to enable high power output #5
base: master
Are you sure you want to change the base?
Changes from all commits
e4732b0
b5ed3de
b96ebd8
12af161
b4c83aa
e8df2f3
013b607
11c9108
c292649
2c8cdbe
def71f5
f819793
0459449
f023445
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,6 +39,7 @@ class Menu : public Screen { | |
ITEM_ADVANCED_MODE, | ||
ITEM_FAHRENHEIT, | ||
ITEM_LEFT_HANDED, | ||
ITEM_HIGH_POWER, | ||
ITEM_TOTAL_ENERGY, | ||
ITEM_HEATER_POWER, | ||
ITEM_HEATER_CURRENT, | ||
|
@@ -88,6 +89,13 @@ class Menu : public Screen { | |
0, | ||
MenuItem::ItemType::VALUE_BINARY, | ||
true, | ||
}, { | ||
"High power:"; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. comma There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ooh, good catch, thank you. But honestly, if we agree that it is better to automatically detect power levels (which I think also, I just hadn't figured out how so I was forcing it with a menu), then all these code changes would go away. The only change required would be to heating.hpp and screen/main.hpp (for the power bar). Settings.hpp and screen/menu.hpp could be unchanged from your version. But, if the intent is to add RTPico tip function, then we cannot auto-detect this, as they have the same resistance as RTM (I think that's correct?). So you would have to have a setting for RTM vs. RTP to change the PIDs used, if new PIDs are developed for all three tips. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, detecting RTM vs RTU is easy, but RTM vs RTP is also possible, RTP tips are very small and my idea is to somehow provide "heating speed" parameter from PID regulation loop, this can easily identify TIP type. but currently it is only idea, I have no practical researches about this ,-) Another idea is to select right tip from menu and all these mechanisms can only stop heating if some detection will say something else. Also RTM and RTP tips uses same parameters (40W/12V/2ohm) so there is no problem.. ok one, RTP tips require little different PID constants. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would much much prefer to be able to switch between RTU and RTM and not have to worry about going into menus to make changes. But I also don't intend to use RTP tips very much, if at all, it's just not the type of soldering I do. But, I think, if there will be different PIDs for RTP and RTM, then that could be a boolean setting in the menu. I suspect it's pretty unlikely that someone would be switching constantly between RTU, RTM, and RTP all at the same time. Probably more likely to use RTU/RTM together as needed, and then RTM/RTP together as needed. In my mind, RTM is still the primary tip, and RTU or RTP are for situations where the RTM doesn't have the right features. So at least if one of the parts can be automatic, that would probably make life easier for some folks. And then if you figure out a way to automate detection of the RTP/RTM, then that can be added, too. But that stuff is way above my skill level, haha. |
||
mullptr, | ||
0, | ||
0, | ||
MenuItem::ItemType::VALUE_BINARY, | ||
true, | ||
}, { | ||
"Total energy:", | ||
" Wh", | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RTU tip has normally 3.5ohm, it is OK if upper limit is 4ohm, but i suggest to set also MIN for RTU, to warn, or make fallback switch to RTM if there will be something less than 2.5ohm
in general it is possible to automatically select the right tip with resistance measurement
what is your opinion?
because if you select high power and then you insert RTM then you immediately broke it.
so option one: write message that is 'shorted' or fallback to RTM power limit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, there is a max resistance for the RTM tips. So the logic checks whether it is between min and max of the RTM (1.5 - 2.5 ohm). Then it is RTM. If it is below 1.5 ohm then it is "low resistance" and essentially an error state of some sort. If it is over 2.5 ohm, we can assume it is RTU, so it sets RTU, UNLESS it is higher than the RTU max (4 ohm) in which case we call it "high resistance" which I understand to also be an error state.
If we added an RTU minimum, then the only new functionality it would allow is to detect an error state in between the two types of tips. So, do we think it is likely that we will see a resistance in between 2.5 and 3 ohm and want to declare that an error state? Our ranges for resistance are arbitrary (RTM is about 2ohm, so we capture anything from 1.5 to 2.5, and then I did the same for RTU, from 3 to 4). But if an RTU tip read 2.9 ohms, would we want it to declare an error, or just run normally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for selecting high power when a RTM tip is inserted, my understanding is that resistance is detected on every clock cycle (that's how I am reading the code, every "tick" is a cycle, is this correct?) that PWM is off, and max power is adjusted the very next clock cycle. So we would very quickly detect that it was an RTM tip, and adjust power limit accordingly, and my assumption is that this wouldn't cause much, if any, damage.
I also set the code so that when the tip is "unknown" (when we first power up the iron, before it runs, it cannot detect resistance), the power limit is 150mW, which isn't even high enough to get the iron warm. But it's just enough power that the iron can detect resistance, and then it adjusts power level. This way, like you said, it won't put full power to a RTM tip (or a tip where it can't tell what it is). Perhaps I can think of a way to always do that on the first cycle when you start heating. That way no matter what, max power will be 150mW until the iron knows for sure what tip is installed.
In my mind there are two ways to do this. We could do it at the beginning or the end. Either very time the "start" routine is called, the iron is set to TipType "UNKNOWN" so that it is forced to 150mW until resistance is confirmed. Or any time the "stop" routine is called, we set TipType to UNKNOWN. Then the routine will immediately determine tip type and continue to function. Then when the user stops the iron, it will remember what type of tip is connected until they start heating again. This could be useful if we, for example, replace the voltage drop display (I don't personally find this useful, maybe it's good for debugging?) with the tip type instead, so a user knows what is detected on their iron (in case they were confused or forgot which tip was which). But once you start you will never accidentally feed 150W to a 40W tip, even for a microsecond.
I will see if I can add this to the code, I don't think it will be too difficult, should just be one line of code, in state_start() or a similar routine, maybe in main.hpp. I will look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RTU can have between 3 and 4ohm, if it will be less (e.g 2.9ohm), then it is a problem, because at 24V it will have peaks higher than 200Watts
If someone find RTU tips with less than 3ohm, we can discuss this again, but now I think it is clear
about detecting resistance: YES I checking resistance in very fast loop when is PWM in ON state, then I immediately react on low resistance or too high power and PWM is stopped immediately in microseconds - reason why PWM is driven by SW and not HW PWM peripheral.
Later I try to draw image where I explain heating principle, but be sure, that detecting resistance is possible in microseconds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I assumed it happened super fast since it was basically every clock cycle. I highly doubt that applying 150W to a 40W tip for that short a period of time (if it even achieved that high power that quickly) would cause any serious damage.
But last night I did add a line to the _state_start() routine where all the variables are reset to zero that also sets _tip_type to UNKNOWN. So basically every time it starts the heating cycle it redetects the tip type and until it does, the max power is 150mW. I'm not sure if running that routine constantly might have an effect on the pid loop (since I think that means it will constantly be set to a max of 150mW and then back to 40W or 150W?). I ran my 40W tip yesterday to test it, and it seemed like the temperature settled one or two degrees low. I can't remember if it did that before, but I don't think so, if anything it was a couple degrees high before.
As for the resistance, you make a good point. I will establish a minimum as well so that a resistance below 3ohm but above 2.5 will register as an error state and neither RTU or RTP. That is an easy change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see this before. Yeah, I suppose instead of being set to RTU when the resistance is over 2.5, it could be set as RTU when resistance is over 3. This would expand the range of RTM though and might miss an RTM tip that was failing and had a high resistance (does that happen when they fail? I assume it does). I don't know how quickly the resistance increases but if we have the error state in between we might catch a failing RTM instead of putting 150W into it and very quickly destroying it, maybe causing more damage to something else.
So I think you were right the first time, have a gap between the two types of tips that is accurate to how they are really built.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also in the check_tip_type(), this will allow a tip type of "UNKNOWN" if the resistance is in between the two, because this is true, we don't know if it's an RTU tip with low resistance, or an RTM tip with high resistance. And since it is declared as UNKNOWN in this case, the max power output will be 150mW which is very safe, even if the rest of the code allows the heater to receive power anyway.