[gnea/grbl Issue#719] Z-Axis behavior while homing

#1 – Efratror 于 2019-09-09

Seems like your switch isn’t breaking it’s contact. An other option is changing the pull of setting take a look at issue #563

#2 – DavePfz 于 2019-09-10

I have verified that the limit switch is working.

The motor does not stop and enter the back-off stage at all.

My question is: Does the homing code account for the inversion of the limit switch?

It has been discussed often enough elsewhere, so I won’t get into the various reason of why a NC configuration is more advantageous.

#3 – chamnit 于 2019-09-10

Yes. It accounts for an inversion. There are thousands of users that use homing with an NC config.

You likely have EMI issues and have your homing direction backwards. Alarm 8 means your limit switch has been detected as triggered and fails to back off the switch by the pull off distance setting.

#4 – DavePfz 于 2019-09-11

OK. In spite of following “best practices”, you guys convinced me to get out the scope. It turns out the drivers on the CNC Shield were causing the noise. Nothing but a cap (or a new layout of the board) would fix this. I added 0.1uF caps to each of the limit switch lines. Now, the noise is well below the threshold.

So, at this point, the Z-axis moves up, hits the switch and backs off. All is good – except…

After positioning the Z-axis, neither the X or Y axis move. I get a faint hum and that’s it.

Note, all axes work as expected in jog mode. So, I know that the wiring, etc. is good. Is there something I’ve missed in the setup parameters?

Thanks

#5 – chamnit 于 2019-09-11

Not sure what would cause this particular issue. Please provide your Grbl $$ settings and $I build info output.

#6 – DavePfz 于 2019-09-12

Here is what I get: (Can’t seem to control the font!)
====
$I
[VER:1.1h.20190825:]
[OPT:,15,128]

$$
$0=10
$1=255
$2=0
$3=6
$4=0
$5=1
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=0
$24=25.000
$25=500.000
$26=50
$27=5.000
$30=1000
$31=0
$32=0
$100=400.000
$101=400.000
$102=400.000
$110=4500.000
$111=2500.000
$112=500.000
$120=100.000
$121=100.000
$122=10.000
$130=305.000
$131=520.000
$132=80.000
====
Let me know what else you might need.

Thanks

#7 – DavePfz 于 2019-09-20

Here’s more information. I upgraded my Arduino CNC shield to version 3.51 from Protoneer and then upgraded the drivers to the TB67S249FTG from Pololu. All of this was to get a more reliable system with higher drive capability.

Because of the pin assignments on version 3.51, I needed to go back to the standard grbl with the variable speed enabled. With all these changes the homing works, but…

After the Z-axis homing, it does the back-off and then sits and hums for about 15 seconds. Then starts the X and Y-axis homing process. Once it finds X, it does the back-off and hums again for about 15 seconds. Then it does the Y back-off. (I sort of recall that after the X back-off it does another Z back-off, but I am not sure. I want to get a smooth operation first.)

Thanks

#8 – chamnit 于 2019-09-20

That’s weird behavior but, if I remember right, Protoneer CNC shield v3.51 requires variable spindle enabled. It’s the older clone CNC shields that need it disabled.

#9 – DavePfz 于 2019-09-20

You’re right on that. That was why I went back to the “standard grbl.” (It had been disabled for the clone CNC shield.)

But, why the delays? Any clues as to how I can track it down?

#10 – chamnit 于 2019-09-20

Not much would cause a 15 sec delay other than Grbl trying to move the motors for 15 seconds. Humming usually indicates the motors are stalling. I would check the current setting on your new drivers.

#11 – DavePfz 于 2019-09-20

The drivers have been set to the same current level as the old ones until after I do the initial shakedown. I doubt that it is the current level for two reasons. The first is that the motors respond well to all of the jog functions. The second is that after this delay, the motors move as expected.

Is there any rule of thumb that would help me in selecting suitable values for the locate and search rates? Right now I have them at whatever default was loaded on my system (25 and 500, respectively), but is something like 10% of the maximum a reasonable starting point?

Thanks

#12 – DavePfz 于 2019-09-24

I change the $24 from 25 to 100 and now the homing operation is as expected.

Apparently there is a minimum value before the motors themselves will move.

Now my parameters are:
$0 = 10 (Step pulse time, microseconds)
$1 = 255 (Step idle delay, milliseconds)
$2 = 0 (Step pulse invert, mask)
$3 = 6 (Step direction invert, mask)
$4 = 0 (Invert step enable pin, boolean)
$5 = 1 (Invert limit pins, boolean)
$6 = 0 (Invert probe pin, boolean)
$10 = 1 (Status report options, mask)
$11 = 0.010 (Junction deviation, millimeters)
$12 = 0.002 (Arc tolerance, millimeters)
$13 = 0 (Report in inches, boolean)
$20 = 1 (Soft limits enable, boolean)
$21 = 1 (Hard limits enable, boolean)
$22 = 1 (Homing cycle enable, boolean)
$23 = 3 (Homing direction invert, mask)
$24 = 100.000 (Homing locate feed rate, mm/min)
$25 = 500.000 (Homing search seek rate, mm/min)
$26 = 50 (Homing switch debounce delay, milliseconds)
$27 = 3.000 (Homing switch pull-off distance, millimeters)
$30 = 1000 (Maximum spindle speed, RPM)
$31 = 0 (Minimum spindle speed, RPM)
$32 = 0 (Laser-mode enable, boolean)
$100 = 400.000 (X-axis travel resolution, step/mm)
$101 = 400.000 (Y-axis travel resolution, step/mm)
$102 = 400.000 (Z-axis travel resolution, step/mm)
$110 = 4500.000 (X-axis maximum rate, mm/min)
$111 = 4500.000 (Y-axis maximum rate, mm/min)
$112 = 1000.000 (Z-axis maximum rate, mm/min)
$120 = 100.000 (X-axis acceleration, mm/sec^2)
$121 = 100.000 (Y-axis acceleration, mm/sec^2)
$122 = 10.000 (Z-axis acceleration, mm/sec^2)
$130 = 305.000 (X-axis maximum travel, millimeters)
$131 = 520.000 (Y-axis maximum travel, millimeters)
$132 = 80.000 (Z-axis maximum travel, millimeters)