Hi , First off Thanks to GRBL Software Engineers for a great bit of Control Software My Set Up : I am Running GRBL 1.1f on a Mega 2560 - Was Programmed using the Hex File Method. I Connect to GRBL through UGS ( Nightly Build Latest ) My Machine is a CNC Router : See the Photo of my Limit Switch Positions & my Cartision Positioning Setup. HOMING ISSUE DESCRIPTION I have tested the Limit Switches Manually to make sure they are working in UGS in Verbose Mode & they appear to be working Just fine - Here is the Output [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Z> - Me Manualy Triggering Z Axis Limit Switch [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Z|WCO:0.000,0.000,0.000> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Ov:100,100,100> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:X> - Me Manualy Triggering x Axis Limit Switch- [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:X> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Y> - Me Manualy Triggering Y Axis Limit Switch [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Y> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|WCO:0.000,0.000,0.000> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Ov:100,100,100> When i Run the Homing Cycle the Z Axis Moves slowly Upwards towards the Switch & I Hear the Switch Activate but the Z Axis Continues to keep on Going up even though the switch has Triggered ? So i Have to hit the Emegency Stop Panic Button to kill all power to the controller My Limit Switches are wired ( Normally Open With 1K Pull Up Resistors to +5V & 100n Ceramic Caps on the Grounds ) Making an RC Filter - I See no False Triggering in Vebose Mode. My GRBL 1.1F Settings are as Follows Grbl 1.1f ['$' for help] >>> $$ >>> $G $0=10 $1=25 $2=0 $3=3 $4=0 $5=0 $6=0 $10=1 $11=0.010 $12=0.002 $13=0 $20=1 $21=0 $22=1 $23=7 $24=25.000 $25=50.000 $26=250 $27=20.000 $30=24000 $31=5000 $32=0 $100=159.426 $101=159.521 $102=100.000 $110=3000.000 $111=2400.000 $112=500.000 $120=25.000 $121=25.000 $122=10.000 $130=670.000 $131=1400.000 $132=200.000 ok [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0] ok >>> $I [VER:1.1f.20170802:] [OPT:VNM,35,255] ok Can Anybody Help me find the solution to my Homing Issues Many Thanks in Advance
put both your X and Y switches on the other side, that is where the CNC stadnards expect them and also where GRBL expects them. are you sure that tripping the Z switch trips the correct pin? what you describe indicates that tripping the Z switch does not trip the Z pin.
Hi David First off Many thanks for taking time to try to help me out on this niggling issue The Z Limit switch does appear to be working as the Verbose Output shows it when i Trigger it Does this look Correct ? verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Z> - Me Manualy Triggering Z Axis Limit Switch [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Z|WCO:0.000,0.000,0.000> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Ov:100,100,100> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:X> - Me Manualy Triggering x Axis Limit Switch- [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:X> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Y> - Me Manualy Triggering Y Axis Limit Switch [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Y> If i Move the Y Axis switch to the Rear of the machine does this mean the home Position will now also be at the rear of the machine ? As you can see in the photo there is no easy access for me to reach that corner thats why i inverted $23 Setting in GRBL Perhaps i am totally misunderstanding the use of $23 & the Cartesian coordinates System On the GRBL Web site it Says " $23 - Homing dir invert, mask By default, Grbl assumes your homing limit switches are in the positive direction, first moving the z-axis positive, then the x-y axes positive before trying to precisely locate machine zero by going back and forth slowly around the switch. If your machine has a limit switch in the negative direction, the homing direction mask can invert the axes' direction. " I Really Wanted the home to be at the front of the machine as i can get to it very easy. Also i read that Industry standard CNC Gcode works in the Negative Area of the Cartesian coordinates System unlike my 3D Printers that work in the positive area of the Cartesian coordinates system - Perhaps this is where i am going Wrong in my understanding & getting confused ? Look Forward to your advice - Many Thanks Again !
Hi ExWhyZee, Yes $23 sets the home move direction, you can put it anywhere you want. Make sure the machine is set up correctly, where X is left to right , positive commands should go from left to right and Y is front to back, and positive commands move the gantry away from you. Z is Up positive. The machine doesn't care which end you call home, it's only used as a reference point for machine zero, work zero is set after that and is most important.. My Machine is front left home just to make David crazy works fine, with GRBL and Estlcam. Cheers Gary
Hi Gary Thank you very much for taking time to clarifying the $23 setting , That makes me very happy as i Really did not want the home position to be at the rear of the machine because i just can not reach over that far. Do You have any Suggestions as to why my Z Axis fails to stop on hitting the Z Limit Switch ? What Happens is when i click on Home all axis , The Z Axis slowly moves upwards towards the switch & the switch activates but the Z Continues past the switch & i have to push Emergency stop button to stop damage occurring to the C-Beam ACME Nut. I have checked the switch is triggering in the UGS Verbose mode and it appears to be working fine. according to the output from GRBL VERBOSE OUTPUT [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0> [verbose]<Alarm|MPos:0.000,0.000,15.000|FS:0,0|Pn:Z> - Me Manualy Triggering Z Axis Limit Switch The machine appears all perfect except for just homing not working as intended , I Can Run a Gcode program & the machine acts as it should. I am Running GRBL 1.1F on a Mega 2560 & also Use Estlcam for Gcode compiling Look forward to any insights or ideas you may have Many Thanks
It's been a while since I used UGS, but yes that looks like it's seeing the switch. You could always try Estlcam, flash the firmware, its easy to revert if you don't have success.. make sure you have the latest stable version of Estlcam (from July 10th). make sure to pick the Mega settings from the hardware drop down (shown below). Make sure the inputs and outputs are correct, and then there is a nice input screen which shows live state as well. Cheers
Hi Gary - Thanks for the Really Good Idea , Had not thought about Estlcam Firmware ! I will Certainly try this if i can not succeed to get GRBL Homing with help from other makers on here & Thanks also for the Detailed Estlcam Screen Captures - This may help me if i do have to bite the bullet & take this route The only issue that i may run into is my Mega has had all the wires soldered to pin Header strips , Wires individually Heat-shinked & then Potted in Epoxy inside a 3d Printed Case to make sure that it was strong & Vibration + Damp Proofed - so if any of the pin outputs/inputs are different on Estlcam firmware i may have to swap out the whole Mega 2560 for another one ? hmmm Just Hoping it's possible to find a GRBL Homing Solution - Fingers Crossed Thanks Again for your Time & Alternative Firmware Idea Gary !
Hi Gary - Thanks for the side by side comparison , I Just been looking at it and comparing which pins that would need to be changed. Your Right It's a Totally Different Pinout setup, so I will hold off on the Estlcam Firmware for now , Unless no solution can be found to fix my GRBL homing Issue - I am sure it's something really stupid i have not configured correctly - I Just hope somebody who has come across this issue before can shine some light & show me the way to my error. But at the moment i am at a complete loss to what the issue is I Know all the Switches work Electrically & in Software they show in verbose mode when i trigger them by hand , But when homing It Starts to home in the correct Direction but fails to see the Z Switch Pin go Low & Just continues to go past the Switch like there was no Signal from the switch. It's almost like the GRBL Firmware forgets to poll the Limit Switch I/O during the homing Routine - But i am very sure somebody else would have found this before me - So that makes me believe it's an error i have made :O Many thanks Again Gary !
Interesting you have your Home $23 direction set to 7 which should make the Z go down instead of up when homing.. all inverted I would think you want 3 for $23, make sure your Z direction isn't inverted.. and jogging works in the right direction, up is up and down is down. Also, that's a great looking machine you have, please post more pics or do a build post in Openbuilds!
Hi Again Gary When i first wired up the steppers to the Drivers & Tested it via Jogging buttons Z was Correct Moving up & Down as it Should X & Y went in the opposite direction to what they should do. So i Inverted the $3 ( Direction Port Invert MASK ) to $3=3 to invert the direction of X & Y Only This resulted in X , Y & Z all moving Posative Direction when clicking (+ Dir ) --- & Negative Direction when Clicking ( - Dir ) So that all looked correct after that adjustment was made to $3=3 When i Tested Homing for the first time i found - Z axis Started Homing Downwards ( Negative ) X & Y Both went in the Posative Direction. My Z Switch is at the top ( Posative Direction ) ---- X & Y Switches are both in the Negative Direction. So i Inverted all of the homing directions with $23=7 ( X,Y,Z All Inverted ) to try to correct this It's Mind Bending getting your head around all the inversions & Direction changes going on in the GRBL Settings - LOL Does this make sense to you Gary ? , or can you see something that i am failing to see. I have considered simply De-soldering the motors & Swapping the Phases around to the motors to do the inversions & Reset Settings back to =0 in GRBL to avoid the mind bending direction swapping going on in settings.
Exwhyzee, that is odd that Z would home backwards from where it should when you have $3 as 3...Should be no reason to swap a coil when $3 does the same thing in the software. I just plugged in an old Mega I had and opened UGS, grasping at straws is "enable status polling" checked? pic below You said you have setup the switches as pull up, default is pull down.. not sure if you changed that in the config. All you really need for noise reduction is the cap.. if you are just using simple switches. Another thing, unrelated to home, do you have the same screws on all 3 axis? I see your steps per mm is 100 for z but ~160 for x and y, I can't figure out the microsteps involved to get 160 step/per/mm? Also you have very slow acceleration, crank that up to about 500 for starters. and your x and Y max speed is different, which is fine, just making sure you know.
Hi Gary - Many Thanks for all your time today trying to help out That's Well spotted ! - I Presume this is polling for checking I/O every 200ms ? I will go up to the shed tomorrow afternoon and boot up the shed PC & Check to see if enable Status polling is checked in UGS. I Run the Standard Version of UGS as the Platform version does not like my Old Battred Frankinstein Shed PC at all - But also i can take this Laptop up the shed & try it on Windows 7 UGS Platform as a virtual machine & See how homing Reacts under the Platform Version of UGS. I will update you tomorrow Thanks Gary !
Hi Gary , The Results are in I Have been up to the shed this afternoon and booted up the PC & checked to see if Status polling is enabled & it was already enabled - I Also Tried Bumping the poll rate up to every 100ms - This had no effect on the homing Issue . Also i Tried Homing Using a completely different Computer running the PLATFORM UGS & the homing still acted exactly the same so this to me suggests GRBL is where the issue is coming from & not UGS (Y/N) ? Also i Got my mini scope out to see if there was any noise on the Z-Limit switch & this looks like a Nice and repeatable Clean signal. Switch Untriggred it reads +4.870V (HI) & Triggred it Drops to 0.092V ( LOW ) with no apparent noise on the Z I/O Pin ? I will Try Downloading the GRBL 2560 Hex File Again & Re-Flash the Arduino with the new Copy to see if i had a bad download or some kind of Flashing Error. I will try this tonight & See what happens with a Fresh Install of GRBL Flashed onto the Mega 2560. Thanks Again for your Idea's & help ! Update : I Downloaded & Re-Flashed the GRBL.Hex Again to the Mega2560 - No Improvement so i have Marked this as a possible issue with GRBL / Mega GitHub - I will Update this when i have more Info or hopefully a Cure. Many Thanks Again !
Hi David That's a Fair Comment - And i can see why your pushing for everybody to adopt the industry Standard. It would cut down on confusion & make digital design files comply from one machine or system to another without modification. It would be very easy for me to implement it to the "STANDARD" to avoid the mind bending inversions in the GRBL Settings , But this would also result in me not being able to reach the machine very easy at the "Standard" home position - I could turn the whole machine around but this would mean unwiring the loom & Control box from the wall etc.. See Photo of installed setup Can you see the issue if my home was set to the Industry standard. As much as i would like to it's a major re-work of the whole installation. Kind Regards & Thanks for your advice.
I don't see why you need to access the gantry in the home position. why can you not just jog it to where you can access it? I will post a pic of my machine later. in your pic is your Y axis the one with 2 motors? if so then homing with gantry AWAY and spindle RIGHT does in fact give you access on the right of the machine as pictured (unless there is something in the way that we cannot see in the pic).
Hi David , Yes the one with the 2 Stepper motors is the Y Axis - Next to the Machine is where i am planning to Fit the Upright Dust & Chip Collector as it's easy for me to run a very short run of Ducting next to the water cooling Pipework in the picture. and the 16A Socket has already been fitted in that corner for the Collector. Jogging it - Is a Solution ! But Why not just Home to where you are actually are best positioned to easily Install & Change End Mills. When i look at almost all X/Y Graph Plots is Mathmatics, Test Instruments & to some extent Buildings I notice a trend that the Origin 0X/0Y is always in the bottom Left hand Corner, To me this makes far more logical sense than 0X/0Y being at the top Right. Can you imagine living in a High Rise tower block who's Ground Floor was the Roof Yes we Could turn the whole building upside down - But then we have some major living condition issues ! Just Pulling your Leg David Yes Jogging is a Solution, but i am going to hold out for a 0X/0Y Front Left Solution. Kind Regards -
Hiya Here is my machine parked at 'home'. As you can see the head is against the wall. I have a macro button in bCNC that goes to the last WCS used is normally near the right/front end, so I just click that to bring it near to me for setup. I have another button for 'go to MCS' which sends it back home before I turn it off. There are no switches, I just push it up against the stops if power fails or I have to Estop. Even after a power fail in the middle of a job this will get me back to the job within about 0.2mm. Yes, the Z motor misses the guitars, only just, but it misses (-: as to mathematics, the co-ordinate system is exactly as in mathematics. when you set a work coordinate at front left of your workpiece all of the Gcode is positive on the workpiece. if you look at a metalworking mill with a moving table you will see why home is up/away/right. this brings the table close to the operator! anyhow, you have X and Y reversed in both the axis setup and the home setup and it is not working. first disable homing. then what you need to do is reverse one pair of wires on each the X and Y motors, then set GRBL to 'no reverse' and make sure jogging goes in the correct directions. (and do Z too if needed so the reverse mask is 0) now set up homing again. if it now works as expected, then there is definitely a bug in that version of GRBL.
Hi David , Yes Your Correct my Steppers Phases 100% do need swapping Around to save me doing the Inversion in software. I Think this would simplify understanding the homing Issue that i am trying find a cure for. I will Give you a Thumbs up on this I will Un-solder the Wires & do the Needed Swapping of the phases to rid myself of the need to do the Inversions in Firmware settings. Then Re-Set all the Motor Direction inversions back to Default =0 & Test a Homing Cycle to see how the machine reacts & Modify the Homing as Needed. I was thinking perhaps this is a GRBL bug that only happens when Certain multiple Inversions are Present in Firmware - Config ?? I Did have a cheap Clarke Mini Metal mill & Converted it to CNC back around 2004 running Mach1 & Because the table moved and the Head was fixed it acted exactly like you describe & i set-up the Homing just like you describe as that made perfect sense for the moving table type machine Set-up. At Home the Bed Moved the work towards you for easy clamping setup & Because the mill was a tiny thing i could still reach the collet holder for end mill swaps. For me now, As the gantry moves and Bed is Fixed - The Homing position is best placed Front/Left - LOL Also as a Backup Cure , Just in case i can not get GRBL Homing Correctly, i have Flashed another Mega2560 as Gary Sugested with the ESTLCAM Control Firmware. So if all Else fails i can Remove the GRBL 2560 & Replace it with the ESTLCAM 2560. Thanks Again David !
Sounds like a good plan, I keep forgetting that you are using Mega and I'm not sure many people are, could very well be a Mega2560 GRBL bug. Though any trigger of any of the switches should cause the machine to stop, regardless of which way things are moving. Cheers Gary
ExWhyZee. Just ordered myself a Mega for use with Estlcam. So I know where to go, for info then, in the future.
Hi David , Gary & GrayUK This Evening I Reset GRBL 2560 to the Default ( No Inversions ) & Checked to see which Motors Needed me to do the Re-wiring of the Phases. Z Axis Was Perfect as it Was so I Left that One Untouched , X&Y Both Needed a Phase Swap to Correct Default Rotation. I Did a Jog Test & all Was Fine - All Axes Moving Correctly without the need of the (DIR INVERSION) Next I Slowed down the Home Seek & Feed for Purely Safety Reasons & did a Home Cycle test Result was Z Finally Homed Correctly But X&Y Shot off Looking for Davids Industry Standard Homing Position - LOL So I Inverted X&Y Homing Directions & Did a Home Cycle Again - 100% PERFECT ! Homed to Front / Left as it Should ERROR IN GRBL ! It Certainly looks like there is a GRBL 2560 Firmware bug that if your X&Y Motor Directions are Inverted & Also Your Homing Dir X&Y is Inverted it Fails to see any Switches Trigger & Just Keeps on Seeking. Now all i Need to do is Fine Tune the Feeds & Speeds & Square & Tram + Check all Axis on machine for any Lost Steps by running a few Long Test Programs. Then Make a Spoil/Fixture Board & Surface It Many Thanks for all your Help & Practical Suggestions David & Gary - Your Top Guys ! Note: My Thank-you is in the ( Bottom / Left Corner )
