Y Axis Behavior After Cut

[RyuKyu567]

I am uncertain if this would be the correct location to post this so my apologies if it is in error. The following issue has been encountered by myself and another individual and we are unable to identify if this is a conflict between HH and Mainsail or if it is something within a configuration somewhere.

Symptoms: Y axis is offset after successful cut utilizing the Filametrix

Occurs on: Bed-slinger printer

Can be reproduced: Yes

Details:
The initial start of a print will process all commands between the printer and ERCF. Upon the filament change the toolhead will begin the wipe/purge tower pausing to initiate the filament eject process. The toolhead will proceed to the cutting arm and successfully cut the filament. The new filament is selected and begins to load. On the return to the wipe/purge tower, the toolhead is offset overlapping the previous purge. This causes a shift in the entire print and tower and increases with each filament change.

I am unsure if this is caused by a conflict in macros or if it is discrepancy in the configuration. Please let me know what information I can provide in order isolate the issue. Thanks!

[moggieuk]

this is almost certainly because of loosing steps in the y-direction. There isn't anything that could otherwise cause a layer shift. Can you carefully watch the toolchange. Is the printhead hitting something during the cut operation or movement towards the pin? (or is one particular move too fast -- unlikely).

I assume this is with the "main" branch? If so it is very surprising because the cutting action is in the x-direction.

[RyuKyu567]

this is almost certainly because of loosing steps in the y-direction. There isn't anything that could otherwise cause a layer shift. Can you carefully watch the toolchange. Is the printhead hitting something during the cut operation or movement towards the pin? (or is one particular move too fast -- unlikely).

I assume this is with the "main" branch? If so it is very surprising because the cutting action is in the x-direction.

Hi Moggieuk,

I can certainly answer the first portion of your question, the second of "main" branch I may need a little help with. I want to say yes... I have been watching this like a hawk while attempting to test a few theoretical work arounds to resolve the issue (needless to say that didn't go well). I can assure you that there are no obstructions in the least bit. I have attempted to slow the acceleration within the printer.cfg down to 500 and below and the results are identical... just... slower lol. I have taken notes on the coordinates for each time to performs the toolchange. Each time mainsail displays the last coordinate, clears to zero (due to homing) and then displays the return coordinate. All of which are exactly the way it should be. I did verify that the tooth count and the pitch of the stepper motor gear is 20 tooth with pitch of 2 which would correspond to the 40 rotation distance within the printer.cfg. I will be more than happy to provide any configuration files or entered variables to assist. I am so incredibly close to getting this thing fully operational so I will do whatever is necessary to assist in this wonderful challenge!

I do appreciate you getting back to me!

[RyuKyu567]

So as a test, I decided to attempt the same exact print using the FORM_TIP instead. Surprisingly enough, the position was exactly where it should have been. I am now looking into the sequence to see if there may be something that can alter the return position of the CUT_TIP macros and sequences.

Quick update... while doing a check each time it completes the first stage of the wipe tower I noticed that once it completes the purge of color 1 the y axis shifts forward before performing the CUT_TIP. Once the tip is cut it resumes to the last position recorded. This is where the offset begins.

Here is a quick video of the printer in question and the issue. You will notice at the pause the bed will jut forward.

https://youtu.be/7NQm0-7nuXc

[moggieuk]

You say "completes the first stage of the wipe tower". Have you turned on all tip forming in the slicer? I looks like that is what you intend so that the tip is cut, then filament reloaded, THEN you want the slicer to purge on the wipetower.

Can you attached a portion of the gcode file around a toolchange operation (include quite a bit before and after) so we can check what the slicer is doing and go from there.

The logic in HH for cutting is in use by 100's of folks without issue so I'm wondering if it is elsewhere. But let's start with the gcode snippet.

[RyuKyu567]

So the last 24 hours has been eventful to say the least. I hope the information that is provided may help.

1: The greatest change was increasing the current of the y stepper motor. My assumption is that since this is on an Ender 3 Max Neo the bed is significantly larger than the profile provided by Klipper which uses the Ender 3 Neo V2. By increasing the current from its default of .580 to .800 greatly increased the acceleration and deceleration power reducing the "Drift" affect. However there was still a slight shift.

2: Prior to altering the current of the y stepper motor I was altering what I would call "speed multiplier" within the cut_tip.cfg. The attached screenshot shows the settings that were changed which nearly eliminated the drift.

Form what I gathered, larger bedslinger printers may encounter this issue due the the weight difference in the y axis in comparison to corexy or other. This however is a guess based on observation only. I am uncertain if it is possible since many of the macros and vars are dependent on the y loc however, would it be plausible to remove the requirements of y axis coordinates needed for the cut_tip capabilities or something similar to that nature? This is not a request by any means, more of a curious question.

Let me know if there is anything else I can provide I will be more than happy to give you as much information as needed!

Thanks!

[moggieuk]

Ok. I think you have answered your own question... the y-stepper IS loosing steps because it cannot depress the cutter without doing so. Increasing the current (even if you edited the macro and did so just for the cutting movement) is probably the best option. Changing speed (which you should do by changing the "travel_speed" in mmu_macro_vars.cfg rather than editing the gcode directly is the other option. Then you can try a different blade that might cut more easily.

You can also try reducing the micosteps for the y-stepper (because less microsteps can increase the torque a little).

It might be that your particular bedslinger printer may just not be capable of the force needed to activate the cutter. Perhaps look into a larger stepper for the y-axis...

[RyuKyu567]

Ok. I think you have answered your own question... the y-stepper IS loosing steps because it cannot depress the cutter without doing so. Increasing the current (even if you edited the macro and did so just for the cutting movement) is probably the best option. Changing speed (which you should do by changing the "travel_speed" in mmu_macro_vars.cfg rather than editing the gcode directly is the other option. Then you can try a different blade that might cut more easily.

I don't think I answered my question at all honestly. Again the Y-Stepper is NOT performing the cut. The X Axis is performing the cut which is working as intended. The issue is that on return to the wipe tower after performing a successful cut, the Bed (Y Axis ONLY) is off by 3 mm each tool change.

If the shift was in the x axis I would agree and fully understand that this would be caused by inadequate force applied with the X Axis stepper motor. However, since this involves only the Y Axis, there is no obstructions, nor additional force required regarding the cut. Now, though I stated increasing the current to the y stepper did reduce the shift to a degree, the issue still remains. Thus the reason why a change was made in the fields listed in the previous screenshot.

You can also try reducing the micosteps for the y-stepper (because less microsteps can increase the torque a little).

I will certainly look into this and do some testing. My concern with doing so is by changing the microsteps may cause other issues concerning accuracy.

It might be that your particular bedslinger printer may just not be capable of the force needed to activate the cutter. Perhaps look into a larger stepper for the y-axis...

As stated above, the cutter is not on the y axis, and the cut is functioning correctly.

If there is a way to disable bed movement completely during the cut sequence that would be fantastic! The only thing that the toolhead would need to do is literally lift up and go left... lol

I will keep at it and see what else can be done. I hope we can continue to come up with a solution, many other users may benefit from all of this information down the road.

[moggieuk]

Sorry, got my X and Y confused :-)

But you said that by slowing the move down you reduced the shift? If this is true it has to be the stepper loosing steps, right?

[moggieuk]

The ONLY other thing I can think of would be if you printer thinks it needs to home on every cut (and then is leaving the toolhead out of bounds). Do you see this in the console log:

Automatically homing XY

I'm stretching here, but if the printer is homing then the Y-axis could be overshooting. If the auto home logic is kicking in then it will move the toolhead back in bounds. This is to prevent future restore position issues. It could also be that the printer is reporting incorrect printer axis minimums and maximums, but first let's see if the homing logic is being triggered..

JFYI. The logic that does the correction is here:

[gcode_macro _FILAMETRIX_MOVE_IN_BOUNDS]
description: Helper to move the toolhead to a legal position after homing
gcode:
    {% set vars = printer['gcode_macro _MMU_CUT_TIP_VARS'] %}
    {% set travel_speed = vars['travel_speed']|float %}

    {% set pos = printer.gcode_move.gcode_position %}
    {% set axis_minimum = printer.toolhead.axis_minimum %}
    {% set axis_maximum = printer.toolhead.axis_maximum %}
    {% set x = [axis_minimum.x, [axis_maximum.x, pos.x]|min]|max %}
    {% set y = [axis_minimum.y, [axis_maximum.y, pos.y]|min]|max %}
    G1 X{x} Y{y} F{travel_speed * 60}

But again, this should only occur if the printer is homing when it shouldn't.

If you suspect this is what is happening you can turn off the auto-home feature (in the CUT TIP section of mmu_macro_vars.cfg)

variable_auto_home              : False

[moggieuk]

You know, what does the printer.toolhead.homed_axes printer variable set to? I've never seen it before, but if it "yxz" or something that is not in the order "xyz" it would explain the behavior...

[RyuKyu567]

The ONLY other thing I can think of would be if you printer thinks it needs to home on every cut (and then is leaving the toolhead out of bounds). Do you see this in the console log:

Automatically homing XY

The only "Automatically homing XY is at the beginning when the print starts. This is just the initial. Anything past that no homing is being performed.

To answer your previous question about:
"But you said that by slowing the move down you reduced the shift? If this is true it has to be the stepper loosing steps, right?"

That is correct. However there were a few things that occurred parralel to that change. The first thing was the increase in current to the y stepper which from a previous post was initially set at .580 which was incredibly low for the 3 Max Neo. I now have it set to .850 which I can go up to 1A if needed since its a 42-40 stepper. I would like to avoid that whenever possible but for testing purposes I can certainly try it.

From there I had a hunch and changed the multiplier from 60 to 55 which since then any cut sequences performed the toolhead would successfully return to its previous position (Im calling it dumb luck). Now... here is another kicker which I don't mean to add to this but it is related. During a test print yesterday I did encounter a few times where the ERCF was unable to grab the filament causing an "all stop" and park in its safe position. No changes in the cfg file were made for these sequence of events. Once the error was cleared and the filament loaded the print was resumed and that is when another shift occurred. As you know, when going to a safe point no other actions other than park are needed, and yet, a shift occurred. So that leads me to believe that something is not quite right.

I'm stretching here, but if the printer is homing then the Y-axis could be overshooting. If the auto home logic is kicking in then it will move the toolhead back in bounds. This is to prevent future restore position issues. It could also be that the printer is reporting incorrect printer axis minimums and maximums, but first let's see if the homing logic is being triggered..

JFYI. The logic that does the correction is here:

[gcode_macro _FILAMETRIX_MOVE_IN_BOUNDS]
description: Helper to move the toolhead to a legal position after homing
gcode:
    {% set vars = printer['gcode_macro _MMU_CUT_TIP_VARS'] %}
    {% set travel_speed = vars['travel_speed']|float %}

    {% set pos = printer.gcode_move.gcode_position %}
    {% set axis_minimum = printer.toolhead.axis_minimum %}
    {% set axis_maximum = printer.toolhead.axis_maximum %}
    {% set x = [axis_minimum.x, [axis_maximum.x, pos.x]|min]|max %}
    {% set y = [axis_minimum.y, [axis_maximum.y, pos.y]|min]|max %}
    G1 X{x} Y{y} F{travel_speed * 60}

But again, this should only occur if the printer is homing when it shouldn't.

If you suspect this is what is happening you can turn off the auto-home feature (in the CUT TIP section of mmu_macro_vars.cfg)

variable_auto_home              : False

So with this we have 2 things:

1: The toohead does remain in bounds as it should so the necessity of it autohoming is null.
2: Out of sheer coincidence the variable_auto_home is already set to "False" from previous testing which has been ruled out and I completely forgot to enable it.

To answer your last question of:
"You know, what does the printer.toolhead.homed_axes printer variable set to? I've never seen it before, but if it "yxz" or something that is not in the order "xyz" it would explain the behavior..."

Here is what I have found thus far:

---

Location: print.cfg
Macro Action: Pause

{% if "xyz" in printer.toolhead.homed_axes %}
G1 Z{z_safe} F900
G90
G1 X{x_park} Y{y_park} F6000
{% else %}
{action_respond_info("Printer not homed")}
{% endif %}

---

Location: mainsail.cfg

_CLIENT_RETRACT
{% if "xyz" in printer.toolhead.homed_axes %}
G90
G1 Z{z_park} F{sp_hop}
G1 X{x_park} Y{y_park} F{sp_move}
{% if not printer.gcode_move.absolute_coordinates %} G91 {% endif %}
{% else %}
RESPOND TYPE=echo MSG='Printer not homed'
{% endif %}

---

Location mmu_cut_tip.cfg

-------------------------- Internal Don't Touch -------------------------

variable_output_park_pos: 0 # Dynamically set in this macro

gcode:
{% set final_eject = params.FINAL_EJECT|default(0)|int %}
{% set vars = printer['gcode_macro _MMU_CUT_TIP_VARS'] %}
{% set pin_loc_x, pin_loc_y = vars.pin_loc_xy|map('float') %}
{% set pin_park_x_dist = vars['pin_park_x_dist']|float %}
{% set retract_length = vars['retract_length']|float %}
{% set simple_tip_forming = vars['simple_tip_forming']|default(true)|lower == 'true' %}
{% set blade_pos = vars['blade_pos']|float %}
{% set rip_length = vars['rip_length']|float %}
{% set pushback_length = vars['pushback_length']|float %}
{% set pushback_dwell_time = vars['pushback_dwell_time']|int %}
{% set extruder_move_speed = vars['extruder_move_speed']|float %}
{% set travel_speed = vars['travel_speed']|float %}
{% set restore_position = vars['restore_position']|default(true)|lower == 'true' %}
{% set extruder_park_pos = blade_pos + rip_length %}
{% set pin_park_x_loc = pin_loc_x + pin_park_x_dist %}
{% set pin_park_y_loc = pin_loc_y %}

**{% if "xy" not in printer.toolhead.homed_axes %}**
    RESPOND MSG="Automatically homing XY"
    G28 X Y
    _FILAMETRIX_MOVE_IN_BOUNDS
{% endif %}

I am unsure if there are others but this is what I could find. If you are looking for something specific let me know and I can check. As you can see this is one of the reason why I reached out. By all things considered it doesn't make any sense.

[moggieuk]

I think we are miss communicating a little. The ONLY think I can think of other than physical problems is this logic in MMU_CUT_TIP:

    {% if "xy" not in printer.toolhead.homed_axes %}
        MMU_LOG MSG="Automatically homing XY"
        G28 X Y
        _FILAMETRIX_MOVE_IN_BOUNDS
    {% endif %}

This, if it triggers, will force homing and then ensure the toolhead is in bounds by issuing a move.

IF (and I'm guessing) this triggers it could be what is happening on your printer. You can verify by commenting out this block in mmu_cut_tip.cfg

#    {% if "xy" not in printer.toolhead.homed_axes %}
#       MMU_LOG MSG="Automatically homing XY"
#        G28 X Y
#        _FILAMETRIX_MOVE_IN_BOUNDS
#    {% endif %}

Then trying again. Can you try?

[RyuKyu567]

I think we are miss communicating a little. The ONLY think I can think of other than physical problems is this logic in MMU_CUT_TIP:

    {% if "xy" not in printer.toolhead.homed_axes %}
        MMU_LOG MSG="Automatically homing XY"
        G28 X Y
        _FILAMETRIX_MOVE_IN_BOUNDS
    {% endif %}

This, if it triggers, will force homing and then ensure the toolhead is in bounds by issuing a move.

IF (and I'm guessing) this triggers it could be what is happening on your printer. You can verify by commenting out this block in mmu_cut_tip.cfg

#    {% if "xy" not in printer.toolhead.homed_axes %}
#       MMU_LOG MSG="Automatically homing XY"
#        G28 X Y
#        _FILAMETRIX_MOVE_IN_BOUNDS
#    {% endif %}

Then trying again. Can you try?

So I was able to commit a lot of time on this yesterday and it took a lot of attempts to figure out which did what and get a decent starting point. I reverted the changes to the read only files back to the defaults and only concentrated on the macro vars and print.cfg. I literally had to reduce all the travel segments down to a value of 10 and slowly increase the speed. From what I have seen so far anything over 75 in the travel seemed to have caused an offset one way or another. I guess with this particular printer it is just a little more sensitive to those acceleration values. The attached is what I currently have set which seems to have resolved the issue. We can close this issue.

[moggieuk]

Thanks for the feedback. May be useful to others.

In general there is a lot of configuration that should be validated and the more different the printer (from the baseline voron 2 and ERCFv2 that I use for most of my testing) the more likely the need for change.

[github-actions]

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.