This is where I learned from: https://www.youtube.com/watch?v=qSj2Ly2pFNs

PM sent. Even if you were a creepy internet stranger, I'd still want to have a conversation. I enjoy learning, best way to do that is talk to guys with experience.

That thread I linked was an awesome (albeit lengthy) read, tons of great info in there related to ERP's and tool management software's. And as far as I've found that g54.4 thread is currently one of the best resources on the web, also well worth a read thru.

Do you have a link to that thread? Looks like you quoted a snippet from a post with other good information, would love to read the whole post and thread. Edit, found it: https://www.emastercam.com/forums/topic/103732-whats-everyone-using-for-tooling-management-as-in-inventory-usage-etc/page/2/#comment-1327457

First of all, huge thanks to everyone who contributed on this thread back in 2022. I learned a LOT from this thread. Last couple days I've been digging into "dynamic work offsets", which 3 days ago I knew almost nothing about. End goal is to load a fixture into the machine within +/-.030ish of where it is drawn in Mastercam. Then pickup the fixture and let the machine compensate to the exact location without having to reprogram/repost. Matsuura HPlus630 4-axis HMC with Fanuc 31i control. Almost all our work is 3+1 (programmed from COR), but if we figure out how to use this successfully we can introduce it to our 5-axis team. Here's what I've learned: 1. G54.2 is workpiece error compensation in x/y/z (no rotation comp). This seems to be for when you're fixture is off a bit to where it was programmed to so you can compensate for the error with the numbers in G54.2. So the x/y/z would be numbers the machine would take into account (along with the rotation?) when reading the standard G54, and it would offset in whatever direction it needs. 2. G54.4 is G54.2 but with rotation comp. This is what I think we would want to use. 3. G68.2 is tilted work planes. Define a point to rotate around and some angels (euler angles or yaw/pitch/roll) and the machine can do the math to get the new plane you want to machine in. You'd use this instead of programming from COR. I don't think we need this. Here's my questions: 4. Is it reasonable to use G54.4 on a 4-axis machine? or will this just overcomplicate things? 5. Do I have to use G68.2 with G54.4? Or can I use one without the other? 6. Does anyone have a better resource to learn about G54.4? I read thru the manual and watched a couple videos but I don't have a good understanding of it yet. It still feels like I'd be punching in some numbers and the machine would automagically make adjustments. This video was super helpful explaining G68.2, but I don't think I need G68.2: G68.2 YT Vid I apologize for the lengthy post. Any information is appreciated.

Have you contacted anyone at ProductivityPlus? I am not familiar with the software but I would think it's an issue on their end not Mastercam.

Is it a MC issue or a P+ issue?

probably the format on peck1$ Don't know for sure without seeing you're post, proceed with caution

Agree with all the advise above. +1 to smaller stepover and more flutes. My first reaction was 11% in ti is a lot, I was thinking 4-5% with a 5 or maybe a 7 flute EM. If the pocket is only 1.237" deep I'd shoot for two .619" step downs instead of .748. No reason for the first step to be the full .748 and the second to be .489. Though Optirough may even out the step downs automatically?

Funny you say that... JP told me about internal subs a couple months ago: Internal subs is how we are running now. To answer the question anyway, one machine has 2MB, I believe the other 3 have 10MB. Always cool to hear how others set things up.

Awesome, I'm in!

Huge thanks for the invite Colin, really wish I could make it, but I'm in the same boat as JP, minus the wife part. My GF goes back to college in two weeks and we're going on a small vaca to Texas next week so my next couple weekends are already full. I'd absolutely watch a video of the discussion tho, sounds like you're pulling together a bunch of very talented, very experienced guys.

The gauge length thing I'll agree with you. Would be nice to be able to adjust that in any toolpath. With that said, as far as updates to old school toolpaths, I imagine one of two things are at play. 1. It's possible new functions aren't backwards compatible with the old school toolpaths. If that's the case, the old school toolpaths would have to be rewritten to accommodate new functions. 2. They've got their sights set on something they deem bigger/better so they don't want to spend the time to update "little" things. Little in quotes there because software development takes ages. Something that seems "little" could take weeks or months of development and testing before release. Say it takes a month to implement gauge length adjustment to all toolpaths. I'd personally prefer that month of development time be spent on improving the deburr or unified toolpath, or even something completely new.

If I remember correctly, someone said CNC Software was trying to move away from MFC dialogs in the coming years. I forget the exact reasoning, but I believe it was something along the lines of better sustainability and expandability. My point is, on the surface it seems like "change for the sake of change", but there seems to be a good reason for such a major change. If anyone has any other information on the topic feel free to correct me, I'm going off something I remember hearing over a year ago, and I don't remember who said it.

If you're in a 3 axis machine, using a tool 12.0dia w/ .5rad, the area you refer to as "this part" is impossible to machine with a .5rad as you show. You either need a 1.0dia ball mill or a 4th axis. Or as @rgrin suggested, another op. I assume the "pattern" you're referring to is the vertical lines you see along the radius. I don't know for sure without looking at your file, but those probably won't show up on your part. If that toolpath motion outputs as a G02 or G03 move, it will be a smooth radius on the part. The vertical lines show up because of how verification models are generated / saved in MC. Any chance you can share the file? Or even a sample file? You'll get a lot more and better feedback if we can all play with the same file.

I'll do just about anything to avoid hand editing after posting. It just opens a can of fat-fingering errors that I don't want to open.

Who handles installation each update for you guys? We wait till the 1st of the year to upgrade and I hate that. The reasoning is to "let all the bugs get ironed out". I want to propose staying up to date and letting each guy choose which version they want to use (either current or 1 year old). But I foresee the response being "who's going to handle updating all 10 programmers computers every couple months?" I'd love to say "don't know don't care, I'll handle my own updating" but that won't go over well. I've been itching to use some of the new MC24 features since public beta but I can't justify updating my files when no one else has MC24 installed. /rant over

Decided to go with the 40,000 + main_prg_no$ approach. This seems like a more robust setup. I realize it adds 1 step for the machinist if an adjustment needs to be made. Instead of searching straight to the sub program, you can search to the M6 line and see what the sub number is for that tool, then search to the sub program. Thanks for the help JP

Gonna hijack the thread real quick. Is it true for ISO that each company writes their own rules? If so, why not be super vague to allow the most flexibility?

Almost identical to my alterations: absinc$ = sav_absinc #result = nwadrs(strp, main_prg_no$) --- Commented out 11/15/23 result = nwadrs(strq, main_prg_no$) # --- Added from above line 11/15/23 #main_prg_no$ = t$ + (1000 * use_cnt) # --- Added 11/15/23 --- Copied to next line 12/27/23 main_prg_no$ =(t$ * 100) + main_prg_no$ # --- Adjusted 12/27/23 if progno$ = main_prg_no$, result = mprint(sprgnerror) pbld, n$, "M98", *main_prg_no$, e$ result = force(feed) # Force output of feed next time it's called for output (in sub) I am still trying to nail down a good way to do subprogram numbers. The biggest thing I want is for it to be easy for the setup guy to jump to a tool's sub incase slight alterations need to be made to the g-code. My first idea was sub program number = t$ + (1000 * use_cnt) where use_cnt = callout number... ... so Q3122 would be T122 3rd call This worked for the first job we sub programmed, but the next job we're doing is setup on all 4 sides of a rectangular tombstone. Each face has origin at POR so the sub program for the large faces is different than the sub program for the small faces. So my idea for a fix was have the sub program number = t$ + (1000 * use_cnt) + (10000 * (#num subprograms since tool change))... ... so Q21010 would be T10, 1st call, 2nd sub This naming convention would work, except I couldn't figure out how to get "#num subprograms since tool change" The idea shown in the code is sub number = (t$ * 100) + main_prg_no$ I realize I still need some kind of iterator, in this case main_prg_no$. In the original example the iterator was a mix between the tool number and tool call, but had no iterator for if the same tool needed more than 1 sub program. The problem I foresee with the current case is if main_prg_no$ > 99 then all the sub numbers will be screwed up. This wouldn't break the code, it would just screw up the naming convention. At this point it might be easier to do it like you, start with 40001, add 1 for each sub, and create a separate op sheet chart for which sub numbers correspond to which tool.

Thanks for the reply. subout$ seems to be the answer to the question I asked, but I think I asked the wrong question. After playing with the post a little more, the question I should have asked is what triggers main_prog_no$ to iterate? And while writing this I realize it may not matter because I can probably just do something like this: if main_prg_no$ <> prv_main_prog_no, (do something)

How does the post decide when a new subprogram is needed? I see "c_msng$" which seems to be the call to the sub program post blocks. But I can't figure out what tells the post to jump to the sub program post blocks and when not to. Furthermore, if I have a transform op which transforms a toolpath, if I don't include my origin in that transform then a new subprogram needs to be output for each transformed location. What tells the post when to output a new subprogram? I imagine it's a list of logic like: if sub program is true & transform is true & include origin is false , then new sub program flag = true but I can't find anything in the post that is handling this. I'm working with a modified MPFAN post. MC2023. Please let me know if more info is needed. TIA

+1 to Mr. Paris Our "Shared Mastercam 20xx" folder is on our network so we can all use the same MD/CD, posts, and tool/toolpath libraries. Had a meeting with our reseller a couple months ago and they said our setup is how they recommend to setup on a network.

Merry Christmas gentlemen

Two reasons we shy away from in machine inspection. 1. Do you want your machine making chips or inspecting parts? We'll opt for chips over inspection everyday. 2. Most of our parts have some sort of stress or spring to them when you take it off the fixture. Because of this, we would get different readings in vs out of the machine. Also, if the print doesn't specify that we can inspect the part "in restrained position" then the part must be off the fixture to inspect. We do have some parts that we probe datums so we can hit tight true position tolerances.