-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
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
Updates for ensure_safe_temperature #6963
Conversation
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.
Is this thoroughly tested? Some of this seems like it simply will not work.
SERIAL_ERRORLNPGM(MSG_TOO_COLD_FOR_M600); | ||
return false; | ||
} | ||
#endif |
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 believe the previous implementation of M600
would start heatup for you and go to the wait-for-heatup screen. Then it would do the same for you if the nozzle timed out and started to cool again. This seems like a step backward to insist that the target temperature already be set at the start, especially as we still have to make sure the nozzle has reached the set temperature anyway and we still have to deal with reheating after a timeout.
So, let's continue trying to restore everything that M600
code used to (or should) do. A lot of good work was done by @petrzjunior and I hate to see it lost.
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.
This was the very beginning of gcode_M600
prior to #6407 being merged:
if (!DEBUGGING(DRYRUN) && thermalManager.tooColdToExtrude(active_extruder)) {
SERIAL_ERROR_START;
SERIAL_ERRORLNPGM(MSG_TOO_COLD_FOR_M600);
return;
}
It didn't check to see if the target temperature was reasonable and if the nozzle wasn't warm enough, it would just bail. That's exactly how advance pause worked prior to the addition of ensure_safe_temperature
. This change adds some additional checks to ensure that the target temperature is above the limit (if there is a limit) and then waits for the nozzle to heat up prior to continuing, which is what you requested in your latest comments in #6407.
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.
Gotcha. I guess when I noticed the temperature suddenly dropping in the middle of M600
I presumed something had been lost. Thanks for making the extra effort!
Marlin/Marlin_main.cpp
Outdated
wait_for_heatup = true; | ||
while (wait_for_heatup) { | ||
idle(); | ||
if (!wait_for_heatup) break; |
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.
This can never happen. The while
statement will already have caught this condition.
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 may be mistaken, but I thought the call to idle()
was to allow the emergency parser to execute. If that's the case, then if the emergency parser sees a M108, then that M108 will set wait_for_heatup
to false, which would immediately be overwritten by the line right after the call to idle()
without this 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 added a new commit to resolve this in a different way that will prevent any possible race conditions or logic errors associated with wait_for_heatup
being reset by M108 in the emergency parser. This should allow M108 to work as desired with M600.
Marlin/Marlin_main.cpp
Outdated
wait_for_heatup = false; | ||
HOTEND_LOOP() { | ||
if (thermalManager.degTargetHotend(e) && abs(thermalManager.degHotend(e) - thermalManager.degTargetHotend(e)) > 3) { | ||
wait_for_heatup = true; | ||
if (!did_show) { // Show "wait for heating" | ||
#if ENABLED(ULTIPANEL) | ||
lcd_advanced_pause_show_message(ADVANCED_PAUSE_MESSAGE_WAIT_FOR_NOZZLES_TO_HEAT); |
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.
We don't want to keep calling this function repeatedly. It should only be called the first time that the code detects that heating is needed.
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.
We can put that back in, but I took it out because the original gcode_M600 function didn't do that for similar calls to lcd_advanced_pause_show_message
:
while (wait_for_user) {
if (nozzle_timed_out)
lcd_filament_change_show_message(FILAMENT_CHANGE_MESSAGE_CLICK_TO_HEAT_NOZZLE);
...
}
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.
Looking at this more closely, lcd_filament_change_show_message
calls lcd_goto_screen
, which first verifies that currentScreen != screen
prior to proceeding. As such, I believe it's relative harmless to call lcd_filament_change_show_message
repeatedly.
@@ -5956,7 +5962,8 @@ inline void gcode_M17() { | |||
nozzle_timed_out |= thermalManager.is_heater_idle(e); | |||
|
|||
#if ENABLED(ULTIPANEL) | |||
if (nozzle_timed_out) ensure_safe_temperature(); | |||
if (nozzle_timed_out) | |||
lcd_advanced_pause_show_message(ADVANCED_PAUSE_MESSAGE_CLICK_TO_HEAT_NOZZLE); |
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.
Where is the logic to wait for the click, turn on the heater, and so on? I can't see how this is supposed to work.
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.
All I did in the original #6407 was split gcode_M600 into three functions, with almost no other changes to the function of M600. If you look in the current gcode_M600, you'll see that the three functions are called sequentially:
if (pause_print(retract, z_lift, x_pos, y_pos, unload_length, beep_count, true)) {
wait_for_filament_reload(beep_count);
resume_print(load_length, ADVANCED_PAUSE_EXTRUDE_LENGTH, beep_count);
}
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 long as it works! I'll have a closer look to make sure I understand what's going on. At some point we'll want to clean up and standardize this LCD stuff more, so I should get a handle on it now!
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 actually want to re-work this section. Currently, after it unloads, it instructs the user to load the new filament. If the heater idle timeout it expires and tells the user to press the button to re-throw. If the user presses the button, it re-heats, but immediately loads the filament when it gets up to temp. This could be confusing if the user wasn't at the printer when the load filament message was displayed, but they get there when the press to re-heat message is being displayed. I went back and I believe this is how M600 worked before #6407, so I don't think I changed anything at this point.
@thinkyhead For some reason, I believe you think I made significant changes to how M600 works in #6407, when in reality I didn't. @Roxy-3D and I throughly tested the changes in #6407 and I believe that any issues that have been found since then were actually issues in the original M600 that carried over into the advanced pause feature because I limited the actual changes to the its function. You might consider revisiting #6407 to see what was actually changed so that we can all be on the same page. |
@thinkyhead Have you had an opportunity to review this again? M600 is currently broken due to the change that was made to
This is where M600 is broken because This PR fixes this issue by reverting |
This does fix the immediate M600 issue. I think it is worth merging because it helps people (myself included) that use M600. It still does not address Thinky's issue that if the nozzle is too cold to do the M600, it gives up and says: [ERROR] Error: M600 Hotend too cold to change filament. The reason I'm going to merge right now is some of us REALLY need M600 to work. This one issue is can be resolved independently of the other issues. In fact... I would put the one or two lines of code in to resolve it if I knew what to do. The problem I have with putting one or two lines in to resolve it is I don't know what temperature is OK. PLA Temps? ABS Temps? The previous hot temp? What makes sense? In the middle of March the code was doing this: inline void gcode_M600() {
if (!DEBUGGING(DRYRUN) && thermalManager.tooColdToExtrude(active_extruder)) {
SERIAL_ERROR_START;
SERIAL_ERRORLNPGM(MSG_TOO_COLD_FOR_M600);
return;
} It was just giving an error and stopping. And with this merge... It does the same thing. Let's continue the discussions on what makes sense. And when we agree... I'll personally do the coding to get it there. But right now.... We need M600 to work and this does that! |
@Roxy-3D I tested what
I think your concern is with the first point, but I don't think there's a better option. One thing to note is that the nozzle temperatures are only checked if a non-zero Finally, the fist commit on this PR won't compile because |
I think I agree... We don't have enough information to do the 'right thing'.
I believe the entire PR is merged. If it isn't I'll scramble to get things fixed. I did grab the code after the merge and verify it. Can you do a quick double check? |
I'm sure it did (I can't check for sure at this moment). My point was that Travis isn't enabling the |
Oh! OK. We should probably turn that on in a few of the configurations. The big problem is it already takes Travis 10 minutes to do the checks that it does do. So we can really do a full suite of tests on every option. We kind of have to bundle a number of checks together. |
Sorry, guys. It's been that kind of a week, and I haven't been able to follow up on issues as much as I want. (Plus the pile is getting large.) Anyway, is there anything to follow up on now that this is merged? |
@thinkyhead gotta love those kind of weeks :-/ I'd still appreciate if you could review my responses to your comments. I went through and tried to test as much as I could to validate what I think you were wanting to see. I think the big things are that the sequencing is back to working how it did before, with the exception of the start of M600 as explained above. I did also validate that M108 aborts the heating process, which M600 had never done previously. There are some more improvements I'm going to work on, including checking the nozzle temperature for M125 if a retraction is to be performed, as well as looking into removing the requirement for an LCD to use M600. I was thinking of accomplishing this via serial messages to indicate the next step, but I'm not sure if there's a precedent for that. Do you have any thoughts on doing something like that, and would it be a good idea to make it translatable? |
I'll read through them shortly…
Well, we haven't ever had a process that is guided by serial feedback, and this is generally because hosts aren't very good at doing back-and-forth with users. I've been trying to come up with a good protocol by which the firmware could ask the host to ask the user for a response, then send that response back to the firmware, but it's not developed. Instead of taking the guided approach, for So, for the initial implementation, the filament change procedure should follow the same pattern. The first |
|
@thinkyhead I think that's a great idea. I'll look into it. |
@thinkyhead About a year ago, we talked about Load and Unload filament, didn't we? I don't seem to have enough free time to get into it, but we should try make |
* Updates for ensure_safe_temperature * M600 fixes
* Updates for ensure_safe_temperature * M600 fixes
This is based on my comments in #6407 and to d878450
This PR supersedes #6958