Thanks Colin, How do I force C to zero with out affecting the modality of the code? if I force it in the post wont the NCI still be reading at C150?

I have tried working with my dealer on this but I am not having very good luck on explaining what I need or something. I was hoping it would be an easy fix but maybe it isn't possible. In mastercam I program the part to B0 C0, then I flip it side ways to B90 B150. Then I flip it back to B0 C0. When I go back to B0 C0 the posted code only moves B and not C. The code works but it kinda freaks every one out. I know it is a time saver and isn't really hurting any thing but I would like to just go back to c zero Here is the code. N1 G0 G91 G28 Z0 T2 M6 G61.1 ( G59 WORK COORDINATE ) G0 G17 G40 G80 G90 G94 G98 G49 G59 X-1.6903 Y-.3171 S3500 M3 G303 C150. B90. G43 H2 Z4.2628 T2 /M8 G4 P1000 (FACE DRILLED SURFACE) Z1.8628 G1 Z1.7528 F40. (deleted code not relevant) G0 Z4.2628 Z5.035 (FACE DRILLED SURFACE) X1.0326 Y1.0778 G303 C150. B0. Z2.635 (end) As you can see, B0 C150. Can I do something to move it back to C0? Thanks for the feed back.

I would recommend building a macro in the machine. Editing the post would be kind of a pain in the butt to do. You will still want to make changes to the post so that it will use the macro... Come to think of it, getting the post to do that might not be too bad. You can do math in a post so just find the post block that calls up your B move and add in a new string variable such as saxisprep = what ever your axis is$ +1. Then output that string and an EOB then maybe a dwell? and then it should output your actual zero location. it's a starting point but check out the MP_documentation from the reseller. There is info in there on how to perform math functions in a post. Hope that helps a little. If you are still having trouble then let us know.

Just learned one today by accident. When back plotting you can step the tool path by pointing your courser over the bar above the screen that indicates how far through the tool path you are and roll the mouse wheel thing. That was a really crumby way of saying it but yeah. It's basically like using S and B in back plot but with the mouse wheel.

I didn't see it in here but may have missed it. In your tool path manager, right click in the white space and chose select. The dialog gives you every option you could ever want when trying to track down a problem tool path or even if you just want to see something specific. Tool number, operation type, even a comment that you left in a tool path. You can combine the selection to make it even more specific. Example, I want to see every time that tool 5 does a circle mill on the top plane. Great for the 100+ tool-path operations. When I do 5 axis stuff, ever comment is unique in some way. It makes it easy to find the tool path you are looking for.

Yeah, I guess I was just a little annoyed with the post and didn't give all the info. Combined the code before with this code. pbld, n$, "G0 G91 G28 Z0", e$ #pbld, n$, *smetric, e$ #pbld, n$, *sgcode, *sgplane, scc0, sg49, sg80, *sgabsinc, e$ sav_absinc = absinc$ #if mi1$ <= one, #Work coordinate system # [ # absinc$ = one # pfbld, n$, sgabsinc, *sg28ref, "Z0.", e$ # pfbld, n$, *sg28ref, "X0.", "Y0.", e$ # pfbld, n$, sg92, *xh$, *yh$, *zh$, e$ # absinc$ = sav_absinc # ] pcom_moveb pcheckaxis That shows it a little better. It's just that there are a lot of shortcuts and some stuff works and other stuff doesn't. I guess I was just always taught to not break code when you are trying to fix code. If you chose to shut off a function then shut it off, don't leave stuff hanging around waiting for someone else to fix later. I get how hard it can be to get something to work just the way you want and how quick it is to hard code lines in but it just makes more work down the line as new features come out, posts are updated and as they are duplicated for new machines that the company buys. Maybe my nose is stuck a little to high in the air to see the reality of this but to me, it's just added to my work load, combing through posts and identifying broken links. Do you think I am being unreasonable?

That was the MP_Documentation from X7. I assume that wasn't your intention.

I just want to confirm, Post Reference Suite is NOT the same as the MP_Documentation. That is the second time my reseller has sent me the MP, at lest this time it's X9.

Here is the whole pwcs block untouched. pwcs #G54+ coordinate setting at toolchange if mi1$ > one, [ sav_frc_wcs = force_wcs if sub_level$ > 0, force_wcs = zero if workofs$ <> prv_workofs$ | (force_wcs & toolchng), [ if workofs$ < 6, [ g_wcs = workofs$ + 54 *g_wcs ] else, [ p_wcs = workofs$ - five "G54.1", *p_wcs ] ] force_wcs = sav_frc_wcs !workofs$ ] That's all of it. Nothing but another block comes after.

there isn't that's kinda my point. The functionality for the mi1 was partially removed.

I have been working my way through a bunch of posts that my company paid someone (not going to say who) to make. But there are some really weird things in here. Look at this and see if you can figure it out. Note mi1$ is not named in the CD. psof$ if mi1$ > one, absinc$ = zero pwcs, sgcode, sgabsinc, pfxout, pfyout, pfcout, pstagetool, e$ ptlchg0$ if mi1$ > one & workofs$ <> prv_workofs$, [ sav_absinc = absinc$ absinc$ = zero pbld, n$, sgabsinc, pwcs, pfxout, pfyout, pfzout, pfcout, e$ pe_inc_calc ps_inc_calc absinc$ = sav_absinc ] pwcs #G54+ coordinate setting at toolchange if mi1$ > one, [ sav_frc_wcs = force_wcs if sub_level$ > 0, force_wcs = zero if workofs$ <> prv_workofs$ | (force_wcs & toolchng), [ if workofs$ < 6, [ g_wcs = workofs$ + 54 *g_wcs ] else, [ p_wcs = workofs$ - five "G54.1", *p_wcs ] ] force_wcs = sav_frc_wcs !workofs$ ] Edit: post mi1 is pre set to have a value of 2 I kinda want to PM the guy who made this post but he hasn't been on here for two years. He still works for our re-seller though.

Yeah, for sure it's cutter comp. Your machine like most machines doesn't like to have Cutter Comp (cc for short) turned on or off in a g2/g3 line. There are probably 10 ways you could program it to stop it from posting out a cutter comp in your arc. Open your mastercam and back plot the tool. Go to your finish pass and watch as the tool comes in. It will be leading in with an arc, meaning the very first move after your z move will be an arc move. No can do. Can't fix it in the post ether. It is just a matter of watching for this. I tend to always program my lead in at a 2:1 ratio. That is, length can be 25%, 50% or 2000% if you feel like it. Just cut your arc percent in half. 50% Line length, 25% Arc length. This is one way to keep it from doing that. But it is not full proof. If the part isn't big enough for your lead in/out then it will cut it down and not tell you. Just keep an eye on it. And think about not linerizing. Massive amounts of code and choppy parts. If you don't have to (machine is not from the 60s) then don't. Hope that helps some.

I am having a rough time understanding you. What is the error, what are the 5 lines before and the 5 lines after and what controller? OR is this an error in Mastercam?

*looks at processor* Oh no, I'm good. This baby has a Pentium 2. Okay, -1 every thing looks great. I'll go check out and see what the lathe guy thinks. Thanks. side note, my computer is pretty old, i7 at 3.4gh and only 8gb of ram a hand-me-down from my boss. "worked great with surfcam"... sub text: in 2008

Making that a -1 did the trick. Just need to figure out how that affects my file in ways that could hurt me down the road.

Okay, so in theory; fprmtbl 17000 8 #Table Number, Size - Machine Definition parameter table 17391 axis_label #Axis label - 1=X,2=Y,3=Z 17402 rot_dir #Rotary direction 17408 rot_index #Index or continuous 17409 rot_angle #Index step 17410 rot_type #Rotary type 17101 all_cool_off #First coolant off command shuts off ALL coolant options 17102 v9_coolant #Use V9 coolant option 17435 stck_sol #Stock stick out length pmachineinfo$ #Machine information parameters postblock #rd_mach is used to call pmachineinfo postblock and read the parameters of the selected axis #combination machine entity set in rd_mch_ent_no. #rd_cd is used to call pmachineinfo postblock and read the active control definition parameters #rd_tlpathgrp is used to call pmachineinfo postblock and read the active toolpath group parameters #"-->pmachineinfo", ~prmcode$, " ", ~sparameter$, e$ #Do not uncomment if being called from pprep$ - see pprep comment #Read parameter lookup tables - if prmcode$ >= 17000 & prmcode$ < 18000, result = fprm(17000) #Run the parameter table for Machine Definition Parameters #Leave lines below commented until you enter values in related lookup tables #if prmcode$ >= 18000 & prmcode$ < 19000, result = fprm(18000) #Run the parameter table for Control Definition Parameters #if prmcode$ >= 19000 & prmcode$ < 19900, result = fprm(19000) #Run the parameter table for Toolpath Group Parameters if prmcode$ = 17435, stck_sol = rpar(sparameter$, 1) fmt "STOCK SOL - " 11 stck_sol #Sets fmt for stock stick out pheader$ sopen_prn, stck_sol, sclose_prn, e$ Should give me stck_sol = prm 17435, right? I am doing something wrong. stck_sol is zero on the debug watch. This may also be an issue. rd_mch_ent_no$ = 0 Just read the part about the rd_mch_ent_no$, looks like I want a -1. How does reading everything affect my post? are there errors I should watch for that might not have a warning?

Hey! That's some handy stuff! Didn't know about that feature.

I didn't even consider that it would have made it a spline because it's a perfect arc. BUT, when you project a spline it stays a spline. This includes lines!

AH HA, NURB!!!

PM your email and I will prep a Z2G

Just to add to the fun I just tried a pocket with helix ramp in. Works great. So I went to the tool path type and switched the type to contour, used ramp and presto. Looks like a good ramp. output 3D is NOT checked. the only difference is the geometry has not been xformed.

Helix is supported is on in the control. Helix all planes is selected. The arc filtering on my co-workers computer is turned off Tolerance Distribution is at .001, line/arc is not checked, smoothing is not checked. He gets a good tool path. I do the same, I don't get a good tool path. As for the output 3D arcs, that's where it gets weird. I turn it on, then click okay and the path doesn't regen. So I manually regen. Nothing changes. Open up the arc filter dialog again and it's not checked. Did it three times. Every time you manually regen, it unchecks its self. also, contour geometry is based on a 2D plane. I x-form projected the path I wanted to use.

So, I setup a basic countor using the ramp type contour, shut off linearize helixes and setup my linking parameters. Then I spit out the code and, helixes are linearized. Okay, so I go back and look at my CD, helixes supported in all planes, so that's good. I double check and make sure linearize is for sure shut off. That's good. Arc filtering is shut off as well. So I ask my co-worker about it and he tries the same post using ramp. His helixes come out fine. Ramping code looks great! So I try shutting down mastercam, delete my tool path and try again, re load the post. Still, I get 1000 lines of code. No G3 except for the lead in/lead out. What am I doing wrong?

This is a pretty advanced question. I think for the most part I have a basic understanding of how buffers work. I have read the MP ref guide on this a few times now and I think I grasp the essentials. Can someone check my facts? To set it up I'll define a buffer. fbuf 1 0 5 1 So we have buffer number one, don't keep, record count of five and initialize the buffer. The 5 is the coulombs, not the number of lines right? So if in my buffer i have; 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 and do a string_1 = rbuf(1, 2) I should get a return of "06 07 08 09 10" right? now let's say that earlier in the post I defined an implied array of; b1_1 : 0 b1_2 : 0 b1_3 : 0 b1_4 : 0 b1_5 : 0 Now I want to get b1_1 to equal line one coulomb one, b1_2 to be line one coulomb two and 3,4 & 5 to follow suit. So would I just run; b1_1 = rbuf(1,1) and then auto-magically the MP fills in 2-5? So if I read b1_3 i would get a return of 03. Okay, assuming that is all okay lets say I want to write to a line. b1_1 = 06 and the rest increment one till you get to b1_5 = 10. So then I run b1_1 = wbuf(1, 4) and my array in my buffer would be the same as line 2 that starts with 06. Does that all sound right? Also is this a typo in the MP Ref? It's the only part that really stumps me. If it's not can you explain why? #MP Post Processor Reference Guide (Vol. 2) pg. 24 fmt 4 b1_y # assign format statement to variable b1_y b1_x : 0 # initialize three consecutive variables b1_y : 0 b1_z : 0 rc2 : 1 # read counter for buffer 2 #ahaslam edit# shouldn't this say fourth, because b1_x was first right? also added # to make the lines the same color #In this case, if you use b1_x in the rbuf or wbuf function, the third variable in the list will be rc2 because MP will have already declared the b1_y variable prior to the b1_x variable through the fmt function. Okay, that's all. Thanks guys (and girls, are there any girls on this forum? I have only ever known one female machinist... she was crazy)

I'm still waiting for word from the man on the class you emailed me about. Stuff like that takes a long time to get around to. I am thinking about asking to do a reimbursement type thing.