Inventables Community Forum

[Guide] Using Grbl to debug your homing switches

I just want to take a look at the grbl configuration as you have it now with homing failing.

Does anything move, or does grbl just alarm?

How did you home the machine (Easel, UGCS, serial monitor)?

Ok, since you said you reset things I’m not sure if you had homing enabled. You have to set $22=1 to activate the homing cycle.

You don’t get any movement of the axes, it just alarms?

Ok, humor me.

If it is not too difficult (just as a test) disconnect the shielding wire for the stepper motor wires so that none of the stepper motor shield wires are grounded (just let them float) and try to home the machine.

It’s just a hunch. I’ve seen it before.

If the steppers are inducing enough current in the shield wires they could be raising ground enough to trick the Arduino into thinking that it is seeing a transition on the homing switch inputs.

That’s the short version.

We can pick this up when you have time again.

1 Like

If you live in a older house (some that were built in the 90s) your outlets (house wiring) may not have the grounds hooked up. Many older homes have three wire receptacles, but many don’t actually have the ground wire hooked up in the service panel.

And sometimes the service panel isn’t grounded.

So, if it turns out you have grounding issues that may be a place to start looking.

The test will give us more information to work with. Hard to say at this point what a solution might be as grounding issues and stray signals are tough to deal with.

I think an important fact for you to consider, @PhilJohnson, is that the limit switches go to digital pins that are not useable as external interrupts. What this means is that the limit switches are monitored by the single processor that is also communicating over UART with your PC and controlling three axis of stepper motors by polling. This means that when your Arduino Uno has time it will check on the status of those switches. If there were noise on the limit switch wires intermittently causing very, very short voltage spikes, it’s quite possible that your Arduino wouldn’t see them because it usually isn’t watching because it’s doing so much between each poll of those inputs. Then during homing, I wouldn’t be surprised if GRBL checked those inputs at a much higher rate, for accuracy, increasing the likelihood that you’ll see a noise voltage spike, incorrectly triggering that input. Does your machine occasionally incorrectly hit a limit switch trigger while running?

That’s the homing debounce in ms… Meaning your Uno is programmed to watch the limit switch close for over a quarter of a second before it registers as closed. If anything, I’d imagine your settings would do the opposite of trigger early. I wonder if setting them to 255 does something different, like setting them to normal closed mode? Like how setting your motor hold time to 255 makes them always-on to lock your steppers.

1 Like

@PhilJohnson

Here’s how it works in version 0.9j

When the homing cycle runs, grbl approaches the homing switch(s) at the homing seek rate ($25). Once the homing switch(s) has/have been triggered, grbl will wait for the homing debounce time in milliseconds ($26), then grbl will approach the homing switch(s) at the feed rate ($24) to fine tune the home position, then grbl will pull the axes off the switch(s) by the homing pull-off amont ($27).

The value for $26 is just the number of milliseconds to wait. No magic numbers.

I’m not too surprised. One of the reasons that I generally ask for the $$ output at the beginning of any troubleshooting session is because many times the problem is located in the settings.

As far as I know, version 0.9j is the most recent “released” version. It is stable in that it is not actively in development, but bug fixes do occur.

Version 1.0c is the hot bed of development as we speak and is where the new changes/features/updates are being made.

I think someone said that the X-controller is running 1.0c which did surprise me a little.

Everybody has their opinion, let me just say that I’m running version 0.9j on my X-carve and I have 1.0c installed on a spare Arduino, in case someone needs help there.

I believe you said you are using Windows XP.

This works on Windows 7 and may work for you. Give it a try. It is pretty simple and if it works it might also clear up some of the weirdness you are seeing with your system.

Not a problem.

Yes, that one should work. You may have to change the x and y extents for the 1000mm ($130,$131).

Leave the homing switch shield grounded.

If you didn’t get an error from the upload then it worked. The $$ settings are stored in EEPROM which is not affected by the program load.

If you want to load the default $$ settings from the new file enter $RST=$ in the serial monitor or UGCS.

If you have them try a 0.47 uF cap (careful with the polarity) from the homing switch connection at the gShield to power supply common.

Later then.

1 Like

Every machine needs a little TLC. :smiley:

1 Like

Ceramic is your friend. Ceramic capacitors, as opposed to tantalum or electrolytic, are very low ESR, or equivalent series resistance. This translates to faster response time in your circuit, which means better noise rejection. Ceramic capacitors derate at DC voltage biases, so a 5V or 6V rated ceramic cap won’t do wouldn’t be as good. Find a ceramic capacitor rated to 10V or more and you’ll be golden. They also have the added bonus of not being directional, so you won’t have to worry about wiring it backwards.

Found some. These actually look like a pretty good deal, though I’d honestly suggest you get yourself a nice through hole ceramic capacitor kit with a bunch of different values.

1 Like

Go with Nathan’s suggestion.

Since you have to order them, if we have to go to the next step you would need a 100 uF 50 volt Electrolytic at that time.

Something like this:

http://www.amazon.com/Aluminum-Electrolytic-Capacitors-Leaded-50volts/dp/B00LWSI3Z8/ref=sr_1_1?ie=UTF8&qid=1462463752&sr=8-1&keywords=100+uF+50+volt+electrolytic

1 Like