[BUG] Editing a mesh causes a disordered movement of the Z axis towards the bottom stop of the Z tower.

[Foxies-CSTL]

Bug Description

On a Delta printer (QQS) with TMC2209 uart with auto leveling UBL.

From the menu, select Motion > Unified Bed Leveling > Mesh Edit.

When I want to edit mesh by UBL Tools menu, only axis C wants to go to the bottom of the C tower.

Configurations

20201122-QQS_Pro-Configs.zip

Steps to Reproduce

Last BugFix with PR #20248 and #19804 included, I perform the following operations:

• reset the eeprom = ok
• launch of an auto-calibration (G33) = ok
• Launch of a cold mesh by UBL Tools = ok
• Editing of the mesh via the menu and the two XY axes are positioned towards H - 50mm but the Z axis is positioned towards 0.
  I stop it before the axis motor locks at the bottom (I have no endstop mini).

Additional Information

Look at the position of the Z carriage

Sequence Video (ZIP): MeshEdit.zip

[Foxies-CSTL]

Hello,
I started again this morning with a new build created from BugFix 20201126 and a new environment. I performed the same test sequence but this time I did not turn off the power to see how far it will end (I was a little afraid of breaking the arms of the Z axis).

• from the launch of the mesh edition, there is an initialization which puts the XY carriage in a position and the Z carriage stops at the bottom then rises to position itself at the same height as the Y carriage (X having moved by the force of the movement constraints of the carriage Z).
• the display of the mesh on the screen shows me a roundabout in a square and the positions of each of the axes.

In conclusion, I would say that there is a problem with initializing the axes when editing a mesh for a Delta printer.

Note: the position of the heating head corresponds to the position on the mesh.

Mesh presentation screen

Position of the arms at the end of the initialization sequence.

[sjasonsmith]

I do see a problem with the manual edit in my printer. In my case the Z axis seems to rise very slowly when I enter the mesh edit screen.

I currently have a character display in my delta, so it might be a completely different root cause. I need to do more investigation to understand what is going wrong.

[Foxies-CSTL]

I need to do more investigation to understand what is going wrong.

Hi,
What do you want as additional information? I haven't tried again since you (Team-Marlin) changed "#define HOMING_FEEDRATE_Z" to "#define HOMING_FEEDRATE_MM_M".
Because of that I had to redefine the whole approach part for the calibration "#define Z_PROBE_SPEED_FAST" etc.
Did you get no feedback from Delta users?!?

[sjasonsmith]

There is very little Delta activity in Marlin. It takes a long time for issues to be noticed, and few people contribute fixes.

[sjasonsmith]

I found the root cause for the second problem I encountered. I have it working on my delta, but need to do a little more work before giving it to you to try.

The two problems I have discovered when using the UBL mesh edit screen.

1. Upon loading, attempts to move to the 0,0 point, which is not reachable on the delta.

2. When moving between points on the mesh edit screen, the nozzle drops and can crash into the bed. I found a bug preventing the move from being segmented, which causes the move to be a vertical arc and not a straight line. It is possible this impacts other parts of the code. I need to look further to see where else this might be a problem.

[Foxies-CSTL]

There is very little Delta activity in Marlin. It takes a long time for issues to be noticed, and few people contribute fixes.

Well, if I can help you ;-)

The two problems I have discovered when using the UBL mesh edit screen.

For the 1) 0.0 is indeed a postion reference for a Delta but not for movements.
For the 2) I tried after the starting kinematics a bit messy. Acquisition of the mesh points takes place properly until the fourth and after the next, the head crashes on the bed and slides until the power supply is off :-(.
There may be something to do with PR #10435

[sjasonsmith]

Please test the changes in the above pull request. They work for me, although we don't have exactly the same configuration.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.