Printer acting very odd after bringing down Dec 3rd commits

[PolloPequeno]

See #8632 for a bit more context

---

Bug Report

• Description: The printer is acting very weird both with SEGMENT_LEVELED_MOVES enabled and disabled (Skew also turned off): During UBL the printer slows to a crawl and when I click +Z10 from simpliy3d's machine controller, both Z and Y move and when I click it again Z rapidly descends. It was pretty scary, it must have gone into the bed 10 or 20mm before I was able to stop it. Thank God for springs!

• Expected behaviour: Anything but this :-P

• Actual behaviour: See above

• Steps to reproduce:
  I really don't want to reproduce this.

---

[PolloPequeno]

I did a bit more investigating, and having UBL enabled/disabled both via M420 and config file doesn't have an effect. The txt file below contains the debugging output from UBL enabled/Disabled via M420. I didn't save the run where I disabled UBL in config, let me know if that would be useful and I can rerun. Changing the value of segment length also had no effect.

What's odd about this is that it's somewhat intermittent, when I home all, the printer acts odd ,moving Z and Y at the same time very slowly then it seems to be running normal and homes, then I'll move the X axis and all 3 axis move.

My hunch is that it's hitting some code in the planner (do all movement commands go through the planner?) that is treating my cart as a delta, that would explain Marlin moving multiple steppers when I request a single axis be move.

Debugging output #8638.txt

[hg42]

I bet it has to do with what I wrote in PR #8611.
Can you try to revert commit 3a97de5?

[PolloPequeno]

@hg42 yes, I agree they sound like the same issue. I has using a build from two or three days ago and that worked fine.

Any suggestions on renaming this issue, so it's more useful for other users?

[hg42]

you may use PR #8611 in the title, otherwise I find it very descriptive

[thinkyhead]

I'll revert the "split first planner move" changes and see if that fixes the issue. Hopefully we can figure out how to get that to work without weird side-effects!

[PolloPequeno]

Sounds good @thinkyhead, I give it a go later tonight or tomorrow morning.

[PolloPequeno]

I did some preliminary testing and everything seems good.

I tested with UBL turned on and segment line length on and off. Skew was turned off. The tests were homing, moving the axes, and letting UBL do a couple of probe points.

I'll run some test prints and try Skew correction out, in the morning.

Best!

I'm running a Cartesian with 1.1.x-bugfix.

[fiveangle]

Came here to report "odd" behavior too... homing cartesian with probe but using MBL probe manual and it moves quickly to bed-center, pauses for split second, then moves Y fast another 50mm or so then executes z home. Execute G1 to move along single axis (Y) and attempt to intentially command further than bed (soft endstops enabled) once hit edge, kept going, but also Z was commanded to move up (making quite a racket ;)

In all, quite the mess, so while the theory behind the spitting up seems sound, the implementation has some gremlins that definitely needs more real-world tests in a separate branch before merging.

Happy to report the revert resolved all issues for me.

[hg42]

in fact the implementation of the feature seems to be fine, but there is a simple quirk with the programming language C++, that is causing "interesting" effects.

For the curious:
The position is only updated for X (it should move correctly).
Y, Z both always think they are at the last position set by other ways like homing.
If you repeatedly want 1mm on Y, it first moves 1mm (if the position happened to be 0), then it wants to go to 2mm but it thinks it's still at 0, so it moves 2mm, then 3mm etc.
If you first drive Y and then X, X moves correctly but Y moves also move the same distance each time, because it thinks, it still didn't arrive.

[thinkyhead]

In all, quite the mess, so while the theory behind the spitting up seems sound, the implementation has some gremlins that definitely needs more real-world tests in a separate branch before merging.

Ah, sorry for that! It will still live at backup_1_split_first so hopefully there's a simple patch that can be made to fix its "quirks."

in fact the implementation of the feature seems to be fine, but there is a simple quirk with the programming language C++, that is causing "interesting" effects.

I'll have to peek at the code to see why X is updating but not Y. Definitely unexpected…