Carbide motion stop failure

CNC Machines Shapeoko
1

I am new to the Shapeoko. I am testing some simple engraving with a 60 degree V bit that was recommended here and found on Ebay. I had 3 lines of text 8 mm tall and 1 mm deep. After the second line was done I hit pause, then decided to stop and inspect the work, this is just a test piece. When I hit stopped it lowered the z axis into the piece and proceeded to drill out about a 10 mm hole. Yikes!!! Glad I was on a test piece.

I had this happen earlier on another test piece with the 201 end mill and thought it was a one off but now it has happened again. In both cases the cut was just fine and the depth was accurate. Everything was good until I hit stop. Both designs were done in Fusion 360.

Any ideas as to what is happening. I am sure it is my fault but should stop pull the bit up and out of the way.

Thanks for any insight you can give me

2

I suspect that what is happening here is the when you stop / pause, the machine is bottoming out on the retraction against the top stops, so thinks it is higher up than it is — when you resume, it plunges the actual travel, plus the assumed travel with the results you describe.

3

When you paused in Carbide Motion, the Z axis is raised a bit. Was your setup at that moment such that the Z axis went all the way up to the top of its travel? If you crashed your Z axis against top of travel and resumed, it would be logical to see the machine drive deep. On the other hand, when you’re paused and you hit the stop button, the machine initiates a homing cycle, which should travel up, not down. Since the limit switch tells the homing cycle to change Z direction, it’s the possible logic issue I have in my fault tree.

I’ve recorded inverted travel behavior during more-than-just-Z probing when resuming a probe cycle that was interrupted using FEED_HOLD, but I’m not at my machine to experiment with whether something similar could occur by attempting to home when the machine is on the Z limit.

2 Likes
4

I just got home and confirmed my hypothesis by experiment. I made a simple slow toolpath that I could easily pause with plenty of clearance, and I set my zero low enough to easily reach a finger in and press the Z axis limit switch. The experiment is trivial to replicate:

  1. In Carbide Motion, pause the machine.
  2. Press the Z-axis limit switch.
  3. Click the Stop button (and then release the limit switch).
  4. Watch as the Z axis first moves down 10mm, then reverses and performs a normal homing cycle.

I don’t know if this was what hit you, @Unclejoe, but I’ve confirmed it can happen if you hit the Stop button when paused against the Z axis limit switch.

5

@ClayJar Can you capture the log output when you do that? I don’t use Motion, but the more people know what it’s doing, the better prepared they’ll be.

6

Certainly. Here’s an abridged log from a normal stop and a stop when already against the Z limit switch. (The listings are in inverse chronological order as displayed in the log window, which bugs me, but hey, consistency…)

Normal Stop:

(6134): -> $h
(6133): -> gc_homing
(6132): <- ok
(6131): -> N0 G4P0.005
(6130): -> gc_wait_for_idle
(6129): -> gc_check_limit_switch
(6128): <- ok
(6127): -> N0 G4P0.005
(6126): -> gc_wait_for_idle
(6125): -> gc_backoff_limit_switch
(6124): <- ok
(6123): -> N0 G4P0.005
(6122): -> gc_wait_for_idle
(6121): <- <Idle|MPos:-50.175,-46.525,-17.450|Bf:14,128|FS:0,0|WCO:0.000,0.000,0.000>
(6120): <- Grbl 1.1f ['$' for help]
(6119): <- ok
(6118): STATE: SET MACHINE STATE: INIT
(6117): -> GRBL_RESET
(6116): -> GRBL_FEEDHOLD

Stop against Z limit switch:

(5447): -> $h
(5446): -> gc_homing
(5445): <- ok
(5444): -> N0 G4P0.005
(5443): -> gc_wait_for_idle
(5442): -> gc_check_limit_switch
(5441): <- <Idle|MPos:-53.700,-46.525,-27.450|Bf:14,128|FS:0,0>
(5440): <- ok
(5439): <- <Run|MPos:-53.700,-46.525,-27.225|Bf:13,128|FS:167,0|WCO:0.000,0.000,0.000>
(5438): <- <Run|MPos:-53.700,-46.525,-26.200|Bf:13,128|FS:300,0>
(5437): <- <Run|MPos:-53.700,-46.525,-25.175|Bf:13,128|FS:300,0>
(5436): <- <Run|MPos:-53.700,-46.525,-24.175|Bf:13,128|FS:300,0>
(5435): <- <Run|MPos:-53.700,-46.525,-23.175|Bf:13,128|FS:300,0>
(5434): <- <Run|MPos:-53.700,-46.525,-22.150|Bf:13,128|FS:300,0>
(5433): <- <Run|MPos:-53.700,-46.525,-21.125|Bf:13,128|FS:300,0>
(5432): <- <Run|MPos:-53.700,-46.525,-20.100|Bf:13,128|FS:300,0|Pn:Z>
(5431): <- <Run|MPos:-53.700,-46.525,-19.100|Bf:13,128|FS:300,0|Pn:Z>
(5430): <- <Run|MPos:-53.700,-46.525,-18.100|Bf:13,128|FS:300,0|Pn:Z|Ov:100,100,100>
(5429): -> N0 G4P0.005
(5428): -> gc_wait_for_idle
(5427): <- ok
(5426): -> N0G1F300.0Z-27.450
(5425): -> gc_backoff_limit_switch
(5424): <- ok
(5423): -> N0 G4P0.005
(5422): -> gc_wait_for_idle
(5421): <- <Idle|MPos:-53.700,-46.525,-17.450|Bf:14,128|FS:0,0|Pn:Z|WCO:0.000,0.000,0.000>
(5420): <- Grbl 1.1f ['$' for help]
(5419): <- ok
(5418): STATE: SET MACHINE STATE: INIT
(5417): -> GRBL_RESET
(5416): -> GRBL_FEEDHOLD

In 5421 you can see Pn:Z (Z limit switch pressed), which is not the case on 6121. That triggers the backoff shown in 5426 and executed in 5430 through 5439.

I tried a similar thing in the UGS I have installed for my laser. It does not automatically home when you stop a job, so the issue does not manifest. When I held the limit switch and attempted a homing cycle, it would execute a backoff before continuing (but much faster, and if I didn’t release the switch fast enough, I’d hit an alarm state).

1 Like
7

Yeah… That’s a problem.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.