Temperature not reached.

[rewolff]

It seems that my heater is not powerful enough to heat my extruder to the desired temperature anymore. Either it is degrading or the room-temperature dropped since I last printed 1 day earlier.

It seems there is no timeout on the wait for temp to be reached Gcode command. Because it is stuck INSIDE a single Gcode command, octoprint cannot abort this.

To test this without my situation where the hardware is at risk (I decomposed a batch of PETG inside my hotend for hours before I noticed that it wasn't doing anything), try this:

every second:

f = 0.003;
curtemp = curtemp*(1.0-f) + heater * 237 * f;

where "heater" is 1 or 0, the heater output signal. This should tend towards 237 degrees, set the target at 240.

[KevinOConnor]

Both Klipper and OctoPrint are designed to handle an M112 command out-of-order. So, it should be possible to halt a printer with that. If you're having issues with that, you'll need to attach a log from the incident - see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

[rewolff]

If that's supposed to work, I probably didn't give it enough time. So octoprint is supposed to send M112 when I hit "cancel job"?

What remains is: shouldn't there be a timeout on the M109 command?

This is the start of my gcode file.

M190 S65 ; set bed temperature
M104 S240 ; set temperature
G28 ; home all axes
G1 Z180 F8000 ; lift nozzle

M109 S240 ; wait for temperature to be reached

[KevinOConnor]

A "cancel job" will not send an M112. You can either manually type "M112" in the octoprint terminal tab, or you can use one of the octoprint plugins to make a button that sends M112.

What would that timeout be? The "verify_heater" code ensures the heater continues to make progress, so if it takes a long time then it takes a long time. Some people have bed heaters that take 30+ minutes to heat up. In the unfortunate case that a user wishes to cancel the request - issuing an M112 or resetting isn't too difficult.

-Kevin

[rewolff]

I'm a quite technical user. I've built 3D printers. I've written Linux kernel code, I've written programs that write G-CODE, I've written programs that input-modify-write gcode. I've configured Marlin for a new printer. I've never needed M112, You've told me that it exists. Apparently building buttons for octoprint is easy. Still having never done it, it feels like a hurdle to take.

And the issue is not that it cannot be aborted, but the issue is that I had three prints go flawlessly so that I was starting to TRUST the printer again. Having started a print job and expecting it to run for several hours, there was no need to check on it every 3 minutes. When I did check on it I saw a flatlined temperature curve. That's quite normal for when it's printing so I again did other stuff while I thought the printer was happily printing.

My hotend seems to have a lot of thermal mass. So it is quite slow now. So when I start a print, but it fails on the first layer, I cancel the job, fix what went wrong and then hit print again. When the temperature at that point is still 150 or so, the thermal inertia of "still cooling" and the underpowered heater element resulted in spurious "no progress made" messages.

So I have had to change the default settings for hysteresis and time to check for progress being made. This is very similar to having to extend the "temp should be reached in XXX time" for people who have a bed that does not heat inside say 30 minutes. . I would find a default of say 20 minutes quite reasonable, and those that have to extend it, well, they will have to extend it.

I think the "progress being made" check is being stopped once inside the hysteresis range. But the "temp reached" triggers on the actual setpoiint being reached. So my printer had the unfortunate coincidence that the steady state temperature was between those two temperatures.

[fredizzimo]

If I understand this correctly, this seems like a serious issue that could potentially cause a fire.

If the sensor is reporting wrong, and reports something below the target, the firmware might keep trying to heat it up. This would only stop when either the heater runs out of power to heat more, or when something breaks down, or a fire is started.

I will definitely soon check the code and see what kind of thermal safety features there are, before I start to use Klipper for real...

[KevinOConnor]

@rewolff - Okay, thanks for the feedback. If I understand correctly, you are raising two issues - the M109 command does not have a timeout, and the verify_heater code does not report a malfunctioning heater if that heater consistently reports a temperature within the hysteresis range.

On the M109 issue - I understand what you are reporting. I do not wish to imply that one should know the intricate details of M109/M112 g-code commands - in my opinion, g-code is "arcane" and a complete mess. Alas, I don't think "enhancing" existing g-code commands is a good plan - I fear it is more likely to confuse users than help. That said, if someone wishes to implement a "SET_HEATER_TEMPERATURE" command with more flexible command parameters then I think that would be a good thing.

On the verify_heater issue - I understand, but I don't see a resolution. If the heater is reporting within range, the verify_heater code has no reason to suspect an issue. We could reduce the default hysteresis, but that raises risks of false positive alarms. (And there has been consistent feedback that users do get these types of alarms, and are sometimes confused by them.)

Cheers, -Kevin

[noud-github]

Yesterday I noticed somthing like @rewolff states in his second post.

my gcode:

M104 S[first_layer_temperature] ; set extruder temp M140 S[first_layer_bed_temperature] ; set bed temp

G28 X0 Y0 ;move X/Y to min endstops M109 S[first_layer_temperature] ; wait for extruder temp G28 Z0 ;move Z to min endstops ;BED_MESH_CALIBRATE BED_MESH_CLEAR Z_TILT_ADJUST G28 Z0 ;move Z to min endstops M190 S[first_layer_bed_temperature] ; wait for bed temp ;M109 S[first_layer_temperature] ; wait for extruder temp

now commented out the last M109 took 5 min or more, did't wait that long cancel not working, realy strange since it is the second time, waiting and temp was already reached. because G28 runned

[rewolff]

in my opinion, g-code is "arcane" and a complete mess.

Agreed To "change the world", someone needs to come up with something better. But there is a catch 22: Nobody will write a slicer to generate a new form of GCODE if no printer supports it and no printer will support a language that nobody can generate.

To get out of this situation, KLIPPER needs to start to support the new language before anybody can generate it. YOU get to design the language.

IMHO one of the concepts that needs to go into the new language is that a machine may have many, many axes. And several other things that are now special case, for 3D printers are axes too. For example, temperature (bed or hotend) is an axis too. When classically you say "hotend 190 degrees", you can say: Move the T axis to 190, please don't wait for it to finish. Currently the "and don't wait" is not available on X, Y and Z but why not? Treat everything the same!

I would suggest to maybe at first translate the new language to G-code internally. Or we write a new interpreter for the new language and translate the old G-code to the new language. To get started with designing a new language: First write an example manually. Take for example a GCODE file for a very small object and translate that by hand. How would you LIKE to have it look? In the end you'll find stuff missing or mis-translated at first. That's not a problem.

Anyway, IF the heater is reporting "in range" then the Mxxx command to go to the temperature should finish.

I do not subscribe to your argument that the language needs to be extended. Just like the verify_heater code throws an error when things are not going well, a new verification routine may throw an error when other limits (configured in the config file with sensible defaults) are exceeded. (FYI: I have enlarged the hysteresis on my system because it was throwing unnecessary errors. So reducing the hysteresis on my system is not useful. )

I would propose that either you have a from "within hysteresis" to "temperature reached" timeout of say 5 minutes. Or a whole "the heating process should not take more than XX minutes" (where XX will need to be say 20 minutes to not bother 95+% of the people with that "new" setting). . Or maybe 30 minutes to try to aim for 98 or 99+...

[KevinOConnor]

YOU get to design the language.

Well, if I get to design the language, as of today, I'd go with a "COMMAND_NAME PARAM1=value PARAM2=value" format. I'd further require that the given command stream be error free (via transmitting it with a proven mechanism, such as tcp/ip, that implements flow control, error detection, retransmits). FWIW, this is what Klipper implements between host and micro-controller software, and it is the basis for Klipper's "extended" g-code commands.

FYI: I have enlarged the hysteresis on my system because it was throwing unnecessary errors

FYI, you may find that reducing the hysteresis, but increasing max_error provides a more robust error check.

Separately, I've added a new FAQ item for cancelling M109/M190: https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#how-do-i-cancel-an-m109m190-wait-for-temperature-request

-Kevin

[KevinOConnor]

I'm going to close this as I think the original question was answered (at least as best as can be).

-Kevin