Need Help- missing feed rate on 4axis motion

[Machiner32]

Our shop just got a hold of a new HAAS rotary axis (HRT-310) for our VM-6 machining center, and I'm still new to the multiaxis package as I've only been using it a few months now and just updated to mcam2022 last week. 

Using a generic HAAS 4X post processor provided by our reseller, so far I've been able to cut some basic wood carvings running multiaxis toolpaths on 3D scan geometry of antique furniture carvings. It's been working fine until sometimes my post will forget a feed rate on random blocks during continuous 4x movements when inverse feed movements should be happening. This causes my HAAS to give a "NO FEED RATE" alarm. When I checked with our resellers and they checked my control definition settings they said everything looks fine it should be posting out inverse feed time, and that it must be a setting on the machine or "something weird" with my toolpath geometry.

I know the machine will alarm with no feed rate is given on every block, and I know get this alarm with even simple geometry as well.

It's been weeks now and still haven't found any solution to this. Customer needs their part that's been chucked up while I scratch my head trying to get some code that doesnt make my machine alarm randomly in the middle of a 3 hr long program.

 

[CEMENTHEAD]

Pretty sure your HAAS has a parameter to set the Diameter of your rotary, I'd check that.

[Flycut]

I found out just last week that inverse time feed on a Haas needs an "F" value on every line.

Feed is typically modal and Mastercam only outputs a change in feed.

If you have 2 consecutive lines with matching feeds the second line will not get an "F".

You need to force feed rate at every line in G93.

HTH 

[Machiner32]

As far as I know, the setting "ROTARY DIAMETER" is a function in the HAAS control that allows units/min feed on a rotary. You enter the diameter of your workpiece and it compensates the feed (works only for 1 diameter"

[Machiner32]

53 minutes ago, Flycut said:

I found out just last week that inverse time feed on a Haas needs an "F" value on every line.

Feed is typically modal and Mastercam only outputs a change in feed.

If you have 2 consecutive lines with matching feeds the second line will not get an "F".

You need to force feed rate at every line in G93.

HTH 

This is what I've been trying to do. I can't find a setting in mastercam control definition that will do this and I have no idea how to edit the post itself. What I dont understand is my program is posting out walls of redundant feed rates of F1000. and then randomly will be missing a F. 

[Colin Gilchrist]

22 minutes ago, Machiner32 said:

This is what I've been trying to do. I can't find a setting in mastercam control definition that will do this and I have no idea how to edit the post itself. What I dont understand is my program is posting out walls of redundant feed rates of F1000. and then randomly will be missing a F. 

Download a copy of MPMaster off of this website, and try that. There should be code in the "Inverse Time" feed calculation Post Block, which "forces" the output of a Feed code, on every line.

      if use_frinv,
        [
        #Feedrate inverse calculation
        ipr_type = two
        result = force(feed, feed) #Always force feed
        #result = force(ipr_type,ipr_type)     #Force inverse time G code if not modal
        if cuttype = three, cldelta = sqrt((x$-prv_x$)^2+(y$-prv_y$)^2+(z$-prv_z$)^2)
        if inversefeed$ = 0, frinv = fr_pos$/cldelta  # 1/min
        else, frinv = fr_pos$/(60*cldelta)  # 1/sec
        if rot_feed & opcode$ <> 3 & opcode$ <> 16,
          [
          if frinv > maxfrinv, frinv = maxfrinv
          if frinv < minfrinv, frinv = minfrinv
          feed = frinv
          ]

The key, is this line:

      if use_frinv,
        [

        result = force(feed, feed) #Always force feed

        ]

That code, when inserted into the 'pfclc_deg_inv' Post Block, ensures that "modality" does not interfere with your Feed Code output.

I would recommend editing the Control Definition, to change the Min/Max Inverse Time values:

 

 

 

[Machiner32]

Thanks Colin, that took care of the issue, no longer getting Feed rate alarms and also the machine seems to run more smoothly. 

Is it possible to modify my other post to do this same thing? I was looking around in my other post and it looks a bit different and I'm not sure if I have the machine/control definition set up right. Doing a 4 axis continuous rotary cut and it's looking like it's not lining up with what I had already cut before, same toolpath I ran before.

I really should have my reseller fix this now that I'm certain that it's not my machine setting or "weird toolpath geometry" like theyve been insisting. I'm starting to wonder what I'm paying "maintenance fees" for...

[Colin Gilchrist]

9 minutes ago, Machiner32 said:

Thanks Colin, that took care of the issue, no longer getting Feed rate alarms and also the machine seems to run more smoothly. 

Is it possible to modify my other post to do this same thing? I was looking around in my other post and it looks a bit different and I'm not sure if I have the machine/control definition set up right. Doing a 4 axis continuous rotary cut and it's looking like it's not lining up with what I had already cut before, same toolpath I ran before.

I really should have my reseller fix this now that I'm certain that it's not my machine setting or "weird toolpath geometry" like theyve been insisting. I'm starting to wonder what I'm paying "maintenance fees" for...

I would honestly advise that you take MPMaster, and have it modified to support whatever machine you are programming for. The reason is that there is much better logic in the MPMaster Post for "handing the differences between 'Actual tool change' and 'Null tool change' inside MPMaster". In addition, MPMaster is already setup to to handle "High-Speed Code Support". So it would be easier to modify a copy of MPMaster to support the Haas G187 P_ E_ functionality, than it would be to add this functionality to your existing Haas Post.

Not all Posts are created equal, and this is an example where that certainly applies.

"Weird toolpath geometry"? < That sounds like someone making an excuse to cover their butts, but I have certainly seen plenty of "bad geometry", which was the root cause of some weird output. In this case, since you tried MPMaster and the output worked successfully, I think you'll be good to go.

I am guessing that the reason the code is not "lining up", is due to some improvements that were made to MPMaster, to calculate the 'Zero Position' of the wrapped/unwrapped geometry.

[Machiner32]

On 6/25/2021 at 10:33 AM, Colin Gilchrist said:

I would honestly advise that you take MPMaster, and have it modified to support whatever machine you are programming for. The reason is that there is much better logic in the MPMaster Post for "handing the differences between 'Actual tool change' and 'Null tool change' inside MPMaster". In addition, MPMaster is already setup to to handle "High-Speed Code Support". So it would be easier to modify a copy of MPMaster to support the Haas G187 P_ E_ functionality, than it would be to add this functionality to your existing Haas Post.

Not all Posts are created equal, and this is an example where that certainly applies.

"Weird toolpath geometry"? < That sounds like someone making an excuse to cover their butts, but I have certainly seen plenty of "bad geometry", which was the root cause of some weird output. In this case, since you tried MPMaster and the output worked successfully, I think you'll be good to go.

I am guessing that the reason the code is not "lining up", is due to some improvements that were made to MPMaster, to calculate the 'Zero Position' of the wrapped/unwrapped geometry.

Hey sorry I forgot to follow up on this, I contacted our reseller again about the post and sent them a zip of my file and when they posted the code they were getting varying results. Said there was indeed some very strange computation error going on and they ran it through some "post debugger" and were unable to figure out exactly what the problem was. I believe they had to send it up the chain to CNC Software to get it fixed, but they got back to me with the fixed post I haven't had any problems since. The other issue with the code not lining up I figured out was actually the rotary CW/CCW direction in the machine def. Good thing it was a testing the path on a chunk of Poplar and not the good Mahogany (have you seen the price of wood lately?!) 

Anyways, its all worked out so consider this case closed. Thanks for the help, and I will be keeping that MP post around