Marking operations dirty when feeds are changed using feed optimization

[Anonymous]

I'll typically toolpath a part fully letting the detect tool length option set my tool lengths for me. Once I have a part toolpathed I'll open up the tool library and round the tool lengths to clean numbers for our operator and also adjust the feed/speed accordingly. Recently I've started using feed optimization because of the significant difference it makes in surface finish. Now, when I adjust the feed/speed and round tool lengths, the toolpaths using feed optimization are flagged with a red X because the feed has changed. I then select each operation that has been flagged to regenerate to get rid of the X's but if I rounded a tool length down when I made those adjustments earlier, the detect tool length option will increase the tool length to a not so pretty number that I'll once again change. I know I could leave the tool lengths the first time around and just adjust the feed/speed and after regenerating then round the lengths (having to make changes twice isn't ideal), I could also just leave the red X but would prefer not to. I guess I don't understand why HSMworks sees changing the feed when using feed optimization different than changing the feeds without feed optimization. If I had to guess I'd think it's  because it uses an equation to figure the feed based on the percentage of the feed rate so it would need to recalculate that but it would be nice if that could somehow be done automatically behind the scenes.

[Steinwerks]

It has to recalculate because of the feed distance from the corner. It does change the toolpath when the feed change distance needs a location to start from, hence a block to place the new feedrate in.

[Anonymous]

I don't quite understand. The distance would be unchanged I would think because it's a set value of .100" for example which would be the same regardless of the feed. Wouldn't the only thing that would change be the value next to the F in the g-code?

[Steinwerks]

Here's why: it has to have a point to associate with the new feedrate. As you can see in the screenshots the actual toolpath changes (look at endpoints):

[Anonymous]

That's just from changing the feed rate? I do see the difference but I guess I don't get why it's there. If either way it knows it needs to slow down .100" from the corner, the actual path doesn't change as you see in my screencast https://knowledge.autodesk.com/community/screencast/d0e26f52-6e88-4037-a057-fdde1b190a84 but just the adjusted feed rate would change I would think? I guess I don't get why the location of the point it slows down at is something that would need to be recalculated when it hasn't changed any unless I were to manually change it from .100" to say .200". Thank you for the pictures and for explaining it but it's not exactly clicking to me as to why it needs to recalculate endpoints when those points would be identical whether 20 ipm or 500 ipm, either way they're be .100" away from the corner in my mind?

[Steinwerks]

Ah so the difference here is you changed the feedrate IN an already applied Feed Optimization. I thought you had applied Feed Optimization to a toolpath in the Compare & Edit dialogue on a toolpath without it previously used. My mistake, I misunderstood/misread.

I agree, changing a feedrate alone should not do this.

@fonsecr is this a bug or is there something else going on under the hood?

[Anonymous]

Yes exactly, sorry I didn't specify that but glad you agree!

[fonsecr]

Hi @Steinwerks,

Yes, thanks for reporting the feedrate issue. I have opened ticket CAM-7399 and the fix will be available for the next major release HSMWorks 2018 R2.

[Anonymous]

Thanks guys