2D High speed becomes dirty by the tiniest change

[SlaveCam]

So I have been working on this project with a LOT of shapes at different depths, using mostly 2D high speed (Dynamic mill & rest mill) and am really frustrated by the fact that almost any change makes those operations become dirty. Changing program number, any misc value and speed or feed will do that. I have wasted so much time waiting for the ops to regenerate, as tool breakage check, spindle/axis load monitor etc. are controlled via misc vars and they are often added in a later stage, not to mentions S&F optimization. There are other operations that will remain un-dirty when changing those parameters. I thereby implore CNC to fix this inconvenience as it would make using mcam much more efficient.

[JParis]

You do understand that anything that gets "changed" and needs to be updated in the nci file NEEDS to be re-genned, right?

If you made those changes and it didn't go dirty, when you posted it the changed info would not be in the nci file.

[SlaveCam]

Having to regenerate the NCI and recalculate the entire toolpath data are different things. Changing stuff that don't affect the toolpath data itself (for example, a misc value) should not require the toolpath to be recalculated, which may take a lot of time. There does not seem to be consistency between operation types, for example, flowline which is my favorite stays "clean" when I change S&F or misc values, Surface Rough parallel becomes "dirty" when S&F is changed but not if a misc value is changed, and again 3D High Speed (Blend) stays "clean" even if both are changed et cetera

This is obviously a difficult thing to manage for coders because it's easy for the op to become bugged and thus it's just safer to flag it is as dirty if *anything* changes. But there would be no fewer bugs if more software testing were prevalent.

 

[crazy^millman]

4 hours ago, SlaveCam said:

Having to regenerate the NCI and recalculate the entire toolpath data are different things. Changing stuff that don't affect the toolpath data itself (for example, a misc value) should not require the toolpath to be recalculated, which may take a lot of time. There does not seem to be consistency between operation types, for example, flowline which is my favorite stays "clean" when I change S&F or misc values, Surface Rough parallel becomes "dirty" when S&F is changed but not if a misc value is changed, and again 3D High Speed (Blend) stays "clean" even if both are changed et cetera

This is obviously a difficult thing to manage for coders because it's easy for the op to become bugged and thus it's just safer to flag it is as dirty if *anything* changes. But there would be no fewer bugs if more software testing were prevalent.

 

What if one of the mi or mr triggers behavior in an operation? I have some that trigger tool inspection and parent child calls. I need the software to regenerate those operations and it drives me crazy when it doesn't and I then have to go back and do it myself. Are there things that shouldn't maybe, but seeing how at the first chance the software doesn't and someone gets and error or worse yet a crash of their machine then who will they feel when the software didn't make those operations dirty?

You answered you own reasoning for it with your last sentence.

[Mick]

This kind of thing happens in pretty much all CAM software. It isn't isolated to Mastercam, and Crazy^Millman explained it on the nail.

 

[Jake L]

Link here where @Aaron Eberhard explains "check sums" and how they affect a toolpath going dirty:

 

Another link discussing what does / doesn't make a toolpath go dirty:

 

And I don't have a link for it but I'm assuming you're using MC2023 because of this comment:

On 3/10/2024 at 6:22 AM, SlaveCam said:

Changing program number

In 2023 (and 2022???) there was a bug that caused dynamic operations to go dirty when you update the program number. I believe this was fixed in 2024.

 

With that said I agree with @crazy^millman, I'd rather have to wait for my operation to regenerate than see an unexpected crash. 

18 hours ago, crazy^millman said:

Are there things that shouldn't maybe, but seeing how at the first chance the software doesn't and someone gets and error or worse yet a crash of their machine then who will they feel when the software didn't make those operations dirty?