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

Start/End Gocde Replacement Token Issue - extruder specific #6590

Closed
FormerLurker opened this issue Oct 27, 2019 · 3 comments
Closed

Start/End Gocde Replacement Token Issue - extruder specific #6590

FormerLurker opened this issue Oct 27, 2019 · 3 comments
Labels
Type: Bug The code does not produce the intended behavior.

Comments

@FormerLurker
Copy link

FormerLurker commented Oct 27, 2019

Application version
4.3.0

Platform
Windows 10 64 bit

Printer
All printers/NA

Reproduction steps

  1. Edit the machine settings of a printer and select 2 extruders (this part is CRITICAL for seeing the issue).
  2. Add the following to the top of the machine's start gcode:
; retraction_speed_0 = {retraction_speed, 0} 
; retraction_speed_1 = {retraction_speed, 1}
; retraction_speed_2 = {retraction_speed, 2}
  1. Add a simple model STL file, slice it, and save the gcode to a file.
  2. Open the gcode file and look at the replaced values for the three tokens above. You will see something like this:
; retraction_speed_0 = 25 
; retraction_speed_1 = 30
; retraction_speed_2 = {'retract_at_layer_change': False, 'machine_filament_park_distance': 16, 'magic_fuzzy_skin_point_dist': 0.8, 'bridge_wall_speed': 15.0, 'ironing_line_spacing': 0.1, 'skirt_brim_speed': 30.0, 'jerk_wall_x': 20, 'machine_min_cool_heat_time_window': 50.0, 'speed_equalize_flow_max': 150, 'retraction_min_travel': 0.8, 'ironing_flow': 10.0, 'speed_support_roof': 40.0, 'raft_interface_speed': 22.5, 'bridge_wall_material_flow': 50, 'layer_height_0': 0.3, 'alternate_carve_order': True, 'material_flow_temp_graph': '[[3.5,200],[7.0,240]]', 'infill_wall_line_count': 0, 'retraction_combing': 'all', 'command_line_settings': 0, 'support_infill_rate': 15, 'multiple_mesh_overlap': 0.15, 'infill': 0, 'retraction_count_max': 90, 'bridge_skin_density': 100, 'travel_compensate_overlapping_walls.... [THE REST IS REMOVED]

Actual results
The replacement token {retraction_speed, 2} was replaced with what looks like ALL possible settings, which makes this difficult to use and greatly expands the gcode size. I have tested this with various different numbers of extruders in the machine settings, and the error occurs any time the EXTRUDER_NUMBER part of the replacement token ({TOKEN_NAME, EXTRUDER_NUMBER}) is greater than or equal to machine_extruder_count.

Expected results
I would have expected the replacement token to be evaluated in one of the following ways:

  1. Token not replaced at all if EXTRUDER_NUMBER >= machine_extruder_count like so:
; retraction_speed_2 = {retraction_speed, 2}
  1. Token replaced with the default value (let's say that is 10mm/sec for example) like so:
; retraction_speed_2 = 10
  1. Token replacement with empty string like so:
; retraction_speed_2 = 

Of the 3 options above, I believe option 1 is more in line with what other tokens do, for example tokens that do not exist.

There are also a couple of other alternatives that would solve my particular problem (but not the reported issue). The first would be to implement another replacement token could be added called {retraction_speeds} that would be replaced like so (if there are 5 extruders for a printer):

; retraction_speeds = 10,20,30,25,10

That would be the most efficient way to report various per-extruder settings IMHO. Unfortunately that would require the addition of many other tokens capable of listing the settings as a CSV string, including {retraction_amount}, {retraction_hop}, and all other settings where "settable_per_extruder": true inside of the fdmprinter.def.json file.
,
The other idea I had would be to create a per-line conditional token (I don't think any conditional tokens exist at all, but perhaps I'm wrong??), something like the following:

{if}machine_extruder_count<2{then}{else}; retraction_speed_2 = {retraction_speed, 2}{endif}

or some other syntax. I understand that these last two items may already exist, and if they do not then they would be more suitable as a feature request. Please let me know your thoughts about this.

Additional information
I've not been able to debug this myself, but I believe the problem is in this file, probably in _expandGcodeTokens function perhaps on, near, or inside this line.

Several Octoprint plugins use these token replacements to extract settings for various purposes. My specific purpose is for supporting multi-extruder printers within Octolapse, a plugin I've been developing. I have been adding a new feature that allows automatic configuration of many plugin settings based on settings outputted to the user's gcode file. I've put in a lot of work trying improve the user experience for folks using Cura, so ANY help with this issue would be GREATLY appreciated!

Thank you so much for your time!

Edit: here is a snapshot of my machine settings, that shows more clearly what my example 'steps to reproduce' are:
image

@FormerLurker FormerLurker added the Type: Bug The code does not produce the intended behavior. label Oct 27, 2019
@Ghostkeeper
Copy link
Collaborator

Very extensive report! That made it very easy to find where the problem was and fix it. Thanks!

@FormerLurker
Copy link
Author

I try :) Thank YOU for this awesome open-source tool. You all are legends :)

Can I what happens if an extruder setting is requested, but is not available? I've only briefly looked at the commit, but it looks like if would leave the token alone like so:

; retraction_speed_2 = {retraction_speed, 2}

Is that accurate?

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Nov 4, 2019

Indeed it will not expand it then. In the code, you see that it'll use the value of default_value_str which is filled with the original replacement key {retraction_speed, 2} then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

3 participants