Issues with Homing after finished or cancelled job Limit Switches

I’m having issues with the limit switches after I finish or cancel a job. It comes in a couple of different flavors and seems more software related than anything.

I have homing enabled,
-I home and then zero.
-Load the job.
-Jog to my material and set Z and then re-zero all.
-Start my job.

If I cancel the job, or after the job finishes, it tries to go back to machine zero automatically. Several times I have had it sit on the limit switches, such that when I try to jog again, perhaps after powering everything down for the day, I get a “limit Switch Hit” error.

The only thing you can do here is either try and home it(which it can’t because it is on the switch already and throws the error) The software also seems to lock out any jog control, so I can’t move via Carbide Control off the switches to then retry.

Once in this state, the only thing you can do is power it down and manually move the steppers of the limit switches and then re-home. Really frustrating. Any ideas here?

What are you using to send G-code? Version of GRBL? 32 bit or 64 bit computer? On rare occassions, I’ve had to not only restart the machine, but restart my computer. I found that with 64 bit software I had random errors. Reloaded the software with 32 bit version and MOST of the problems went away.

1 Like

I’m using Carbide motion(3.0.368) on a 64 bit win 10 laptop. That said, I’m not sure it is a 64-bit application as it is installed in the x86 programs dir.

It looks like the GRBL version is 0.9g(Installed by the latest build of carbide motion).

If I could pull the gantry on the limits powered, it would home fine. I am only having to power down to not fight the steppers.

I have had one random disconnect about an hour into surfacing my waste board. For that, I had to reboot the controller. “USB device has malfunctioned” error.

I believe Carbide Motion is a 32 bit app which would explain it loading where it did. I don’t use that app, rather I use Universal Gcode Sender. If I cancel the job, the spindle just stops where it’s at, raises and returns to JOB zero. Same with the completion of the job. I’m using Vectric Aspire for design and gcode generation. I’ve modified the Vectric Post Processor to both eliminate some code that GRBL doesn’t understand and to have the spindle (Dewalt 611) start and stop.

The only time I experience what you’re saying is if I have manually moved the gantry out of the way and accidentally moved it against one of the ends of travel where the limit switch for that axis is triggered. When I turn on the machine and start UGS I get the same error message about the limit switch. At that point, you’re right, the only way is to disconnect the machine from the software, move it off the limit switch and restart the machine…

OR, I have had the issue where there has been either a gcode error or I have taken too deep a cut that causes one or more axis to lose its place. At that point, I’ve had an axis go to the limit switch activated position. At that point I disconnect, restart the machine re-home the thing and when I tell it to go back to Job Zero, it will not be in the correct place. I then have to reset all 3 axis to the proper zero.

Does yours actually go to machine zero or job zero? Are you using CarbideCreate to generate the gcode?

1 Like

Unfortunately it goes to machine zero after every job. I’d much rather it raise the spindle and stop where it is. There may be a complicate jig/supports around a part, etc., so it racing across 32" of table after each job isn’t just annoying, it could cause mechanical interference issues as well. There is no option in carbide create to not return after a job completes(wish there was).

If I use meshCam, it does raise and stop after a job(like I would prefer), though a cancelled job will return it to machine zero. Also, you can define “no go” zones where it will avoid those coordinates.

What are you plugging your router into that can switch the power on and off with gcode? That would be nice…

You can edit the G-Code file to control what happens at the end of a job to at least some degree.

1 Like

Yeah, that would be an ok workaround. I have had it happen on power on too unfortunately, so no way to gcode around that…

The getting stuck on the limit switches is something they need to address in Carbide Motion software, I would consider that a broken state and a bug. At least let you manually jog without forcing homing every time you open the jog panel…

It would also be nice to set an end-state in CM in your job setup maybe… “seek job zero, machine zero, retract, do nothing” type of a thing…

Thanks for your suggestions guys! And for all of your posts Will…