Can't you just put it in there? I'd just stick it under the code: if tool_table = 1, ptooltable Because that's the logic you're piggy backing on. Hope that helps.

Hey, I'm not saying this is the best thing to do, I know I wouldn't want to do this. I just understand there's some cases where you can't beat 'em and have to join 'em. It builds cases in the future where you can say you've tried it their way and it hasn't worked out, now let's try it mine....

Wow, that's unfortunate. So how do they want to determine the direction for rotation? If it's 180 degrees either way will cause as much motion, or would they like to restrict motion between -180 and 180 degrees? If that's the case you can add a little while statement in the pxyzcout post block, if you don't have access there, it could even go in the pcout and pfcout post block. Just something like: code: while cabs > 180, cabs = cabs - 360 while cabs < -180, cabs = cabs + 360 That would be the only way to "hack" it, the rotary axis values that are used in the post are output by mastercam, so there's no super clean way of doing it.

Put your call to pspintable into pwrtt.

You can use Camaix's machinesim to do some verification, but it's upstream of the gcode. It's about as close to gcode verification you can get.

Yikes, so this is a VR? Are they running with G143 tool length compensation??

OK cool. That's often the missing link. Coordinates work differently inside the TCP functions so if something isn't working that's often the ticket. BUT, M128 is a TNC function.....not Millplus. M128 should give you an alarm in Millplus. Try with neither of the codes, and datum on rotary centre. The version of the post that I have for you here does not have axis sub turned on.

Hello Rafael, Are you using M128 (TNC) or G141 (Millplus) during your axis sub? I have nothing but good things to say for the service that DMG provides.... Brett

Take a look in the pl_retract block. I'm assuming you want this only on tool changes or end of file. Also make sure that you have your home_type set to something other then 1 (switch in header).

We are finding some variation in the Okuma lathes setup world wide based on the Okuma rep in the area, but usually it is a few minor tweaks. Thanks to Greg for all the Okuma support!

Huh, I haven't seen a fanuc that can start at an angle other than 0 with G43.4. That will be sweet! You're right, totally has nothing to do with your CAM software.....but a lot to do with the post. Sounds like you're looking at a trunnion. Definitely get the G54.2. It works for both 3+2 and 5-axis. G43.4 isn't really doing much more for you except the ability to use diameter wear comp for swarf machining (G41.2). BTW, Matsuuras do have the G54.2. Not sure about G43.4 though. Mori has both. Good luck with it Shawnald! Brett

Hey Doug, I've seen this before with those paths. Need to do it in the post. If you've got an mpmaster style post you can force G0 to G1 conversion in the control def. If not, you need to get into the post and convert them yourself. (you can use the mpmaster method as a guide) Brett

Not sure if you've resolved your issue or not but the gist of the error is that you have most likely started your cut with a vertical tool, which means there is no way for your post to calculate a C-axis value (if c is rotating about Z), as every solution is correct. Without any way of looking forward, the post asks for your input so you don't end up with a large C-axis move when the other rotary axis finally begins to move, which could result in a gouge. HTH

That's a good one, looks like a signed direction B axis which is causing those issues, or at least that's how your post has been setup. May want to contact your reseller to help you out with that one! Chris

Just search for the G93, G94 and G95 string in the string select tables and put a # in front of the G93, G94 and G95. ex. sg94 #G94

rather *e$

Could be the post or the program itself. In the post you can look in the ptlchg$ block or just search for "M00" or sm00. You should be able to easily see if it's in the post. Just put a # before those lines. First thing you should check is whether or not the programmer put in a M00 as canned text. Chris

set it to one decimal value smaller

In version X MR2 this could be related to a tolerance issue as we would not output a Z move unless it had changed (I'm assuming you are cutting in the top tool plane). Sometimes there are minor tolerance issues that can be resolved by bumping up the NC precision in the control definition. Chris

Hi Bruce, I can say I have setup for this style of machine before and the mathematics is quite similar to an integrex style machine, just because there is effectively another rotary axis that needs to be accounted for. The main difference being that you will manually have to set the head to a specific angle and you will only be able to do 3+2 machining rather then simultaneous 5-axis. That being said, the compensation for the tool length will be done in the post as it was in your vortex post that Dave did for you. Chris

nofalloff, You really just have to get into the pg76new post block, rip it apart, and put it back together again. You'll get it! Brett

ShefferCNC, There are dialed in versions of mplmaster for the Mazak machines that you should check out. If you're not interested in that, mplmaster is a solid starting point. Brett

Defintely X2. Looks like we overlooked updating the executable version. Brett

All, The new install of mplmaster on this page has some additional programming notes. They may be particularily helpful if you're using a sub spindle. Brett

All, We have run 3D comp (for ballnose cutters) on surfacing tool paths on several controllers from our posts. At this time we can only get the data from Mastercam on 5-axis surface paths. This is not to be confused with G41.2/G42.2 which is control/wear comp for swarf cutting (endmills). This can be run on any path because you can add a misc integer to force comp output even if Mastercam doesn't have a dialogue box for comp selection. Brett