Error when using G93 with canned drilling cycle

I am having trouble running a simple drilling operation. I have kinetic control 5.2.6. I am posting a simple drilling operation using the Mastercam Post downloaded from the website (2023). The error I am getting upon trying to run the gcode is “Cannot Feed with Zero Feedrate”. It does not give a line number but by process of elimination it is occurring on the line with the G81 canned cycle.

If I switch it to use G94 instead of G93, the error does not occur. Problem is, I cannot get the post to output anything but G93 for the canned cycle.

The documentation on the LinuxCNC site has the following line which is interesting:

When the inverse time feed rate mode is active, an F word must appear on every line which has a G1, G2, or G3 motion, and an F word on a line that does not have G1, G2, or G3 is ignored.

Sounds a little bit like LinuxCNC might be ignoring the F word on the G81 line. If that is the case, is that a problem with LinuxCNC for ignoring it or with the post for using G93 on a drilling cycle?

Code is below:

%
%
(AXIS,stop)
(HOLE)
( T2 | 1/4 BALL ENDMILL | H2 )
G20
G90 G94 G17 G40 G91.1
( DRILL THE BALL POCKETS )
G49
G53 G0 Z0.
G53 G0 X2.5 Y2.5
G53 G0 B0. A0.
M5
M01
( 1/4 BALL ENDMILL | TOOL - 2 | DIA. OFF. - 2 | LEN. - 2 | TOOL DIA. - .25 )
T2 M06
S8500 M3
G90 G93 G17
G54
G0 B-60. A0.
M254 P9
G59.3
G0 X0. Y-.1875
G43 Z.6582 H2
G99 G81 Y-.1875 Z.1582 R.6582 F68.
G80
M5
G53 G0 Z0.
G53 G0 X2.5 Y2.5
G53 G0 A0.
M30
(AXIS,stop)
%

The LinuxCNC documentation says it’s an error to run canned cycles in inverse time mode (G93), so that is a post issue.

https://linuxcnc.org/docs/html/gcode/g-code.html#gcode:canned-cycle-errors

Thanks, is it Mastercam that wrote that post? The reason I ask is that the PocketNC Post that is downloadable from the Mastercam site does not support RWO or TCPC.

I’ve run into another similar problem with the post(from the PocketNC site) but I am having trouble finding documentation to determine where the bug is. When using Simultaneous 5-axis toolpaths the post sets G93 before outputing the lead-ins with a G6.2. The G6.2 with a P1 parameter (feed move) is raising an error in the PocketNC even though there is a feed rate specified. Strange thing is, the on-line simulator does not raise an error. Maybe I need to upgrade the firmware in my PocketNC.

Here is the code that raises the error:

G90 G93 G17
G54
G0 G43 H1
G0 B-11.874 A44.998
G6.2 X-.2807 Y1.4807 Z-.0971 I1 J1 K0 P0 F10.
G6.2 X-.2807 Y1.4807 Z-.0971 I0 J0 K1 P1 F10. <— error here
M428

Changing it to the following runs fine

G90 G94 G17
G54
G0 G43 H1
G0 B-11.874 A44.998
G6.2 X-.2807 Y1.4807 Z-.0971 I1 J1 K0 P0 F10.
G6.2 X-.2807 Y1.4807 Z-.0971 I0 J0 K1 P1 F10.
G93
M428

It sounds like you’re running into a bug that was fixed in 5.3.1, which prevented G6.2 from working in inverse time mode.

Yes, Mastercam developed the post and the one on our site was developed before the release of Kinetic Control. I recommend reaching out to Mastercam for an updated post.

Thanks for the quick response. I updated to 5.4.6 and sure enough the error in G6.2 goes away. Thanks for that. I should have done that sooner.

I get a little bit farther and am running into another related problem. In the following code the axis moves after the G6.2 are being interpreted as feed moves and raising an error because they do not have an F word. The interpreter is treating the P word in the G6.2 command as modal and using it to set the motion type for following lines. I believe the post expects those lines to be interpreted as rapids.

I am having trouble finding documentation of the G6.2 command so hard to tell if this is correct and the post should be resetting the movement type after the G6.2 line or if the interpreter should be doing it.

Any pointers in this regard are appreciated. I have opened a support ticket with our Mastercam reseller to get an updated post. I am hoping to use the PocketNC to teach a class next term, hence why I am trying to find all the changes needed to add to the support request so that they can be fixed in one release and we can get a useful post. I really appreciate your help with this.

Code is Here:

SyntaxEditor Code Snippet

G0 Z1.
G49 G54
G43 H1
B-11.874 A44.998
G6.2 X-.2807 Y1.4807 Z-.0971 I1 J1 K0 P0 F12.766
G6.2 X-.2807 Y1.4807 Z-.0971 I0 J0 K1 P1 F12.766
M428
Y.6562 X-.3389 ← Interpreted as feed move, raises error
Y.3734 Z-.3739
G1 X-.3971 Y.0905 Z-.6507 F37.5

I’ve raised this issue with Mastercam before, so it seems they haven’t addressed it yet or your post is out of date. I believe you can work around it by using feed rate moves rather than rapids (I think this is a setting in Mastercam somewhere).

The documentation for G6.2 is here: https://pentamachine.atlassian.net/wiki/x/CoATZg

It doesn’t go into detail about its modality, but it does change the motion mode to G1 when using P1. It’s a custom code that we implemented and could potentially change its behavior, but most motion codes are modal, so that’s what we went with.

Took me a second but figured that out. It does work around this problem. Thanks.

I am using the post downloaded from your site dated 12.29.22. If there is a later one that you are aware of, I’d appreciate a pointer. The one available on the Mastercam site is ancient. Doesn’t support RWO or TCPC.

Once again. Thanks for your time and quick responses. Really appreciate it.

I’ve reached out to a contact at Mastercam. I’ll let you know if I hear anything.

Mastercam has asked for your info and your reseller along with a Mastercam file that demonstrates the issue. If you want to send that info over to service@pentamachine.com, we’ll try to move things along.

Thanks John. Sent that in.