Well, there has to be something wrong in there or you are running a version of Grbl that doesn’t support homing switch status reports.
I’m not at the machine so can’t post $$ until tomorrow. However it’s just 0.9 with steps/mm and $10 changed
Has this gotten any attention recently? I’m facing the same issues and flashed the controller twice already with the Inventables fork of grbl with no luck. Is there a setting I have to enable to read the LIM value? I have tried $10=19 and that also hasn’t worked for me. Do note that I am trying this through the Arduino IDE while I can enter commands, there isn’t always text recognition.
Check this thread:
Post your $$ output.
What is the failure scenario?
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.
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.
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.