Allow Custom User Park GCode

[charredchar]

I would like the ability to use custom gcode in place of _MMU_PARK but still utilize the park options such as variable_enable_park_runout. I am thinking something similar to variable_user_park_extension where a user can enter their command or gcode macro specifically for what is called when _MMU_PARK. Or maybe some other option to replace entering variable_park_xy with a command so it can still utilize everything else in _MMU_PARK but run what ever macro you want in place of just moving to the XY location.

If you'd like an example of why this could be helpful, I park my nozzle on a silicone pad to prevent oozing during things like tool changes but the nozzle needs to come at the pad from the side or else it risks damage or knocking something lose. All of my normal parking macros take this into account but I can't utilize the automated parking in HH this way.

[moggieuk]

The macros are fairly tightly woven together -- there are a lot of factors to consider and variables are stored on this macro, but I think a user extension at the end of the _PARK macro may be possible. You would need to turn off:

enable_park
enable_park_runout 
enable_park_standalone

thus the _PARK macro becomes nothing more that a way to record the z height of the toolchange.

You can try this: even though the file is "read-only" you can edit mmu_sequence.cfg in Happy-Hare/config/base/mmu_sequence.cfg. Add a line to call your macro at the end of the _MMU_PARK. This will not survive and upgrade because the edit will be overwritten but it would be good to know that everything else still works. Once I know that I could add the extra "user extension" which will survive upgrades

[charredchar]

The macros are fairly tightly woven together -- there are a lot of factors to consider and variables are stored on this macro, but I think a user extension at the end of the _PARK macro may be possible. You would need to turn off:

enable_park
enable_park_runout 
enable_park_standalone

thus the _PARK macro becomes nothing more that a way to record the z height of the toolchange.

That's the thing, I would prefer to keep these options as I want my toolhead to park during tool changes or during a runout. As of right now if I want to park during these two instances I need to disable all three and write elaborate macros to encompass the same situations where it might also break in some edge cases I couldn't account for. I was trying to accomplish my parking movements using the other extension options but I am consistently running across situations where it fails, dragging my nozzle across the parking area in a way that is risking damage. Another option could be to add a user_pre_park and user_post_park option like the others, where it can run gcode before and/or after the _PARK gets called but still be inside of any other macros using _PARK. This could work in a situation like mine where I could have it run a macro to move into position it needs to be before the final park move.

You can try this: even though the file is "read-only" you can edit mmu_sequence.cfg in Happy-Hare/config/base/mmu_sequence.cfg. Add a line to call your macro at the end of the _MMU_PARK. This will not survive and upgrade because the edit will be overwritten but it would be good to know that everything else still works. Once I know that I could add the extra "user extension" which will survive upgrades

This is something I am trying to avoid as I've already ran into instances of an update breaking my modification to read-only files.

Maybe a different way to approach it would be to allow a completely different mmu_sequence.cfg file like you can with tip forming/cutting by changing the form_tip_macro: setting? I wanted to rewrite the cutting config for custom movements during the cut cycle so I duplicated the config and changed all of the commands within, adding CUSTOM to it so they couldn't conflict with the original config. In this example I could duplicate mmu_sequence.cfg as mmu_custom_sequence.cfg then rename every macro name with CUSTOM in it along with my modifications where needed. It'll still use the variables as it should but it will no longer conflict with any other macro outside of that file.

[moggieuk]

Happy Hare has lots of levels where the user can customize, and indeed you can go all the way and define a completely new sequence. As you point out there are a LOT of factors to consider to prevent crashing or something unexpected. That was my point saying that there are a lot of connected parts.

The suggestion to hack a line into the current _PARK macro was not meant to be permanent, it was to give you the opportunity to try something out to see if it can work for your use case. Knowing that would allow me to implement something generic.

BTW I'm hopelessly deep into Happy Hare. Close to 800 hours now and I need to rely more on PR's so if you have suggest something I'm completely open to it.

Maybe I'm over complicating what you need to do. The current x/y move in _MMU_PARK does:

            G1 X{x} Y{y} F{travel_speed}                # Move to park position

If that one line could be replaced with something custom that would take the desired x,y, would that be sufficent? You could then do "L" shape movements, etc.

Ie this logic:

            {% if vars.user_park_move_macro %}
                {vars.user_park_move_macro}
            {% else %}
                G1 X{x} Y{y} F{travel_speed}            # Move to park position
            {% endif %}

[moggieuk]

# The default parking logic is a straight line move to the 'park_xy' position.
# To implement fancy movement and control you can specify a
# 'variable_user_park_move_macro` to use instead of this straight line move.
#
variable_enable_park            : True          ; True = Enable parking move when printing (not runout), False = disable
variable_enable_park_runout     : True          ; True = Enable parking move during runout handling, False = disable
variable_enable_park_standalone : True          ; True = Enable parking move when not printing, False = disable
variable_restore_xy_pos         : "last"        ; last|next|none - What x,y position the toolhead should travel to after a toolchange
variable_park_xy                : 50, 50        ; Coordinates of park position for toolchange if using default park logic
variable_park_z_hop             : 1.0           ; Additional Z_hop (mm) when toolchanging (works in and out of print)
variable_travel_speed           : 200           ; XY travel speed in mm/s
variable_lift_speed             : 15            ; Z travel speed in mm/s
variable_auto_home              : True          ; True = Automatically home if necessary, False = disable
variable_park_after_form_tip    : False         ; True = if tip cutting to delay move to park position, False = park immediately
variable_timelapse              : False         ; True = take frame snapshot after load, False = disable

# You can extend functionality to all Happy Hare sequence macros by adding
# a command (or call to your gcode macro)
variable_user_pre_unload_extension  : ''        ; Executed after default logic
variable_user_post_unload_extension : ''        ; Executed after default logic
variable_user_pre_load_extension    : ''        ; Executed after default logic
variable_user_post_load_extension   : ''        ; Executed after default logic but before restoring toolhead position
variable_user_park_move_macro       : ''        ; Executed instead of default 'G1 X Y move' to 'variable_park_xy' position

[github-actions[bot]]

This issue is stale because it has been open for over 30 days with no activity. It will be closed in 14 days automatically unless there is activity.