Dude, I rarely quit on anything I try to accomplish, but when it came to getting the limit switches to work on the x-carve, well I have better things to do with my time. I tried and tried and the only thing I EVER accomplished with the limit switches was to break them with each attempt. I gave up and unhooked the wires. I hope you have better luck than I did. I know this doesn’t help but I got tired of wasting my time on it. If you figure it out let me know.
Those are not limit switches, homing switches. They calibrate your Home Zero. What you’re doing manually is Work Zero. When you start using multiple different Cam application, you will see sysmptoms.
I have previous post regarding guarding Z switch, might help.
Non working Y switch problem must be cabling problem. Suggest to go over connections one more time.
Since this is a new thread on Limit Switches, I’ll jump on in hopes that we get more activity (and a resolution) than the previous threads have given. out of all the ones i’ve read, and by the activity of my X-Carve (newly completed and in the testing stages)… i’m more prone to believe that this may be an electrical noise problem. I would welcome those that have a better idea of what is going on w/ the logic in the Grbl GCode to put in their 2-cents.
in my reading, i’ve found so many different people with similar, but many times not the same problems with limit switches. i have checked out my wiring:
i turn the system off
i put a continuity tester (on my volt-meter) connected between the Ground & any of the 3 Limit switch pins that attach to the G-Shield and all three register continuity when the switch is activated, and then back to open when the switches are in their “normal” state.
i’ve tried the “Homing Process” over a dozen times. most of the time, the spindle goes down about a half an inch and then nothing else. no GSheild activity lights, & therefore no motors running.
one time, i actually watched as the Z-Axis (Spindle) started to rise to the top. i interrupted it before it got there, by actuating the Z-Axis Limit Switch with my finger, in case the limit switch was not going to work. BUT my actuation of the limit switch, DID indeed STOP THE MOTION! after it did that, it started to go down for just a quarter inch or so and stopped. like before - nothing.
i haven’t been able to recreate that again.
in the end, as i mentioned above, i’m leaning towards electrical noise picked up by one or more of the limit switch unshielded wires. although they’re twisted, i’m not sure if that is enough with all that stepper motor voltage being pulsed through those cable snakes.
i’ve heard of more than one person placing a “filter” (cap + resistor) on the terminal (G-Shield) end of the wires and that working).
Hopefully someone will be able to maybe confirm that this IS a problem and it will help to confirm all these “Limit Switch” problems.
I will do my best to sus’ this out - after all i DO have an oscilloscope and i SHOULD be able to see what’s going on. I’m a newbie to CNC, but i’ve been working w/ the Arduino for sometime now. once i get more familiarized with G-Codes and the “grbl library” (there is a “limits.h” header in there i’ll look @ today.) i’d be happy to share any more insights i run across over the next week or so.
please help if you can, i’d LOVE to get this limit switch thing (homing switches is a much better name.) resolved.
@BartDring is that pin normally set high or low? If low, a 1k resistor between that pin and ground should help reduce false positives right? Or is something like that already implemented on the board? Could a better debounce on that pin also help? Something like 50ms should eliminate false positives related to noise and that could be handled in the next release.
Double check the wiring on your Y Homing switch, specifically that you wired it to the correct pins, it is so easy to get it swapped on the micro switches.
FYI: it homes the x axis and the y axis at the same time. This confused me a lot.
At first I thought my x axis was not homing at all. Then I thought there was an error because both axis were moving at once.
@Earwigger The switch closes to ground. The Arduino provides a weak pullup of about 30k. A 1k to ground would be like activating the switch. A stronger pullup might help. The gShield does not add any filtering. Grbl can add a debounce.
@Earwigger The lower the impedance the better. 15k Ohm is still only about 1.5mA of current in the closed state. I have seen 1k used.
If you really want to start hacking, you could change the logic and run normally closed switches. It would be a lot less noise sensitive. A lot of DIY hardware runs normally open because if someone accidentally makes sets a pin as an output it blows the port by driving into ground.
I see people re-using Arduinos, but forget to program them for the new application before putting on the shield. Before they can re-flash them, an old program damages the chip.
I tried to use the limit switch wiring to carry IR sensor data for my tachometer and that was a big fail. It did allow me to visualize the noise from all of the inductive loads on the readout. It is pretty amazing. I think a length of shielded cat 6 instead of the limit switch wiring might also solve the problem and simplify/cleanup the wiring situation as well.
I’m having problems with my Homing in that i’ve only gotten the z-axis to work temporarily one time out of nearly countless times of testing.
My question to you is this, if I left the pins coming from the homing switches off the GShield, and told Easel that I AM using homing switches, when I click to test the homing switches, shouldn’t I see Easel go through, or at least star,t the “homing sequence”. I would have to stop it manually before the Z-Axis motor brought the spindle crashing to the top… but without anything connected to those shield pins, the homing sequence SHOULD work because there is not any chance of electrical “noise”, right?
SHOULD work because there is not any chance of electrical “noise”, right
Well, not quite. The internal pull-up on the homing switch pins is a “weak” pull-up. It should be better than with the wires connected, but no guarantee. The X-carve is an electrically noisy machine.
The homing sequence moves the Z axis to the switch first (assuming normal setup - this can be changed in grbl) and when that operation is complete it then moves the X and Y axis together until each of them reaches its respective switch.
If you want to verify that the software works you can use an external pull-up (1K very strong, 5K moderate, 10K should work too) on the homing switch pins and a switch on each pin to ground, then you can manually test homing.
If you don’t want to disconnect your motors for the test then you could move your Z down and the X and Y away from the front/left corner and then be sure to stop everything before they get to a switch.
good points. I’m ok with the theory that in a Normally Open(NO) switch position, there is no connection between the pin on the GShield board. if the voltage on any of the 3 pins for limit switches does not get pulled down to 0 (by connecting it to ground thru the switch, then the GRBL software will assume that switch has not been activated.
but in my case, i’m not interested that the homing sequence runs through its paces correctly, i’m just trying to force the homing system to start. with no pins on the GShield, then the connections on all three pins (9, 10, & 12) are electrically “open” to ground & therefore the homing sequence SHOULD run. i’m saying that this is activated this way on my system, the Z moves down one “jog” and the program and the X-Carve juet sit there with the monitor showing the “Stop” button. this action of forcing the Homing Sequence was run many times with the wires from the limit switches attached to those 3 pins, also. i get the same outcome.
I’m not sure what you are referring to as the “monitor”. Is that Easel that you are using to try to start homing?
With nothing hooked to the gShield limit pins (and indirectly the Arduino pins) the pins are in a “floating” state. Normally the grbl code has the internal pull-ups activated on those pins (forcing the “high” state) which in most cases would prevent the pin from transitioning to a “low” state.
Since it is a weak pull-up there are cases where enough electromagnetic noise close by can induce a transition on the pin.
However, your situation seems to be different. Do you have a terminal program like HyperTerminal or Putty so that you can talk directly to the grbl code? There may be something wrong there.
Edit: I just noticed your $$ output from another thread. That’s what I was going for. It’s not set up right. You need to get that corrected before you proceed.
we’re pretty much on the same page.
When i said “monitor” i meant what was on my computer screen for that page in Easel’s Machine Setup.
Those pull-ups are internal to the UNO & therefore electrically “before” the pins, so their state should not change without any connection to the pins. the pins don’t need anything connected to them in order for the UNO to detect that the 5v is still there. I also would assume that there very low probability of “noise” coming in on those pins through the air now that they are so electrically/physically distant from any of the motors.
that being said - I’m almost certain now that you are correct in that my situation on this is different. My not being able to connect via Machine Inspector. That’s not all, I’ve installed two other communications program and I get the same information seeming to connect, but no response to any of my g-code entries.
so, I’m not going to address the problem I’m having on this thread anymore, and just follow it, because i’m interested in where it leads. I will continue my journey on the “Jogging X & Y goes 3x the distance.” thread.
btw, I’ve been reading up on the “Magnetic (Hall Effect) Noise-free End Stops / Homing Sensors” thread and it looks promising - I’ve ordered 10 of the sensors (they’re less than a dollar each). and will try and fool around with them, also. i’d love to have both Limit detection on both ends of X, Y & Z with the ability to “Home” accurately for restarts.
just a quick update, got my X-Carve to actually go through some “mock-carves” last night. everything seems to work EXCEPT for my Zero-ing sequence. I had to do the mock-carve without the zero sequence.
Since my problem now, is not specifically that my Y limit switch not working, I feel it best that I go and either find a thread more specific to my problem, or start up a new topic of my own. I find Forums to be very useful when used well. that includes making sure you keep to the topic within any thread/topic, AND being as specific as possible when writing the Subject line of a new topic. Larry, if you’re reading this, I’m hoping to see you (and others) as I grind away at my new topic, which i may name, “Homing Sequence stalls after 1 second of initiation on Easel.”
thanks for everyone’s help here. If i find anything that will help out here, i will post.