In Mastercam - you have 9 ways to skin a cat. I would prefer "Swept 2d", even though it's not spirial, it does produces arcs and least number of code lines.

JP_SPIRAL(1).mcam

prcc_call_end$

almost works as intended, besides other redundancy, it completely ignores subout$ in plin0$.

"G0 Z.0707
G0 Z.11
M9
M205
G91 G0 G28 X0.
G28 Z0.
G90"

Should be one the lower turret, yet somehow it ends up being written to a wrong channel.

(****************************************************************)
(*********************** UPPER TURRET TOOLS *********************)
(****************************************************************)
(****************************************************************)
M200 M300
G0 G18 G20 G69 G80 G40 G90 G94

G109 L1 (UPPER TURRET)
G91 G0 G28 X0 Y0
G28 Z0
G90 G53 B0

G0 Z.0707
G0 Z.11
M9
M205
G91 G0 G28 X0.
G28 Z0.
G90

M30

(****************************************************************)
(*********************** LOWER TURRET TOOLS *********************)
(****************************************************************)
(T3  | ID ROUGH R0.0313)
(****************************************************************)
G109 L2 (LOWER  TURRET)
G91 G0 G28 X0
G28 Z0
G90

(T3  | ID ROUGH R0.0313)
N3 ( OP NO.3 )
G10.9 X1
M901
M202
T003003
G90 G54
M8
G0 Z.11
X4.6633
G18
G92 S6000 R2
G96 S100 P1 M203 R2
G0 Z.0707
G95 F.01
G271 C.1 R0.
G271 P100 Q110 U-.02 W.01 F.01 S100
N100 G0 X5.4958 S100
G1 Z.0524
X5.3137 Z-.0387
G3 X5.2954 Z-.0608 I.0221 K-.0221
G1 Z-.1251
X4.7849
G3 X4.7407 Z-.1342 K-.0313
G1 X4.6999 Z-.1546
N110 X4.6633
M30

On 8/28/2021 at 9:15 AM, Tim Johnson said:

This sounds more like a wait code syncing issue. We do different processes on both spindles at the same time constantly on our i-300ST including OD roughing on both spindles. Do you have wait codes on every process or tool change? Depending on the parts we may run ten processes with tool changes on the main spindle using one wait code while the sub spindle may run several processes with indexing on it's same wait code without issue.

Edit: One thing we do here is printout the main spindle code separately from the sub spindle code. This makes it easier for the operators to find the needed wait codes when restarting in the middle of a program.

Something that is running in my head is to put only the tool change and wait codes on the "main" tool change programs and add the cutting paths on separate subprograms for each tool. This could potentially save the operators time searching for wait codes when restarting in the middle of the programs. I don't know if this is achievable yet though.

Tim, Thanks for your reply:

First of all: I have just started my journey into Mill-turn programming. The issue that I'm describing was brought to my attention by a Junior Mill-Turn programmer. I know it makes no sense. Everyone, Including Applications Manger @ Mazak, is telling me: there must be a problem with the "Wait Codes". I'm just describing an issue from some one else's words.

I'll get to the bottom of it.

1 hour ago, crazy^millman said:

Is there a Pinch Turning Code you can use to use both at the same time to speed up the process? Are you using MT for programming?

Hi Ron,

Thank you for reply:

The G-code was NOT generated by MT. We just manually moved some M-waiting codes around to allow both Main and Sub to to work Independently at the same time. Yet, the Sub is not working as intended. It does seems like both Main and Sub are synchronized. We are not doing  Pinch Turning at this time. If I understand you correctly, It's possible to Pinch Turn different turning profiles at the same time. It just happens that in our case it's on different spindles and that's why it's not working correctly?

Thanks.

Hello Mastercam community.

Appreciate your help.

I'm having a little problem with INTEGREX i-200ST.

I'm using an upper spindle to make an OD finishing cut on Main spindle(that takes a long time.)

Meanwhile, I want to do some OD roughing with the lower turret on the Sub.

Basically it doesn't allow me to have Main in G1 and Sub in G0. As soon as Sub reads G0 it waits for the Main to read G0 and only then G0 on the Sub is processed.

Seems like a safety feature. Anyone seen anything like that?

Thanks.

On 2/3/2021 at 8:09 AM, neurosis said:

 Sure it can.  If you don't mind the retracts. 

 

 

Give it a try.

On 2/1/2021 at 5:21 PM, Candicane said:

The other day i was trying to put curves on 1 solid face but it was like it was selecting everything but..

I dont know what i did but i managed to set it somehow so that i could pick the face i wanted..

I just want to know how to toggle this for next time..

Thanks 

You have this selection menu: When you pay for a seat. You don't ask such questions.

21 hours ago, ajmer said:

Check the entry helix tab

Could be that the helix is too big to fit into that area..there is an option to plunge or skip pocket if helix won't fit..try making the helix values smaller. Also check XY  clearance. Make that number smaller

The entire toolpath is Entry, except the last contour at the final depth. The Helix is circular, it can't profile ramp.

Cimco's HSM addon looks promising. Only if it worked correctly, direction of cutting does not work "both ways" and it does not recognize "rest stock" correctly!

pocket.mcam

Same toolpath, as 3D contour with cutter comp off. Saved modified geometry. Do I have to make my own ramping?

Ridiculous!

Funny thing is: the original pocket g-code is 935 lines long while this one is 917 lines without filtering.

Lead In/Out needs be fixed so it points inside the pocket: I love and I hate Mastercam at the same time

The toolpath here is a "Surface rough pocket". The toolpath looks very nice except the plunge! I just don't understand why most of the legacy toolpath's don't support ramping!

The only way to avoid the plunge is to plunge outside containment.

It's a non center cutting tool, I can't plunge with it.

Mastercam is Ridiculous!!!

I never had any luck with it but, there is always an option to get a ceramic bristle brush and go over the surface.

Surface High speed(Horizontal Area)

I like to use for flat area's. Very efficient. Recently I cheated by using  "2d dynamic mill" for finishing purposes. You need to filter it to get nice arcs. (Is there any other finishing tool path like that?)

Pocket has too many (lead in/lead out) leaves marks.

It just a toolpath across two chains. There is no surface!

Lets  have some fun: you where tasked with finishing the Z level of the Saturn rings. What is the most efficient tool path?

Don't worry bumping into the planet-as it's a gas giant!

This one is a 2d high speed dynamic milling. Produces a toolpath of 600k, with some filtering can be reduced to 15k.

Am I missing something? I couldn't find a finishing toolpath to produce similar results.

On 10/16/2020 at 8:12 AM, gcode said:

and spaces

Some posts, will post G01 instead of G1,etc.. I think you can strip those as well.

Pardon me for hijacking the thread. Yet, I have seen a lot of scraped parts and machine crashes on some of our older machines when filtering is used. In fact, I had to set "Present arcs as line segments" on "High Speed Toolpaths" . Control definition is set correctly.  I'm thinking that Arc tolerances in the machine parameters for imperial units are set incorrect.

I have read a lot about this issue, yet it's still not clear. Can someone shed some light here?

Thank You.

The version of the hasp driver at work and at home might be different.

On 10/10/2020 at 9:41 AM, crazy^millman said:

Recently, I had an argument with our customer that our drill points are not 118%. First of all, no one longer uses 118% drills bits. Secondly, they want +/- 0.005" on the drill depth. STI chamfers is a different story. In fact, I had a pleasure of installing a number of STI heli coils, I can attest that degree of a chamber does not make a difference. If the pitch is too tight,  you are not getting it in!

5 hours ago, JoshC said:

Crazy^millman shouldn't the machines controller Decelerate/accelerate where needed to prevent the machine from beating itself up, i am not sure if i am understanding what your saying correctly but I was under the impression the machine controller would slow it down to whatever feed the machine can actually handle. Like for example if I peel mill a little tiny slot, lets say .55" wide with a .5" tool so its swinging little arcs at 1000000ipm, my machine here will slow it down to whatever feedrate the machine can handle. I can throw a crazy feed at our haas super mini with next gen control and it will probably cut that peel mill a .55" wide slot with a .5" tool at like 50ipm even if i program it for 5000000ipm because the controller does its thing and decelerates to what its actually able to handle, it doesn't beat the crap out of the machine from my experience. and on other machines i have ran its been the same situation for me in the past so maybe you have seen that on a specific machine but i have not so i am not sure what you mean exactly. on top of that machines even have settings like haas's G187 settings that effect things like this. 

I am not saying that I typically like to peel mill/dynamic mill with that small of loops but nor do I ever throw a crazy feed like that into the program but just saying i have never seen the machine beat itself silly due to something like this so im having trouble imagining what your describing. 

 

5 hours ago, JoshC said:

Josh, It seems like there has been a lot of miss conception when it comes to dynamic milling.  First of all: I would say: unless you are milling 2.5D, it might not be worth it. Secondly, most modern machines have glass scales on encoders and memory buffers are capable of handling 2000 imp.

Yeah, I have read a lot about the wear on the ball screws due to minor movements. In fact I can attest to this. I do see  0.0005" back lash on a 63" table over period of 30 years.(most of it due to dropping the parts or hitting it with the fork lift!)

Mastercam has a setting to Decelerate in the corners. Same as a high speed toolpath option. None of it worked as intended!

Setup sheets can be overwhelming. Yet, I do like to follow this format:
1st Sheet shows the Setup operator how the setup is going to look like and where the work offset is.  2nd sheet shows the stock size dimensions, orientations, fixtures and elaborates more on the work offset. 3rd sheet has operations tool list with basic description of what the tools are. 4th sheet has a detailed description of the tools and holders.

I wish we could have come up with some standard Tool Naming convention: Lets say if a tool 808 was to break, operator knows that it's a 3/16 flat end mill with cut flute of 0.5" and stick out length of 0.85" and it should be in ER16 holder.

If the tool was to break and operator has no setup sheets, just by reading the tool description the tool can be changed.

JParis, 1.25" Shearhog? really!

1 hour ago, byte me said:

I do my part to contribute to the community by sharing source code rather than trying to monetize it, because I think the benefits are greater that way, I guess there are two schools of thought here, are there pirates who have benefitted off my work? Sure, but so have many legit users. Food for thought.

For some of the folks out there, all of it is just theoretical. At the end of the day it's the end user that provides all the end feed back. It's just wrong to keep the feed back as a tribal knowledge and to monetize on it as if it was something that you have invented yourself!

1 minute ago, byte me said:

The Resellers depend on post sales to survive, hence, they benefit most when you buy a new post for each new machine.

I don't disagree with the tactic. Yes, everyone's piece of equipment is individual and everyone has their own preferences on how their piece of equipment operates. Yet, lets not reinvent the wheel.

Mr. Crazy.

I think I do owe you an apology: I didn't mean to be rude.

I'm not here to discredit anyone and I'm not into blogging.  I'm just a guy who works at a machine shop!

In fact when it comes to inhouse posts - they are the most helpful people. I just don't understand as to why every time we need to start from generic post when  all of it has already been addressed else where! As you have mentioned 1+1=2.

Regards,

On 9/16/2020 at 8:02 PM, crazy^millman said:

You are not mentioning all the work MP.DLL is doing in the background with the MP language. This is where most external 3Rd party people struggle getting good code from Mastercam. They only use the NCI and the NCI is not the whole equation for getting NC code. It is the PST working with MP.dll that creates all the magic; one without the other will not give the correct output. Years ago we could tweak the MP.DLL, but that ability got removed about X3 or X4 if memory serves me correctly. 

Mr.Crazy: I just wish there was more information and flexibility. We do honestly pay for our seats: I just wish that the platform was more opened for developers.

Pardon me but this is Crazy:  I need to work with the posts that are 20 years old from inhouse-solutions and I'm sorry but they still don't work. How many more years of revision changes am I to see? Every time we are to buy a post from Inhouse solutions- we start with a generic 20 year old post; when is this going to end! Well, when I read a log  in the post modifications from a reputable company and it has already been 20 years: seems like like we made  a wrong choice!

On 3/23/2020 at 7:40 AM, pro grammer said:

pe              #End of line
      e$

pfe             #Forced end of line
      *e$

pn              #Line numbering
      n$

pfn             #Forced line numbering
      *n$

 

 

Yeah. This takes the cake for both arrogance and stupidity.

Very interesting read. MP was created by someone with a background in "C". '*' is a pointer to a variable. '$' is a notion that a variable is a string. Everything here is according to standard. It's similar to complaint that we didn't use his iphone to launch Saturn-V rocket to the Moon!