[Request] Ability to read GCode for Printer Profile

[SystemIdleProcess]

If this is a feature request describe it here

I use Cura to slice and there are numerous variables that I can output in either the start or end GCode based on the settings I'm using for the print. It would be nice if Octolapse could use these values for at least some of printer profile settings.
A full list Cura variables are available here: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json

Example of added values to Start GCode in Cura 3.2.1:
;Retraction Length: {retraction_amount}
;Z-Hop Height: {retraction_hop}
;Movement Speed: {speed_travel}
;Retraction Speed: {retraction_speed}
;Detraction Speed: {retraction_speed}
;Z Movement Speed: {speed_travel}

Example of output in GCode:
;Retraction Length: 1
;Z-Hop Height: 0.15
;Movement Speed: 120
;Retraction Speed: 60
;Detraction Speed: 60
;Z Movement Speed: 120

Version of Octolapse

Octolapse Version: v0.3.1

Version of OctoPrint

OctoPrint Version: 1.3.8

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: YES_OR_NO

What were you doing when the problem occurred

1. STEP_ONE_GOES_HERE
2. STEP_TWO_GOES_HERE
3. STEP_...

What should have happened?

PUT_YOUR_DESCRIPTION_HERE

What happened instead?

PUT_YOUR_DESCRIPTION_HERE

Operating System running OctoPrint and Octolapse

OS Name: OS_NAME_GOES_HERE
Os Version: OS_VERSION_GOES_HERE

Printer model & used firmware incl. version

Printer Model: PRINTER_MODEL_GOES_HERE
Printer Firmware Version: PRINTER_FIRMWARE_VERSION_GOES_HERE

Browser and version of browser, operating system running browser

Browser: BROWSER_VERSION_GOES_HERE
Browser OS: BROWSER_OS_GOES_HERE

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: GCODE_FILE_LINK_GOES_HERE

Link to settings.json

Link to settings.json with all passwords removed: SETTINGS_JSON_LINK_GOES_HERE

Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE

Link to octoprint.log

Link to octoprint.log: LINK_GOES_HERE

Link to contents of Javascript console in the browser

Link to javascript console output: LINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: LINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps. I'm currently saving for some additional test cameras in preparation for develiping multi-camera support.

[FormerLurker]

First, this is a great request! I have thought about this very same thing and am glad that I know it's something people want.

However, there are some problems that need to be worked out. Currently OctoPrint completely strips out all comments, so they never reach Octolapse. What is needed is a pre-processor that can store meta-data about each gcode file as it's uploaded, or something similar. OR, if I could find a way to pause the printing process before any gcodes are sent to the printer I could digest the whole file then. That would add to the start-up time somewhat, but would work for gcode files that have already been uploaded, and wouldn't require a database...

Alternatively, what if you could tell Octolapse to extract print settings from a gcode file as a one-time thing, and it would copy what it learns to your printer profile? That would be somewhat easier, but will still require some kind of parser to read out the settings from the comments. I wonder if something like this has been made before (not looking forward to writing yet another parser, lol!)

[SystemIdleProcess]

I'm glad my idea/request wasn't too out there. I'm kind of lazy when it comes to having to manually set values.
So does OctoPrint strip the comments out at print time or load time? I downloaded a gcode file from OctoPrint that I uploaded directly from Cura and the comments are still there. If that is the case, something that integrates into the file section might be the only option. I use a Preheat plugin in OctoPrint that reads the gcode for the bed and hotend temp and preheats them prior to me clicking print.
Otherwise, I think a one time file load would be useful at least for me, assuming I remember to do it after I make adjustments.
Another more extreme alternative is to somehow integrate into the OctoPrint plugin that Cura has to try and load the data from Cura directly when it uploads the file to OctoPrint.

[FormerLurker]

Print time. Currently Octolapse uses built in OctoPrint hooks to 'listen' for gcode before it's sent to the printer. It never has a chance to read through the actual file prior to receiving the first gcode queued by OctoPrint. In fact, the built in events for detecting print-start are not useful for Octolapse at all, because all of these events are generated asynchronously, which creates race conditions that can't be overcome.

When the gcode arrives, it is stripped and pre-processed. I've asked Gina about this, and she says it's for performance reasons, and I tend to believe her :) However, I am investigating some ideas that are looking quite promising.

Pre-processing capability will be a game changer for Octolapse. The possibilities for new forms of smart-stabilization and pre-flight error detection alone are going to be worth the effort!

[SystemIdleProcess]

Godspeed!
Thank you for the awesome plugin!

[talldonkey]

Parser for Gcode settings now seems to exist!
https://plugins.octoprint.org/plugins/SlicerSettingsParser/
Display for Parser:
https://plugins.octoprint.org/plugins/SlicerSettingsTab/

And it does parse speeds, from the brief check I did.

Setting	Value
bridge_fan_speed	100
bridge_speed	60
deretract_speed	0
external_perimeter_speed	60
filament_cooling_final_speed	3.4
filament_cooling_initial_speed	2.2
filament_loading_speed	28
filament_loading_speed_start	3
filament_max_volumetric_speed	15
filament_unloading_speed	90
filament_unloading_speed_start	100
first_layer_speed	20
gap_fill_speed	40
infill_speed	120
max_fan_speed	100
max_print_speed	120
max_volumetric_speed	0
min_fan_speed	100
min_print_speed	20
perimeter_speed	100
retract_speed	25
small_perimeter_speed	20
solid_infill_speed	80
support_material_interface_speed	100%
support_material_speed	50
top_solid_infill_speed	50
travel_speed	120

[FormerLurker]

Oh my gosh, and I just finished creating this for simplify and slic3r! Going to have to test this code for speed now. If it's faster than my method, I'll be happy. It's certainly simpler.

[FormerLurker]

So, settings extraction directly from gcode has been fully implemented for Cura, Simplify3d and Slic3r variants, including multi-extruder support. I'm not 100% confident with the multi-extruder stuff yet since nobody had run it on a real printer yet, but it's worked in the debugger and for my MMU (shared nozzle though, so offsets have only been tested in the debugger).

I'm going to mark this closed, and any issues that arise can be handled in new threads. Thanks for your contributions!