We use Supply-Pro (https://supplysystem.supplypro.com/) it is automated inventory management, works well. Cabinets are provided by our vendor with locking drawers at no charge. Orders are placed automatically. Almost never out of any tools and we can see where go.

Hi Colin, Trying buffer 4. I did not have anything in psof$ as mentioned... How would I sort, it's been a while? Ultimately, I'm looking for a text string, not a workofs$. pwrtt$ #Pre-read NCI file if tool_info > 1 & t$ > 0 & gcode$ <> 1003, ptooltable if gcode$ <> 1001, plast_recd pcur_recd if gcode$ = 1003, [ size3 = rbuf (one, zero) rc3 = one if rc3 < size3, preadcur_nxt ] # pwritbuf4 workusedg = workofs$ workusedg = wbuf(4, wc4) pwritbuf5

One job ago, I had a buffer that wrote all of the work offsets used in a program on a horizontal mill and listed them, as well as used programmable parameter input (G10) to set all of the work offsets relative to the top of pallet, center of rotation. Worked great, EXT, G54-59, P1-48, and even DFO. Fast forward several years, and I can't seem to get a buffer to work to simply list all of the work offsets being used by a program. I want a quick reference for the programmer or anyone else to see which work offsets are being used, when they look at the header. Can anyone enlighten me?

One method I use in situations like this would be to use Push-Pull and shrink that flat bottom hole until it does not intersect with the fillet. Then go ahead and remove. It doesn't always work, but its quick in most situations.

See my post from May 23... maybe this will help. https://www.emastercam.com/forums/topic/104375-xform-rotate-count-instances/#comment-1331158

I use custom drill parameters for this. That way I'm not eating up valuable resources (mi / mr) for something that only applies to a drilling cycle.

You can always do a parameter dump. pparameter$ #Read operation parameters #rd_params is used to call pparameter postblock and read the parameters of the operation specified in rd_param_op_no #"pparameter", ~prmcode$, ~sparameter$, e$ Delete the hashtag on pparameter line, post your code both ways, then do a file compare. Look for what's different to find which parameter it is. Careful, there is one that represents the number of times that the operation has been changed, but I forget the number.

Have any of you run into this issue? I can't show this model, but essentially what is happening is that as this material gets thinner, the step over increases when it whips around 180 degrees. When done, there is no fin left, this is a recessed area. I'm using a 1/2" endmill in hardened stainless 4% radial engagement. It does not like the heavy stepover. For what it's worth, I'm using 2021. Any tricks or 2022, 2023 have a fix?

I use CF cards, with a PCMCIA adapter, to drip feed from, on Makino mills...

The problem as I see it, is that Mastercam is somewhat intuitive if you are a machinist. Because a skilled machinist can jump on it with a very short lesson and get some use out of it, management seems to be reluctant to pay for training (in my experience). So on the marketing end, Mastercam is undersold. However, I bet nobody at CNC Software would say with a straight face to a perspective customer, "we have the FANUC kernel embedded in out software, so you will get perfect code every time". That statement, from brand x CAM company, even got me for about 5 seconds. Wait a minute, how does having the kernel in your software know how all the parameters on our machine are set up? Two same exact model machines can be set up differently... I have been told what Mastercam "can't" handle, but never had a show stopper that a little post magic or lying on a tool definition etc couldn't cure. Other softwares, if it can't do it, usually means you can't either.

I did some deep digging and came up with nothing. Then I tried posting the .nci file and nothing. However, I did find an exploit. As long as the checkbox "Remove comments" is unchecked, a gcode of 1008 is output between each instance of the transform. I used that comment as the trigger to put in the code needed for the cycle to function. With little safety check to make sure the box is not checked, we're good to go.

Hey guys, I'm stuck on a transform toolpath. What I am trying to accomplish is to inset some pre-defined code in between a transform toolpath that uses depth cuts. I cannot use ptlchg0$ because it puts the code in on every depth cut. Is there a way to detect when a transform toolpath initiates a new instance of the copied toolpath? Thanks in advance!

I have 2021 because of the IT people... But, here's an example of what I use for a #6-32 thread with a SPTM098LA threadmill. I have these exported as .ops files. It's great when I can just pick the thread I want, pick the location and depth and get a good thread on the first attempt.

I ran into a situation like this before. Two new Nakamura WT-150's purchased at the same time, but the parameters were different causing the milling cutter comp to be on the wrong side and G2/G3 flipped on one of them. The owner wanted to know why a program ran differently on the "same" machine, so I had to figure it out. There is no replacement for having eyes on the problem. Once I saw what it was doing and looked at the code, it was obvious what the problem was.