I've got a lot on my mind at the moment, so maybe that's the cause of the issue....
Plunge feedrate is set to 100 ipm. Cutting feedrate is set to 30.
Code output is plunging down at 30 ipm.
This is using my post AND the generic Fanuc. I've looked at my settings and I'm not finding anything that would cause this
Same f3d from MY OTHER POST
EDIT; Anyone else lose all their operation default setting at the last update?
EDIT # 2, this only appears to happen on the "Roughing passes, Stock Contours" tool path. Regular 2D Contours are working as expected. This also happens on a 2D Pocket that I'm using for the counterbores (gives me a spiral toolpath). Entrance is set to Predrill, and it's feeding down at my cutting feedrate
EDIT: Also happening on a Facing pass
Solved! Go to Solution.
Solved by paul.clauss. Go to Solution.
I'm running this code through several different posts, just to make sure it's not running into an edit I've done (to the post) that is causing it. Same results across the board
This is definitely a little weird. Used my work post and got the same issue with plunge set to 100 using your file. But the dumper seems to be just fine:
129: onParameter('operation:tool_feedCutting', 30) 131: onParameter('operation:tool_feedPerTooth', 0.001636661211129296) 133: onParameter('operation:tool_feedEntry', 30) 135: onParameter('operation:tool_feedExit', 30) 137: onParameter('operation:tool_feedRamp', 91.99999999999999) 139: onParameter('operation:tool_feedPlunge', 100)
However if you make it a simple no-roughing-passes toolpath you see this (red plunge line):
Which means that the entry on your original part is using the lead-in feedrate for the plunge which is also verified by the dump post (no /*plunge*/ note anywhere):
407: onRapid(5.265991931825172, 1.4139013215312808, 0.5999999909889041) 408: onRapid(5.265991931825172, 1.4139013215312808, 0.19999999699630136) 409: onMovement(MOVEMENT_LEAD_IN /*lead in*/) 409: onLinear(5.265991931825172, 1.4139013215312808, 0.03937007874015748, 30) 410: onLinear(5.265991931825172, 1.4139013215312808, -1.236102336973656, 30) 411: onLinear(5.266721830593319, 1.4115716528704785, -1.236102336973656, 30) 412: onMovement(MOVEMENT_CUTTING /*cutting*/) 412: onCircular(true, 4.500000120147945, 1.171259842519685, -1.236102336973656, 5.303499717412032, 1.171259842519685, -1.236102336973656, 30) sweep: 17.402435deg radius: 0.8035 413: onLinear(5.303499717412032, -1.171259842519685, -1.236102336973656, 30) 414: onCircular(true, 4.500000120147945, -1.171259842519685, -1.236102336973656, 5.266880425881213, -1.411065229280727, -1.236102336973656, 30) sweep: 17.364594deg radius: 0.8035 415: onMovement(MOVEMENT_LEAD_OUT /*lead out*/) 415: onCircular(false, 5.314601387564592, -1.4259879044660433, -1.236102336973656, 5.299679012749139, -1.4737091665192852, -1.236102336973656, 30) sweep: 90.000431deg radius: 0.05 416: onLinear(5.347400575172244, -1.4886316915196696, -1.236102336973656, 30) 417: onMovement(MOVEMENT_RAPID /*rapid*/)
Simple 2D Contour dump:
407: onRapid(4.453716728630967, -1.5837598785640685, 0.5999999909889041) 408: onRapid(4.453716728630967, -1.5837598785640685, 0.19999999699630136) 409: onMovement(MOVEMENT_LEAD_IN /*lead in*/) 409: onLinear(4.453716728630967, -1.5837598785640685, 0.03937007874015748, 30) 410: onMovement(MOVEMENT_PLUNGE /*plunge*/) 410: onLinear(4.453716728630967, -1.5837598785640685, -1.18610239404393, 100) 411: onMovement(MOVEMENT_LEAD_IN /*lead in*/) 411: onLinear(4.453716728630967, -1.5337598605418767, -1.18610239404393, 30) 412: onCircular(false, 4.4037165604238435, -1.5337598605418767, -1.18610239404393, 4.4037165604238435, -1.483759842519685, -1.18610239404393, 30) sweep: 90deg radius: 0.05 413: onMovement(14 /*finish cut*/) 413: onLinear(-4.500000120147945, -1.483759842519685, -1.18610239404393, 30) 414: onCircular(true, -4.500000120147945, -1.171259842519685, -1.18610239404393, -4.812500120147945, -1.171259842519685, -1.18610239404393, 30) sweep: 90deg radius: 0.3125 415: onLinear(-4.812500120147945, 1.171259842519685, -1.18610239404393, 30) 416: onCircular(true, -4.500000120147945, 1.171259842519685, -1.18610239404393, -4.500000120147945, 1.483759842519685, -1.18610239404393, 30) sweep: 90deg radius: 0.3125 417: onLinear(4.500000120147945, 1.483759842519685, -1.18610239404393, 30) 418: onCircular(true, 4.500000120147945, 1.171259842519685, -1.18610239404393, 4.812500120147945, 1.171259842519685, -1.18610239404393, 30) sweep: 90deg radius: 0.3125 419: onLinear(4.812500120147945, -1.171259842519685, -1.18610239404393, 30) 420: onCircular(true, 4.500000120147945, -1.171259842519685, -1.18610239404393, 4.500000120147945, -1.483759842519685, -1.18610239404393, 30) sweep: 90deg radius: 0.3125 421: onLinear(4.4037165604238435, -1.483759842519685, -1.18610239404393, 30) 422: onMovement(MOVEMENT_LEAD_OUT /*lead out*/) 422: onCircular(false, 4.4037165604238435, -1.5337598605418767, -1.18610239404393, 4.353716692586583, -1.5337598605418767, -1.18610239404393, 30) sweep: 90deg radius: 0.05 423: onLinear(4.353716692586583, -1.5837598785640685, -1.18610239404393, 30) 424: onMovement(MOVEMENT_RAPID /*rapid*/) 424: onRapid(4.353716692586583, -1.5837598785640685, 0.5999999909889041) 425: onSectionEnd()
Basically I think the feed plunge output bug is directly connected to the previous bug and I would be surprised if it isn't cleared up by the latter when the next update goes through.
Except the feedrate issue also shows up in the Face operation. And the other issue (lead-in, roughing passes) might not be getting fixed in the next update.
IF they have human beta testers, they may need to revise their methods and do a more thorough job
EDIT: It also exists in a pocket routine
So it's even easier to diagnose than going through the dumper, the color-coded toolpaths show it as well as the Show Toolpath option. Anyway I'm getting the same results in Inventor HSM.
I would suspect it may not be a toolpath-specific issue, but how the CAM is handling the feedrate application. If this doesn't get a response this weekend I will check HSMWorks on Monday but I don't recall running into this issue.
@al.whatmough I think this is heavily related to Seth's other thread on the lead issues as it's obviously not applying feedrates properly, but perhaps this has to do with trimming the leads and the system defaults to specifying the plunge move as a lead instead? Definitely odd things going on and I got the same results trying it in Inventor HSM Pro Build 4.1.0.075
Hi @LibertyMachine, @Steinwerks,
Thanks for posting! This is a known issue logged as CAM-2511 with our development team. I have made a note linking this post to their page on this issue and will circle back here once I receive an update.
We appreciate you bringing this to our attention!
Just received an update on this issue from development and wanted to let you know that it should be resolved in the upcoming March update to Fusion! Please let me know if you continue to have issues after then.
Thanks again for bringing this to our attention!
That is great news! Thanks for the update
@paul.clauss did this actually make it into the update? Running through a bunch of scenarios, it appears that it did NOT make it
Hi @LibertyMachine,
This one is marked as resolved in our log - can you give a specific example of a time when it is not working? Thanks!
Umm...yeah. Screencast incoming
And Facing operations still plunge with the Lead-In feedrate:
Yellow is rapid, Red is Plunge feedrate, Green is Lead-In/Out, Blue is cutting
The original ticket was make to correct the feedrate for pre-drill function. Originally the pre-drill entry method was incorrectly using the cutting feedrate instead of the proper plunge feedrate, even thought the preview was showing a red line for the plunge move.
These are separate cases that I will make new tickets for.
Can you check that you haven't set a too high Feed Plane? If not desired then simply disable it on the heights tab.
2D Contour with chamfer tool selected (and chamfer option turned on), doesn't care about the "disabled". Still outputs lead-in feedrate for it's Z move. And yes, there are times to use the 2D Contour over the other Chamfer operation
Default stuff has been messed up for a while, not just the last update. It seems to randomly grab new defaults for random items.
In 2d contours, it seems the finish Feedrate is used instead of Cutting feedrate in certain cases when Multiple finishing passes isn't even used.
Ah, my comment was about your last reply for the Face operation 🙂 Need to check if chamfering has any special cases.
We haven't really changed the defaults behavior. But if you do have suggestions for particular defaults that you think should be different you can always open a topic for that on the idea station so we can have a look.
Please note that if you have overridden the global defaults then you wouldn't see the built-in defaults.
@fonsecr Gotcha. Yes, that was a setting I was missing. Setting it to Disabled goes allow it to use the Plunge feedrate, this is great!
And, I think I've figured out what is going wrong with the 2D Contour w/chamfer option: Safe Distance, on the Linking tab. If Feed Height is set to any option (other than disabled) and it has a value that is unequal to the Safe Distance, there is a movement of "lead-in" feedrate. At least that's what I'm finding. I'll have to make a mental note and run it through various selection options and see if it still holds true