Well that did the trick. I never would have guessed that in a million years. You would think that something as critical as that would have been disclosed. Thanks gcode.

I assumed that box was for exactly what it says. Seeing as post is from Postability I can give it a try I suppose.

You need to tell machine sim where the tool is in relation to the spindle On my Mori and Okuma VTM machine sim we do it like this (see screenshot below) These numbers are relative from the virtual tip of the turning tool to the C/L and face to the spindle and are inserted on the Insert page of the 3D tool designer In this screen shot, Z8.0722 would be what we traditionally think of as the gage length to the virtual tip of the insert, not the actual tip. This is for Machine SIM only. The post outputs good gcode regardless of these settings. The easy way to get these numbers is to "Save geometry to a level" from the Tool Manager

Well, figured out how to set the tool up so it shows correctly in backplot and sim., but simulation still wants to cut with the gage line of the spindle. The tool is off center of the spindle as well. I'm guessing both a related to how I have the tool defined so just gonna keep changing things.

developer [email protected]

I've reached out to our MC reseller as the last time I tried to contact Postability directly I was informed that I needed to go thru our reseller. I created a 3D tool, but I cannot seem to get it orientated correctly so that simulation shows the tool in the milling spindle correctly so it turns the part with the A at zero like a VTL. My posts asks for a tool length but I don't know if it's asking for a length offset number or length of tool from insert to gage line. I thru some numbers in there and nothing changed and the machsim ignored the tool altogether and used the gage line of the spindle to machine the part.

It's become a lot more user friendly with all of the online tool builders and available models from manufacturers. I find problems when exporting the 3d tools to Vericut, so maintaining 2 machine tool libraries for everything can be a headache, but there's always worse problems to deal with.

I would reach out to Postability and see what they say. Your post may need some tweaking

Gcode, using an MPPODSTABILITY post that says it started live as a Mori Seiki NMV 5000 post. I've read in a couple other places about using 3D tools. I've made a few for our lathes and was going to experiment with making one for this machine but I was hoping I'd be able to just use 3d geometry of the adapter then just merge in stick tools. Guess I'll look in to making a 3D tool and holder a little deeper. Thanks. # Post Name : MPPOSTABILITY_DOOSAN_DVF8000T # Product : MILL/LATHE # Machine Name : DOOSAN DVF 8000T # Control Name : FANUC 31i MSX-701 III # Description : MORI SEIKI NMV5000 G-CODE POST (TILTING/ROTATING TABLE WITH TURNING) # 4-axis/Axis subs. : YES # 5-axis : YES # Subprograms : YES

What post are you using?? I program an Okuma VTM which is a vertical lathe with B axis turning and 5X milling capabilities I use a Postability Lathe post with 5 axis mill You may need to get something similar When we started programming this machine we just ran old school 2D lathe tools but now use 3D tools made from vendors stp files They are a real pain to build but worth it once they are done. # Post Name : MPPOSTABILITY_OKUMA_VTM # Product : LATHE/MILL # Machine Name : OKUMA VTM 65/100/80YB/120YB/200YB # Control Name : OSP # Description : GENERIC G-CODE POST (MILL-TURN) # 4-axis/Axis subs. : YES # 5-axis : YES

We just bought a Doosan DVF800T which is a 5x mill with turning function. For the life of me I cannot figure out how to create a turning tool for the mill spindle and have it locate correctly. The mill spindle is a KM63, and we're going to use a KM63 to Capto (6 I believe) adapter, then use Capto holders to hold the turning tools like we are on a couple of our Doosan vertical lathes. I imported a dxf of the KM to Capto adapter and added a turning tool to it and trimmed the geometry so the lathe tools and adapter are my lather tool holder color and the insert is the right color. Positioned it so the leading corner of the insert is touching the X & Y axis like a standard turning tool. But it doesn't show as being on center of the mill spindle and it changes the toolpath completely. I know I'm doing something wrong, just not sure what. Thanks.

Licensed Mastercam users can go the Tech Exchange at Mastercam.com Select Posts Enter Okuma in the Keyword Set Product to Mill Set the Version dropdown to your version of Mastercam (2019 to 2025) and hit Search There are five different flavors of Okuma mill posts available at no charge. It looks like they are offering posts for Versions 2019 through 2025

Chase it right to your reseller

Hi all, new to machining and have purchased a MC-4VB Okuma mill and I'm chasing a post processor for it

That's the way to fully solve it

I've actually already been talking to James about the Camplete route. Thank you for the link.

1 and then toolpath transform

What's happening here may not actually help you, so I wouldn't rely on it. It's a handy tip when it does, though! What's happening here is behaviors that have existed for a long time, but they only really "show up" in a multiaxis path. When backplot goes to display a tool, it has to draw it somewhere. There hasn't been any movement yet so it doesn't know where the vector of the tool is going to orient it, which causes it to just be drawn in whatever plane the toolpath itself is in. As soon as one step of movement is done, the tool will align to the proper vector. Where this wouldn't help you is if the plane is correct, but the line isn't (in this particular example). Agreed. You should at least be using MachSim. Yep, set up your MachSim, preferably hooked up to the post. It'll be a lot cheaper than a full seat of Vericut, but I would always advocate for something like Vericut This might be a good bridge until you can get there. We recently had a thread about it:

Thank you. I went back and back plotted the toolpath, and saw exactly what you're describing. Definitely helpful. Thank you.

Video showing what I mean: https://www.dropbox.com/scl/fi/g8zm2qm32mn5jaywgcq93/Deburr_Axis.mp4?rlkey=f9dvki3nbts8b92oi6y9tmjd6&st=tzufbm1d&dl=0 Link to file: https://www.dropbox.com/scl/fi/zy7s5lr680u0nbol3pkh0/Deburr_Axis.zip?rlkey=nx72qym6pn3ezo78xbkh9dhj1&st=bprb46g8&dl=0

I've made the same mistake before, luckily I've never had the code make it to the machine. IIRC if you backplot (maybe in verify too???) when the toolpath starts the tool will be oriented along the wrong axis (it will be oriented along the axis control line), then it will snap to the correct axis before starting the motion. I saw this happen and after rewatching it and scratching my head a bit, found that the axis control line was different than the z-axis of the plane. I corrected the axis control line and no more funny tool orientation at the start of the backplot. I believe the same thing happens in unified, and I would assume it happens in other multiaxis paths as well. It's not "easy" to catch, but it is catchable. I think this was back in MC23 too, not sure if MC24 behaves the same.

Select all the operations > right-click, edit selected operations > change NC file name. Make sure all the operations in your Toolpaths Manager have the same NC File Name. You likely have multiple operations selected, and Mastercam is posting multiple NC files. Try minimizing the one you see, or looking to see if there are "tabs" for different files in the editor.

When I post a program only 1 tool shows up, how do I fix this?

I'm curious because I'm not familiar with this Line method of axis control, can you share a sample file? I've always treated single offset programs the same as multi offset programs, only forcing all the work offset outputs as g54.

Yes, because I used the Line method of axis control. So it was basically generating code as if it was a COR program with 1 offset.