Haas slow inverse time feeds

[Anonymous]

I noticed that my inverse time feeds are to slow , how do I fix this? Fusion said a run time of half hour and two hours later I'm still going. The linear feed is 6 ipm so I'm not trying to cut faster than what the controller can prosses.  

[bob.schultz]

Do the moves look like they are taking 60x too long?  If so, then change the following variable in the post so that the time unit is seconds instead of minutes.

var inverseTimeUnits = 60.0; // 1.0 = minutes, 60.0 = seconds

Are you seeing a lot of F9999 feed rates.  If so you can increase the maximum value that can be output by modifying the following line in the same location within the post.

var maxInverseTime = 9999; // maximum value to output for Inverse Time feeds

[bob.schultz]

In my haste I was backwards as far as the unit of time for Inverse Time feedrates.  Make sure that it is in Minutes and not Seconds.

var inverseTimeUnits = 1.0; // 1.0 = minutes, 60.0 = seconds

[Anonymous]

hi @bob.schultz  

Its more like .25 to get the correct feed , sorry for the delay as I ran into a sync issue with the rotary axis's and gave up on 5th axis for this job . basically .015" ball mill tracking a 90 deg corner at a 20 deg side tip  

[bob.schultz]

If the number is .25, then there is something wrong.  Can you supply a sample model that shows this issue?  It is also possible that DPM feedrates can be used instead of inverse time feed rates, by setting the 

Rotary moves use DPM feeds property to Yes.

 Sorry for the delay, but for some reason I am not getting notified when someone posts to a thread that I am active in.

[Anonymous]

Hi @bob.schultz  it running slow wasn't model specific , I want to say I've now used three different haas post configs and they all have yielded the same result  . I will say changing to dpm things where not synced correctly with continuous 5th axis moves or shuddering  . 

thank you 

[bob.schultz]

Thanks for supplying the model, I looked at the calculations and they should be correct.  As an FYI, the post estimates the move length by calculating how far the tool end point will move due to the rotary axes movement and adding this to the XYZ slide movement.  The time is calculated by dividing this distance by the feedrate.

If you are having issues with the rotary axes not synching with the linear axes movement, then this is not something that can be caused by the feedrate numbers output by the post, but would be with the machine itself and may point to other issues.

[Anonymous]

@bob.schultz  it may look right but when have paths at have a eat of 10 min and 2.5 hrs later its still running there is something wrong I would say 

[bob.schultz]

Of course I cannot dispute what you see on the machine, it's just that I cannot see anything in the output from the post processor that would cause this.  The cutting time calculated by Fusion for the flow operation is 74 minutes.  The post processor calculates a machining time of 90 minutes, an increase but not as much as you mention.

It is possible that the changes in the C-axis directions is the cause of the extended machining time.  If you break up the flow operation into 2 separate operations, one for each side (I don't know if the cylinder is even necessary since this is cut by the flat sides and this is the face that is causing all of the C-axis movement) you should not see any rotary axes moves during the operations and this will improve the speed on the machine.  Personally I don't like the way Flow is controlling the rotary axis in this corner.

You can also get an exact match in machining times in the post as compared to Fusion by removing the logic to calculate the cutting tool path along the rotary path when the rotary axes move, so that the machining time in the post is exactly the same as calculated by Fusion, but I don't see this making much difference on the machine.  You do this by making the following change in the getMoveLength function.

// calculate the tool tip move length
  // tool tip distance is the move distance based on a combination of linear and rotary axes movement
  // moveLength.tool = moveLength.xyzLength + radialLength; // <<< COMMENT OUT THIS LINE
  moveLength.tool = Vector.diff(endTool, startTool).length; // <<< ADD THIS LINE

[Anonymous]

Hi @bob.schultz ,

I did some testing today . A swarm in fusion @ 10 ipm and one in brand x software.  The rates the machine moved where not the same. I would just program a faster rate in fusion but the linear feeds would be too fast . Oh getting away from inverse time feeds did help a little 

[bob.schultz]

If you can send me the part you are using for Fusion with the swarf operation in it and the output from the other cam system, I can take a look and see if there is something obvious.  The swarf cuts should be simple and the same in both systems, for example a single pass around a cone would be good.

[Anonymous]

@bob.schultz 

I can do that tomorrow morning  . I didn't think of that. I went from slow to fast with dwells from buffering I think. 

[Anonymous]

Hi @bob.schultz  

Here are the two nc files . both should be feeding at 10 ipm 

Thank you 

[bob.schultz]

Hello @Anonymous, the sample output you provided from Fusion is a 3-axis program and not a swarf operation.  You are also using parametric feed rates and I notice that the cutting speed is 5 ipm and not 10 as you stated.  I noticed in the original part that you supplied that the feed was set to 1 ipm and not 6 as you said.  Could this be your issue?

I will need to have the model to effectively analyze the feed rate numbers, so if you can create the same swarf operation in Fusion (using the same size cone as the other CAM system) and provide me the model then I can go from here.

Thanks

[Anonymous]

Hello @bob.schultz  this is the correct  file , Coffee had not kicked in yet . Is there a way to force being able to rotate the b axis when probing . I want to check my center of rotation of the stock and when I set tool orientation it is ignored when posted .