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
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
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:
1 Like