mmirate
commented
2 years ago In the case of real checksum algorithms, like SHA256, no file can contain its own checksum.
Consider a file whose checksum is not yet determined; it has a particular checksum C1, but no contents which express that its checksum is C1. Now you insert the checksum near the top of the file as requested. The result of this insertion is a slightly different file which therefore has a checksum C2 != C1, but which contains an expression of checksum C1 (not C2).
What I believe would be far more feasible, is to collaborate with the web-API server folks (Moonraker, DWC, OctoPrint, etc.) to have some way to specify the checksum as a parameter to the API call which initiates the upload. Then Moonraker (or DWC or OctoPrint) can verify that checksum for itself, and react accordingly in case of mismatch.
What I believe could be far simpler still, albeit perhaps annoying, is to make the SHA256 checksum available as a substitution parameter in the filename. Then it just takes a very small shell script™ to check any given file, and since Klipper is just Linux under the hood, that's easy to barf up in a few minutes. (Not so easy: (a) integrating that shell script into Klipper so it never prints anything whose filename contains an invalid SHA256 checksum; (b) physically reading from the web UI screen the resulting filenames, which if this feature used, would attain brand-new levels of ludicrous length; and (c) doing any of this on pure-microcontroller systems such as DWC-in-standalone-mode.)
Aside: if all of your errors are incomplete uploads rather than actual garbled data, then you don't actually need any slicer changes. Your use of Klipper already dictates that the g-code's final non-comment line is "END_PRINT", so it should only take a very short shell script to determine whether a g-code file to be printed contains that line or not.
Even firmwares as primitive as Prusa's Marlin fork can - when asked to print a particular file from the SD card - scan to the end of the file, search for the Marlin g-code for "end the print", and if it is not found, halt until the user confirms that that condition was expected. (cf https://help.prusa3d.com/article/file-incomplete-continue-anyway_1847) I am moderately surprised by the lack of such a safety feature in Klipper, and I would be similarly surprised to discover such a thing about Duet.
cyr123
shamal69
Is your feature request related to a problem? Please describe.
On multiple occassions I have generated valid gcode from SuperSlicer, however when uploading to Klipper, the file becomes corrupted, resulting in invalid gcode being actioned by the printer. For small prints, I can live with reprinting, however on large prints (4hrs+) when this occurs nearing the end of the print, substantial time and filament is wasted.
Describe the solution you'd like Ability to include SHA256 checksum generation into exported gcode file. Ideally as commented content at the top of the file.
Describe how it would work When the option has been selected to "Enable SHA256 checksum" in the Printer Settings, a commented SHA256 checksum for the exported gcode file is inserted at the top the file.
Describe alternatives you've considered
Running my own SHA256 hash once gcode has been generated, upload to Klipper (Fluidd) and then SHA256 check file on RPi file system prior to commencing print. This is very time consuming and as Fluidd has support for SHA256 checksum verification, it would be a simple solution.
Obtaining a fully shielded USB cable to connect the RPi and the printer.
Additional context I appreciate the consideration of this request. Thank you for the GREAT software!