G95 - Feed Per Revolution

[Fully_Defined]

Thanks to Liberty Machine  in a previous thread, at least I know what the problem is: I am not getting a feed per revolution command - G95 - in the code posted through the Meldas post processor. This fully explains why I had the same problem in HSMWorks using the Meldas post processor obviously also supplied by Autodesk.

Why not?

I am a little bit lost as to why any tapping cycle would reference feed per minute instead of feed per revolution. Maybe I'm missing something?

I just want to tap - I don't want to read or write a novel, and I can't believe that I am the only person to have this problem. How can I ensure that when I click "Post Process" that I get a feed per revolution command?

[LibertyMachine]

Old Meldas and Mitsubishi controls did not support G95. Floating tap holders and callout the feedrate, hope for the best. Controlling thread depth was...not fun.

As mentioned in the other thread, just port over the changed you want into the Fanuc post and call it good. It will have the tapping format you desire. A couple M codes might need changing, but that's easyey peasey

Not every post in the library gets love from the developers. Some are a lot more updated and massaged then others. Some of the...less common controls are rather basic in their abilities

[Fully_Defined]

---

@LibertyMachine wrote:

Old Meldas and Mitsubishi controls did not support G95. Floating tap holders and callout the feedrate, hope for the best. Controlling thread depth was...not fun.

As mentioned in the other thread, just port over the changed you want into the Fanuc post and call it good. It will have the tapping format you desire. A couple M codes might need changing, but that's easyey peasey

Not every post in the library gets love from the developers. Some are a lot more updated and massaged then others. Some of the...less common controls are rather basic in their abilities

---

I showed in the other thread that it also did not give me G95, so I'm not sure how using the Fanuc post will help me.

I understand how to delete 99 and type 200 in its place, but I have no idea how to write code.

[zwelsh91]

I did a little bit of testing with the Un-edited Meldas post processor. here are my results.

First I modeled a block with a 5mm hole in it and then created a tapping cycle to tap the hole in cam. I have all of my fusion settings set to Inch units. Here are the tool parameters and the code that was output from the post processor.

Everything seems to have posted correctly with the units set to inch. Now Here is the kicker when the code is posted in mm I get the same issue as you have been describing with the feed value being the same as the rpm and no G95.

Again I will attach a copy of the post for edits aside from expanding the number of tools and offsets (you say you have that covered)

[zwelsh91]

---

@zwelsh91 wrote:

Now Here is the kicker when the code is posted in mm I get the same issue as you have been describing with the feed value being the same as the rpm and no G95.

---

Please disregard the above statement. 

The code is correct when the feedrate (F100.) is in millimeters per minute. If the feedrate were in Meters per minute the feedrate would need to be .1

[Fully_Defined]

---

@zwelsh91 wrote:

---

@zwelsh91 wrote:

Now Here is the kicker when the code is posted in mm I get the same issue as you have been describing with the feed value being the same as the rpm and no G95.

---

Please disregard the above statement. 

The code is correct when the feedrate (F100.) is in millimeters per minute. If the feedrate were in Meters per minute the feedrate would need to be .1

---

I stumbled upon this forum post today: https://forums.autodesk.com/t5/hsm-post-processor-forum/tap-cycle-with-quot-e-quot-instead-of-feed-m...

I hadn't considered E values for the feed. I'm pretty sure my mill can handle this, and I think it's the best case scenario for me.

I downloaded the edited post, changed the allowable offsets to 200 and it output the following code:

O10120 (PART 5)
(T157 D=8. CR=0. - ZMIN=-34.25 - RIGHT HAND TAP)
N10 G90 G94 G17
N15 G21
N20 G28 G91 Z0.
N25 G90
(DRILL15)
N30 M09
N35 T157 M06
N40 S200 M03
N45 G54
N50 M08
N60 G00 X-18.375 Y-13.745
N65 G43 Z15. H157
N75 G00 Z5.
N80 G98 G84 X-18.375 Y-13.745 Z-34.25 R-12.5 P0 E0.8
N85 X18.375
N90 G80
N95 Z15.
N105 M09
N110 G28 G91 Z0.
N115 G28 X0. Y0.
N120 M30
%

It's still wrong - it is for an M8x1.25 tap and the E value is 0.8. No bueno.

I think it may be because it was written with an imperial workflow, but again - I don't write code.

[zwelsh91 · Accepted solution]

That is interesting. I too downloaded the file that was shared in the post you shared and generated code with all of the parameters I used earlier. Here is what I got:

I should also say that I was also able to reproduce you results with the m8-1.25 tap.

Also if you remove the multiplier the post will output 1.25

change the code on lines 643, 654 and 665 to this:

pitchOutput.format(tool.threadPitch)

After making that edit I had an output of this:

[Fully_Defined]

Thanks for the suggestion!

Previously, I took the latest post and compared it the modified post from the forum, in HSM Edit, and then inserted the relevant changes. I must have mistyped it or something, because it didn't help. I actually tried doing exactly what you suggested, but in that context it didn't work.

After just going with the post in the forum, changing 99 offsets to 200 and deleting the "1 / ", it produced the code below.

Tomorrow I'll run it and see if the machine even accepts E values! Thanks dude!

O10121 (PART 5)
(T157 D=8. CR=0. - ZMIN=-34.25 - RIGHT HAND TAP)
N10 G90 G94 G17
N15 G21
N20 G28 G91 Z0.
N25 G90
(DRILL15)
N30 M09
N35 T157 M06
N40 S200 M03
N45 G54
N50 M08
N60 G00 X-18.375 Y-13.745
N65 G43 Z15. H157
N75 G00 Z5.
N80 G98 G84 X-18.375 Y-13.745 Z-34.25 R-12.5 P0 E1.25
N85 X18.375
N90 G80
N95 Z15.
N105 M09
N110 G28 G91 Z0.
N115 G28 X0. Y0.
N120 M30
%

[zwelsh91]

Did you have any luck on the machine?

[Fully_Defined]

Sure did.

I decided to learn a little scripting and made some changes that made it work. I'll attach a copy of the post processor code so you can compare it, but I haven't changed everything I want to yet (left-tapping, etc.).

I found the error, BTW. The feed is driven by the lead-in feedrate in the tool library, and definitely should not be. For one, it is not an entry that is user editable in Fusion (and HSM I presume) without downloading a tab-separated spreadsheet and then reuploading it. Even then, in my experiments that value I entered in the spreadsheet did not survive the transfer back.

Instead, I set the feedrate to the pitch, then inserted G95, then gave it the ability to be a decimal instead of an integer, then inserted G94 when G80 was called.

If I'm honest, I'm a little upset that so many Mitsubishi operators have chimed in that tapping isn't working, and nothing has changed in the code that Autodesk supply. How many folks have to come to this forum totally clueless why it isn't working - like I did - for Autodesk to alter the code supplied with HSM and Fusion?

To recap, I changed the offsets to 200, the feedrate to thread pitch, called G95, allowed the feed to be a decimal and finally called G94. If you find any other changes then I goofed!

Also, I'd like any suggestions how you would have done it differently.