Print cancel/abort should trigger DGUS_PRINT_END about klipper HOT 4 CLOSED

The thing is, the touchscreen doesn't really cancel the print, it simply asks the host (OctoPrint, ...) to cancel it.

It makes more sense to me to let the host send the DGUS_PRINT_END considering that.

For OctoPrint, it is as simple as adding a GCode script for After print job is cancelled in the settings with the right command.

from klipper.

A good workaround. I suggested the above because I am a big fan of avoiding "distributed features". Ideally it would be great if DGUS_PRINT_START and DGUS_PRINT_END were not required at all. Again, pardon my ignorance if I am completely out to lunch due to lack of knowledge of the implementation (I do not understand the exact reason for why the start and end commands are required).

For example, when using Marlin, the moment a print starts the print screen appears on the LCD without any special commands being issued from the host. With Klipper on the other hand the print screen does not appear until after bed and extruder heating completes. This is with DGUS_PRINT_START being the first line in the start GCODE in Cura.

from klipper.

Marlin (in the case of using serial) does some guess work to know the print status (using the print counter IIRC, which starts when heating up).

It's integrated in the core of Marlin so that ui modules simply get notified when the print status changes, regardless if you're printing over serial or directly from the SD card (and it's pretty reliable).

With Klipper by default you can get a rudimentary status based on whether there are commands coming in. It's not particularly reliable (it doesn't play well with pauses for example).

While you could implement the same logic as in Marlin and get a somewhat reliable status, it's still pretty complicated to handle every case properly. Considering the fact that the user already had to setup the host to work with Klipper, I don't think it's a lot of extra work to add two commands to the start/end scripts and this has the advantage of being 100% reliable.

With Klipper on the other hand the print screen does not appear until after bed and extruder heating completes. This is with DGUS_PRINT_START being the first line in the start GCODE in Cura.

That's simply because Cura puts your start script after heating is done (this makes sense if you're adding a wipe line for example).

Add the command to the Before print job starts script in OctoPrint and you'll get the behaviour you want.

from klipper.

Thank you - I appreciate your explanation of the Marlin auto-detection and differences in Klipper. I would have not been able to dig into the code to search for this due to time limitations.

My comments about avoiding distributed features stem from lots of experience in architectural design of complex aerospace systems, not software design specifically.

I think this can now be closed, thank you!

from klipper.