Gcode file size not matching what is sliced

Basic Information:

Printer Model: VZBot-330
MCU / Printerboard: Raspberry Pi 4, Flysuper 8 Pro
Host / SBC
klippy.log
logs-20240425-093108.zip (1.8 MB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Odd issue I am seeing, I have a file that is 114mb when sliced, but when I upload it to the Mainsail web interface, it is only showing as 111.7mb. I tried uploading a few more times to make sure it was not a connection issue, drag and drop, click the upload button and still not showing the complete file size.

I then tried to WinSCP to upload directly to the Rasp Pi, and on the Rasp Pi, it shows the full file size of 114mb, but in mainsail its still showing only as 111.7mb.

I figured give it a go and print it, but the file did stop and missing the rest of the file.

The file systems are different; Windows typically are NTFS, RPi and clones with on-board storage are exFAT, and the SD card file system is typically FAT32.

All of these store the files in different ways, so the file size also may be reported differently.

I wondered about that but @Noble8 is reporting “the file did stop and missing the rest of the file”.

So, what I think we need is for @Noble8 to

  1. Post the gcode of the model he is printing
  2. Explain where the print did stop (ie did it stop with roughly 98% done). If he can post pictures of the unfinished model, that might help

Your log contain following records:

Unknown command:“POWER_OFF”
Finished SD card print
Exiting SD card print (position 117149695)

So most probably you did reach the end of file where klipper did read that “POWER_OFF” command.

Also if you recalculate that positions to Kbyte or to Mbyte
117149695/1024 = 114403Kbyte
and for Megabytes
117149695/1024/1024=111.72Mbyte

So you did see Kbyte value in your Slicer/WinSCP which was trimmed to represents only thousand parts.
Mainsail did calculate Mbytes correctly.

You didn’t lose any portion of a file.

Here is a photo of the print showing it stopped.

I forget what the % it showed on the printer screen

Thats interesting to learn about the Kbyte to Mbyte conversion so I learned something new today :slight_smile:

not sure if its allowed to post the gcode of the file as it was a paid stl file. I know there are some methods to convert gcode back to stl and I dont want to cause any issues

I dig your log and found additional logs which explain it

between this 2 Stats we see that target temp 0 was requested from extruder

Stats 63827.1: … extruder: target=220 temp=220.2 pwm=0.178
Stats 63828.1: … extruder: target=0 temp=220.3 pwm=0.000

most probably it was caused by this errors

Stats 63836.1: … extruder: target=0 temp=215.3 pwm=0.000
Unknown command:“DSLR_SNAPSHOT”
Unknown command:“SET_FAN_SPEED”
Unknown command:“SET_FAN_SPEED”
Timelapse: Rendering started
Remote Call Error
Traceback (most recent call last):
File “/home/ODProp/klipper/klippy/extras/gcode_macro.py”, line 93, in _action_call_remote_method
webhooks.call_remote_method(method, **kwargs)
File “/home/ODProp/klipper/klippy/webhooks.py”, line 401, in call_remote_method
raise self.printer.command_error(
gcode.CommandError: Remote method ‘timelapse_render’ not registered
Exiting SD card print (position 117135135)
Stats 63837.1: … extruder: target=0 temp=214.4 pwm=0.000

then it seems like somebody try to restart print with cold extruder.

Stats 65698.6: … extruder: target=0 temp=25.7 pwm=0.000
Starting SD card print (position 117135135)
Stats 68185.5: ------------------ extruder: target=0 temp=23.0 pwm=0.000

later

Unknown command:“SET_FAN_SPEED”

and last error

Unknown command:“POWER_OFF”
Finished SD card print
Exiting SD card print (position 117149695)

Conclusion - you Gcode file contain a set of unknown commands for klipper and at point Stats 63836 there was a call to some Gcode_macro which did produce error Remote method 'timelapse_render' not registered which interrupted your print, most probably it was a call to your TIMELAPSE_RENDER macro.

It might be stored in an area that is bad.
Have you tried renaming the file on the printer and upload the file a second time and check the file size?

I found the timelapse render in the maching end gcode in orca. I used the preset Vzbot profile so didnt think to look there. Removed it and going to give it another go.

Thank you for your assist! I did try to restart by hitting resume, assuming the machine would have recalled the previous settings and would run. Likely there might be some config i need to do for that part to function