System goes on hold after hitting the go to zero in UGS

1st I home the system $H
Then I use the zero block and routine.
Then I press the return to zero and the system goes on hold.
I do not have a hold button hooked up.
It has never done this before
Any suggestions?

Here is the settings:
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=4 (dir port invert mask:00000100)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=2 (status report mask:00000010)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=1 (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)
$100=40.100 (x, step/mm)
$101=39.900 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=88.000 (z max travel, mm)

Your go to zero is violating the soft limits somehow. I had that happen to me before and didn’t realize why until the Z almost broke the switch.

1 Like

I have no idea why as I was not having this issue before.
My soft limits are now off so I do not get the error. :confused:
I can’t even get it to home properly as it gets a false indication that the limit switch was triggered.
So my homing will move then stop prior to the limit switch and I have to check it to make sure it actually homed.
Sometimes it doesn’t fail after not homing properly.

I just want a system that works. Getting tired of all these issues.

1 Like

I did check them using UGS and having the system report their status.
These were working perfect before I did the mod with the TB6600 drivers.
The switches work when you trigger them and watch the screen in UGS.
I am using UGS for my jobs.

Thanks Phil for your input.
$10=19 is what I set
I did re-flash the firmware with the 1.0 version of Grbl from the grbl github repository.
I did not know someone modified the version. Where is it located?

Phil do I understand you correctly, I can change max Z rate (plunge)?
I have noticed the plunge increases the run time on detailed 3d carves.
What effects on the machine will occur by increasing the max Z rate?

I have the new X contrler so do I ned to adjust currrent? Based on the specs for machine I thought it was not capable of more than500 mm/min. I will try to set at 1000 mm/min.

Can’t find the download… :confused:

You are right all motors are the same. However the acme lead screw on Z reduces the travel compared to the belt only mechanism of the X and Y.
I just checked and my Z only moves about 0.085" per motor revolution. Y moves 1.59" per motor revolution.
So for the recommended defaults the Y motor would run at about 198 rpm for 8000 mm/min and the Z motor would run at about 235 rpm for 500 mm/min.
I also suspect the driver has a limit regarding number of steps per second maybe that is a Hz rating.
Don’t get me wrong I am very pleased with the XC. Just thinking of ways to improve and reduce carve times.
I do like the Z mod you have done and I eventually want to increase Z travel capacity but with Inventables components with exception of the self made Y risers.

Yes, the current version of grbl for the Arduino/X-controller is limited to 30,000 steps per second officially, but you can use higher rates in some circumstances.

1 Like

Sorry I was not referring to acceleration.
I was responding to your statement about motors being same. My point is that plunge rate is reduced by the acme screw.
At the recommended defaults the Z motor is already having to run faster than X and Y.