Yeah it would be nice to have a choice of how depth cuts are handled. Thanks for passing on the suggestion.

Thank you for the example, but this forces me to use conventional milling. I would prefer to use climb milling, bottom to top motion, but break it into 2 depth cuts, first one being on top. You would think this would be fairly logical way to do NPT threads.

We are machining 2" NPT 11.5 TPI. The tool is 5/8 diam solid carbide with 12 teeth. There is a lot of engagement with this tool, would be more efficient if I could do it in 2 depths with slightly larger stepovers. If I reduce the number of teeth yes it will do 2 passes, but starts with the bottom which is useless in my case. Same problem as the original poster had here over 10 years ago.

Still no way to do this properly in 2024? Im using a fairly big threadmill, getting a little chatter, would be nice to be able to break it into two depths.

Colin, in my case its not even saving the tool. The tool that is created is completely different length. Any thoughts on that?

Yeah someone else mentioned this. I can live with that. But in my case its creating a new tool thats much shorter! I asked Inhouse solutions about it and they suggested that the projection issues were resolved in update 5. I tried update 5 with same result, it did not fix the problem.

Seems very broken for sure. Even the linking parameters are messed up. For example in my drill cycle, I save a default depth of -0.030" for my spot drill but the operation created is at 0.0. I dont use viewsheets personally so cant say for sure about that

Just thought I would post an update on this problem. I tried changing from update 2 to update 5 and im getting the exact same result. I did notice something strange tonight. No matter what length tool I save in the operation defaults, the new tool that is created has cutting length equal to the diameter, and overall length is equal to 2x diameter. For example if i click on the following operations, this is the tool that gets created: Drill (1/4 spot drill) LOC = 0.25 OAL = 0.50 Pocket (3/8 endmill) LOC = 0.375 OAL = 0.750 Face (3" Facemill) LOC = 3.0" OAL = 6.0" The operation default file is saving the correct info for the tool. But the tool that is created by the new operation is always 2xD long. Is anybody else having this issue?

In older versions (like 10+years ago) I could choose a tool in the operation defaults and when I start a new file that operation would create that same tool. It is still doing that for me now, still creates the tool. But no matter what I try, I end up with a shorter tool, and 0.25" projection in a drill cycle. Its doing the same thing in a pocket cycle too, the tool created is shorter then the one saved. But its not shortened as much. I havent tried all the other operations... too depressing to go any further lol. Nobody else is having issues with this?

That would be great if it did that. But in my case when I start a new operation I loose the holder (goes back to default) and end up with a completely different tool (way shorter) .

Yeah that would keep you on your toes for sure lol.

Thanks for the help Colin. I could live with the default holders, as long as its saving the proper tool. But why are my tools becoming shorter? This makes no sense? And it messes up my verify with the short tools, I need to edit the tool every time. A normal length tool with a default holder and long projection would be fine for verify 95% of the time. Operation defaults are kind of useless the way they are right now. It would be quicker to just change to a library tool every time, and thats a big waste of time too.

Only seems to happen when initially creating the operation with the default tool. Once I change to a different tool I can renumber and everything posts fine without forcing a second regeneration. As a work around now i've set my default tool to a tap, so programmer will be forced to choose a different tool every time.

It regenerates automatically, And shows green check mark meaning everything is good. Then I post and get the wrong tool number. Forcing another regeneration did fix the problem. This is still ridiculous. If I change a tool number, and it regenerates automatically, and i get a checkmark it should be good to go. If its NOT good to go without another regeneration it should not let me post.

Hey guys I have another bug here with 2024. This one is dangerous. After creating a dynamic toolpath it posts the wrong tool number. Anybody else ever see this? Easy to recreate the problem: - Start new file, and draw a circle. - Make a Dynamic rough toolpath from circle without editing default tool values, click ok - Wait for toolpath to generate, then open parameters, change tool number and click ok. - Post it out and you get the original default tool number, not the new number that you changed it to. Not the number thats currently showing! I dont think its a post issue, I get same result with default machine and my modified mpmaster post. This is a very dangerous issue! The number of bugs with 2024 is absolutely ridiculous.