[BUG] Probing Z while Y at max value makes both XY motors move on a CoreXY machine

[delgueda]

Bug Description

In a CoreXY printer, probing the bed (G30, M48 or G29 P1) while having at Y max causes the X and Y motors to rotate in a way that moves the carriage to the right OR sometimes once to the right and once to the left (distance of about 1-2 mm). Placing the nozzle at any value below Y max stops this behavior (for example, placing it a Y = max - 0.1 mm).

My configurations.

Configuration.h and Configuration_adv.h attached (2.0-bugfix version).

Steps to reproduce

1 - G28 2 - G1 X100 Y196 (X value irrelevant, Y max in my printer is 196) 3 - M48 or G30

Problem also arises when populating the mesh using MESH_INSET = 0 1 - G28 2 - Set bed temp 3 - G29 P1

Expected behavior

Doing M48 or G30 should probe the bed keeping the X carriage stationary.

Actual behavior

Bed probing (G30 or M48) while at Y max (196 in my printer) causes the carriage to move about 1-2 mm.

Additional Information

video explanation: https://youtu.be/aGhqOkYjlto

bugfix2.0.x_configuration_files.zip

(post before editing)

I have UBL activated and tuned in a custom CoreXY 3d printer (hypercube). My mainboard is a RE-ARM/RAMPS 1.4 and I'm using marlin version 2.0.5.3. I also tried with the latest 2.0 bugfix. My Z probe is a precision piezo disk attached to my X carriage. Whenever there's need of probing the bed at the Ymax bed edge (for example during G29 J 3-point tilt correction) I noticed the X carriage moves slightly to the right. In order to check if this was a problem with my printer build or kinematics, I loosened both XY belts from the carriage and noticed both motors (XY) move counter clockwise when probing the bed. I can reproduce the issue by doing G28, G1 X100 Y196 (196 is my bed Y max) and then G30 or M48. I haven't noticed any influence of the X position to reproduce the bug. If I move my Y axis to any value < YMAX (G1 Y195.9) the issue doesn't happen. conf files.zip

[boelle]

@delgueda is this still an issue?

[delgueda]

Yes, I just checked again and it's still an issue. This time the X carriage moved left and right in small distances with each probe. I'm still using version 2.0.5.3

[boelle]

Please test the bugfix-2.0.x branch to see where it stands.

[delgueda]

I just installed the latest bugfix-2.0.x and tested again. The problem still exists, no change at all.

[sjasonsmith]

@delgueda, would you mind updating your description to follow the formatting in the issue template? Consistent description formatting makes it much easier for people to quickly understand the issue and how to replicate it.

If you need to see the issue template, just click the buttons to report a new issue, but please don't actually submit it!

[delgueda]

I edited the report to follow the formatting. I also made a video showing the problem and attached my conf files for the bugfix version. Sorry for not doing it before, it's the first time I ever file a bug report.

[boelle]

@sjasonsmith did the reformat of the first post cast any light on this one?

[sjasonsmith]

@delagela I just realized that you have skew correction enabled. This is probably the cause of the unexpected motor movement.

To test that, disable SKEW_CORRECTION (or just SKEW_CORRECTION_FOR_Z) and see if the behavior goes away.

[delgueda]

Yes! Disabling SKEW_CORRECTION_FOR_Z made the printer behave as expected. So it looks like this is a bug in the implementation of skew correction for Z.

[sjasonsmith]

Why would it be a bug? It looks like your configs have values in them that would cause skew correction to occur on Z moves. It is probably doing what it is supposed to according to the numbers entered.

[delgueda]

Why would it be a bug? It looks like your configs have values in them that would cause skew correction to occur on Z moves. It is probably doing what it is supposed to according to the numbers entered.

It only happens at the maximum value of Y (196), if I move the toolhead to 195.9 it doesn't do it. Because of that it doesn't seem to be correcting skew. Also the movements in X add up with each probe instead of returning to the starting point. If it was correcting skew, I would imagine that after probing and raising Z the toolhead would return to where it was before probing.

[delgueda]

Now I noticed that if I leave XZ and YZ skew compensation but set XY compensation to 0 (M852 I0) the printer doesn' t move the toolhead when doing z probing with M48. I hope this is useful.

[boelle]

i think this is a case where it works as it should but the user expect something entirely different

and its also a case where functions are used to make up for a bad assembled machine, why do you need skew correction if your machine is assembled correctly?

[delgueda]

OK I give up. I just wanted to help. Good luck.

[sjasonsmith]

@delgueda I think you actually do have an issue worth looking into, especially the bit where moving the carriage 0.1mm prevents it from happening. I had added labels after your earlier comment, but didn’t reply because I don’t know when anybody will have a chance to look closer at it.

I’m reopening this, as somebody should try to reproduce this to understand why it is happening. I won’t be surprised if this isn’t even CoreXY related.

Perhaps this is a config issue, but if that is the case I would like somebody more experienced with skew correction to explain why the behavior you described two comments ago makes sense.

[boelle]

i have the same board and printer style, but a bl touch probe, i cant reproduce it

only difference other than the probe is that i dont use skew correction (i have no need for it)

my config is here: https://github.com/boelle/Marlin/tree/Core-XY

i will try again tomorrow just to be sure

[sjasonsmith]

@boelle if you want to reproduce this you will need to enable the skew correction features like the posted configs. There no point in testing if you don’t.

[boelle]

i wanted to test this one but sadly i cant

i use a bl touch as probe and not the nozzle and i need to use #define PROBING_MARGIN 30 to stay clear of the ends on my axis i started out with 50 but could not get it lower than 30

in effect i cant do a G30 at the max of Y as it will not allow a probe if closer than 30 to end of axis

[boelle]

not sure but a few differences i noted in the config compared to mine

me classic jerk you #define NOZZLE_AS_PROBE me #define BLTOUCH you #define AUTO_BED_LEVELING_UBL me #define AUTO_BED_LEVELING_BILINEAR

another odd one is that you do not have ro in the LCD language strings so the config is not the newest

in the adv config file you use babystepping and i dont

not sure if that matters but it was the things that sticks out to me

[boelle]

1 - G28 2 - G1 X100 Y196 (X value irrelevant, Y max in my printer is 196) 3 - M48 or G30

works fine for me, no XY movement as i use BL touch and i have a probe XY offset i have to back of the XY max or else it will not allow me to probe

Problem also arises when populating the mesh using MESH_INSET = 0 1 - G28 2 - Set bed temp 3 - G29 P1

doing G29 P1 starts a normal probe just like G29 would

@delgueda how can you use nozzle as probe? please explain how your probe is setup

[boelle]

my config: https://github.com/boelle/Marlin/tree/Core-XY

but i made these changes

[delgueda]

@delgueda how can you use nozzle as probe? please explain how your probe is setup

That information is my first message. I use a piezo disk as Z probe sensor. That allows me to use the tip of the nozzle to probe the bed. I don't think you'll be able to reproduce the condition (prove at Y MAX) without using the nozzle as probe and margin = 0.

[boelle]

i do have margin set to 0 but its the probe i have that prevents me from probing at the edge

i do have a 500x500 bed but to try and reproduce i faked a smaller bed so at least i could get to the edges with the nozzle

since i have plenty of space i could "force" it to probe anyway of course that is dangerous if you dont know what you are doing, i just need to know how to trick it to probe regardless

[delgueda]

I see you enabled skew correction, but did you enable SKEW_CORRECTION_FOR_Z?

If I enable SKEW_CORRECTION, but leave SKEW_CORRECTION_FOR_Z the XY motors don't move abnormally.

[boelle]

my plan was to test in steps

sometimes if you enable all at the same time you dont know what settings caused it, so i will enable for Z and retest later

does the values matter? or is it enough just to enable with default values?

[delgueda]

does the values matter? or is it enough just to enable with default values?

I have done small changes in the values and the problem persist. I haven't tried the default values. I'll try again later today, with other values and the defaults.

[boelle]

no problemo, why i ask is that the printer is not completety build yet silicone heater is not here before tomorrow and the flexplate is sold out so i can print but for testing it should be good enough

[boelle]

just tested and still no XY move

config: https://github.com/boelle/Marlin/tree/Core-XY

with these changes as to fake your config

[boelle]

no probe offset allows me to probe at the edges, since i have a 500x500 bed its safe to do so, but to others watching: Dont do this if you dont know what you are doing, if you break something from reading this you did not know what you did

the half bed size change is just something i picked, this allows me to probe to edge as you do

only left is to figure if the default number for skew correction matter or not

[boelle]

i added your numbers for skew correction, still no XY move during G30

Send: G30
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
Recv: Bed X: 240.00 Y: 230.00 Z: 1.00
Recv: X:240.00 Y:230.00 Z:10.75 E:0.00 Count A:75200 B:1600 Z:8600
Recv: ok
[...]
Send: M18
Recv: ok
[...]

[boelle]

just curious, how old is your copy of marlin and where did you get it from? for where please give direct link

[thinkyhead]

@delgueda — How's it going? I see this issue has been buried in the pile for a while. It's been a challenging couple of months…

My strategem would be to look at the points in Marlin where skew is applied, namely the Planner::apply_modifiers method, which is called from Planner::buffer_line and analyze what goes on and whether the weird behavior is peculiar to Core kinematics, or whether it could affect regular Cartesians. I'd add a bit of logging at the interesting points inside of buffer_line to see whether unusual limits are being applied, or if other factors may be at play.

Of course, to ensure that we are all on the same page, I would ask that you do all your testing with bugfix-2.0.x.

I'm about to crash for the night, but let's pick this up tomorrow (Saturday, CDT) and compare notes.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[github-actions[bot]]

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.