Marlin: Printer acting very odd after bringing down Dec 3rd commits
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.
HekTron802
All 21 comments
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.
HekTron802
on 3 Dec 2017
I bet it has to do with what I wrote in PR #8611.
Can you try to revert commit https://github.com/MarlinFirmware/Marlin/commit/3a97de52ef6bc178e34af54db70f803b4d6ab451?
hg42
on 3 Dec 2017
@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?
HekTron802
on 3 Dec 2017
you may use PR #8611 in the title, otherwise I find it very descriptive
hg42
on 4 Dec 2017
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!
thinkyhead
on 4 Dec 2017
Sounds good @thinkyhead, I give it a go later tonight or tomorrow morning.
HekTron802
on 4 Dec 2017
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.
HekTron802
on 4 Dec 2017
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.
fiveangle
on 4 Dec 2017
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.
hg42
on 4 Dec 2017
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…
thinkyhead
on 4 Dec 2017
@thinkyhead we seem to have missed each other several times now at different communication "channels", I concentrated all my investigation on the PR #8611 because I thought this has the most information gathered. Please look there for the reason and solution. I could also add a new PR including the old one, but this doesn't look right to me, because I only added a little piece to it. I think you should add my little patch yourself, right? it's also on #8611
hg42
on 4 Dec 2017
we seem to have missed each other several times now at different communication "channels",
This is the first issue I visited today. I'll have it patched shortly, then apparently the "split planner move" patch will be good to go!
thinkyhead
on 4 Dec 2017
nice...
hg42
on 4 Dec 2017
@thinkyhead
This is the first issue I visited today
sorry, I don't want to push you...I see you are very active with very different topics, technical and non-technical...
we are in different time zones (you have 13:40 and I have 22:40 now) but even if we are both online, our communication is heavily overlapping, because we choose different places to write... :-) and it's probably my fault... I am getting so much mail from Marlin, that it's difficult to see your's in between. I guess I have to setup some filters.
hg42
on 4 Dec 2017
Oh yeah, there is a lot of Marlin traffic these days! If I were to turn on email notifications I'd be so swamped… As it is today I'm hit-or-miss because my bloody charger died. Right now I'm plugged in at an Apple Store. Maybe I'll get a new charger while I'm here.
Thanks to your patch I can get back to focusing on the 1.1.7 release notes. I hope we can have it out tonight and say _hasta la vista_ to 1.1.6.
thinkyhead
on 4 Dec 2017
@thinkyhead your awesome...(and please don't allow all this activity to let you burn out :-) )
hg42
on 4 Dec 2017
I did some testing with the updated code for "split first planner move" (000818f and 3abd307) and everything is working great. Thanks!
HekTron802
on 5 Dec 2017
@hg42, I got an e-mail from you on this issue, but your comment isn't showing up for some reason. I'll paste it
@HekTron802 are you sure?
@thinkyhead when I merged the bugfix-2.0.x branch, I got a ramp down/ramp up behaviour between the split moves. I think the reason is the moves_queued > 1. At least if I remove the "> 1", I get continuous moves again. Can you have a look at it?
Yes, it's working fine for me but I am using 1.1.X_bugfix. Last I checked 2.0.X_bugfix hasn't been updated for this.
I'll reopen this issue, in case anything pops up later in the 2.0.X world. Hopefully we can close it quickly as there are now 666 issues opened. Make sure to say your prayers tonight! :-P
HekTron802
on 5 Dec 2017
I guess I mixed up some source versions when looking on github with my smartphone.
It's also too late now. Will go to bed.
I'll have a deeper look tomorrow.
And praying... :-)
hg42
on 5 Dec 2017
@HekTron802 I was confused, because the repo changed in between, thinkyhead updated both branches
hg42
on 5 Dec 2017
In general... Both branches are being kept very closely in synchronization right now.
Roxy-3D
on 5 Dec 2017
Related issues
otisczech
·
3Comments
Matts-Hub
·
3Comments
pubalan12
·
4Comments
ceturan
·
4Comments
ShadowOfTheDamn
·
3Comments
Most helpful comment
This is the first issue I visited today. I'll have it patched shortly, then apparently the "split planner move" patch will be good to go!