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

HH 2.7.3 z-hopping when park_toolchange is set to -1,-1 to disable move / park #486

Open
ningpj opened this issue Oct 29, 2024 · 5 comments · May be fixed by #494
Open

HH 2.7.3 z-hopping when park_toolchange is set to -1,-1 to disable move / park #486

ningpj opened this issue Oct 29, 2024 · 5 comments · May be fixed by #494
Labels
enhancement New feature or request IN_PROGRESS

Comments

@ningpj
Copy link
Contributor

ningpj commented Oct 29, 2024

Use case - standard, purge block based filament changes, no blobifier or cutter.

Setting variable_park_toolchange : -1,-1, 0, 0, 2 to prevent HH from moving/parking on toolchange so it remains above the purge block now causes it to z-hop 2mm following 2.7.3 update. Presume variable_min_toolchange_z : 2.0 now enforces this when z <= min height whether parking or not. Since I'm not moving the head from the purge block min_toolchange logic should be conditional and only applied when x & y >= 0 or when z-hop is explicitly set.

14:42:05 // Parking toolhead at (x:n/a, y:n/a, z:2.0) for toolchange operation
14:42:05 // Restoring MMU gear stepper run current to 100% configured
14:42:08 // Run Current: 0.89A Hold Current: 0.21A
14:42:08 // Unsynced MMU from extruder
14:42:08 // Unloading filament...

@moggieuk
Copy link
Owner

You are correct that it would be the min_toolchange_z "floor" that would cause this min height as a safety feature.

So are you suggesting that if park x,y is -1, -1 AND z-hop is 0 then the min_floor should not be applied?

@ningpj
Copy link
Contributor Author

ningpj commented Oct 30, 2024

Yes. z-hopping over the purge block amplifies blobs and would return this to the previous behaviour. If the toolhead doesn't need to move and all 3 arguments are set to off then the min_floor shouldnt apply IMO

@moggieuk
Copy link
Owner

This thinking makes sense but it does potentially defeat the purpose of the floor (which was btw a user suggestion after they scratched their bed). However if coupled with no X/Y movement I think it is fine.

@moggieuk
Copy link
Owner

moggieuk commented Oct 31, 2024

Since I'm buried in v3.0 development and testing, can you try this fix for me. I think it is as easy as this. Edit mmu_sequence.cfg and add the three lines indicated. This is in the [gcode_macro _MMU_PARK] macro definition around line 125:

    {% set park_z_hop = park_z_hop|abs %}
    {% set z_hop_ramp = z_hop_ramp|abs %}
    {% set min_toolchange_z = vars.min_toolchange_z|default(1)|float|abs %} 
    {% if x == -1 and y == -1 and  park_z_hop == 0 %} # ADD ME
        {% set min_toolchange_z = 0 %}                # ADD ME
    {% endif %}                                       # ADD ME
    {% set park_travel_speed = vars.park_travel_speed|default(200)|float * 60 %}
    {% set lift_speed = vars.lift_speed|default(15)|float * 60 %}
    {% set pos = printer.gcode_move.gcode_position %}
    {% set origin = printer.gcode_move.homing_origin %}
    {% set max = printer.toolhead.axis_maximum %}

If you verify I will make this change.

@moggieuk moggieuk added enhancement New feature or request IN_PROGRESS labels Oct 31, 2024
@ningpj
Copy link
Contributor Author

ningpj commented Oct 31, 2024

Sure, no problem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request IN_PROGRESS
Projects
None yet
2 participants