We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
Well, I’ve been having trouble w/the Homing Sequence on my brand-new X-Carve. doing all sorts of diagnostics, I finally took the Limit Switch/Spindle Control connector completely off the GShield, and took readings off the 9,10 & 12 pins of the shield:
9 & 10 around 5 vdc each, pin 12, 0 vdc.
I then powered down the UNO & removed the GShield, and powered the UNO back up & got 5 vdc off of all 3 pins!
put it all back together (without the limit switch connector connected) & got 0 vdc on the Z-axis (pin 12).
I then took the shield off and and with my Ohm meter, read the ohms from each of the pins 9, 10 & 12 to Ground.
all were 5M-ohm which is pretty open, but in any case, they were very close in Ohms and therefore it leaves me clueless as to why I’m getting 0 vdc on pin 12 when the shield is attached.
any suggestions as to what may be causing my problem?
Is your Z isn’t moving when you try to carve at all, or you’re wondering witch pin has power.?
Best way to understand good connections is turn power supply off, start moving X then Y then Z one at a time. If you see LEDs lighten up one by one, means have no wiring problems.
the issue isn’t any of the x-carve motors, I am able to go through a “mock” carve with a felt-tip pen taped to the spindle. motors work great, but I have not been able to run the Homing operation in Easel. I’ve already Ohm’d out all 3 switches to confirm they were all normally open & the wiring detected their “activation” (closing the connections).
my problem has to do with when the x-carve logic connections are not even connected to the gshield. i’m getting those values (stated above). I have the feeling that things are pointing to a degraded internal pullup resistor on pin 12 of my arduino UNO.
i will (hopefully) try and get another UNO up & running tonight & test it’s limit-switch pins out.
good suggestion - I’ve looked that over fairly closely, i’ve tested the pin with respect to its neighboring pins and it appears that the connections are solid & clean.
gonna try a different UNO.
Ok, just to get me up to speed. If the gShield is mated properly to the UNO, the USB cable is plugged in to get power to the UNO, and the 24 volt power supply turned on you should see the blue LED and three green LEDs on, on the gShield. Is that what you see?
Yes, that is what i see. and like I mentioned before, the x-carve works properly, all motors run & jog. i’m just not able to run the Homing Sequence.
this is because, i have 0 VDC from pin 12 of the GShield to ground when i SHOULD have 5 VDC from zero to ground, (as I have on pins 9 & 10, i.e. X&Y limit switch pins}.
so, i hooked up a different UNO board (one that i 1st tested on my Hyper Terminal program with “$$” to affirm that the settings were indeed loaded onto the UNO.
Again, I tested (without the GShield attached to the UNO) and got 5 VDC across all three pins (9, 10 AND 12) to ground.
powered down & then attached the GShield to the UNO & plugged it back into the USB port and it happened again.
I had 5 VDC across the pins 9 & 10, but 0 VDC on pin 12.
since this was a 2nd UNO board, I will assume that you are onto something there, Larry -
my guess is it’s a problem with my GShield loading down that pin12 to ground, somehow. I did do some cleaning around the solder point on the shield and i also re-soldered it.
I will order a new board tonight (sigh) and see how that goes.
Erik, I’m using version 9j. I read up on it and I know that the Spindle (pin11) and the Z-axis limit (pin12) have been reversed from the version 8. The spindle pin is working fine, I can control the spindle on/off through software, so that is another indication that I’m using the correct pins.
And just for the record, I’d like to question why the forum word editor can have a spelling checker, but cannot seem to capitalize the word “I” nor capitalize words at the beginning of a sentence is beyond me. I guess I’m spoiled. Don’t get me wrong, I LOVE this forum.
Good morning. Larry, I did this test. I tested the Ohms between all the limit pins (9, 10, 12) to ground and all 3 of them were over 5 M-Ohm.
I know, Right? there really shouldn’t be a problem here. there’s no short to ground on that shield pin, yet, when I plug in the shield to the UNO (even when the logic pins from the X-Carve limit switches are disconnecte, pin 12 still goes from 5 VDC down to 0 VDC, basically shorts to ground.
I’ll get my new shield tomorrow & hopefully (if that works) then it will certainly point to the GShield as being screwed up (on that pin, at least).
If the new shield works, I could probably then use the original (bad) shield if i cut off that pin 12 from connecting to the UNO and have a breakout wire from pin 12 on the UNO directly to the Z-Limit switch on the X-Carve. that is, if there is no other circuitry on the Shield that shares the data on Pin 12.
This reminds me, Does anyone have the schematic for the GShield, or is that proprietary?
I think that pin 12 is just a straight through connection. So, it sounds like when you plug in the gShield the pressure of the connection is causing a short. May be a bad header.
Larry,
I concur, it looks like the 1st schematic on that gbrlShield shows J8 as straight through except for pin1 which is not connected on our pin-set anyways.
so… if I have time tonight, but it will certainly soon, and since I have a new Shield on its way, I will go ahead and CUT the pin 12 off the Shield so it will NOT go down into the UNO, and i will come out of the UNO’s pin-header 12 and go directly to the Z-axis Limit Swithc wire & see what the hell happens.
I’m game and I have a good feeling of a positive outcome.
oh, and THANKS so much for the Shield Schematics. (I’m storing those puppies away for future reference!).
Ok, when you get that problem resolved, this is what I would do next.
I like to keep things simple, so I start at the bottom and work up. If you know the basics are working then you don’t have to worry about them when the upper level doesn’t work. You know the problem is in the upper level.
So, when you get your hardware test working (all pins are high and switch to low when you press a homing switch) try the following to check out whether the software sees the transitions.
Using HyperTerminal - check the grbl $$ output to make sure where you are starting.
Change the status report flags to print out the homing switch values that grbl sees by setting $10=19
Use the “?” (no quotes) grbl command to get status (UGS doesn’t pass this command to grbl so you need to use HyperTerminal). If everything is good and no homing switch is pressed one of the output values should be LIM=000. Zero means normally open is open (not tripped), one means normally open is closed (tripped).
Press one of the switches and do the ? command again and see if it shows a change. I believe the order is ZYX, but I haven’t checked that lately so it might be different. If this is correct and you hold the Z switch closed and issue the ? command you would see LIM=100. Repeat for X and Y.
If all that works then you’re ready for the next step, $H grbl command to home the machine.
That’s great - I love deep level troubleshooting, so this is right up my alley. the board is due to be delivered by tomorrow night… so close… oh yes, so close!
Thanks so much, Larry. I have not, yet, but will probably start my education on the gbrl commands over the next few days.
again - great test! can’t wait to use it.
put the shield onto the UNO & tested the terminals 9,10 & 10 to ground . all were 5 VDC. good.
Soldered on the 90degree headers on the gshield and then ran the same test… i’ll be darned of the Z-axis (Pin12) gave me 2.6 VDC. better than 0, but hey.
Popped all the Stepper Motor wires on, then the Power wires.
tested the pins again, this time i got over 4 VDC to ground on pin 12 - better and maybe close enough.
ran the Easel (local) and ran the homing function - Z-axis good, X/Y axis, the Y seemed to run ok but the X was not running very well - it started then stopped well before the limit switch.
like the proverbial idiot, i ran the homing function a few more times, one of them I had the X-axis start really close to the switch - it worked.
filddled with all the limit switch cables to make sure they were good. was getting good readings still off the z-limit switch.
ran the homing seq with X&Y in the middle of the work area. SUCCESS!
ran it about 3 more times - all good! (btw) there should be a way to test the homing sequence without having to re-run the whole program each time! make it a code or something - put it into the grbl lib).
opened HyperTerminal & went through each of the 3 Limit switches with your instructions on testing each switch open & typing ? and then with the switch closed. worked on all 3 switches!
I have only one more question related to this thread and after that I’m fine with calling this one solved…
when the Homing Sequence finishes on my X-Carve (all three axis’ are homed), the program does not come to an end. it remains with the “STOP” button on the screen. Is this normal for the program? I’m thinking not. It would be too simple to have the program count that all 3 switches have closed and then give the User a message that the program ended successfully. But i’ve seen sillier things happen.
anyway, I’d appreciate some feedback on that question.
I now do not have any excuse not to do a test-carve. pretty scary, but pretty exciting!
thanks for all the help in this thread - I’ve certainly leaned a whole lot.
Sounds like you have some noise on your wires to the homing switches.
Here are some things to consider:
I run my machine with soft limits turned on. If you do this you need to home your machine every time you turn it on (you should do this anyway). This gives you the best bang for your buck. If you use soft limits the switches are only used for homing so if you have a good homing cycle — once homing is complete the grbl code ignores the switches so no false alarms on the homing switches.
With soft limits on, the grbl code will check each G-code command before it executes it. If the command would cause your machine to go outside the machine space grbl would not execute the command and will alarm.
This prevents your machine from destroying your homing switches and keeps your machine from crashing into a rail. Also keeps the Z axis from running off the end of the acme rod (it has happened on this forum).
Also, there is a potential problem if you use a program that sends a G28 command (UGS does this when you press a return to zero button) to the X-carve.
Using UGS, go to the Machine Control tab. Press the “$H” button. If the homing sequence works correctly then the "Machine Position should be x=0,y=0,z=0 and the “Work Position” could be anything.
Press “Reset Zero” and the “Work Position” should change to x=0,y=0,z=0.
Go to the Command tab and enter the G-code command G28.1 (that’s G 2 8 dot 1)
This will initialize a parameter that tells the grbl software where to go if it receives a G28 command.
Sometimes this parameter is garbage and if your machine gets a G28 without this set properly it’s bad news.
Interestingly you can set your G28 position anywhere in valid machine space and that becomes your G28 position and when grbl gets a G28 command, that’s where the machine will go. Just keep in mind that G28 works in machine space not work space co-ordinates.
I will try this out.
btw - tonight I ran my 1st carve. It went quite well. Only 2 things went wrong.
I used the wrong bit for my 1st attempt. fixed it in the 2nd run.
I used to deep of a cut on my 1st run - 2nd run, more shallow - success!
used tape to hold my plywood down - not a good idea.
although the clamps i was trying to create did not come out tonight, this was more of a test run anyway.
tomorrow evening I will screw down the material into a board that’s screwed into my waste-board and that will take care of that.
i’ll experiment a little more with cutting depth and bit speed & movement speed.
All in all, very happy - no skipping, all the axis motors ran very cool as did the 400W spindle with the 1/2" plywood.
much lest dust & sawdust than i imagined, but i was using a thin bit.
until tomorrow
as far as i’m concerned this topic can be set to SOLVED.
thanks for everyone’s support!
Hi everyone!
I had problems with the limit switches for Z axis.
So i went check voltage on both Arduino and my CNC shield.
It seemd ok on the arduino when cnc sheld was not connected 4,85V , but when connected
Z limit pins reported 0V, so i checked continuitinity on the cnc shield and found it on
former pin 11. My solution was to weld a small cable from Arduino pin 12 and conect it to
cnc sheld pin 11, see foto. Now it all work perfect. Homing and limits.
