On 1/17/2024 at 3:57 PM, Jake L said:

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

Figured I should answer my own questions after a conversation with @GoetzInd

4. G54.4 is useful on a 4-axis machine because it eliminates the need to position your fixture perfectly to where it was programmed in the CAM software.

5. G68.2 and G54.4 are completely separate functions. 54.4 is work error comp. G68.2 is tilted workplane, used for setting the zero point of your program to something other than COR. This makes the numbers in the program "make sense" so it's much easier for the machinist to make adjustments at the machine. Both functions can be used independently, or in conjunction.

One other major thing I learned is Tool Center Point (TCP) which is G43.4. This causes the x/y/z numbers in the program to be at the tip of the tool. This is used when rotating one or more axis while in the cut. It's another function that makes the code easier to read for the machinist.

Thanks again for reaching out and sharing so much information Mike!

You mean like converting the scientific notation to standard form?

https://www.calculatorsoup.com/calculators/math/scientific-notation-converter.php

This is where I learned from:

https://www.youtube.com/watch?v=qSj2Ly2pFNs

19 minutes ago, GoetzInd said:

See, I'm not just a creepy stranger from the internet....

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.

12 hours ago, Kyle F said:

I'll be reading through that thread as well @Jake L I also saw your bump on the old g54.4 thread and there is a ton of great info in there

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.

1 hour ago, Aaron Eberhard said:

Here's a thread where he replied to me a few years ago:

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.

11 minutes ago, jedeyelaser said:

I assume its a Mastercam issue. its a problem with the planes and coordinates. when you try to select a point to probe it seems okay but the minute you click okay and are done with the probing programming, it chooses a what seems random coordinate and you cant fix it that I'm aware of. Pretty much rendering probing useless in Mastercam 2024 and 2025

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. 

1 hour ago, jedeyelaser said:

also was told it still is a problem in 2025 as well and they have no clue when it will be corrected.

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

22 hours ago, Metals and materials said:

Any suggestions if I could do better. Attaching pics of part as well for better view. 

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?

5 hours ago, Newbeeee™ said:

Just talking out loud....How big is your control memory Jake?

Because if you can, you can't beat running internal sub progs - ones that stay in the 1x main program. This way no one forgets to save the subs at the end of the job run, because they're within the prog....

FWIW, after going round in circles with this back in the day, we decided to just use 0001 for 1st sub call and 0002 for second etc. Because the subs are saved in the folder with the main prog, and the sub header also stated "SUB FOR PROG NO XXXX", so there was never any issue with potential mixup.

Obviously later controls and 8 digit prog numbers would allow better file numbering (ie all subs to start 5xxxx for example)

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.  

20 hours ago, Colin Gilchrist said:

Date changed to Saturday, February 3rd... Not sure if that changes anything? Either way, you're welcome to join or just watch the videos when you can.

Awesome, I'm in! 

21 hours ago, Colin Gilchrist said:

Will certainly record whatever we do and post it to YouTube afterwards. Trying to do "YouTube Live" takes a lot of production, but we may end up doing a Teams meeting invite, and just recording that. Teams is a bit easier to manage than a broadcast stream.

@Jake L, you're welcome to join as well!

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.

14 minutes ago, crazy^millman said:

What do the old school toolpaths look like? Have the changed? Have they been brought forward to the new GUI? When will they get the transition? These are the things that show me inconsistent implementation from a GUI standpoint. how about support Gauge Length across the board for holder in the software? We don't program machine tool from the edge of the tape on a holder, but go use them in a setup sheet or just look at them in any of the interfaces and what are the measurements based off of? I was personally onsite back in 2011 and had this very conversation with developers and it is still not supported correctly? Don't even get me started on probing.

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.

9 minutes ago, MikronGuy said:

I feel the same way Ron does. Why fix something that is not broken. Why not give the users both options. Every time a new version of MasterCAM comes out we have to relearn the software. By the time we understand the way the new version works a new version comes out and the cycle starts over.  Its a different situation when you are testing the software instead of trying to earn a living off of it.

Even the roll outs don't address the new changes. all they do is recycle old tool paths on  tried and tested parts.

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.

12 hours ago, Izzat said:

So the Stock below is the Stock Model after all the operation, I used Bullmill 12.0 Radius 0.5 in a Raster operation thinking it would get me the 0.5 fillet on the Workpiece floor.  

12 hours ago, Izzat said:

Need this part to be 0.5 fillet.

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.

12 hours ago, Izzat said:

Is there a way to reduce this pattern on the Workpiece? Would using Smoothing under the Arc Filter tab result in a smoother surface?

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.

54 minutes ago, JParis said:

I do a lot of hand work to my programs after I post them...one of the things I do is add notes in the Tool Comments as to which subprogram/subprograms are called for that tool change. It helps them narrow down where to look

 

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.

38 minutes ago, JParis said:

Sorry, I'll never understand why a company that pays for maintenance lets their users decide which versions they will & won't run.

We run the latest at all times...if hire another person, that person will also need to run the same version.  

I can't have 8-9 guys all running different versions. Damn, I forgot how many we have now, lol

I apologize if this torques any one off but I just don't get it

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

27 minutes ago, cncappsjames said:

Now, because they were so specific in their ISO/AS manual, they could not add CNC Inspection to their procedures

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?

22 minutes ago, JParis said:

OK, now you're into this section...I had a feeling you needed something else besides the subout$ 

...

You'll notice a section near the end dated 2/10/2020  I have to alter the code for my mazak required output ....

What are you trying to achieve might be a better way to go at what you need.

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.

On 12/23/2023 at 6:46 AM, JParis said:

subout$

That's the command you're looking for...

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.