Marlin: M48/G29 broken in RCBugFix

[gcormier]

Just flashed RCBugfix. Houston, we have a problem.

G28 - homes no issues.
M48:

1) Double touch is enabled. Performs first touch (with BLTouch pin extended).
2) Pin does not redeploy.
3) Printer changes X/Y?! Hit panic button as the printer will smash through axis limits.

Was fine until I flashed the latest.

Output

17:28:50.827 : N17 G28_37
17:28:50.831 : echo:Active Extruder: 0
17:29:06.992 : echo:Active Extruder: 0
17:29:06.996 : X:114.00 Y:157.00 Z:5.20 E:0.00 Count A: 21680 B:-3440 Z:2080
17:29:07.499 : N23 G28 Z0_104
17:29:07.504 : echo:Active Extruder: 0
17:29:14.796 : echo:Active Extruder: 0
17:29:14.801 : X:114.00 Y:157.00 Z:5.20 E:0.00 Count A: 21680 B:-3440 Z:2080
17:29:31.626 : N32 M48 V4 P5*41
17:29:31.631 : M48 Z-Probe Repeatability Test
17:29:31.632 : Positioning the probe...
17:29:34.819 : Printer reset detected - initalizing.

[gcormier]

In action : https://goo.gl/photos/kMHe6mGiboTDuS9J7

EDIT: Actually, lots is broken in this one :)

[Roxy-3D]

I'll check it out in the morning.

[gcormier]

Thanks! G29 also broken straight out of the gate - crashes on the X or Y axis (can't tell which is first).

[Roxy-3D]

Thanks! G29 also broken straight out of the gate - crashes on the X or Y axis (can't tell which is first).

Can you double check your Configuration.h file and make sure there isn't an obvious mistake?
This almost sounds like the machine can't home. And that behavior doesn't care about UBL's Mesh.
You can also build the firmware with the Debug options available, and turn on all flags with a 255 value. (UBL has extra debug flags available.)

[gcormier]

Sure I can flash the stock one. This is the same configuration that worked
on an rcbugfix from sept 22.

G28 works without any problems.
On Mon, Oct 10, 2016 at 8:56 PM Roxy-3D [email protected] wrote:

Thanks! G29 also broken straight out of the gate - crashes on the X or Y
axis (can't tell which is first).

Can you double check your Configuration.h file and make sure there isn't
an obvious mistake?

This almost sounds like the machine can't home. And that behavior doesn't
care about UBL's Mesh.
You can also build the firmware with the Debug options available, and turn
on all flags with a 255 value. (UBL has extra debug flags available.)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4995#issuecomment-252784156,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIABdwAsx5Nn0U2fa7GYeUXKGHsUajvWks5qyt6pgaJpZM4KTAvH
.

[Roxy-3D]

OK... I did merge some reasonable looking changes that where in a Push Request a few days ago. If you back those out, is it OK? If so, we need to revert that 'merge'.

[gcormier]

Could you let me know which one that is, and I'll try it out?

I just spent 45 minutes rebuilding my config from a clean RCBugFix clone and just got it making sense... almost at the point I can keep working at it. I did a quick G29, and it did go in a completely opposite X/Y direction then on my 'broken' build, so I have very little clue what's going on in that regard right now. Also I'm not even sure I have the same configs for the bed levelling...

I'm wondering if head crashing on my broken build is due to invalid offsets for my probe... too tired to figure it out now, tomorrow I'll try to spend some more time on it.

[gcormier]

Alright, so G28/G29 is working on a clean build.

However, one interesting note, the BLTouch issue that @thinkyhead fixed up around Sept 22 is back - the BLTouch probe hits the bed before the bed has been lowered enough.

[Roxy-3D]

I did a quick G29, and it did go in a completely opposite X/Y direction then on my 'broken' build, so I have very little clue what's going on in that regard right now.

The only thing that controls axis direction are these lines in the Configuration.h file:

// Invert the stepper direction. Change (or reverse the motor connector) if an axis goes the wrong way.
#define INVERT_X_DIR false
#define INVERT_Y_DIR true
#define INVERT_Z_DIR true

However, one interesting note, the BLTouch issue that @thinkyhead fixed up around Sept 22 is back - the BLTouch probe hits the bed before the bed has been lowered enough.

Yes. The BLTouch stuff is not in the UBL Branch yet. But you should be able to configure it with the same numbers that get setup in Conditionals.h.

[gcormier]

@Roxy-3D This is not the UBL branch, just plain regular RCBugFix unfortunately.

[gcormier]

Bah. Let me close this and figure out what's going on before I take this further lol.

[gcormier]

Okay, confirmed.

G28 : works.

G29 : broken. Crashes head.

M48 : broken. Does a Z probe, and then start to move X/Y axis. I think this is what we should focus on, as why would M48 move X/Y axis? It never does that. Also odd, is it only does a SINGLE probe, then starts moving. It does not do double touch. (M48 P5 V4)

This is on RCBugFix as of 5 minutes ago.

Configuration.h.txt

[Roxy-3D]

Right now, UBL and RCBugFix have identical code for M48. M48 works just fine in the UBL Branch. (I literally merged those user supplied changes into RCBugFix, and then I cut and pasted its updated M48 code into UBL. )

I can try to cobble a Configuration.h file together later today and try RCBugFix. But the fact it is not doing a double touch doesn't sound right. Is it possible this might be a BLTOUCH issue????

[gcormier]

I mean, it could be, although I don't think @thinkyhead has made any BLTouch changes since when we were working on it late September. I do try to check RCBugFix pulse every few days to see what's new.

Unfortunately I don't have enough knowledge of the code to theorize further... but I can provide testing for sure.

What's odd is G28 is working perfectly fine, including double touch. If G28 was crashing somewhere then I'd obviously look to my config further.. it's the fact that G28 works but the others don't that (to me) indicate a bug...

I do see a couple commits regarding M48 and G29 but no clue on how these would affect.... I wonder if I can try to revert those successfully in my fork to see if M48 is fixed?

[Roxy-3D]

I do see a couple commits regarding M48 and G29 but no clue on how these would affect.... I wonder if I can try to revert those successfully in my fork to see if M48 is fixed?

Yes. That would be a good thing to do. But those changes were mostly made for the purpose of cleaning up the output and to report the probed location more accurately. I didn't see anything 'dangerous' and that is why I merged the changes.

Still... It would be good to get those changes out of the equation and see if you still have a problem.

[gcormier]

Let me see if I can figure out how to do that with GIT :) I might be back.

(I'm targeting 1370d9a on Sept 22, as I believe that's what I've been running successfully for a few weeks.)

[gcormier]

Alright, I did a checkout of 1370d9a, then cherry-pick of my configuration file.. and I can confirm that one is working (some minor BLTouch bed-strikes issues but M48 does not cause any X/Y movement...)

I'm trying to cherry-pick 6335acb..3ed8f83 to add the next days work, but there's conflicts and it's not as straightforward... maybe I'll do another checkout.

[Roxy-3D]

And... This is just a guess... Once you find a 'Stable' BLTouch code set... My guess is if you cut and paste the current M48 code into it, it should work. But of course, the "Proof will be in the pudding."

[gcormier]

1370d9a - working (Sep 22)

eb4fa8a - does not compile. (Sep 24)

9cebbab - broken M48 (Sep 25)

[Roxy-3D]

Have you tried the 'current' M48 in the September 22nd code? I think that should work. (assuming it compiles clean.)

[gcormier]

Okay..

1370D9A, with the full M48 copy and posted, works without any issues (minor bltouch plate-strike issues.. not related to this bug, probably fixed a few commits after 1370D9A)

Which makes some sense.. for G29 and M48 both to be broken, it must be one of the deeper functions, probably to do with probing? And something called by G29/M48 that is not called by G28?

[Roxy-3D]

@Thinkyhead Are the last 3 or 4 posts enough to figure out the issue?

[gcormier]

More details until Thinky shows up...

3ed8f83 also broken.

[gcormier]

6b9bf8e is the dirty commit for M48 issues.

Looks like G29 is separate.

[Roxy-3D]

6b9bf8e is the dirty commit for M48 issues.

I think what you are saying is "The 6b9bf8e commit is the one that broke M48." Is that correct?

[gcormier]

Yes, sorry :) I am on the hunt for G29.

[gcormier]

Hmm, okay so 6b9bf8e also breaks G29... but if I checkout RCBugFix and revert that change, while it fixes M48, it does not fix G29. EDIT : Don't let that lead you astray... stick to the broken commit lol.

[thinkyhead]

Thanks for looking into this. I have been strained for the time and attention to get into it. But something I changed pretty recently did break G29 – and it seems to be specific to BLTOUCH – as for some reason it fails to raise between probes. The only way I can gain more insight into this is to provide more logging code. I will try to do that soon.

[gcormier]

Sounds good! I'll be here to help troubleshoot.

[bgort]

I'm going to pull the latest RCBugFix to see if I have this problem. Everything was fine as of a few days ago.

[bgort]

Just pulled 0921c7d (the latest as of now), and no problems here with any of G28, G29, or M48.

My configs, in case they're of any help:

• Configuration.txt
• Configuration_adv.txt

[gcormier]

Interesting.

I think the first major different for @thinkyhead would be I am COREXY, you aren't. (Again, I know little of the underlying code, perhaps that is insignificant.)

[Roxy-3D]

I'm starting to question if we have some bad BLTouch probes out there. I think it would be helpful to put an LED (with a resistor in series) on the signal pin of the BLTouch. Then you could verify it is switching back and forth at the right times.

[gcormier]

But a bad BLTouch probe would not cause M48 to start drifting in the X/Y axis... and the probe definitely triggers, otherwise the head would crash.

The BLTouch does have a red led when it is retracted. It turns off when deployed, and goes back to red when triggers.

[thinkyhead]

So if you revert just these changes in Marlin_main.cpp it fixes the M48 issue for you?

[Roxy-3D]

OK. I don't have a BLTouch. If the LED blinks at the right time it is probably doing the right thing.

[bgort]

I think the first major different for @thinkyhead would be I am COREXY, you aren't. (Again, I know little of the underlying code, perhaps that is insignificant.)

Yeah, I'm not sure either.

[gcormier]

So if you revert just these changes in Marlin_main.cpp it fixes the M48 issue for you?

From my memory yesterday (it was a blur).. I stepped back each commit until I got to one that worked, and that was the commit previous to 6b9bf8e that was working.

(If you have any tips on how to use Git better for my Configuration.h with all these reverts/checkouts... I'm all ears 😄)

[gcormier]

Gave it a shot! I'd like to try and revert that change, but it's just a wall of code for the mergetool and I have no idea what I'm doing unfortunately.

[gcormier]

I hooked up the old inductive probe, as there was some suspicion of it being BLTouch related. Same issues!

[Fulg]

I can reproduce the same M48 issue with RCBugfix ca7275a67a429d557d369041c7643128d4a032c4. M48 does a single Z probe then starts moving off elsewhere, I have to turn off the printer to avoid probing outside the bed area. PROBE_DOUBLE_TOUCH is defined. I have a similar config as @gcormier (CoreXY with BLTouch).

This does not occur on the same printer with RC7, where M48 P5 V4 does a double-touched repeatability test at the current position, as expected.

[Fulg]

I'll try a bisect once I get back to try and find the cause (getting good
at redoing my config from scratch!), I'm surprised nobody else sees this
behavior. It could be specific to CoreXY. All I know is, on RC7 M48 works
just fine, but on RCBugfix M48 doesn't, with the same hardware and
configuration; it is quite possible the problem comes from elsewhere.

On 16 October 2016 at 23:15, Roxy-3D [email protected] wrote:

I can reproduce the same M48 issue with RCBugfix ca7275a
https://github.com/MarlinFirmware/Marlin/commit/ca7275a67a429d557d369041c7643128d4a032c4.
M48 does a single Z probe then starts moving off elsewhere, I have to turn
off the printer to avoid probing outside the bed area.

I know this is going to sound very defensive. But M48 calls the standard
(lower level and common) probe routines. If M48 works in some versions of
the firmware, but then flips to not working (and maybe back to working), it
isn't M48. M48 hardly even changes. And in fact, for the longest time M48
didn't work with Delta printers. Only 8 or 10 lines of code had to be
changed to get it to work with Deltas.

So... If you could look at what changed between those working and
non-working M48's, most likely something changed in the way Z-Probe's
happen.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4995#issuecomment-254103437,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADKqVRoJJ96IXr4felxkcxaC3FhLz6yrks5q0ug2gaJpZM4KTAvH
.

[FHeilmann]

I have this problem as well on my CoreXY machine (RCBugfix branch), however I'm using an inductive Probe for probing.

[Roxy-3D]

It could be specific to CoreXY. All I know is, on RC7 M48 works just fine, but on RCBugfix M48 doesn't, with the same hardware and configuration; it is quite possible the problem comes from elsewhere.

I have this problem as well on my CoreXY machine (RCBugfix branch), however I'm using an inductive Probe for probing.

My guess is the problem is down in the probing sub-system. M48 uses the same probing calls that G28 and G29 use. A number of changes have been made to that since RC-7 started. Some of those changes were to keep the probe from raising too much.

This may be showing up on CoreXY printers. But my guess is it isn't related to the printer being a CoreXY. I guess we will know soon enough when you find the change that causes this.

[Fulg]

I can only confirm what has been found previously by @gcormier: 6b9bf8e8fe409d59a8b52bb26230742a0c4744b5 by @thinkyhead is the cause of the M48 issues. At cc639d7d9cee71ffd79227f557b9b25895def91e, M48 works fine.

Interestingly, while at 6b9bf8e8fe409d59a8b52bb26230742a0c4744b5, disabling CoreXY mode solves the issue (M48 does not move between probing attempts), so you will not see this issue on cartesian hardware.

[Roxy-3D]

M48 does not move between probing attempts, so you will not see this issue on cartesian hardware.

It does with the 'L' or 'S' options... But Good Work! I'll dig in a little deeper in the morning.

[Fulg]

It does with the 'L' or 'S' options...

To be perfectly clear (in case it matters later), all my tests were done with G28 followed by M48 P5 V4.

[szafran81]

Hi guys,

Having the same problems here.
Didn't try to use M48.
My problems are with G29.
G28 works fine in RC7 and RCBugFix (current).
G29 works as expected on RC7 but not on RCBugFix.
When it starts probing it doesn't move the head up between probes in the first pass of the X axis, then when it goes to make the probing in the second row it starts to move the head up - and the same with the third row (I'm using 3x3 grid).

Sorry if that sound weird. Don't know how to explain it in a different way. But if there's need I can make videos and post them here.

I'm using a Mendel90 - so it's not CoreXY specific.

EDIT: Just got home and made the videos: https://goo.gl/photos/jVngcGJYmda9vsiV9
One is from RC7 and the other from RCBugFix 8ddd039
Tested RC6 and it works like RC7. Also RCBugFix makes my Z motors make weird noises.

[gcormier]

Anything I can do to help out or contribute to this issue?

[Roxy-3D]

I think we are going to have to find the specific changes that caused things to break. And then examine those changes very carefully to figure out what the error is that got introduced.

Can you do a binary search to find where the behavior was correct. And then the exact change that made things go sour? That would be super helpful to get this fixed.

[Fulg]

Both @gcormier and I already identified 6b9bf8e8fe409d59a8b52bb26230742a0c4744b5 as the source of the M48 problems; I did not dare do a G29 on RCBugFix. Going back to the previous commit, cc639d7d9cee71ffd79227f557b9b25895def91e, solves the M48 issues. Maybe @szafran81 can confirm if this solves the G29 issues as well.

As further proof, if I revert the change in Marlin_main.cpp from 6b9bf8e8fe409d59a8b52bb26230742a0c4744b5 in the current RCBugFix (8ddd039e683ef6a1dceab19562c3c34c976b111e), the M48 issues are resolved. G29 still tried to probe outside the bed area, but I do not have a known-good config with RC7 yet.

[Roxy-3D]

I did not dare do a G29 on RCBugFix.

I understand. What I do when I'm not sure about new code is I raise the Z up 50mm or 75mm. I then give it a G28 and when it starts doing the Z-Probe, I reach under the probe and trigger it so it is well above the bed. And then I'll do what ever other automated probing like M48 or G29 and continue to reach under the probe and manually trigger it. Once I know it is going to behave correctly, I let it do it for real and probe the glass.

Both @gcormier and I already identified 6b9bf8e as the source of the M48 problems;

OK! So, just let me confirm this by asking it a different way: If you remove the changes in 6b9bf8e the behavior becomes correct?

And a followup question: What happens if you take the most recent RCBugFix and remove those changes? Does everything else seem to be reasonable when homing and probing?

The big problem is ThinkyHead is so busy with other stuff that it might be helpful if we can take this off of his list of things to figure out. If we know the 6b9bf8e changes can be taken out of the current RCBugFix and that makes things better, I feel confident doing that...

[Fulg]

And a followup question: What happens if you take the most recent RCBugFix and remove those changes? Does everything else seem to be reasonable when homing and probing?

Yes! That is exactly what I said in my last paragraph, I already tried before replying. Removing 6b9bf8e8fe409d59a8b52bb26230742a0c4744b5 from the latest RCBugFix solves the M48 issues for me.

I do not have a working RC7/RCBugFix setup for testing G29, for some reason it tries to move way past the configured bed dimensions even though it should limit itself to the defined bed size minus MIN_PROBE_EDGE, but that's not what happens. Once I have it working in RC7 (with known good probe offsets) I'll try again in RCBugFix.

[Roxy-3D]

@Fulg Can you post your Configuration.h file? Maybe I can spot an issue with it. (Because I would really like to see you get your stuff working with the current RCBugFix without the 6b9bf8e changes. That would make me feel comfortable enough to make the change.)

[Fulg]

Here is my Configuration.h file. As I said I may have forgotten to change some default setting to get G29 to work, I did not put in the time to make it work first in RC7. As far as I know the probe offset is OK (Z safe homing is correctly moving the probe to the middle of the bed, not the hotend).

[szafran81]

Sorry for the late response.
Just getting to uploading and checking 6b9bf8e and cc639d7 and some other things (eg. I'm seeing wierd things here - like the auto leveling making corrections in the wrong direction of the bed - my bed is lower towards X0 Y0 and the ABL is printing the lowest towards X_MAX Y_MAX).

EDIT: Sorry - I don't think that I will be of much help - both of those commits don't compile for me properly.

EDIT2: Regarding wrong ABL corrections during print - unfortunatelly I was correct. Tested from RC6 until 627f9d5. This is what I'm getting from current RCBugFix after G29:

G29 Auto Bed Leveling
Bilinear Leveling Grid:
0 1 2
0 +0.63 +0.38 +0.08
1 +0.50 +0.20 -0.39
2 +0.24 +0.25 -0.44

And the print heads height is corrected in the wrong direction. So i'm getting totally squished filament on one side of the bed and flying in the air filament on the other.

EDIT3:
Two prints done one after another:
ABL enabled: https://goo.gl/photos/iVt2ErR11gWtEMG29
ABL disabled: https://goo.gl/photos/fwJLrZJ9DECRusny9

So for now I'm going back to printing without G29.

[Fulg]

I have since debugged my leveling setup with RC7 and have a working configuration with G29 over there. Unfortunately RCBugFix does not work at all with the same config and tries to move outside the defined probe areas immediately, even after reverting 6b9bf8e8fe409d59a8b52bb26230742a0c4744b5. It looks like M48 and G29 are separate issues after all.

For reference, I have attached my working configuration for RC7 and the
non-working one for RCBugFix.

I have also attached the output of M111 S32 before the G29 for both versions. The log for RCBugFix is short because the move went beyond the printer's physical limits and I had to cut the power to prevent damage. RC7 works flawlessly and probes all 9 points correctly.

G29_debug_RC7.txt
G29_debug_RCBugFix.txt

[thinkyhead]

Hmm, I have been dubious about https://github.com/MarlinFirmware/Marlin/commit/6b9bf8e8fe409d59a8b52bb26230742a0c4744b5 for a while, but just needed some confirmation.

The idea with this change was: If we're just getting the current_position from the steppers after an endstop or probe move, there should be no need to re-sync the planner to the current_position. The stepper.count_position[] ought to correspond. If the steppers got interrupted, then re-syncing the planner to the steppers _should_ do the trick.

However, I do see the complications this introduces. For one thing, the kinematics are always going to be imperfect, so conversion from stepper-counts to millimeters and then back again will necessarily change the stepper positions.

So, I suggest finding all instances where I used planner.sync_from_steppers() and revert them back to using sync_plan_position() or SYNC_PLAN_POSITION_KINEMATIC().

[gcormier]

Huzzah. That PR fixed it up on my printer :)

[gcormier]

I'll give it a shot. So literally those occurrences across the entire code
base?
On Sat, Oct 22, 2016 at 4:15 PM Scott Lahteine [email protected]
wrote:

Hmm, I have been dubious about 6b9bf8e
https://github.com/MarlinFirmware/Marlin/commit/6b9bf8e8fe409d59a8b52bb26230742a0c4744b5
for a while, but just needed some confirmation.

The idea with this change was: If we're just getting the current_position
from the steppers after an endstop or probe move, there should be no need
to re-sync the planner to the current_position. The
stepper.count_position[] ought to correspond. If the steppers got
interrupted, then re-syncing the planner to the steppers _should_ do the
trick.

However, I do see the complications this introduces. For one thing, the
kinematics are always going to be imperfect, so conversion from
stepper-counts to millimeters and then back again will necessarily change
the stepper positions.

So, I suggest finding all instances where I used
planner.sync_from_steppers() and revert them back to using
sync_plan_position() or SYNC_PLAN_POSITION_KINEMATIC().

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4995#issuecomment-255551247,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIABdz4OPK7MqXssKwpCXjIk4ZBb6Axfks5q2m7sgaJpZM4KTAvH
.

[thinkyhead]

So literally those occurrences across the entire code base?

@gcormier Yes: both!

But, the fix has already been merged.

[gcormier]

Wow, super weird - I sent off that email a few days ago :) It never showed up so I said screw it and did all of them :P