Cnc4newbie Z upgrade issue - limit switch hit

CNC Machines Shapeoko
1

Hi all,

Hoping someone can shed some light on a problem I am having right after upgrading the z carriage. (https://cnc4newbie.com/store/en/upgrade-kits/shapeoko/shapeoko-3-square-linear-bearings-slider-p105c77c67/)

After installation, and running the commands below, I am running into an issue with a limit switch trip alarm.

I ran these commands before homing the machine for the first time after the upgrade.

$3=2
$20=1
$102=200
$112=2000
$122=750
$132=150

Went on to initialize the machine and that’s where I ran into an alarm; Limit switch hit.

Machine homes, Z, X, and Y without issue, then proceeds to move to the front of the machine for the Bitsetter op. Hit Resume, machine moves above the Bitsetter, then travels 0.400" down and the alarm pops up.

If I go into the settings and disable the bitsetter, machine homes, and has full range of motions in all directions without issue.

Is there something else that needs to be configured in CM for this to work? Running v513 for reference. Only thing changed from a hardware perspective was the Z carriage, bitsetter was working fine prior to this.

Thanks, Mark

2

Hi @mar80,

I hope you don’t mind a bunch of questions to try and narrow it down to possible causes:

  • I assume this behavior is perfectly repeatable ?
  • did you move the BitSetter position on the front rail slightly while upgrading ?
  • when you disable the BitSetter, can you jog manually to the top of the bitsetter plunger and jog Z up and down there with no errors ?
  • what is the exact error message text?
  • does this still happen if you disable soft limits by setting $20 to 0 ?
3

Hi @Julien,

  • I assume this behavior is perfectly repeatable ?
    -Yes it happens every time.

  • did you move the BitSetter position on the front rail slightly while upgrading ?
    -No, the bitsetter hasn’t moved

  • when you disable the BitSetter, can you jog manually to the top of the bitsetter plunger and jog Z up and down there with no errors ?
    -Yes, I can move the carriage over and right down to the bitsetter

  • what is the exact error message text?
    -Alarm2 is displayed in the log, and Limit switch hit is displayed in the foreground of CM

  • does this still happen if you disable soft limits by setting $20 to 0 ?
    -Disabling the soft limits, then homing works as expected, and the cutter is probed off the bitsetter as is is supposed to.

Any reason why the Soft limits would be causing this problem??

Thanks for the quick reply!

1 Like
4

I had a feeling it would be the soft limits (which the Alarm:2 confirms, it’s the GRBL alarm for “G-code motion target exceeds machine travel”, I suspect the “Limit switch hit” message in the foreground of CM is incorrect/misleading)

Can you re-enable soft limits, retry, and at the point where the error happens make a note of the current X/Y/Z values in machine coordinates? (click on the position title in CM to switch between relative coordinates and machine coordinates)

And also check what the values for $130 and $131 are ?

Somehow, while doing that plunge for probing on the BitSetter, the machine sees a G-code command that tells it to go to some position that GRBL thinks is beyond the defined soft limits ($130, $131, $132)

5

Here is where the machine halts, with both the position displayed, and clicked over to machine position in CM:

position:

x:347.725
y:-96.800
z:-14.600

Machine position:

x:-25.500
y:-388.000
z:-15.000

I dumped all the options from GRBL:

$$
$0=10
$1=255
$2=0
$3=2
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=1
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=5.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=200.000
$110=5000.000
$111=5000.000
$112=2000.000
$120=400.000
$121=400.000
$122=750.000
$130=845.000
$131=850.000
$132=150.000

1 Like
6

Thanks. Well I’m scratching my head. If manual jogging down to BitSetter level works, that $132=150 is adequate, and I don’t see why the BitSetter probing move would be different, but then again I’m not sure what CM does behind the scenes during that specific sequence. It does enforce its own soft limits during jogging, but since you can jog ok, that’s not it either.

Since the CNC4Newbies Z axis is not in the list of what CM knows about, what base setting is currently selected in CM for Z-axis type (before manually updating the few GRBL params that needed to be updated) ? I would assume it’s the standard/stock Z axis since this is what you had before.

It would be interesting to see what happens if you select “HDZ”, apply that configuration, re-modify the 6 specific GBRL params for the CNC4Newbie axis, if you feel like doing that test.

I’ll try and use your exact GRBL settings + CM setup on my machine tonight(EDIT: machine is down, it’ll have to be later), to see if I can reproduce this behavior.

In the meantime, may I ask you to copy/paste the full content of the Log window corresponding to machine initialization with BitSetter enabled and soft limits on, up to the moment it fails ?

Anyway you already have a workaround (disabling soft limits, which I do very often anyway, I don’t like them). I would also have recommended you try a different G-code sender to see whether that’s a CM-specific issue, but that 's more effort than needed for now.

1 Like
7

Hi Julien,

Here are the logs, with and without soft limits enabled for the homing process:

Soft Limits disabled:

N0 M5
ok
N0 G4P0.005
ok
N0 G4P0.005
ok
$h
ok
N0 G4P0.005
ok
N0 M5
ok
N0 G4P0.005
ok
N0 M5
ok
N0 G4P0.25
ok
N0G0Z-5.0000
ok
N0G0X-210.0000Y-400.0000
ok
N0 G4P0.005
ok
N0 G4P0.005
ok
N0 M5
ok
N0G0Z-5.0000
ok
N0G0X-25.5000Y-388.0000Z-5.0000
ok
N0G0Z-15.0000
ok
N0G38.2Z-155.0000F800.0
[PRB:-25.500,-388.000,-95.640:1]
ok
N0 G4P0.005
ok
N0G0Z-91.3300
ok
N0G38.2Z-246.3300F50.0
[PRB:-25.500,-388.000,-95.620:1]
ok
N0 G4P0.005
ok
N0G0Z-5.0000
ok
N0 G4P0.005
ok
N0G0X-210.0000
ok
N0 G4P0.005
ok

Soft Limits enabled:

N0 M5
ok
N0 G4P0.005
ok
N0 G4P0.005
ok
$h
ok
N0 G4P0.005
ok
N0 M5
ok
N0 G4P0.005
ok
N0 M5
ok
N0 G4P0.25
ok
N0G0Z-5.0000
ok
N0G0X-210.0000Y-400.0000
ok
N0 G4P0.005
ok
N0 G4P0.005
ok
N0 M5
ok
N0G0Z-5.0000
ok
N0G0X-25.5000Y-388.0000Z-5.0000
ok
N0G0Z-15.0000
ok
N0G38.2Z-155.0000F800.0
ALARM:2
GRBL_RESET
[MSG:Reset to continue]
ok
Grbl 1.1f [’$’ for help]
[MSG:’$H’|’$X’ to unlock]
$X
[MSG:Caution: Unlocked]
ok
N0 G4P0.005
ok
G92.1
ok
G54
ok
G10L2P1X0Y0Z0
ok
G21
ok
G49
ok
G90
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 M56 T0 F0 S0]
ok
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
N0 G4P0.005
ok
N0 M5
ok
G92.1
ok
G54
ok
G10L2P1X0Y0Z0
ok
G21
ok
G49
ok
G90
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 M56 T0 F0 S0]
ok
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
N0 G4P0.005
ok
M56P1
ok
$$
$0=10
$1=255
$2=0
$3=2
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=1
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=5.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=200.000
$110=5000.000
$111=5000.000
$112=2000.000
$120=400.000
$121=400.000
$122=750.000
$130=845.000
$131=850.000
$132=150.000
ok

I had the regular belt drive Z axis configured and only changed the params when I fitted the new carriage.

I set it to HDZ, re-applied the params with soft limits on, and same result. stalls 0.400" when moving down above the BitSetter. Soft limits disabled, all is ok.

Are there any drawbacks running the machine with soft limits disabled assuming the limits switches are fully operational?

1 Like
8

This probe move takes you, potentially, beyond your soft limit. That’s why you get the error.
If you want to use Motion, disable soft limits. Motion has its own built in protections that try to prevent you from crashing.

I find this interesting, though…

With no limits (what Carbide Motion expects) you probe, retract a little bit (odd value?) then probe down another 155mm from where you are. I don’t know why it needs to probe 155mm again when the last probe was less than 5mm away.

6 Likes
9

I love it when I wake up and @neilferreri has solved the mystery for us! :slight_smile:

Indeed, the default GRBL configuration set by Carbide Motion is with soft limits disabled, and it has its own internal limits it uses during jogging/probing. What I find interesting (and was never curious enough to check before) is that CM uses a 155mm max probing movement when it goes to the BitSetter, when the max travel is configured to be 150mm (hence the alarm, as Neil said, when soft limits are enabled, with CM assuming they weren’t). I suppose the intent was to add some margin to cope for corner cases / modified machines where 150mm would fall a little bit short to reach the BitSetter plunger (imagine setting up your router really high up in the mount, with a really short endmill), and no one noticed that it could cause a problem with soft limits enabled (since that’s not a “supported” configuration officially)

Anyway: running with soft limits disabled is perfectly fine, since this is the default configuration, and if you are using CM, you need to keep soft limits disabled anyway. Not sure why it did not strike me as obvious in the first post.

5 Likes
10

Because you’re run ragged with all the details? :smiley:

3 Likes
11

Thanks everyone, really appreciate taking the time to lend a hand.

Cheers!

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.