G33.1 rigid taping on a mill leads to a couple unexpected events

With LinuxCNC 2.7.11, I added a 2500 ppr encoder to the spindle fed back to the encoder input on a Pico Systems' USC board. This combination works well, for spindle position and speed up to the max RPM of my small mill. I have noticed two oddities with G33.1 rigid tapping that I need some help with.

1. The manual for G33.1 (linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g33.1) says

If the X Y coordinates specified are not the current coordinates when calling G33.1 for tapping the move will not be along the Z axis but will rapid move from the current location to the X Y location specified.

But if I specify g33.1 x1 y1 z-1 k0.05 from position 0,0,0, there is synchronized motion to 1,1,-1. The rapid to 1,1,0 does not occur. Is the manual wrong, am I wrong, or is this a bug?

2. Occasionally, G33.1 will do what appears to be a rapid move seemingly to the Z position, without regard for spindle synchronization. I think that this is most likely to occur after a crash in the middle of a previous g33.1. (I'm learning the system, drilling and tapping wood, and I don't have everything perfect.) I believe G80 (cancel canned cycle) helps, but I don't know for sure.

So, I think the sequence is G33.1 that does synchronized move correctly but crashes during the cycle causing an e-stop (because the servo or spindle faults), the situation is recovered by backing the spindle out, moving, and drilling a new test hole. Now, I begin G33.1 again and the unexpected rapid move occurs.

I'm working off that G80 is required after all G33.1 crashes. Does that sound right or is this a bug or am I doing something wrong?

Rigid tapping is looking pretty promising. Not sure it'll work reliably with my basic BLDC motor without a break. The spindle coasts for a long time, but this gives me a real reason to look into an alternative motor to attempt to add breaking to the BLDC.

Thank you, Kent

Thank you John. I'm pretty sure it was a picture that you posted of a mill spindle mounted encoder that inspired me to try this.

What do I know, but it feels like the interpolation in X and Y is more appropriate for G33. Like G33.1 carries over most of G33, and that the manual is reasonable, but the initial rapid in X-Y was never implemented fro G33.1.

What do you think of #2, rapid initial moves? Could the state of LinuxCNC following a crash (external e-stop) during a G33.1 be a bit off? Is G80 a safe and required "reset" or might something else be off here?

(I had similar unexpected behavior in path blending following an external e-stop. The path blending parameters changed from those I had set in an init program. That's a topic for a different thread though after more testing.)

kentavv wrote:

1. The manual for G33.1 (linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g33.1) says

If the X Y coordinates specified are not the current coordinates when calling G33.1 for tapping the move will not be along the Z axis but will rapid move from the current location to the X Y location specified.

But if I specify g33.1 x1 y1 z-1 k0.05 from position 0,0,0, there is synchronized motion to 1,1,-1. The rapid to 1,1,0 does not occur. Is the manual wrong, am I wrong, or is this a bug?

I don't know about the docs, but I would NEVER do this! I want the machine at the desired XY coordinate before any Z motion occurs. So, I always move to the XY coord of the hole first, then do the G33.1 in the next line.

2. Occasionally, G33.1 will do what appears to be a rapid move seemingly to the Z position, without regard for spindle synchronization. I think that this is most likely to occur after a crash in the middle of a previous g33.1. (I'm learning the system, drilling and tapping wood, and I don't have everything perfect.) I believe G80 (cancel canned cycle) helps, but I don't know for sure.

I have not seen this in ages, but I'm also very cautious about aborting anything with a G33.1 operation in it.
I did have a problem some time ago where the VFD would fault thinking that all the motor reversals would overheat the motor.
I had to unclamp the tap and back the machine out manually, big pain, but it did not cause uncommanded movements.
(That was a much older version of LinuxCNC, however, not using Robert Ellenberg's new trajectory planner.)

Jon

Thank you again guys. If what I'm seeing is not a bug in the LinuxCNC, please update the documentation. A new comer would expect that's the authoritative source for guidance. As the section is written is written now, the behavior is similar to a single move G80, not unreasonable, but performs like a G33. And a note regarding G80 or other crash recoveries for canned cycles. (If the documentation was a Wiki, I would be glad to help; this is the third similar break-your-tool-gotcha I've found, and last I checked the other two remain.)

I still suspect these are bugs, but perhaps #1 on some fancy five axis machine it makes sense

Unrelated, but a simple website improvement that would help new comers is to use hints to the search engines (sitemap? robots.txt?) to ignore all old versions of the documentation and only index ../current/.. instead of ../version/.. URL paths, where ../current/.. is an alias to the most recent version. Currently, the search results are a mixture of 2.6 and 2.4 (sometimes older) but rarely 2.7, which is too bad because each new version of the documentation improves.