[BUG] Homing Backoff Runtime Error

[rflulling]

Homing backoff, runtime error

Steps to Reproduce:
uncomment "#define HOMING_BACKOFF_MM { 10, 10, 0.1 } // (mm) Move away from the endstops after homing" in a current version of the nightly build.

Note: have not downloaded again since 9/4/2019 to see if there is a change. It is possible this a bug already addressed. Less it be a conflict with another option unknown.

No Files other than Configuration and Configuration_Adv have been edited.

Expected behavior:
With this uncommented, in previous iterations, the bed will raise and perform normal XYZ zero and self calibration. Then move away from Zero.

Actual behavior:
As of this build, uncommenting this line will fail the build.

sketch\src\module\motion.cpp: In function 'void homeaxis(AxisEnum)':
sketch\src\module\motion.cpp:1661:32: error: 'Z_PROBE_SPEED_FAST' was not declared in this scope
line_to_current_position(Z_PROBE_SPEED_FAST);
^
exit status 1

Additional Information

Custom Build dual direct large format
PSU_NAME "Non-ATX 360W 24V 15A"
Controller: Makerbase MKS Gen 1.4
Driver: Todd Grace A4988
Firmware: Marlin BugFix-2.0.x (09/04/2019 20:44)

64bit Windows 7pro
Gigabyte GA-H55M-52H
Intel 650 i5-3.2Ghz, 8GB XMP DDR3, 1TB SATA3
XFX ATI R7 260 w/2GB DDR5

Link to printer is USB2.0 Intel chip set I believe.

• I have included a zip with the full nightly build just in case it contains a bug particular to that build.
  MarlinBugFix-20X-201909042044.zip

• Provide pictures or links to videos that clearly demonstrate the issue.
  

[sjasonsmith]

I think it changed in #14972. You should be able to build by uncommenting the following line in Configuration.h:

//#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)

[rflulling]

I operate without a probe. I try to keep all everything turned off that it will not complain about being turned off. But testing to see if it will compile.

Nope. Sorry. Failed compile.

Same error.

[sjasonsmith]

Oops, I told you the wrong line. You need to uncomment the line that defines Z_PROBE_SPEED_FAST.

[rflulling]

Why is this required now? I don't even use a Z-Probe.

Heck lots of stuff seems to be broken, like manual LCD bed leveling. So I keep those functions turned off. No point cluttering my control menu with junk I can't or don't use.

---

So it seems that some one... bound these functions:

#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z
to
#define HOMING_BACKOFF_MM { 10, 10, 0.1 }

So now homing backoff cannot be used without the Z Probe Fast Home option enabled. But Z Probe Fast Home, has no ties to Homeing backoff and works regardless.

I still feel this is a bug as the firmware should be using whatever has been defined to detect home, be it an endstop or a probe and not suddenly requiring a probe. If this function now requires a probe. Some one needs to add those notes either in the Wiki, or in the config file as a comment.

[sjasonsmith]

I think that change will also cause the X/Y backoff to use Z_PROBE_SPEED_FAST as well, which doesn't seem correct. Backoff is normally only a couple millimeters, but if anyone uses a large backoff it would be noticeable. For many printers that XY backoff would run at about 4 mm/s rather than the old bump speed, which would probably usually be 25-50mm/s.

[rflulling]

in my setup (and you can see it from the uploaded firmware), I have the bumps and the back-off active. Off the top I don't recall what the bumps do. But in going home the machine will find home quickly, then more slowly do it again, to get a very precise setup. If I had a very accurate Z-Probe, it would be good to be able to use that on the second bump. But I don't, so it should be using the switch, which seems to be working as far as I can tell. Now, once the second bump is set and the machine should be Zero to within 0.05mm of each home, the machine will now Backoff, 10mm from each edge as a safety. And yes, I recognize this is NOT a hard offset, those tend to create more complications than they resolve. I have clips on my bed and the head is able to run past the clips. The Z should now lower slightly to take any tension off the head mount if any at all. Plus this avoids contact with the build plate during initial warm up. All in all, backoff is not a requirement as I can script the behaviors. But it's a great tool to have to simplify the mess. And helps me to avoid accidentally smashing the head into clips when starting a print or calibration.

All in all the point of the post was to say, "Hey! Something changed and it was unexpected!"

Thank you SJasonSmith, you helped identify how to get my setup going again, and as such further highlighted the bug. From my point of view this is resolved. But as a bug it is not. Unless some one with greater insight into the code would rather us believe this is a feature... (yes I deal with programmers at work, and bugs are often features so they don't have to be fixed...)

[rflulling]

I should give the nightly build a download again tonight and see if this has changed. Update as needed here. -More to come.

[sjasonsmith]

I think that change will also cause the X/Y backoff to use Z_PROBE_SPEED_FAST as well, which doesn't seem correct. Backoff is normally only a couple millimeters, but if anyone uses a large backoff it would be noticeable. For many printers that XY backoff would run at about 4 mm/s rather than the old bump speed, which would probably usually be 25-50mm/s.

I finally got around to trying this out. There is a real problem, although it isn't what I had expected.
The backoff speed is actually too fast for X and Y. This is because Z_PROBE_SPEED_FAST is defined in mm/m, and this is passing it to a function expecting mm/s.

I'm testing a fix for this and the original issue right now. I'll post a pull-request soon.
One risk is that the old fix was effectively raising Z at it's maximum axis speed, rather than the intended Z_PROBE_SPEED_FAST. It is possible that changing this to use Z_PROBE_SPEED_FAST correctly will cause the original BLTouch issue to return.

[sjasonsmith]

In my experiments, it seems that the changes in #14972 have no real effect if your machine is freshly booted, because the feedrate defaulted to 1500mm/m. It was not using the bump speed as the pull request suggested, it was using feedrate_mm_s, which seems to be unchanged by the prior fast/slow homing moves.

If you execute a slow move prior to G28, then you get normal-speed homing, but slow backoffs matching the prior move.

[rflulling]

Happy to help identify an issue. Not wanting to break the software... Just feels like binding the zprobe should be an if enabled function that can be disabled not required. That way no changes to the values are needed at all. Though notes warning what value might break it, would also be nice. :)

…

On Wed, Sep 18, 2019, 2:58 AM Jason Smith ***@***.***> wrote: In my experiments, it seems that the changes in #14972 <#14972> have no real effect if your machine is freshly booted, because the feedrate defaulted to 1500mm/m. It was not using the bump speed as the pull request suggested, it was using feedrate_mm_s, which seems to be unchagned by the prior fast/slow homing moves. If you execute a slow move prior to G28, *then* you get normal-speed homing, but slow backoffs matching the prior move. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15221?email_source=notifications&email_token=AI2WIQSRJ66W2JB6AR5KCA3QKHNR7A5CNFSM4IVN7H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD67FPDI#issuecomment-532567949>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI2WIQS22VHEB7UX2GZBJ43QKHNR7ANCNFSM4IVN7H7A> .

[sjasonsmith]

@rflulling, my pull request was just merged into bugfix-2.0.x to address this. Can you try it out and see if it resolves your concerns?

[rflulling]

Am running on a copy from Sat? Though did not try to disable Z probe yet. So far it has been running and stable with the probe function active though I have no probe and have no other related functions active. Will download a fresh copy and work in the settings tonight. Thank you.

…

On Wed, Sep 18, 2019 at 8:37 PM Jason Smith ***@***.***> wrote: @rflulling <https://github.com/rflulling>, my pull request was just merged into bugfix-2.0.x to address this. Can you try it out and see if it resolves your concerns? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15221?email_source=notifications&email_token=AI2WIQSLTDFE3JDGSNSG75DQKLJT3A5CNFSM4IVN7H7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7B5QBI#issuecomment-532928517>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI2WIQT2QD7HXQE47LCREBLQKLJT3ANCNFSM4IVN7H7A> .

[rflulling]

Downloaded fresh 2.0.x version........ 09/19/2019.....

I wonder if I am the only one to use WinMerge to expedite Config setup? No it is not automated. Least not the editing... Only the compare.
-Lets me snoop in all the other changes, even if I don't understand what they do. I can compare the full code of every document in the firmware in seconds. ;)

Transferring settings.
Disabling "#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z"

Have a print running. But, Verify compile, looks good, no errors.
Unless I can break it, I will say fixed. Upload after print.

[sjasonsmith]

Have a print running. But, Verify compile, looks good, no errors.
Unless I can break it, I will say fixed. Upload after print.

Did you have a chance to upload and try the new firmware? If it is ok, can you go ahead and close this?

[rflulling]

will add to if anything new pops up. Otherwise, yes looks good right now. Thank You for the fix.

[rflulling]

Just discovered one more lurking that I did not catch. Is related.
This error is generated with everything off that does not need to be on. -Just be sure there was no other cause.

//#define Z_PROBE_LOW_POINT -2 // Farthest distance below the trigger-point to go before stopping

[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.