I built a CNC router using CNC Shield running GRBL. I have proximity sensors for limit switches and after homing the machine I have set the homing pull off to 8mm was 3mm to see if that helped but doesn't. After homing the machine it moves 8mm off in x and y and it resets home of the machine and work to 0,0. Then if I move the x,y off a bit and then hit go to 0,0 it goes past the current home position in negative Y and hits the limit. What am I missing? I feel like after I updated the software in CNCjs this started happening because I had to redo all my grbl settings but I think they are right? $0=10 (step pulse, usec) $1=255 (step idle delay, msec) $2=0 (step port invert mask:00000000) $3=0 (dir port invert mask:00000000) $4=0 (step enable invert, bool) $5=0 (limit pins invert, bool) $6=0 (probe pin invert, bool) $10=1 (status report mask:00000001) $11=0.010 (junction deviation, mm) $12=0.002 (arc tolerance, mm) $13=0 (report inches, bool) $20=0 (soft limits, bool) $21=1 (hard limits, bool) $22=1 (homing cycle, bool) $23=3 (homing dir invert mask:00000011) $24=50.000 (homing feed, mm/min) $25=900.000 (homing seek, mm/min) $26=250 (homing debounce, msec) $27=8.000 (homing pull-off, mm) $100=800.000 (x, step/mm) $101=800.000 (y, step/mm) $102=800.000 (z, step/mm) $110=2000.000 (x max rate, mm/min) $111=2000.000 (y max rate, mm/min) $112=2000.000 (z max rate, mm/min) $120=200.000 (x accel, mm/sec^2) $121=200.000 (y accel, mm/sec^2) $122=200.000 (z accel, mm/sec^2) $130=740.000 (x max travel, mm) $131=700.000 (y max travel, mm) $132=115.000 (z max travel, mm)
perfectly normal for GRBL that going to 0 will trigger the limit, it sets home 0 at the trigger point and going to 0 will always re-trigger causing an alarm. That is why our Fusion360 postprocessor has an offset for g53 moves to prevent it hitting the Z limit. The offset in the homing setup does not offset the home, it only retracts the axis so the switch is no longer triggered
Thanks for reply, so when my machine homes to the offset positions I have it set to resset machine coordinates to zero. The screenshot of the zero'd out is after it is homed and at the offset positions, that's what is confusing me. Both coordinate systems are zero'd at that position. I thought that since that's the new 0,0 that it would go there and not to the limit switch zero position.
I think that you are confusing MACHINE co-ordinates and WORKPLACE co-ordinates. Homing sets the MACHINE co-ordinate system (sets the back, right, up corner of the machines available space to the maximum for each axis - this is normally zero and the MACHINE co-ordinates get more negative as you move away from that corner). The "offset" David referred when talking about the Openbuilds post processors is the pull off distance that is the final part of the homing movement to move an axis away from the trigger point of the switch so that it is not permanently triggered. Setting XYZ sets the current WORKPLACE coordinate system. You set XYZ zero IN THE SAME PLACE as you set the origin (reference point) in your cam software. This tells your controller whereabouts in the MACHINE space you put the workpiece. WORKPLACE co-ordinates can be positive or negative in relation to the zero point you set. What you have been doing is setting the WORKPLACE co-ordinate system to zero at the home position in the MACHINE co-ordinate system. The G53 command means that what follows on the same line is a command (eg G0 - rapid move) to be carried out in the MACHINE co-ordinate system. If there is no G53 at the beginning of the line the command will be carried out in the WORKPLACE co-ordinate system. Hope that makes sense and clarifies things for you.. Alex.
Thanks for the replies, I'll read over those. I thought by setting enabling HOMING_FORCE_SET_ORIGIN in my config.h file would resolve this since screen shows machine coordinates as 0,0,0 at correct location that it would always go back to that. Need to do more reading I guess.
