We have one Integrex 200-III ST (640MTPro) and it's pretty reliable now... but it took months (even years!) to suit it my needs and still require to be used properly with Mastercam GUI. It supports lower turret with 2-processes (G109 L1/L2+waiting codes), tooltable with Mazak letters parameters, management of the safety location of lower-turret below opposite chuck, Face polar drilling/Milling, transfer,... There is no multiaxis option on this one but I set it up on another Integrex 200-IVS(Matrix). Machining axis-5 is ok with inverse feed rates. The main problem which still remains is to avoid to exceed Y-axis work area

Thanks to Rob who pointed me to this resource very helpful: MP doc

Does "pretract" is a mastercam postblock ($) or a custom one? When is it called? If you want to do this at every toolchange, why don't you use ptlchg$ postblock?

I am totally agree with that, mine is working the same! I'm talking about x,y,z coordinates here. Just give it a try: make a toolpath in Mastercam with a random toolplane. Post. Now make another tool plane from the first one which you rotate around its axis-Z with a random value. Then use this toolplane with your toolpath operation. Post. If you compare both programs, i'm pretty sure you get the same output! But... NCI wasn't the same at all, though. So the post did the job. If not... then you have something else in your program which is telling the controller to deal with your program. Perhaps an other special function.

I think your post is smarter than you think! So here was my problem... mine didn't work as you said (but now yes!). CYCL DEF 19 was correctly set (angles) and i didn't changed them. In this macro (DEF 19), you only set virtual 'angles' in parameters. Controller manages physical angles motions and work offset, but... your post still needs to output good X/Y/Z coordinates because for one job, there is only one set of X/Y/Z coordinates. And in Mastercam if you set a random tool plane, you get randoms X,Y,Z in your NCI... so your post must do all the job.

Thank you for giving me clues to find this annoying bugbug. I checked windows settings and variables statements, both were ok and it was my mistake... I was calculating my angle with Acos formula only and even with a 9 digits number: acos(0.999999999) is still far from 0! Atan is much more precise. All seems OK now. I'd like to try this Hole-axis C(or net)-hook, but where may i find an X3 version? Yours

My machine is a Deckel DMU60P with a nutating table (A-axis +45°/-30° and C-axis 0-360°) and a 2-position head (Horizontal/vertical). For axis-5 positionning, my post (Heidenhain) is using a useful function ("CYCLE DEF 19" in Heidenhain). Currently, to make correct output with my post (which is pretty reliable though), i need to create my Mastercam toolplanes in a unique way. First of all, I must match every X-axis tool plane parallel to X-axis front WCS view (=sides/back...). Once i did this first step, there are still 2 possible planes (the one i created and the one rotated 180° around Z-axis) so i must check (=to choose this one) Y-axis tool plane is pointing toward positive Z-axis WCS. That's it. Pratically with Mastercam GUI, to get my X-axis i usually need to project a line onto a surface in front or side view. With years of training i'm pretty fast to do it. But, lately i had to program a pretty complex part with many (many...) different planes. And this procedure is really tiring... even if i'm using a Spacepilot, a lot of hotkeys and a double-click macro with my mouse (an Evoluent vertical to prevent repetitive stress injuries that i already have...). I recorded more than 10'000 clicks a day. I was the first surprised.lol. Well, here is what i'd like to achieve: To create my tool planes in a much more friendly way (like any C-planes), by selecting an entity (ie:arc, normal or face,...). Just care about Z-axis and that's it! During the past 2 days, I worked on this and implemented it in my post. I 'basically' MP programmed what i was making with my mouse in Mastercam GUI: - I projected a point on my tool-plane (m1$->m9$). The point(1,0,0) in WCS front view or the point (0,1,0) in WCS side view if the first one failed. First projected point is (1,-m7$/m8$,0). Second one is (-m8$/m7$,1,0) - So theses coordinates give me a vector which is paralell to X-axis WCS - I unitize this vector which will be my new virtual X-axis - I rotate it 90° around z-axis tool plane to get my new virtual Y-axis. I assigned the numeric variables axisx$, axisy$,axisz$ to (m7$,m8$,m9$) then used MP formula My_axis_Y = Rotv(90, my_axis_X) - I calculated my new Z-axis with crossed product formula My_axis_Z = vaxb( my_axis_X, my_axis_Y) - I tested that My_axis_Z is matching (m7$,m8$,m9$) to check that my projected point above was OK - Then i checked that My_Y_axis is pointing upward by testing its z-wcs coordinate > 0. If not then I rotate 180°, My_axis_X and My_axis_Y (see above in Mastercam GUI) So I was stuck there when i sent my message... As i couldn't find how to map a point not expressed in WCS matrix. I found a turn around: - My new virtual tool plane is defined so i created a square matrix (My_axis_Xx,My_axis_Xy,My_axis_Xz,My_axis_Yx,.....,My_axis_Zz) - I mapped original X-axis tool plane(m1$,m2$,m3$) into this new plane thanks to the MP formula Vmap, to get its coordinates expressed into my new virtual tool plane. - Working in 2D plane now, i finally calculated this 'precious' angle between original X-axis tool plane and my new virtual tool plane (with Acos/Asin). - Then i rotated every nci points needed with that angle I still need to debug but it seems to work fine. I just get a problem, it seems that system is rounding some variables. I could notice some little errors with the calculated angle (0.005°). That's why i'd like to try another way to calculate, perhaps with a matrix. I don't understand why it is rounding. Is there a system tolerance numeric variable? Yours

Hello all, I'd like to improve my DMU60P(axis-5) postpro and i need a little help... Here is my problem: I need to map in another matrix plane some toolpathes NCI points (x$,y$,z$). Currently, they are expressed in Mastercam tool plane matrix (m1$->m9$). I found in MP.dll help file that a formula (vmap) allows to map vectors expressed in WCS into any matrix. But i don't know how to express my NCI points into WCS... I also read into my MP help file (perhaps outdated because it came with V9) that a matrix formula wasn't still implemented (mmap). Its name sounds great^^ i'll give it a try. Otherwise, anyone can help to express NCI points to WCS? Thanks

But if you alter geometry and need to regen... you can't. So you must edit every point again. I really avoid to change nci data like that. It'd be great if CNC system could implement an auto slow down/up before arcs and direction changes...

Machine is a Mazak integrex 200 Matrix 6 months old. Post-processor, well, I'm looking into it as I need to do a 5-axis job soon. Inverse time should be ok with my machine control (G93 G-code) and i am convinced this is the way to go. But here is a good point from Matt : "If you're using a post that has a good calculation for inverse time then it should work great and will take into account feeds changing due to diameter." I try to optimize these calculations because I read almost everywhere formula below to calculate length of the toolpath (which is needed to calculate inverse feed): Length = sqr((Prv_x$-x$)^2+(Prv_y$-y$)^2+(Prv_z$-z$)^2) But what's happening if during the toolpath, tooltip position almost doesn't change but tool direction does (so only 4th and 5th rotary axis) a lot? Well rotary axises are gonna move very fast as time calculated will be near zero. So I think this kind of calculation is ok if you're machining with tooltip only (bull nose) but for, for example swarf machining it's not reliable... So if anyone have an idea?

My problem isn't that i exceed machine specifications but that I'd like to get a constant tool load and smooth tool motion.

Hi all, I am not really comfortable with 5 axis toolpathes and i am wondering about inverse feedrates for my postprocessor. Every formula I read don't use rotary axis to calculate tool movement (and time). Is this really the way to go? I'm thinking about an impeller blade finishing toolpath for example. It looks like, only using XYZ points to make calculation, sometimes involve rotary motions too fast... Any idea?

Yep i made a mistake by rewriting... It works great thanks for the sparamete$ tip

So it's prmcode$=1346 (need to enable op file, question 1502) Thanks a lot

Hi all, Anyone knows if there is a way to read compensation type (wear/control/computer/...)in 2D contour toolpath in .pst file? thanks

Just need to unblock the file (on file properties)

You're welcome ;-) I still use it everyday...

It depends if you have many holes to machine... If just a few, i would go with a turning threading tool with 1 insert, then thread milling cycle.

'Thread mill' is the only way to go with cc if you need to machine from bottom to top. Drawback, lead-in are not powerful...

This is here By the way, That's OK with a mill machine definition but I just experienced a weird thing with lathe in Mastercam X3. It looks like that with a lathe machine definition (with milling capabilities) mill holders don't use holder.mcx file... On my seat Lathe is using holder parameters in tool definition (of course with turning tools but milling too)! Pretty weird.

May we update Mastercam verify module with new Machineworks libraries ?

No, there is 5-axis milling simultaneous verifier so Multi-Axis Machining Module should be included. I see there is a recent V6.6 machine works module. Does it can be updated into Mastercam ?

I see what you mean, better But the main problem is: How to export the "tool manufacturer" strings ?

Sorry I don't really understand what i would need to do... can you explain more step by step? Do you mean: to read tool holder string field of Mastercam current tool? If this is it... I don't know how to read that information.

For a large amount of metal to remove in TA6V, here we really like Mitsubishi High-feed AJX cutters with VP30RT inserts. Pretty fast and good tool life.