In X6 you should be able to use Surface High Speed - Rest Roughing with a containment boundary.. I don't know how big that part is, but if it were me I would be using some small solid carbide highfeed mills to remove most of that stock.

I wonder if it is a matter of not being at tool change position prior to calling the tool change with M6? If I don't do a G0G91G28Z0 G0G91G28Y0 To get in tool change position prior to the M6 it will fail, but otherwise it works fine. Additionally, we need to make sure the tool call of T1 is on a separate line as the M6 T1 M6 will work .. whereas T1M6 will fail We have 8 640M Fusions controls and 4 M-32 controls, In addition to those we have 4 Smart 430's with the Smart Controls and we have a couple of 510c's that have the matrix control.. I use the same code for all of them, the only differences I have to worry about is some controls use a G28 and some use a G30 for home The only two of our Mazak's that code doesn't work on is we have one M32 that has an older style tool changer so doesn't stage tools and an old m-plus that also doesn't stage tools and does not use M6 at all

If they are truly just looking for staging the next tool there is really no need to go all Mazak on it.. Sure they have their own wonky syntax, but the same tool staging that works for virtually any machine I have ever run also works on a Mazak. Toolchanges like.. T1 M6 G0G90G54X10.Y10.M3S2500 G43H1Z5.M8T2 Works just fine.. calls tool 1 into the spindle then stages tool 2 while tool 1 runs, it uses the standard logic in mpmaster (or many other posts) and it works in Fanuc, Mazak and Yaznac controls.. I personally don't see any value in making special code for Mazak to 'look like' their code when standard code will work on a variety of different machines with no changes.

You could, but most likely that would be a hand edit and he mentioned earlier in the thread something about 400 holes. That just doesn't sound like fun to me.

Do you not have to home out your rotary table? Or is it on a riser that's not shown or something? We do similar things with ours, but they need to be able to rotate through 360 for safety so they can't be destroyed by operators that don't know any better..

Great.. glad it helped..

Gramby, Macro's are stored in the control as a separate program, then depending how you set them up, and how they are written, they can be called a number of ways.. A macro with no options to be set could be called with a regular M98 (though to be honest I don't know why you would do this) A macro can also be used using a G65 call which lets you pass in values like you would in a canned cycle in order to modify the behavior of the program for example.. you could pass in a D1.25Z-1.0 to control the diameter and depth of a hole (assuming you had a macro written to handle those values) The last method you can use is a G66 Macro call which is a modal call and will work like a canned drill cycle where it will repeat the macro at each new position until it is cancelled. On some controls it is also possible to 'link' a macro program to a G code so you can simply call a custom G code and it will call the macro.. this is particularly handy IMO when you create a modal macro that is made to utilize a G66 call .. As for file size.. since the macro is a separate program and you can call it like you would another canned cycle.. it can be used without influencing file size if done correctly.

I am just guessing here, but I think it is likely that the variables speed and/or spindleout is simply not defined when you are in the pretract block If that is indeed the case.. then a simple fix would be to create a new variable that looks at speed where it is actually used in pspindleout and pfspindleout and sets a flag to use later .. I am thinking you create a variable like m5reqd - this will be a toggle to either use or not use m5 m5reqd : 0 # Flag then in the two postblocks.. you do this.. pspindleout #Spindle speed and M code output if (speed > zero), m5reqd = 1 else, m5reqd = 0 if not((opcode$ = 3 | opcode$ = 16) & nextdc$ = 3 & rigid_tap), speed, spindle pfspindleout #Spindle speed and M code output forced if (speed > zero), m5reqd = 1 else, m5reqd = 0 if not((opcode$ = 3 | opcode$ = 16) & nextdc$ = 3 & rigid_tap), *speed, *spindle Now you should have a variable m5reqd that is set to 1 if an m5 is nesc and 0 otherwise So now in your pretract .. you can test for the value of m5reqd rather than checking against speed which is not initialized in pretract.. Hope this helps.. as I said .. this was based on an educated guess that speed just isn't initialized in pretract.. also.. I haven't tested this..

Ron, I think your correct about needing to use buffers to do this. When the post processor goes through the file it reads the nci file one line at a time, so it wouldn't know the next tools until it got to the lines they were used in. The way around this is to use a buffer file, which I believe is what is already used to stage the next tool.. being as that is most likely the case, I think most of the work is already done for you. You could probably just read the next two tools from the buffer rather than just one, you would also probably have to write some kind of logic to handle when you get to the end of the file so on the second to last tool it stages the last tool and then the first tool , and then on the last tool it would stage the first two tools. You would also have to do something to handle when there was less than two tools, or only two tools. Either way .. if your post already uses buffers to handle staged tools, then you would simply have to modify the reads so that in the psof ptlchg0 and ptlchg blocks it calculates the next two tools - this can be a bit of a pain since it does require working with buffers.. and well they kind of suck to work with if you haven't played with them before.

Creating a hole that's that is 1 to 1.5 x diameter for depth prior to drilling with your long drill is going to give you the best hole.. You said you can't afford to have shorter drills in your magazine, but do you have an end mill available? If so you could just use a helical ramp and create your pilot holes that way.. just a thought. . I can see the reasoning behind going slower and not using through coolant when starting the hole, but on some of those smaller drill sizes your up at 14x diameter, regardless what you change your cycle to, your still trying to pilot a hole with an extremely long drill that's not made to make a pilot hole.

Yeah .. what I was trying to say is you end up needing a set of variables for each thing you want to apply it to.

And.. yeah now that I read Cathedrals post.. verify would indeed be totally screwed up.. I was thinking originally that you could make a misc int to flag it to put in a variable in the code.. but then it gets weird if you want to use variables in multiple places.. say clearance and depth for example..

One way I could think of that wouldn't be that hard would be to cheat.. make a switch in the post to look for -501.00 assuming your not running metric.. You are unlikely to ever have an actual -501 value to worry about unless A. your machines are a hell of a lot bigger than what I'm used to seeing, or B. you have some completely bizarre method for zeroes with them way off in outer space. If either of those cases are likely then this would be a bad idea, otherwise, you could just make the post include logic in the proper place to look for -501 and if it exists place a #501 in the code.. There are a number of ways you could accomplish this, personally I think making the logic look for if Z < 500 then make your ouotput be # abs(original Z value) whcich would allow you to use any macro variable over 500.. If you were using metric and 500 could come up you could always go with a larger number like 100501 then just subtract the 100000 from it in the post.. Either way .. seems like it could be done without too much trouble, but you will have to be willing to fudge it a bit.. don't think you will get away with the # in the actual fields no matter what..

You said you used mostly Mazak's in your other post.. my guess based on that is your using control comp. If so that's the reason for no cycle time.. for whatever reason they don't compute the cycle time on (most/any?) paths that use control comp. I guess this is because they can't know how the machine will turn comp on and off and how that will effect cycle time, personally I think its pretty lame.. they should really at least give the same cycle time as if it was control comp and a warning that this time might not be accurate or something. If you make a second copy of your file and set it to computer comp, it will give you a cycle time.. if you have even one path that is set to control comp when you backplot you wont get a cycle time.

Another thing that will do this is if you have a lead in/out on a line.. or you extend the start or end with the lead in/out options.. I have to agree with everyone else that this is better handled through changing how geometry is chained than in a post..

X-form Translate .. hit copy radio button .. should do it if I am understanding your question..

I use control comp all the time because our machines also use full diameter for the offsets. You should be able to get control compensation to work reliably by doing the following.. 1 - Put in the values that you would want for line in/out and arc in/out as if you were using wear comp 2 - Add 50% of the cutter to your initial values from step 1 to compensate for the movement the machine will make when it turns the comp on 3 - Set line in and line out to perpendicular 4 - Make sure gouge check is on. You will also want to make sure that backplot and verify are setup to simulate cutter compensation in control. For the classic backplot, this is a checkbox you can check once you have hit the exclamation mark icon to open up options when you run backplot, for the new backplot and for verify this option is available when you hit the backplot/verify button next to the verify button on your toolpath manager. Also, you will want to verify that your control definition has the control supports cutter compensation in control box checked on the cutter compensation page of your control definition. Someone said earlier in the thread that the lead in or out can be set to tangent or perpendicular, however in my experience tangent lead in/out does not always work correctly, I have yet to have a problem with perpendicular. Given that the arc in/out is what actually leads onto the part, the fact that the line is perpendicular should not really ever be an issue.

Best luck I have had with A286 is using fine tooth roughers running with coolant.. I guess it depends on the part geometry but using fine tooth roughers I was able to remove stock far faster and with much better tool life than any kind of highfeed or dynamic type paths using regular cutters. Never even crossed my mind to bother with inserts so not sure how they would work but tbh im not surprised at the 30 minutes tool life.. that's prob not too bad for inserts in A286 .. that stuff is pretty bad to cut.

Just got to try this yesterday.. I ended up getting a Allied Spade drill and going with the method jlw described above. Used 135SFM and a .006 chipload and it cleared the chips no problem, just wanted to say thanks to everyone for the input.

Based on the above.. I would try the following.. angle = (Math.Asin(temp1) * 180/Math.PI)

From a very quick look at the MSDN website .. it appears that the function returns a value in Radians.. The following is from the MSDN website .. 'DeclarationPublic Shared Function Asin ( _ d As Double _) As Double Parameters d Type: System.Double -------------------------------------------------------------------------------------- A number representing a sine, where d must be greater than or equal to -1, but less than or equal to 1. Return Value Type: System.Double ----------------------------------------------------------------------------------- An angle, θ, measured in radians, such that -π/2 ≤ θ ≤ π/2 -or- NaN if d < -1 or d > 1 or d equals NaN. Remarks A positive return value represents a counterclockwise angle from the x-axis; a negative return value represents a clockwise angle. Multiply the return value by 180/Math.PI to convert from radians to degrees.

Yeah its pretty big.. I have about 37 inches under the spindle at tool change position.. so height wont be an issue at least..

Honestly I had no idea where to find a regular drill.. fortunately its only about 30 parts.. so will look for the old school drill I think.. now that I know where I can find one.. really have never had much need for drilling big holes this deep.. so didn't really have any idea where to look..

How about just sending them to the benchmark thread which shows the progression of computers over the last several years .. it also shows the differences in time for calculating differing toolpaths.. This discussion has been had many times over but the long and short of it is.. would you rather put up the $$ up front for the computer or pay your programmers to sit on their xxxx instead of being productive while they wait for their substandard computer to process toolpath's / graphics.. As was already said.. it really depends on the work being done.. if your working on 2D toolpaths with all simple wireframes.. then get yourself a commodore 64 with the cassette tape drive.. if your working on complex 3D parts with solid models with hundreds or thousands of faces then your going to have to do much better than that... (of course the commodore 64 comment was a joke.. but it illustrates the point) Simple work probably doesn't justify a high end build, however if you have complex parts then your needs for a higher end PC will go up substantially very quickly.. If your programmer is waiting for his slow computer then he is not being productive.. this is time you are still paying for.. but your not getting a return, in addition your parts aren't getting done because they are waiting for a program which could mean your machines are sitting.. So in essence you saved a couple grand on a computer (once) and for the couple grand you saved you are now continually holding up machines that cost hundreds of thousands of dollars and are paying labor costs for people to stand around and wait for a computer - additionally your productivity has gone down which means your not able to make the same part for the same cost as your competitor .. which could mean jobs you don't get .. If anyone ends up waiting longer than nescessary because of that computer, then your losing money.. and your 'savings' on the computer quickly will become irrelevant based on the losses created by the slower than necessary computer. Now of course.. it doesn't help to buy a computer that outperforms your needs.. but in reality.. your computer you use to program is every bit as important a piece of your production equipment as your machining center.. so how can you really justify saving a couple thousand up front and paying for it over time..

So I got a project thrown at me that were not really setup for .. but it has to get done one way or another.. and i'm not allowed to send it out (not my call), so here is what I have to do.. I have a vertical machine (no horizontal available) with the standard through spindle coolant (not high pressure), I need to drill a 1.625 hole 13 inches deep (with a 118 drill point) in 6061 Aluminum Currently my main problem is even finding a drill with the proper geometry.. so far the only drill I have found is a Allied Spade drill which has the reach but comes standard with a 132Deg tip.. also in aluminum they suggest to have a coolant flow of 70Gallons per minute.. (I highly doubt I have that much flow) I was wondering if anyone knows if they (Allied) will make custom drill points at different angles.. or if anyone has any other suggestions for different tooling brands or options. If need be I can always drill with the 132 point and then perhaps find an old monster twist drill that's got a 118point on it to cut the drillpoint for the part geometry .. I would prefer however to cut once and be done with it if at all possible.. although I am pretty concerned that this is going to end up being a drill / clear chips - rinse repeat process.. Anyhow .. looking for any suggestions for tooling and or process considering the limitations mentioned above..