Breaking homing switches - Uh, and lot's of other stuff

I thought this deserved its own thread since there are a number of people with these two problems.

There are various ways to implement homing/limit switches. The X-carve firmware (ie Grbl) provides software support to implement homing/limit switches.

A hardware version would have the switches interrupt the power to the X-carve and is the most robust solution, but will not be discussed here.

The software solution has all the characteristics of anything that is controlled by software. As long as everything works right, you’re good to go. If the software gets hung then all bets are off.

The Homing switch solution. Three switches are mounted such that they will trip when the machine is at “Machine Location 0,0,0” which is defined as the HOME position. If you have the switches at the appropriate location and you have configured Grbl to use Homing when you or your G-code software issues a $H command to Grbl then your machine will go to the location indicated by tripping the Homing switch on each axis (there is also a configuration setting to have your machine move a small distance away from the Homing switch after a $H operation so that the Homing switch will not be tripped when you start the remainder of your G-code). This offset lets the Homing switch also function as a Limit switch for that end of each axis.

To keep the machine from running off the end of the axis that does not have a switch, there are settings in Grbl to let Grbl know how far it can travel along the axis without going past the maximum work area. If these variables are set properly and “Soft Limits” are enabled then the combination of Homing the machine and using soft limits will allow the software to keep your machine from leaving the work area (as long as the software is functional).

The other solution Limit Switches. This solution has a switch at each end of each axis. These are usually set up as “Normally closed” so that one pin on the Arduino can be used to handle both switches.

To use the Limit switch option, you would have Grbl set up to use “Hard LImits”. In this mode the software goes to the “Alarm” state and stops processing commands if any of the switches are tripped.

Need to Home question:

If you just turn on your machine then the software has no idea where your spindle is located. Homing is an easy way to synchronize the software and hardware to a known position. You could do it manually if you prefer.

Once the software knows Machine position then you also have to tell the software where the Work position is so that it knows where to move to - to start your carving.

One without the other is not enough for the machine to operate properly.

Hope this helps, if not ask questions and I’ll try again.



This option should work fine with both hard limits and homing in Grbl 9 they actually work well together, but the issue is, you would need to use some capacitors and resistors to block out the noise from the spindle and stepper motors for the hard limits to work (shielded cabling may work, but may not be enough without the capacitors and resistors).

I can’t find where I read that now, so I’ll defer to you on that point. I don’t have that setup to test it.

Interesting that if it does work that way and using NC switches, then you could conceivably home to either end of each axis which would lead to a lot of other problems synchronizing with your CAD/CAM software.

I used shielded wire for everything and a capacitor across the spindle motor wires at the spindle motor end. It runs pretty clean. I haven’t run it with a load yet, but I did test it with the spindle motor running.

This subject is certainly worth its own thread.

With my machine thus far, I’ve wired in additional switches so that I’ve now got switches at each end of X & Y axis and the single switch at the top of Z (as discussed here - Installing limit switches (not homing switches)).

The X & Y’s are wired in parallel pairs and connected (as described

However I’m still struggling to get them working as is (supposedly) described here

It appears that my issues are now mostly relating to correctly setting up GRBL to enable both the Homing feature as well as using the same switches as limit switches.I just need to spend a little more time reading and a little less time cutting…

Mind you, your suggestion of simply interrupting the power supply if any switch is tripped is looking easier and easier by the day. Whatever I end up doing, I’m glad I took the time to wire in the additional switches with the option to use them as either NC or NO - it’ll save re-running all the cables again.

@DavidWestley unless you use some low value pull up resistors and small capacitors to block out the remaining noise from the spindle and stepper motors you’re always going to get False triggering of the limits. I just ordered some caps and resistors and will try a small circuit when they are delivered and let you know the outcome. Of cause I just got my Dewalt 611 and spindle holder in last night, so first I need to get the machine back up and running.

@BrianSaban Brian the Arduino has pull up resistors activated on the homing/limit switch inputs. If you want a more aggressive pull up you can add external resistors.

@DavidWestley David, having gone through the research on this issue I have changed my thinking and have decide not to go with full blown limit switches. I’ll just put my reasons here and let each one decide which works best for them.

Let’s take a worst case limit switch horror story to illustrate a point. You’ve got this really cool design for your X-carve 1000mm. A friend likes the design and says 'Hey, could you send me the G-code so that I can carve that?".

In your design at some point the machine goes to Machine 0,0,0 and drills an alignment hole then goes to Machine 1000,1000,0 to start a part of the design.

Without thinking about it, your friend fires up his stock X-carve 500 and starts sending the G-code to carve the project. His machine goes to Machine 0,0,0 and drills the alignment hole then picks up the next line and heads for Machine 1000,1000,0.

Since it’s a long trek his machine gets full acceleration to full speed and hits his limit switch at Machine 300,300,0.

Since he has a DeWalt router there’s a lot of momentum built up it’s probably going to do some damage.

Sure, this is a contrived example, but I think it makes the point. The limit switch will trip, and the Arduino will respond, but I think it will be a little late.

The same scenario with homing switches and soft limits.

Your friend fires up his machine and homes the device. He starts up the G-code file and it moves to Machine 0,0,0 and drills the alignment hole. It fetches the next G-code instruction to go to Machine 1000,1000,0 and the software says “Alarm - …” and nothing moves until the operator intervenes. It knows the move is outside the work area for the X-carve 500 and doesn’t allow the G-code line to execute.

This is a very simplistic thought process and there are many scenarios that can occur, but for my situation I think I’m going to use the Homing/Soft Limits approach.

Homing and soft limits have secondary benefit that speaks to BrianSaban’s concern about spindle and stepper motor interference in that, once the machine is homed, the switches are no longer involved. Soft limits check for co-ordinates out of range - not switch values.

Since I don’t have limit switches I can’t test my theory here, but I did test the homing/soft limits and they work as described here. If you have Homed your machine, the soft limits will not honor a G-code command that is outside the range specified in the Grbl parameters, it will Alarm and not move.

Oh, there is an issue with a system that kills power when the limit switch is tripped. You’ve got the momentum issue illustrated in the story above. Stepper motors have a high holding torque when not stepping but with the motor activated. Killing power to a stepper motor will let it free wheel so it won’ be able to provide a braking effect if you just kill power.

I’m enjoying this discussion partly because it’s making me think about this issue more than I would have, had it not occurred.

Thanks to all for their input…

Ok, here’s the latest on where I’m at with the limit switch and homing saga…

I’ve installed additional limit switches and so I now have a switch on each end of both the X and Y axis and a single switch on the top of the Z axis. These are all Normally Open switches, wired in parallel pairs (the two X switches in parallel and ditto for the two Y switches)

Using Easel (through the Inventables site) I then ran the Machine setup program which (for me) was the easiest way to “enable” the homing switches in GRBL. I’ve no doubt there’s a simple command for doing this via Universal Gcode Sender (UGS), however I’m all for taking the simple path wherever possible.

The advantages of using Easel to set up Homing is that it has a series of test sequences which allows you to

  • Enable homing
  • Test each switch
  • reset the homing direction if it’s wrong etc

Having enabled homing, I can now use the “$H” homing command to home the machine (ignore the “”)

I then set up “Soft Limits” (clearly a good thing, as described by Larry in the above post) by

  • Homing the machine to find X0, Y0, Z0
  • Using the “jog” feature in UGS (arrow keys on my keyboard) to move each axis to what I considered as its safe maximum travel and then recording the X, Y and Z position for each.
  • Entering each soft limit via the UGS command line ("$130=790" for the X axis, “$131=790” for the Y axis and “$132=80” for the Z Axis - without the inverted comma’s of course). GRBL should respond with “ok” after entering each command.
  • These settings are confirmed by sending the $$ command - GRBL will respond with a list of all current settings where you’ll be able to check your entries have been added.

I then enabled “Hard Limits” in GRBL by sending the “$21=1” command (GRBL should again respond with “ok”)

  • Now when I manually “jog” the machine along an axis to the point where one of the limit switches is closed, the machine will stop and generate an alarm.
  • To reset this alarm, I have to manually move the machine away from the offending limit switch, reset the alarm ("$X") and re-set the machine (“Soft Reset” in UGS)
    Note I’ve only played with this briefly - there may be a better way to reset the alarm.

So to summarise, I’ve now got:

  • Homing enabled
  • Soft Limits enabled - GRBL will not accept commands the exceed the maximum limits set for each axis
  • Hard Limits enabled - If I manually move an axis too far, the machine will stop & generate an alarm
  • Important note - the Z axis soft limit will be pretty much useless unless you use the same tool and tool length every time. Anytime you put a longer tool into the machine, you’ll either need to reset the limit, or just make sure you’re not likely to cut into your table/waste-board

Is this the final setup - clearly not. I understand there are noise issues with the switch wiring (I did use shielded cable for the new switches, but I’ve not yet connected to the controller - I assume this would go to ground, but that TBA). I’ll shortly be adding a DeWalt unit to replace the current tiny spindle, so how that changes things I’ve yet to determine. I’m also pretty keen to see how other solve these issues.

For reference, see here for a list & description of some of the GRBL commands and what they do

For interest, below are a couple of image on how I fitted the additional switches - not the neatest or best option, however it suited some of the restrictions I have with the way I’ve configured my machine. Please excuse the somewhat crude table set-up I’m using at the moment which is an odd combination of T Slot channels, threaded holes and multi-piece wasteboard. I’ll get around to something better when I stop tinkering…

David, I think there may be a problem with your setup. It’s late here and I can’t do any testing tonight, I’ll look at it some tomorrow.

What I do with the soft limit on Z is set it so that the spindle mount will not leave the Makerslide. Obviously, you are correct that changing bits can cause a problem for soft limits on Z.

A hole in the waste board is not pretty, but if the spindle mount comes off the Makerslide with a router running at 14000 or so RPM bad things can happen.

My current setting (if I’ve done it right) has the spindle mount only going down to the point where it’s level with the bottom of the makerslide - at least that was where I’d intended it to be.

I’m on nightshift at the moment, so I’ll check it asap - as always though, comments and suggestions are greatly appreciated.

Further update.

I’ve temporarily disabled my hard limits because as expected, I’m getting false alarms from what I can only assume is the noise mentioned in previous posts.

The two solutions I’m working on are

  • I’m going to replace the spindle with a DeWalt router. Because the cable won’t run with the limit switch cables, I’m guessing that will reduce the noise.
  • I used shielded cables for the limit switches, I’ll finish these off by wiring the shield to ground on the Controller.

Will see what this does…

I am running the Dewalt DWP611 and the switches are wired up with shielded cable…I am not getting false alarms on my switches.

@ErikJenkins are you running hard limits or only homing?

Hard limits…I also added 2nd switches to the X and Y axis.

nice, haven’t seen it done yet. Can you shoot a video?

I can try…lol…no promises on quality.

1 Like

@DavidWestley David, you can check to see if the interference is coming from the spindle by running a project with the spindle off. Just make up a project that doesn’t move the spindle down to the work surface and let it run “in air”. If this works without triggering a hard limit then the spindle is probably your noise source. If you still get false triggers then your noise is from a different source.

Thanks Larry.

At the moment, and probably because I’ve not yet wired the cable shielding to anything, I’ve actually disabled hard limits ($21=0) because I’m sometimes getting hard limit alarms while the spindle is off and nothing is moving.

Not sure if you’ll know, but would I connect the cable cable-shield wiring to the “Ground” pin on the Controller, to ‘earth’ on the machine, or even to earth on the AC power supply (the side of the power supply that I generally try to keep away from)? I’m assuming it’d be the ground on the Controller…

I know you and others have discussed adding a capacitor and resistors to further reduce noise. Any suggested values & a simple wiring diagram would be gold, although having just come off nightshift, I’ve not yet searched for this, so it may be that this info already exists in the forums.


@DavidWestley Hi, David.

I just took a closer look at your pictures and the homing/limit switch wiring in the pictures is not shielded wire. Are the pictures out of date?

The shield wire should be connected to the negative terminal of the 24 volt power supply. Since the gShield is connected to the same terminal you can connect the shield wire to either place, just make sure that it is connected to the ground side of the circuit. (In my case I have a terminal strip to hook up all the grounds and power connectors).

The resistor/capacitor discussion is about using a low pass filter to eliminate high frequency noise. The resistor/capacitor circuit provides a low resistance path to ground for high frequency signals, but does not pass DC. The attempt is to short circuit the noise without affecting the DC component. In reality it does slightly modify the response time of the switch circuit.

I would recommend that you just use homing and soft limits and not use the hard limits in this situation and here is my reason.

The homing switches and limit switches are hooked to the same place on the controller. Both are serviced by the Grbl code on the Arduino. If something is wrong with the Arduino/gShield so that soft limits will not function properly then hard limits will not work either. This way once your machine is homed you don’t have to worry about noise on the switches.

Yep, the photos are a little old. They show the original limit switch wiring & if you looked carefully, you’d possibly see the 5 core shielded cable I ran for the new switches - photos were mostly intended to show the switch positioning. The old switch wires were clipped off and reconnected to the newer run.

I’m inclined to agree that the hard limits are not a great idea in practice & I’m seriously thinking of abandoning the idea altogether (or repurposing them as power cut-outs).

Even the homing & soft limits are less than foolproof. Having homed the machine, reset the work zero (not machine zero), indexed the machine away from the work and then selecting “Return to Zero”, it still ran the Z axis up and destroyed yet another switch…

Shortly after, i had a mechanical failure. Some more downtime ahead…

Took me a little while to get back to this. One of the requirements for soft limits to work is that the entire work space must be in negative space. I found this in the Grbl code. I don’t have time today to look into this further, but I’m new to this and I’m not sure what they mean by negative space. I’ll have to do some research.

Since I haven’t gotten around to moving things about on the machine I hadn’t run into this.

How did you return to zero? Are you using Universal G-code sender? If so, you can use the $C button to have Grbl process your commands but not move the machine. I use this for debugging.

With the $C command active soft limits should still work.