Mastercam 2023 verify shows tool crashing thru part

[crabbydad]

recently upgraded to Mastercam 2023. I programmed a hybrid and tool path looked good. When I ran thru verify, It shows tool holder crashing thru part. Ran back plot and looked at path from front view and it shows huge arcs in the  XZ. I could not get it fixed, so I ended up programming my second op in 2022 using the same toolpath and parameters with no issue. I ran into the same issue on another part with an area rough. I was able to change the direction of the containment and it worked. I went back to the original part that had an issue and tried repicking the containment in a different direction, different containment and no containment, with no resolution to the crashing in verify. Anyone else had this issue? When i first had the problem, I reran the migration wizard to see if this helped, but it didn't

[gcode]

look at the Arc page in the Control Definition

Compare your 2022 Control Def to the 2023 Control def.

also

compare the tolerance page in System Config  and the Filter page of  your 2022 and 2023 machining operations 

[crabbydad]

I compared the pages to 2022 and they are both the same

[gcode]

If you open a good 2022 file in 2023, does it run correctly?

[nperry]

23 hours ago, crabbydad said:

recently upgraded to Mastercam 2023. I programmed a hybrid and tool path looked good. When I ran thru verify, It shows tool holder crashing thru part. Ran back plot and looked at path from front view and it shows huge arcs in the  XZ. I could not get it fixed, so I ended up programming my second op in 2022 using the same toolpath and parameters with no issue. I ran into the same issue on another part with an area rough. I was able to change the direction of the containment and it worked. I went back to the original part that had an issue and tried repicking the containment in a different direction, different containment and no containment, with no resolution to the crashing in verify. Anyone else had this issue? When i first had the problem, I reran the migration wizard to see if this helped, but it didn't

I've struggled with this along with one of my counterparts at work. 2023 showing gigantic gouges in verify that are non-existent. I've verified beautifully in 2022 and moved the file into 2023 (because of trying to work around other 2022 glitches) and had verify show non-existent gouges. 

Very frustrating.

[gcode]

I've got 5 programmers running X23 and we are having no problems like this.

There must be a setting wrong somewhere

Check this page of your Control Def

See if the x22 and x23 settings match

These setting should also accurately reflect the rapid motion behavior of your machine.

This screen shot is set for dogleg rapids.. and Verify might show false crashes if your machine rapids in a straight line

Inversely, if your machine doglegs and you have this set for straight line rapids Verify could fail to show actual crashes and gouges

on  the machine.

Also, open your Verify settings and set them to always use the 5axis engine

[rgrin]

I had a similar issue in the past. Programmed a part in 2021 using a 3D Equal Scallop path. It started at the top of a pocket and  walked down the wall and cut into center. When the part came back and I was running 2022, I saved a new file and tried to run what I thought was "proven program". I snapped a tool on the first part. For some reason, the logic on that path got rewrote so that it started in the center of the pocket and worked its way out.  It may look like none of the settings have changed, but it seemed like maybe something on the back end of the toolpath got tweaked.

 

Have you tried just opening a fresh instance of that part and making just that toolpath and see if it repeats? Converting files can sometimes give strange issues, especially when you are working of a server like we are

[byte]

I seem to remember the issue when that happens being that the wrong machine was selected for simulation

[gcode]

31 minutes ago, rgrin said:

It started at the top of a pocket and  walked down the wall and cut into center. When the part came back and I was running 2022, I saved a new file and tried to run what I thought was "proven program". I snapped a tool on the first part. For some reason, the logic on that path got rewrote so that it started in the center of the pocket and worked its way out.

You had this setting unchecked and it ran inside out anyway??

 

 

[rgrin]

I don't recall exactly. I was pretty new to programming then and equal scallop wasn't the right toolpath for what I needed to do. I guarantee I broke something in order to get it to work the first time. Then when I updated it probably fixed whatever I broke and made it correct.  It just happened to be that the fix changed the behavior. IDK, it was last year and unfortunately I don't have a 2021 install anymore to verify I'm not crazy.

 

I might have been using a waterline toolpath in 2021 and then the fix was to switch to equal scallop? I know the main struggle I was having was getting it to respect the direction I wanted to cut in. I was messing with Up vs Down mill and One Way and clockwise spiral and counter clockwise. I don't get to use 3D toolpaths very often so it takes me awhile to get one to work. Just use the ole guess and check method until I get something that looks like it will work

[arepasky]

Interesting....I am having the same issue with 2023.....when I check the G code, it it perfectly fine.....when i run it in verify....i get my tool going through the part(using 4th axis for positioning).....on Mcam 2023, the issue occurs on toolpath #23......when I run the EXACT SAME PROGRAM in Mcam 2024....it occurs in toolpath #30....same g code and all...same post as well....it is beyond frustrating