Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print_time and used_filament placeholder usage in custom G-code #13915

Open
Cheesemuffinz opened this issue Jan 6, 2025 · 5 comments
Open

Print_time and used_filament placeholder usage in custom G-code #13915

Cheesemuffinz opened this issue Jan 6, 2025 · 5 comments

Comments

@Cheesemuffinz
Copy link

Cheesemuffinz commented Jan 6, 2025

Creality printers display the estimated print time, filament used and layer height when selecting a print. This functionality requires those values to be present in the G-code file at the very beginning in such format:

Example (from Cura)

;TIME:2582
;Filament used: 1.57225m
;Layer height: 0.2

Prusa slicer does not emit these values into the G-code and custom G-code only allows the use of "layer_height" and does not allow the existing placeholders "print_time" and "used_filament" to be used in custom G-code. Additionally, there is no way of making changes to the very top of the emitted G-code.

Please allow the usage of these placeholders in custom G-code and possibility to change what is at the very top.

Example

;TIME:{print_time}
;Filament used: {used_filament}
;Layer height: {layer_height}

Possibilities that come along with allowing the use of these placeholders are not limited to the one presented here.

@neophyl
Copy link

neophyl commented Jan 6, 2025

They might not be at the start or match Cura (why should it be identical to some other software anyway ? ) but at the bottom of a sliced file is information. For example from a random gcode I had sliced -
; objects_info = {"objects":[]}
; filament used [mm] = 2243.91
; filament used [cm3] = 5.21
; filament used [g] = 6.47
; filament cost = 0.19
; total filament used [g] = 6.47
; total filament cost = 0.19
; total filament used for wipe tower [g] = 0.00
; estimated printing time (normal mode) = 47m 27s
; estimated printing time (silent mode) = 47m 31s
; estimated first layer printing time (normal mode) = 1m 53s
; estimated first layer printing time (silent mode) = 1m 54s

So that has filament used and print time.
Also every sliced file has ALL the settings used at the bottom too so looking through those we have amongst them -
; first_layer_height = 0.2
; layer_height = 0.15

So more information than what Cura provides. It's all in there if someone wants to parse the contents of the file. Its just as easy for software to parse stuff from the end of a file as the start, makes no difference to code.

Add a post processing script to Prusa Slicer (which is already part of the software) to parse that data and write it to the start in the format you want.

Edit - a simple google search turned up this page https://github.com/mriscoc/Ender3V2S1/wiki/How-to-generate-a-gcode-preview which has instructions on a script that adds in a thumbnail but also the time, filament used and layer height. I'm sure theres enough info there to get you started.

@Cheesemuffinz
Copy link
Author

Cheesemuffinz commented Jan 6, 2025

True, it is possible with post processing scripts to move the needed parts to the top.
However, I think it would be quite a crucial functionality in a slicer to output the code in the proper format in the first place, which is specified per printer, in their profiles.
Then again 3D printing is kind of a DIY hobby so writing a post-prosessing script is part of the fun. We need to also keep in mind the people who cannot code.
Edit:
The reason why the "simple google search" page did not come up while I was researching this is that I did not search for post processing as it is not exactly what I was looking for. Thank you for the link.

@neophyl
Copy link

neophyl commented Jan 6, 2025

My point is that the info is already part of the gcode file, so if creality wanted to display it they could.
You could ask creality to support Prusa slicer, orca slicer, slic3r as they all have the same. But that’s not really in their interests is it as they want people to use their slicer Cura.
Prusa already support different firmware flavours, marlin etc which creality use on their printers, it’s Creality’s choice what parts of marlin or klipper etc they implement.

@Cheesemuffinz
Copy link
Author

Cheesemuffinz commented Jan 8, 2025

Cura is Ultimaker's slicer not Creality's, and it still works out of the box with Creality printers when right profile is selected. I think that it is the Slicers job to make the G-code into the correct format. Prusa Slicer even has profiles that you can configure for Creality printers but they do not display the said information, meaning that is leaves the job "halfway" done.

@neophyl
Copy link

neophyl commented Jan 8, 2025

You are still missing the point. Cura is Creality's recommended slicer for their printers, they have made their implementation of the open source firmware they use on their printers compatible with a Cura feature. If they wanted their firmware to show that same information from a gcode file sliced with Slic3r/PS/Super Slicer/Orca then they could easily do so.

Meanwhile due to the already existing post processing function that is kindly built into those slicers it is possible to do what you want as the information is already there in the file to be used.

This extra info that you want is NOT part of any gcode standard. So much of the stuff included in m odern files is not part of any standard. Is there a good case for a new standard, yeah. There always is. Good luck with that though. Also the profiles supplied for non prusa printers are generally supplied by the user base and not prusa employees.

This should be a feature request for Creality firmware devs.

You could of course modify Prusa Slicers code to make it do what you want yourself and submit a pull request. Put your own time and effort in to help the Creality user base out. Personally I think using as Post Processing script will be easier.

I'd rather Prusa Dev's spend their limited time on one of the MANY other open issues that actually effect quality of prints rather than on supporting printer non essential stuff (that can already be done by the user), from a large company that should be fixing their own codebase to add support for a really popular family of slicers.

Personal opinion of course. Hey your feature request might already be on their list, who knows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants