Safety issue - going home

I’m not sure if this should be a Feature Request or appropriate to be asked here - so I’ll start here…

At the end of a job, the bit retracts only a small distance above workpiece (is it the retract height set in the toolpath?), turns off the spindle (because I have a BitRunner) and prompts to Resume. When I do this the machine travels along the Y axis, at a bit of a lick, to the rear.

This is potentially quite dangerous, because the bit doesn’t retract as high as it could, and I’m not sure why it works like this.

To be honest, it should be obvious that every machine-initiated rapid movement - i.e. where users have absolutely no control other than the off button - should be made with the Z axis at it’s zenith, to make sure it clears anything that might be in the way, e.g. stock, clamps etc., avoiding as much as possible the potential damage the bit, stock, workpiece or even the spindle.

The solution would be to use an appropriate GRBL command (I don’t understand GBRL, by the way, but it sounds like a simple thing) to raise the spindle before moving it backwards. If it is based on the retract height set in the project’s g-code file, this needs to be resolved.

Thank you

2 Likes

Yes! Well said Peter. I would certainly feel happier if the rapid moves were all carried out as uncontrolled circumstance moves. I would not want to hijack the point but would love to see it combined with user defined rapid points which were persistent. That way the would be no shocks for the user who did not expect the machine to move in a certain direction. Indeed, there should be no reason why user defined points could not be numbered in order of priority to ensure that the rapid movement would hit or pass the rapid points in a directional manner, thus bringing a level of certainty to the final movement.

2 Likes

I have Shapeoko xxl with hdz. When the job is complete my hdz retracts to almost full height. I am running latest cm. What version are you running?

1 Like

I’m running the latest versions of CM & CC too, on an XXL with a Z-plus :face_with_monocle:

Hmm, I am running with a Z-Plus on my SO3 standard and it does not behave the same as yours. I do not have a bitrunner though. Mine finishes the job, retracts to full height and then rapids to the back right corner. It then prompts me to turn off the spindle. I will check my software versions and verify that behavior when I get home today.

1 Like

This sounds related to your issue #3. You are losing Z position. Can you share your gcode?

@nwallace, for clarity, this is what happens with mine, when a the project finishes:

The bit retracts immediately above the point it last cut, to what appears to be the same height from the stock as the Retract Height set in the Job Setup screen in CC, but this might be a coincidence.

Then I get a pop-up telling me to turn the spindle off (but it’s already been turned off by the BitRunner) with a Resume button.

When I click the Resume button, the spindle moves towards the back, in line with the last cut. It doesn’t go ‘home’ to the NE.

I’d be interested to know if that’s how yours works, too!

I measured the difference between the top of the stock, where I’d zeroed the machine before I started the cut, and afterwards when trying to resolve the issue before asking on here, and it was almost 16mm lower - and why it cut through the bottom. At no stage during the did it make any inappropriate noises, it just cut down too far - and if I hadn’t caught itit probably would have gone into the waste board.

The files are attached, but in Show Simulation and an external .nc file viewer, they looked as I expected them to.

Whatever is causing this, it’s beginning to pi55 me off, and worse? I’m losing faith.

The stock is still in place, so I’m going to do an ‘air’ cut tomorrow and (hopefully) take a video of exactly what happens, because I think the first cut into the stock was a lot deeper than I expected as (you will see in the CC file) the depth of cut is set at 0.040" (a hair over 1mm).

Hexagonal Box - 1p176in.nc (159.4 KB)
Hexagonal Box.c2d (206.0 KB)

Can you share your grbl settings?

If you tell me how to do it, or is it using $$ in the MDI in CM?

I’ll do it tomorrow, though, coz it’s a bit late for me. I need my grumpy sleep! :rofl:


:+1:

1 Like

Thank you. I’ll get on it tomorrow Zzzz

Also check if your Z has any play in it. It should not move up and down by hand.

1 Like

Hmm, I’m doing something wrong here!

Ah, sorted :+1: I didn’t know about the Log window. The results are in:

$$
$0=10
$1=255
$2=0
$3=2
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=3.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=200.000
$110=10000.000
$111=10000.000
$112=1000.000
$120=500.000
$121=500.000
$122=270.000
$130=845.000
$131=850.000
$132=95.000
ok
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:-5.000,-801.850,-61.890:1]
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F50 S0]
ok

Nope, no play there :+1:

When testing this again, be sure to measure both the Z-Axis position and also, separately, the tool protrusion.

The only time I’ve had this happen was when the collet was faulty and the tool pulled itself out as it turned, running deeper and deeper into the stock.

2 Likes

Am I correct in thinking the vertical position of the Z axis, and not the position of the Z axis in relation to the X and Y axes?

I did the measuring thing after the event, and the tool protrusion was 45mm, the workpiece 31mm and gap between the two was 40mm.

You’re right… I meant the Z-axis’ vertical position. So the distance between a fixed point on the axis and a moving point on the axis.

You’ll need both before and after measurements, of course :slight_smile:

:+1:

I knew that! :rofl:

Honestly, there are so many things to do/remember between thinking of a project and starting to cut it, that the fewer step checks you need to make in that process will leave a user less prone to make mistakes.

I’m sure every single person on this forum has made any number of mistakes and will learn from them (eventually, if not immediately) but the software (and hardware) should be reliable, and I’m beginning to think it’s not.

Is this repeatable? Or was it a one time thing?

Can you set Z0 a half inch above the wasteboard, then in the MDI send:
G21 G53 G0 Z-5
G0 Z0

Repeat those two commands several times. It will send your Z, at rapid speed, to the top and bottom of travel. It might give an indication if there is something mechanical (or electrical) causing the issue.

NOTE: The G21 sets you to mm mode. If you use inches, set G20 when you’re done.

Yep… we’ve got to get this sorted for you so we can see if it’s you or the machine and subsequently point our fingers in the correct direction and feel satisfied.

Humans are unreliable, and if you add their reliability curve to an unreliable machine’s reliability curve, it’s probably close to the shape of a frustration curve, which is of course a well known shape. Though maybe you’d get a curve shaped like the surface of on top of a nicely poured pint… and then of course… em… I think I’ve lost my train of thought.

1 Like