Zombie thread is ten years old. Don't hold your breath.

Price. Solid carbide 3/4" shank is exponentially expensive, and we don't use it enough to warrant keeping a lot on hand taking up storage space.

We use solid carbide mills for everything 5/8" and under. For drills, we have a metric crap ton of Iscar SumoCham indexable carbide and we use those on most things 5/16" up.

Your default home position is set in the machine definition, in the machine axis combination tab. Keep in mind the numbers you'll see are Mastercam Top view numbers (like you're looking at the screen.) So Y is your lathe X, X, is your lathe Z, and Z is lathe Y. I try not to define home positions with the tool. Leave it to the machine and you won't have that problem as long as it's set right; change the dropdown in the operation properties to Home Position > From Machine and it will stay the way you defined it in the step above. ^^ I believe you have a Y outputting because you must have an axis combination that includes a Y axis. Did you make this machine definition yourself? Is it just a generic machine definition? When I post using the MPLFAN post on a 2 axis, I get no Y; but if I use it on my Y-equipped Okuma's, I'll get a Y. This leads me to believe you need to check your axis combinations. As for the doubling, this is done in the post to convert numbers to diametrical. The home position isn't exempt, so the best thing to do is define your home position as half of what you want. As for why your machine isn't moving to the numbers you type, that's beyond me. Make sure you're looking at the right offset; every machine has three "positions"- Machine position, Work Offset position, and Shift position. I can't really help you with this problem without actually seeing the machine work.

Maybe I'm saying something obvious that you already know; but when we have to run huge files on our older 16i Fanucs, I'll load the code on a pccard and run it as a subprogram. We use a compact flash card that can hold several gb, and a cf to pc adapter. I'm not sure if your Haas, or any Haas, has a pc card input though.

I keep my WCS as top. Mastercam should automatically orient the part correctly in the post. The snippet of code you posted is from the generic MPLFAN post, though, and I use a custom post so your results may vary.

If you're using the default post, you don't need to change the post, just the control definition. Open up your control definition, and go down to the "text" option. It will expand into suboptions. You need the first one, General Misc. Int/Reals. You'll see that the first three have a definition in them: Work Pos. Abs/Inc Ref. Return Click into the box for the first one, and at the end of the text put in //1 Do the same for the third one. Save and exit. This sets the default for every operation to 1. Post your program and it should be right.

If you get Renishaw, you'll probably end up using this to write the paths:

Unless he's running tight tolerance medical or aerospace, I'm going to have to respectfully disagree. If the parts he's making fall into the general +/- .005" tolerance the machine is more than capable of keeping it in there and running (as long as the machine runs true, no backlash, etc.) We use our probes day in and day out and they can keep a part within one or two thousands repeatability, verified by offline CMM. I guess it all depends on the type of work, that's really the defining factor. I do agree that the strain gauge probe is definitely more precise than the mechanical trigger probe, but that also adds a few k onto the price tag.

We use Capto exclusively on our Okuma Multus and Macturns, and we have nothing but good things to say about them... except about the price.

The Prod + software is actually pretty powerful, and you can measure angled planes, do alignments, pull data, etc. from some really complicated geometric shapes. I use it all the time to set my alignment from intersecting, 3D planes on our 3+2 mills. However, organic, non-geometric features are beyond it's capabilities. You wouldn't be able to do that using just the built-in macros, however. You either need the stand alone software or the Mastercam plug in and a 3D model.

Not sure about the Haas, but we've outfitted at least five Fanuc machines with Renishaw OMP-60 probes with full macros, and that install runs around $10k each. We also use Productivity Plus for offline programming of the probe; we have the stand alone package, but the plug in for Mastercam costs around $2k (which is about half the standalone price [depending on your reseller, of course.]) If your Haas is older and uses RS232, you'll need a separate software program on your DNC computer to read what the Renishaw macros output using DPRINT. (You don't need this at all to run the probes or anything, but it sorts and collects all the information into a nice excel spreadsheet.) So the whole software suite is around $12k including training and install. So for your first install, I'd say you're looking at around $22k; after that, if you want to outfit more machines, all you need is more hardware and macros and those are $10k. Of course, then you run into the problem of checking a part on the same machine it was made on... Any error in the machine will be an error in the probe.

...unless by 3d you mean fourth / fifth axis milling, in which case you need multiaxis.

Which is fine for the N number, but dealing with tool tracking and subprogram numbering, it isn't relevant. I wasn't very clear in my post when I was talking about sequence numbering: We don't use N numbers at all ~except~ at a tool change, and that N number always corresponds to the number of the tool being used. For example, a simple program would look like this: N3 (SPOT DRILL) G0 G40 G80 G90 G54 S1000 M3 G43 H3 X0 Y0 Z1. T2 M8 ... ... M6 N2 (DRILL) G0 G40 G80 G90 G54 S1000 M3 G43 H2 X0 Y0 Z1. T3 M8 ... ... M6 N302 (SPOT DRILL) .... And on and on. Notice how the N number is tied to the tool number. As the tool is used multiple times, the N number keeps track and increments itself accordingly. This can be tied to a subprogram number, so the first time tool three does it's own subprogram, it can be M98 P0030. Then the subprogram for the next tool can call M98 P0020. When it goes back to tool three, and calls a new subprogram, it will be M98 P0031. Keep it mind I'm an amateur at post stuff, so there may be easier ways to do this. For the tool tracking, the first thing I did was create a few variables and strings: fmt "N" 4 tool_seq #Tool sequence variable nt1 : 0 #Initialize tool track string nt2 : 0 nt3 : 0 fmt " " 2 seqmult I actuallly have a "nt" for each tool, so there are 30 lines. This is what makes me think there is an easier way to do this, but this works for now. Then in the psof postblock and tool change postblocks, I added the following lines: ptoolnum #Call tool track postblock if seqmult > 1, tool_seq = t$ *100 + seqmult else, tool_seq = t$ *tool_seq, sopen_prn, pstrtool, sclose_prn, e$ If your post doesn't call up the first tool in the psof postblock, you'll have to find it. Then I made a simple postblock that does the tracking logic and stores them in the variables: ptoolnum #Change N number for multiple calls of same tool if t$ = 1, nt1 = nt1 + 1, seqmult = nt1 if t$ = 2, nt2 = nt2 + 1, seqmult = nt2 if t$ = 3, nt3 = nt3 + 1, seqmult = nt3 again, there is a line line this for every tool up to 30 So what happens is, as a tool change is called, the post already has the t$ number ready to use. It goes to the ptoolnum post block, finds what tool it is, and changes the "nt" string that I made up to keep track of the tool use. It then sets the seqmult string variable to the count that the string has. When it finishes that postblock and goes back to the toolchange postblock, as long as seqmult is greater than one (as long as the tool has been used more than once) it adjusts the tool_seq variable I made to add the string count. Hopefully this helps.

I've had to add some logic and a postblock to increment my tool N numbers when the same tool is used at different times. The way we number sequences here is pretty simple: the first time a tool is called up it is simply N and the tool number, ie N3. The second time it is used it is N302, the N303 and so on. This same method could probably be used to increment your sub program numbers, without the need to use a misc int or real. If you're interested in the code let me know and I'll post it. Right now I'm supposed to be working

We looked at EDM when we started the project but the quotes we were getting weren't feasible with the limited run we had at the time. So I set to figuring it out. I won't lie, it took me quite a while of trying many different things before I came upon an idea that works. However, we've received the order several times since then and it works so well we wouldn't even think of changing the process.

I use a FF tip on a multimaster as well. We have one part that has a .500" wide slot almost 8" deep in 316 SS; I use a .472" Multimaster feedmill at .015" and 270 IPM.

We have several Iscar Multi-Master type holders with a 12" long carbide shank. You can screw on different types of mills to the bottom. I think our biggest is 1.25" It's far from being cheap, though.

Yes, at least it should if he's on windows. It's a standard Windows shortcut to change the default font size for almost any given program. You can do it in your web browser, email client, etc. It doesn't change the font size in the program per se, it just changes how Windows shows it; in other words, if Code meter says the font is size seven, and he zooms in until the font is so big only one letter will fit on the screen, Code meter will still say the font is size seven. It will stay that way for the program until he changes it.

hold down ctrl and scroll your mouse wheel.

We're an ESOP company and the employees evaluate other employees every six months as part of our bonus distribution program. It's a simple, numbers based form that is evaluated by a team afterwards to look for screwy things (so you can't bomb another employee because you don't like them.) Not sure if you're looking for something like that, but if you are, shoot me a message and I can give you a sample.

I'm sure I'm missing the obvious, but can't you just simply do file > save as... > .iges? I do that all the time for our cmm guy. Feel free to throw tomatoes at me if you need to.

It's easier, simply put. They don't make it clear in the manual (see below), but when you store a sub program as a .ssb, you only have to load the main program and the control will scan the file and pick out any .ssb you call up and load it into memory. If you decide to use .sub you have to load those subprograms when you load the main program. .sub are only used in the file that references them, while .ssb is can be used and referenced to by any file. It's confusing, really, and pointlessly so. Basically, if you have a repeating pattern for a tool that is only going to happen in that job and never be used on anything else, you can name it a .sub If you have a file that you tend to use across mutliple jobs, such as a bar pull macro, that can be an .ssb that is always resident and "live" in the system memory. Here, we have always used .ssb, and we never use .sub. There is no point unless you like to keep every program ever made stored on the machine. If you choose to keep it all on the machine, however, the control scans every "live" program. Having tens or hundreds of .ssb's stored on the control will make for a very, very long load time. Clear as mud, right?! From the manual: (2) Subprogram Files Format for file name: Main file name.SUB Patterns often repeated when cutting parts, such as Vee-grooves and parting off cycles, are filed in a subprogram file when preparing part programs. A subprogram file comprises one or more subprograms, with “SUB” used as the extension. When selecting a main program that calls subprograms, the subprogram file for the relevant subprogram(s) must be also be called. (3) System subprogram file Format for file name: Main file name.SSB Basically, system subprogram files are the same as the subprogram files explained above. However, whereas subprogram files are called at any time as required, system subprogram files are stored in the operation memory as frequently used machining patterns. A system subprogram file comprises one or more system subprograms, and the file name consists of the main file name and the extension “SSB”. Once stored in the operation memory, programs can be accessed from the main program as required.

.ssb files are just sub files that can't be selected as a main program, like macros or barpulls or things you want to repeat. If you use a macro for a bar pull, there is no need to post it out every time in your .min. The macro resides in the machine and all you have to output is the line that calls it up. You can make any .min an .ssb, and any .ssb a .min; all you have to do is change the end code and the file extension: .min ends in M02, .ssb ends in RTS

We've had Okumas for decades, and I don't think we've ever used the schedule system. We run our bar pull as .ssb sub programs. The main program is a .min or .bin with the bar pull call at the the top. First line in the program is N0002 like so: G13 (REVISION B 06/10/14 827 SEC) N0002 G00 X 20 Z 30 P0010 N0003 G50 S2500 N0004 CALL OSTOP FDOT=9.512 Then at the end of the program we run simple logic for the part count. If the part counter reached what we set it at, it ends the program. If not, it loops back up to N0002 and repeats. N0601 V24=V24+1 N0602 IF[V24 GE 2] GOTO N9999 /N0602 P-0010 /N0602 GOTO N0002 N9999 M02 Easy peasy lemon squeezy.