CM freeze when jog in Z touches limit switch, no error

CNC Machines Shapeoko
1

Annoying little problem, just wondering if I’m the only one…

My procedure when setting up a new job is to jog to my origin, set x,y,z; save then manually jog Z up in order to install the dust boot and to move the bit high enough to not hit anything in case I’ve made (another) mistake :slightly_smiling_face:.

Often but not always if I jog all the way to the top of travel in Z and hit the limit switch CM stops responding. No error, just stops. Then I have to close CM, re open and re home. At this point, after verifying x,y,z are still good I can run the job, turn on spindle and vac and away we go.

Bad limit switch or…?

1 Like
2

Strange that’s essentially my procedure too and never had that issue. Though I was using carbide motion 3 forever, are you using 3 or 4?

3

I have the same problem. Only started happening after I upgraded grbl and carbide motion. I’ve just lived with it.

1 Like
4

Running 4.0.409. And, now that I think of it, didn’t have the issue prior to my update from 403 (I think).

5

I did find once I upgraded to CM4 that if there’s any issue during homing even if you power off the machine the software stays locked in homing mode.

6

I believe this is the default behavior in GRBL 1.1 when you hit hard (and soft) limits. Carbide motion must not surface GRBL alarm messages. Grbl sends something along the lines of [MSG:Reset to continue] to the GUI software. More details here.

If you connect with the nightly version of UGS and tap your Z limit switch you can verify whether or not this is what’s happening.

1 Like
7

Thanks for your input. I have to wonder, if this is “default behavior” in grbl 1.1 it seems virtually all CM users who’ve updated to 1.1 would experience the issue, at least occasionally?

I’m just a wannabe maker/woodworker, don’t know squat about grbl, although it’s on my list, just as soon as I master Fusion 360, VCarve desktop, SO3 setup and tuning…:flushed:.

8

I use Intellig-code…and when I do that, I get an alarm 1 which is “soft/hard limit reached”

It is expected behavior if you have hard or soft limits set.

I try not to trigger my z homing/limit switch as a matter of work flow.

1 Like
9

OK, thanks. I’ll make more of an effort to avoid hitting limit switches when setting up. Had no idea that was a feature.

10

This happened to me today. Totally froze up, no big deal. thought I would close CM and turn off the ShapeOko and restart…
No go… Power cycled the Shapoko again and noticed that I got a “USB device” error notice (Windows 7).
Reboot windows.
No go… Same error. hmmm…

Shut down the PC again, this time also unplugged the USB cable and restarted everything.
Now it works again.

I guess my USB port is still supplying power when the PC is off, so what ever state the ShapeOko controller got itself into from hitting the limit switch really took a hard reset to get it back.

So what the heck happens to the controller when then the Z Limit switch is triggered? Pretty catastrophic what ever it is.

11

It goes into alarm mode — see https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl

12

But why doesn’t throw an error (limit switch) error on the screen?

1 Like
13

happen to me today, shut down CM and was fine. Notice that when I don’t use my machine for a couple weeks, it acts up a bit for a bit.

14

Precisely.

Also, due to my inexperience, I’ve made errors that caused multiple z limit switch collisions that not only threw no errors but allowed me to pause then stop the job whereby the machine homed. I’ve attempted to continue to run jobs after this happens but, as you would expect, z-zero is compromised. The point is, No Error, No Freeze.

Weird.

15

My guess is CM doesn’t put the error on the screen. I use intelligcode, and I get the alarm state displayed.

It’s a critical error, so you have to power off the controller and reconnect the program…re-home as well.

1 Like