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

More
23 Jan 2018 05:48 #104871 by kentavv
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

Please Log in or Create an account to join the conversation.

More
23 Jan 2018 13:12 #104888 by BigJohnT
I think the manual is not correct after testing in a simulator.

JT

Please Log in or Create an account to join the conversation.

More
23 Jan 2018 20:14 #104919 by kentavv
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.)

Please Log in or Create an account to join the conversation.

More
23 Jan 2018 23:37 #104927 by BigJohnT
The best way to recover from any type of situation is a good preamble to setup the proper settings for the G code. I alway assume that I need to set everything on the first line of the G code file.

JT

Please Log in or Create an account to join the conversation.

More
28 Jan 2018 18:01 #105108 by jmelson


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

Please Log in or Create an account to join the conversation.

More
28 Jan 2018 18:58 #105111 by kentavv
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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.454 seconds
Powered by Kunena Forum