Thread Milling

[jim1108]

When I thread mill, cutter compensation is desirable so you can dial in to the proper thread diameter. I posted on this topic before, but I just noticed something in the way SC generates a move before the first arc lead-in to the cut.

When you thread mill with a tool that is significantly smaller than the thread diameter, say a .180 diameter thread mill cutting a .3125 diameter thread, pitch is irrelevant for this topic, SC generates a small x,y rapid move before the actual lead-in cut, which is desirable for me. This is where I add a G1 G41 Dxx Fxx in that move line to comp on, and I just G40 at the end of the operation. It works great and is a simple program edit.

The problem is when you use a thread mill that is closer in size to the thread diameter, it does not add this move. For instance a .180 diamter thread mill cutting a .250 diameter thread. It just arcs into the cut right away. This makes it much harder to incorporate cutter comp.

Is there something in the post processor that can be changed to allow those moves to be generated for any size thread mill, thread diameter combination?

Thanks for any response. Here is a simple job file and my post processor. You can see what I am talking about when you change thread diameter from .25 to .3125.

[Les Newell]

I could get the post to convert that leadin arc to a straight line. It could then apply the G41 to that move. Would that help?
What Dxx and Fxx values are you using?

[jim1108]

Yes, I think that may help. I would have to try it on the machine for verification.

My D number is dependent on the tool number I am using and F(feed rate) will vary also. That can be added manually on a job by job basis. My machine holds 30 tools.

Thread mill format example:
(9/16-18)
(THREAD MILL, 0.236 IN X 18 TPI)
T19 M06
G0 G90 G43 M03 Z1. H19
M08 (COOLANT ON)
S1600 M03
G00 X0.0 Y-0.0 (This could be any x or y depending on thread location on part, using 0,0 for example)
Z-0.44
G1 G41 D19 F2. X-0.0005 Y-0.0957
G03 X0.1638 Y-0.0 Z-0.4261 I0.0543 J0.0957 F0.339
X0.1638 Y-0.0 Z-0.3706 I-0.1638 J0.0 F1.0171
X-0.0005 Y0.0957 Z-0.3567 I-0.11 J0.0
G00 G40 X0.0 Y-0.0
Z0.1
Z1.0
M09 (COOLANT OFF)
M05
G0 G91 G28 Z0 Y0
G90
M30

[Les Newell]

This should do the trick

[jim1108]

Thank you Les for the quick response.

I did a dry run on my machine and did not encounter any alarms, and the moves looked correct with and without a D value in my offset page.

There are a couple of issues that could be a problem when and where it comps on.

Please refer back to my thread mill example above. I typically rapid to safe z above part on the x,y center of the hole to be thread milled, rapid down to depth, then make a small G1 move in x,y the same time I call up G41 and D# to comp on in this line. Then I perform my arc into the cut.

The modified post has the tool doing a x,y rapid move in the hole, hitting the side of the hole with the tool(you can see it in the simulator), then comping on during the first arc, arcing again (which I have never seen), then spiraling up for the cut.

I am not sure what to change in the post to remedy this.

[Les Newell]

Hmm, this looks like a bug in SheetCam. Those first few passes shouldn't have the rapid moves. What version of SheetCam are you using?

[jim1108]

I am running the latest updated version of TNG.

[Les Newell]

Is that the development version or stable?

[jim1108]

It is the stable version

[Les Newell]

Ther is a new stable version with the bug fixed.

[jim1108]

Hello Les,

I updated SC and ran the same job with the update, and it did remove the rapid move at the beginning, but the first arc is being generated in the wrong direction ("I" should have a negative sign).

Even after manually adding the minus sign, the code still is not properly arcing into the cut.

The first X move should not be directly into the cut, then arc.

The first XY move will be small enough to not engage any material, but its only used to engage cutter compensation. The first arc (referenced from where the first linear move stops) should be where it leads into the cut with the appropriate Z move after that first linear move, then do one complete cut, then arc out while canceling cutter comp.

Then repeat same way for each cut until thread diameter is reached.

Right now it feeds into the cut in a linear move while comping on, then does one full revolution at half the cut radius(should not do this at this coordinate) , then does the full cut radius move.

It does not show on SC's built in simulator for some reason, but Camotics and NC corrector show the incorrect moves.
My machine is down today, so cant verify, but the simulators have never been wrong and I know the code is wrong.

The first "I" value should have a negative sign before it like the others. It is arcing in the wrong direction, progressively getting larger as each cut is made.

The thread mill example I posted above is the correct format for every control I have used.

Thanks for the work on this Les.


Edit:
The above description is only for the modified post processor you sent me which enables the cutter comp.
My orginal post processor I uploaded works fine with the latest update by removing the rapid move into the material.
Sorry for not clarifying it earlier.

[Les Newell]

This post may fix it.

[jim1108]

Everything looks good on my simulators and the code looks like it may work.
The only thing that seems odd is it does not arc in to the cut. The SC simulator shows it arcing in, but its not in the code.
It arcs out of the cut perfectly fine.
I will try to run some test holes this week when I am back at work. Thanks again for the post Les.