To anyone that has the new Mori's with Esprit on the machine, how do you guys keep the operators from trying to do their own programming. We deal with that enough with CAPPS.

I have had this problem off and on since X3. Some arcs are fine and some are linearized. If I remember correctly setting the NC precision to .00001 fixed this problem for me. Control def--Tolerances--NC Precision.

We had this problem with our Mazak V40. Most of our stuff is in mazatrol, but we had a manual program in Mazatrol for a thread mill. The program was in incremental and gave the same errors you show. The same code would run on our other Mazak. I switched the code to absolute and it accepted it although I have no idea why.

We use Sumitomo and Sandvik high feed mills, both work good, but I would have to lean towards the Sandvik.

Oh, let's a milling an offset od like a crankshaft journal, or milling an L shaped slot on the od of a tube where you need the walls parallel to each other.--I actually did the slot with axis sub and then a contour toolpath using the Y axis to straighten the walls out, but I think you would need to have multiaxis to do it all in one toolpath.

To fully utilize the 4-axis capabilities of a Mori NL3000 with Y axis (single spindle) you would need the Multiaxis license, correct? I have used axis substitution with the tool on Y0, but do not see how you can control all 4 axis with the tool not on Y0 without the Multiaxis upgrade. Just want to be sure I am not missing anything before turning in a software request for the upgrade. Thanks X4 Level 3 Lathe Solids

The mill design and toolpath course just has two 20 question tests. The course gives you a part to practice with in case you decide to get Mastercam Certified which is something different.

Here are a few of my complaints. 1) Misc ops not working consistently and showing the same in back plot and verify. 2) Sometimes we you change a tool path the tool follows the part correctly, but it still shows about .050" worth of stock around the part. 3) When I change something that has nothing to do with the actual tool path all operations get dirty. 4) Round boring bars in verify--try looking at that with custom drawn Sandvik Capto bars. 5) Canned cycles--I have a post fix that corrects this and the issue of seq #'s resetting on stock flip that I have posted elsewhere on here, but back plot does not behave like the machine does. 6) In mill I can make major changes to an existing file--in lathe it is easier to start over. 7) How about when verifying milling operations the part turns (like back plot) instead of the tool moving around and thru the part.

This morning I was doing a simple live tool program and on the stock flip it moved all the 1st side operations to the back side of the part and when I tried to fix them it crashed. It seems to be getting worse instead of better.

Don't feel frustrated, it takes time. I am nowhere close to being as good as a lot of the guys on this forum are. I know what you mean on not having any time to investigate anything. I tried all the above during lunch and after work.

I did try the high speed tool path and it would not output the G112. The conditions I explained here are necessary to set the millcc variable to 1 from the misc value, but another set of conditions come into play in order to output the G112 or G107. In the pmillccb post block the cutpos2$ needs to equal one in order to output an G112 and when I ran a high speed tool path the cutpos2$ was always zero. 1=Start point, first point on surface, chained contour, etc 0=Before start point; reset at each tool change, including null So I would say the high speed surface tool paths do not support the G112 or G107 cycles.

I tried a radial finish toolpath with both a NL3000 set up and a vtl and both output the G112 (G12.1) code. The current values for the cuttype variables will not be in the post, they'll come from the NCI file and change based on operation.

I haven't ever tried using G112 in a surfacing tool path, and I am assuming you don't have a Y axis. Is the work you are doing on the face of the part? According to my post the cuttype needs to equal four (Y axis substitution) or the abs(cuttype) needs to equal two (r/l face cut) in order for the millcc to be set equal to the misc value 4. I would suppose a post for a VTL would be set up in a similar way. When using mill/turn verify and backplot seldom do the same thing.

If you turn on the peck groove in the groove rough parameters there is a place where you can select the peck depth and the retract. I think this might do it. I am at home and I don't use the canned groove at work so I am not 100% sure.

Some lathes have an option called type two cannned cycles which allow a change in tool direction like a plunge in one axis only. For example you can plunge on the x or the z but not both. They are usually designated by a W0 on the first line of the profie such as: N20 G0 X2.85 W0.

www.cncci.com has example of this on their tip page.

Is anyone using a Mori Seiki NL Y axis lathe to do four axis contouring outside of g12.1 or g07.1? These machines to not have inverse time feed and I need to know the best way to move a linear axis and a rotary axis at the same time. Our distributor suggests using deg/min and breaking the rotary motion into 1 degree increments, but this doesn't seem to me to be a solution. Can anyone point me in the right direction here? Thanks.

We have a Fadal VMC with a small rotary on it off to the side of the table. Most of the time we run vise work on the table and when running these parts the operator does not like the A axis 0 moves in the program at all so I set up a Misc Int. for using A axis. I don't know whether that is the smart way of doing it or not, but that is what I did. It is still something you can forget to turn on though.

One of the things that you can do is set your C0. so the jaws are oriented however you want. We do this with our Mori's (I assume you can on other brands) and have C0. between Jaws 1 and 2. That way we can move a part from one machine to another and not have to worry as much about hitting the jaws.

Thanks Colin, the parameter read did the trick, for some reason I could not get the sup_op_id$, but using the op_id$ worked just fine. I posted the results on a seperate thread. Thanks again.

I belive I have found a fix to get the correct finish canned cycle start point regardless of the order of operations. I created a buffer to store the position of the tool before the rough cycle is called and then it reads from the buffer on the toolchange post blocks if it is a finish canned cycle. The coordinates are stored by the op_id$ instead of the sub_op_id$. When doing a parameter read for some reason I could not get the sub_op_id$ info. This is what I did and it seems to be working great. ------------------------------------------------- code: sav_absinc : 0 #Saved absolute/Incremental spd_rev : 0 #Flag to reverse spindle direction sav_gcode : 0 #Gcode saved sav_feed : 0 #Feed saved sav_ipr : 0 #IPR saved sav_feedcc : 0 #Feed saved, canned cycle sav_iprcc : 0 #IPR saved, canned cycle sav_ccxst : 0 <-----------ADDED to save X positon at start of canned cycle sav_cczst : 0 <-----------ADDED to save Z positon at start of canned cycle sav_spdir : 0 #Spindle direction saved sav_omitsq : 0 #Omitseq saved sav_subout : 0 #Saved subout sav_frc_wcs : 0 #Force work offset flag saved sav_bug2 : bug2$ #Saved setting for bug2 sav_cutpos2 : 0 #Patch to handle cutpos2 flag through null toolchnages cir_at_zero : 0 #Arc center at centerline in XY plane, -1 if not plane 0 pnt_at_zero : 0 #Position at centerline with milling c_ax_flp : 0 #G18 plane with C axis arcs in neg. range rslt_plc : 0 #Return value from plcval rslt_upd : 0 #Return value from updstr sof : 1 subop_no : 0 <-------ADDED stores the op_id$ that is referenced by finish. Added the following buffer. code: # -------------------------------------------------------------------------- #Buffer 4, recall start point of lathe canned turning cycle. wc4 : 1 #Initial count for write buffer 4 rc4 : 1 #Initial count for read buffer 4 size4 : 0 #Buffer 4 size fcc_subid2 : 0 #Buffer 4 fcc_ccxst : 0 #Buffer 4 fcc_cczst : 0 #Buffer 4 fbuf 4 0 3 0 0 #Buffer 4 # ----------------------------------------------- --------------------------- Added the following write and read blocks for Buffer #4 after the pwrite_g70 and the pread_g70 blocks code: pread_g70_start #Recalls canned cycle start positon. foundcc = zero size4 = rbuf (four, zero) wc4 = one while wc4 <= size4 & foundcc = zero, [ fcc_subid2 = rbuf (four, wc4) if fcc_subid2 = subop_no, [ sav_ccxst = fcc_ccxst sav_cczst = fcc_cczst ] ] pwrite_g70_start #Write G70 start position buffer fcc_subid2 = op_id$ fcc_ccxst = sav_ccxst fcc_cczst = sav_cczst fcc_subid2 = wbuf (four, rc4) ----------------------------------------------- This is were the position get saved to the user created variables. prcc_setup$ #Lathe canned cycle setup #Capture values from rough sav_ccxst = vequ (copy_x) #save current position<----Add sav_ccxst = sav_ccxst * dia_mult<----Add sav_cczst = vequ (copy_z) #save current position<------Add ---------------------------------------------- In this post block the info is written to the buffer. code: prcc_call_end$ #Rough canned cycle end # Restore cc_1013 to the value it held prior to the rough # 1/17/03 # groove canned cycle. cc_1013 was changed in ptoolend. # 1/17/03 if tool_op$ = 208 | tool_op$ = 62, cc_1013$ = sav_cc_1013 # 1/17/03 if tool_op$ <> 208, [ omitseq$ = sav_omitsq #Close the ext file result = fclose (sbufname3$) #Open the ext file as a buffer #Use the size to determine the start and end sequence subout$ = sav_subout size3 = rbuf(three, zero) if omitseq$ = one, [ ng70s = n$ ng70e = n$ + seqinc$ ] else, [ if old_new_sw = zero, ng70s = n$ + seqinc$ else, ng70s = n$ + (seqinc$ * two) ng70e = ng70s + (seqinc$ * (size3 - one)) ] pwrite_g70_start <----------------ADDED pwrite_g70 ] ------------------------------------------- This is part of the ltlchg$ post block, what I added here also gets added to ltlchg0$ code: if home_type > one, absinc$ = zero rd_prm_op_no$ = op_id$<------------ADDED This makes sure I read the parameters from the current operation rd_param$<------------ADDED This call pparameter$ if tool_op$ = 201, pread_g70_start<---------ADDED if lathe finish canned cycle read from buffer. if tool_op$ = 201, xabs = sav_ccxst<---------ADDED if lathe finish canned cycle xabs equals saved value from rough if tool_op$ = 201, zabs = sav_cczst<---------ADDED to do the same for Z pbld, n$, psccomp, *sgcode, pfxout, pyout, pfzout, strcantext, e$ n$, pscool, e$ if lcc_cc_pos, plcc_cc_pos #Use sav_xa to position with comp. LCC ------------------------------------- Added to pparameter$ code: if prmcode$ = 13121, subop_no = rpar(sparameter$, 1)<------reads the op_id$ of the rough cycle that the finish cycle is referencing and stores it under subop_no The values are stored in the buffer by the op_id$ so you need to read the upcoming parameter for op_id$ out of the finish cycle so you will pull the correct info out of the buffer.--Thanks Colin Gilchrist for the lead on this. By the way if you change the sub_op-id$ in pread_g70 and pwrite_g70 to op_id$ it should provide a work around for the X4 bug of setting all you sub_op_id$ to zero after a stock flip which was discussed on here earlier. I have not tested this much though. Sorry for the long post.

Yep--32 bit XP.

I think I have got this figured out--let me do some more testing to make sure I haven't messed up something else and I will post results.

Small world isn't it--I live in Hedrick, a little town twenty miles to the southeast of Oskaloosa. I do have the V9 Post Guide and Monday I will shoot an email to [email protected]. Appreciate the help.

The value represents the depth of the first threading pass and the passes will get smaller as you reach the final diameter of your thread. I do not know how Mastercam caluclates the depth of the first thread, but if you run it in backplot and watch the coordinates at the bottom of the screen you should see the first path being the depth you stated above. If you need to reduce it you will have to select more passes.