Back Z button does weird simultaneous things

Software
1

I was cutting my sled and realized just before I cut the whole thing out that if I put a groove between the brick holes, I could use a zip tie to hold the bricks in place (maybe… we’ll see if the zip ties get flat enough not to rub).

So, at the top of the sled, I hit pause, raised the router, and hit <Z enough times to get me to one of the brick holes (the crosshair kept flickering, but I could see it), and then 2 more (to make sure I was “in the hole”). When I pressed “Resume”, the router started its long journey to the hole, but GC only waited for “the drill hole” operation to complete, not the journey to be finished (and when it popped up with the Z change, all motion stopped)…I kept hitting “Ok” on the depth changes until the crosshairs lined up and then used <Z to go back again… and had to repeat it 3x to get it to “start in the hole”.

Was I doing it wrong? What I was hoping for when I pressed “Resume”:

  1. Router retracts to safe position
  2. Moves to the hole (this can take a while - we shouldn’t be executing the G-Code yet)
  3. Move to the correct Z (on the line) [pop up the Z change dialog for us manual guys; this is where I set it to 1/4" cut)
  4. Resume G-Code (cutting my slot)
1 Like
2

what version of gc and firmqware are you running, that is a problem we had a
couple versions ago, but I thought we had it fixed

1 Like
3

The “master” just before the newsletter came out (FW 1.4, and I suppose GC 1.4, but GC 1.4 wasn’t packaged/released yet, so I’m running from the head at that time).

1 Like
4

The fast forwards and backwards commands are a little bit strange at times because they jump back to a previous line in the gcode and resume from there, however the way gcode works is that it often relies on information that was sent in even earlier lines (for example moving the z-axis height). The result is that it can be a little bit hit or miss in terms of if it behaves in the way we want it to.

I am totally in favor of trying to make this behavior a little bit more intelligent, but I think we should be careful that our assumptions about what the “right” behavior is will be right in all cases

5

That’s what I was trying to start – if we get agreement on “what I was hoping” then we can get a good fix in place.

If someone sees something amiss with “what I was hoping”, let everyone know… I’d like it to operate in a safe (I just got my powered Z hooked up), expected way.

Even once we get back to @dlang’s point, I want to make sure we have the “move z to safety first” in place so I don’t gouge things while doing a move.

1 Like