More homing problems

I have had my machine (1000 mm, X controller) for 2-3 years now and have not been using limit switches but want to make use of the Work Coordinate system so I am trying to set them up.

My issue is the z axis homes properly but X and Y move to trigger the switches but the motors don’t stop and retract as they should, they just keep on trying to move. I have checked the status of the switches by triggering them manually and after I have had to do an emergency stop while trying to home and they show to be triggered (1,0,0 for z, 0,1,0 for y, and 0,0,1 for x)

These are my settings:
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=7 (dir port invert mask:00000111)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=19 (status report mask:00010011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=1 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$30=255. (rpm max)
$31=0. (rpm min)
$32=1 (laser mode, bool)
$100=26.667 (x, step/mm)
$101=26.667 (y, step/mm)
$102=50.181 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=1800.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=300.000 (z accel, mm/sec^2)
$130=740.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

I tried changing $27 to 5 as mentioned in another post to avail.

The only difference in the switches is the X and Y are they type that comes with the xcarve and the z is one that comes on the CNC4Newbie Z axis. They are all wired the same.

I don’t understand if GRBL shows the switch triggered in status why the motors keep trying to move.

Appreciate any suggestions.

(tried homing in Easel, Picsender, and UGCS with same results).

Write down/save the current values from the $$ output, we may need to restore them later.

Use the information here to install a more up to date grbl, using Xloader described on the link page. Xcarve_JTech_grbl - latest release (9/1/2017)

Use the 9/1/2017 version. Post the $$ settings here.

If it is still trying to move against the homing switch then the switch is not wirred correctly or defective on not being triggered.

Grbl 1.0c [’$’ for help]

$$
$G
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=7 (dir port invert mask:00000111)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=19 (status report mask:00010011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=1 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=0 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$30=255. (rpm max)
$31=0. (rpm min)
$32=1 (laser mode, bool)
$100=26.667 (x, step/mm)
$101=26.667 (y, step/mm)
$102=50.181 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=1800.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=300.000 (z accel, mm/sec^2)
$130=740.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

I measured the voltage at the connection to the xcontroller. All show 5V that drops to 0 when the switch is depressed manually.

I ran another test homing. The Y axis moves to the stop but keeps trying to move left and the voltage at the xcontroller read 0v on the signal from the Y limit switch. X did not complete as I restarted the machine

I restarted without moving the gantry and status shows as 010.

@JackieLPreston

It looks like the settings are reasonable at first.

Change $10=115

It looks like your initial problem may be the Y axis.

take some pictures that show where the homing switches are mounted and just close enough to tripl

The status in the first image was:

<Idle,MPos:0.0000,-6.8105,0.0000,WPos:-0.1600,-6.8105,-0.4700,Buf:0,Pin:000|0|0000>

and the second was:
<Idle,MPos:0.0000,-6.8105,0.0000,WPos:-0.1600,-6.8105,-0.4700,Buf:0,Pin:001|0|0000>

ok

X and Y switches mixed up?

First you need to clean up the wiring to the homing switch terminals. The wiring shown in the picture (not very good solder job) would not last very long and it’s a bit of luck to catch it now.

The other information from the pictures is that you have intermittent contact on the X and Y axis homing switches as shown by the status command.

The way the homing cycle works is to move the Z axis out of the way, searching for the Z axis homing switch to change state.

Only after the Z axis homes correctly will grbl move to work on X and Y simultaneously.

So, you have to get the Z axis to home properly before the remaining axes even move.

When you clear up the Z axis problems then you can use the status command to locate the problems on the other axes.

I made a mistake in my previous post indicating y when it was actually x and these pictures are of the x axis but they both do the same thing - it just depends on which gets to the stop first. My Z axis will home successfully then x and y start moving towards the stops simultaneously. I have adjusted the carriage on different occasions so that x arrives at the stop first and other times that y arrives at the stop first. In either situation they try to continue to move forward instead of stopping or backing off.

It seems to me that the system is recognizing the switch has been triggered otherwise the status would not change it just doesn’t respond appropriately and stop.

Otherwise I have no problems and everything functions appropriately.

BTW, thanks for your efforts.

Actually I took the first picture intentionally before it triggered then moved it forward. My status responses are very repeatable.

Try changing $27=5 to see if the homing sequence is not backing off the switch enough.

Maybe even 10 or more just to rule it out.
$22 should be 1

I tried all these changes with the same response. My Z axis homes rapid, backs off, seeks slower then stops. My x and y still do not stop.

My understanding is that I should be able to simply insert 2 wires in the ground and x limit switch terminals then connect them while trying to home that axis and the stepper should stop, back off and seek at a slower rate. This would remove all issues such as bad switches or wiring.

Assuming I do this and it still doesn’t work - what next? Call to tech support?

SUCCESS!

I’m not sure exactly what fixed the problems. I went through the wiring again, made the suggested changes to GRBL and adjusted the contact positions of the switches on the stops and it finally works.

I want to thank everyone who contributed.

No on to more cutting/burning…

Thanks again.

1 Like