Community
Fusion Manufacture
Talk shop with the Fusion (formerly Fusion 360) Manufacture Community. Share tool strategies, tips, get advice and solve problems together with the best minds in the industry.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Drilling on Lathe - G1 instead of G81

5 REPLIES 5
SOLVED
Reply
Message 1 of 6
Anonymous
3056 Views, 5 Replies

Drilling on Lathe - G1 instead of G81

I am trying to drill the center of a part on a lathe. Presently, I am using a drilling operation, which seems to be supported for milling and not turning, and is therefore not outputting the correct code. To my knowledge, this is not an error in the FANUC postprocessor that is solved with this line:

capabilities = CAPABILITY_MILLING | CAPABILITY_TURNING;

 

What should happen is that the drill should move along the z axis to a parametrically defined point on the z axis, and then retract. 

 

In a mill, there are canned cycles for drilling that are all variants of a G81. This would not be a problem if this operation were taking place on a mill. However, the lathe I am using does not support the G81 canned cycle, or its more complicated variants. 

 

What I would like to be able to do is to use a G1 to cut to the point, and then G0 out. The function that I would think would be able to accomplish this is the Turning Profile: Inside Profile operation or the Turning Profile: Face Profile operation, but neither seem to support the drill as a valid tool for that operation. 

 

What should I do?

 

For reference:

I would like to drill along the center line of the part included from the stock front to -3 mm from the edge in the center of the part. This operation would take place in the setup labelled "Smaller_Side".

Tags (3)
5 REPLIES 5
Message 2 of 6
djowen40
in reply to: Anonymous

If you modify your post processor you can force your post to use expanded cycles for the drilling commands. This will give you G0 and G1 moves for any of all drilling cycles. I do not have a lathe and have not used a CNC lathe but have done a lot of playing with post processors (including developing one to use a mill to perform lathe operations).

 

Using the bulilt in Fanuc lathe post i got the following code for you "Drill_Small_ID" Op.

(DRILL_SMALL_ID)
N15 T0101
N16 G54
N17 M8
N18 G98
N19 G97 S5000 M3
N20 G0 X0. Z10.277
N21 G0 Z8.277
N22 Z10.277
N23 Z8.277
N24 G81 X0. Z-87.473 R8.277 F1000.
N25 G80
N26 Z10.277
N27 M0
(DRILLING_DONE)

 Modifying the post to use expanded cycles I get following where the G81 is replaced by a G01  move and then a G0 move to bring the tool back to clearance height.

(DRILL_SMALL_ID)
N15 T0101
N16 G54
N17 M8
N18 G98
N19 G97 S5000 M3
N20 G0 X0. Z10.277
N21 G0 Z8.277
N22 Z10.277
N23 Z8.277
N24 G1 Z-87.473 F1000.
N25 G0 Z8.277
N26 Z10.277
N27 M0
(DRILLING_DONE)

 

To use expanded cycles you need to modify your post processor. Below i have given a brief outline of how to convert a canned cycle to an expanded cycle. I will use the standard drilling op (G81) as an example but the same would apply to other cycles. I am going to use the standard Fanuc Turning post from the built in post lib for the purpose of this example.

 

I would strongly suggest you dry run and test the output multiple times and i take no responsibility for any damage...

 

Modifying your post: [If you know noting about programming code then this might be a little daunting]

1. click the post button to post out your code. 

2. with the post processor you wish to modify selected hit the "open config" button just to the right of the post drop down.

3. Save a copy. File save as. you do not want to modify the original as then there is no going back

4. now you can start the modification.

 

on line 1032 you will find the following code:

switch (cycleType) {
    case "drilling":
      writeBlock(
        (properties.type == "A") ? "" : gRetractModal.format(98), conditional(properties.type != "A", gAbsIncModal.format(90)), gCycleModal.format(81),
        getCommonCycle(x, y, z, cycle.retract),
        feedOutput.format(F)
      );
      break;
    case "counter-boring":

Everything between case "drilling": and break; controls the output for a standard drilling G81 command. you need to replace this with expandCyclePoint(x, y, z); It should look like this when you done.

switch (cycleType) {
    case "drilling":
      expandCyclePoint(x, y, z);
      break;
    case "counter-boring":

This will remove the G81 command and replace it with an expanded cycle. You can do this with any of the cycles under the switch (cycleType) statement. Again i would strongly recommend you do these one by one and test everything thoroughly. Unless you really know what you are doing stay away from tapping cycles as they require spindle synchronization  which is usually only support by canned cycles.

 

I cannot emphasis this enough. TEST EVERYTHING TWICE. Or even 3 times for good measure. I take no responsibility for any damage.  Let me know if you need more info

 

Message 3 of 6
Anonymous
in reply to: djowen40

@djowen40 - Thanks so much! I replaced those lines in my post processor and I am more or less getting exactly what I want. I am certainly getting an expanded cycle instead of a canned cycle. Obviously I accept full responsibility for any changes to my post that I end up using in my machines. 

 

However, in both my final outputted g code and yours, there are four completely unnecessary rapids prior to cutting that don't need to be there (shown in red):

 

(DRILL_SMALL_ID)
T0101
G54
M6
G96
G97 S5000 M3
G0 X0. Z0.4046
G0 Z0.3259
Z0.4046
Z0.3259
G1 Z-3.4438 F39.37008
G0 Z0.3259
Z0.4046
G0 X0. Z2.
(DRILLING_DONE)
M7
G28 U0.

 

Do you have any idea why these are there and how I might be able to get rid of them?

 

Thanks again.

Message 4 of 6
djowen40
in reply to: Anonymous

@Anonymous 

Short answer:

Adjusting the heights in the drill cycle to be the same point will fix most of this. The feed retract and clearance planes need to be the same offset from the same reference as shown below to remove the un-needed Z moves. note everything is "from: the top height and offset by 5mm.

 image.png

 

 

 

The long verison:

Lucky (or maybe unlucky, depending on how twisted you are) for you I love solving problems and playing with code. It has taken me about an hour to trouble shoot this detail so enjoy if you feel like nerding out. Otherwise just do the above and except that you will have a couple of unnecessary move left.

 

I have put more detail and some notes on other possible refinements below. Here goes (deep breath). I am going to construct a very simple model and do a couple of comparisons.

 

Setup:

Part as shown below with the WCS on the stock front with no additional stock. This puts the Z0 point at exactly the top of the hole which makes the numbers easy to follow. 

image.png

 

Heights Comparison:

Below is a snap shot of two tests i ran to varify my suspicion. Test 1 has the feed, retract and clearance height all set at different levels above the top heigh. 5, 10 and 15 mm repectively. looking at the output code this makes it easy to see where the "extra" Z moves are coming from. Test 2 has them all set the same a vola most of the gibberish  is gone. 

image.png

 

Expanding on the notes:

Note 1:

In the onSection entry function gMotionModal.reset(); is called several times this forces the next G0/1/2/3 command to be output. I would recommend leaving it that way. You could possibly get away with out but the testing involved in verifying it is 100% safe would be long. 

 

If you are 100% sure that you are always going to have your tools in a position where a move in X wont crash the machine you may be able to get rid of the initial position altogether. personally i would rather be safe and have one extra move than crash my machine... Smiley TongueSmiley Tongue

 

Note 2:

on line 109 the definition of is

 

var gPlaneModal = createModal({onchange:function () {gMotionModal.reset();}}, gFormat);

 

this basically specifies that the g motion is to be forced output after the arc plane is adjusted. I suspect that this is something to do with the way the Fanuc controller processes arcs. it may not be required but without knowing more about the controller i cant comment.  Modifying the line to look like below will remove the erroneous G0 for this case but i am not sure what is going to happen for other operations that change the arc plan. I can't actually think of a lathe output that would use anything other than the ZX plane for arcs so it may not be an issue but i am not sure.

 EDIT:

var gPlaneModal = createModal({}, gFormat);

 

 

Message 5 of 6
geir.soennesyn
in reply to: djowen40

This helped alot 🙂 editing the generic Fanuc post to work with our mid 90`s Mori-Seiki SL-15, Moric-T6F.

Next up is tapping 😮

Message 6 of 6

This solution did not work for me. Just in case anyone else looking at this runs into the same issue, the following may help you. 

 

switch (cycleType) {
case "drilling":
writeBlock(
(properties.type == "A") ? "" : gRetractModal.format(0), conditional(properties.type != "A", gAbsIncModal.format(0)), gCycleModal.format(1),
expandCyclePoint(x, y, z, cycle.retract),
feedOutput.format(F)
);
break;

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Technology Administrators


Autodesk Design & Make Report