search

Desuuuu / klipper

Klipper is a 3d-printer firmware. Modified to work with DWIN T5UID1 touchscreens.
GNU General Public License v3.0
124 stars 51 forks source link

Print cancel/abort should trigger DGUS_PRINT_END #9

Closed ReXT3D closed 3 years ago

ReXT3D commented 3 years ago

When a print is cancelled either from the touch screen or from Octoprint / Fluidd or such, the print progress screen remains on the printer touch screen. A manual DGUS_PRINT_END needs to be issued from the terminal to remove the screen. I am not sure if this is the right place for it, but I believe [t5uid1_var __status_abort] in _klippy/extras/t5uid1/dgus_reloaded/varsin.cfg should be issuing DGUS_PRINT_END automatically.

Desuuuu commented 3 years ago

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.

ReXT3D commented 3 years ago

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.

Desuuuu commented 3 years ago

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.

ReXT3D commented 3 years ago

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!