Doesn't that mean you are making enough chips to make some money?

I would think 50ipm is pretty slow. Likely you can go at least 2x that speed before losing much accuracy. I would find a good middle ground and see how the part quality looks.

I would hope so by now, it seems to be an issue with all square outside shapes, especially on the first pass.

They won't do anything unless they are hooked up to the post. It all comes down to how much work the post developer wants or needs to put into it.

Okuma can't help? Surely someone in NC has a PDF of it? I might have something at home, but it would require digging out and booting up an old computer, but it is likely a p200 manual set, as it's been ten years since I was working there and that was the latest and greatest at the time, I don't believe we had any P100's left on the showroom floor.

I have had to chain an island before, then cut it off with a separate path in a few depth cuts. But for me, it usually isn't for tool breakage, but rather the island breaking off below the facing surface.

So true. No two machines are the same, and for all intents and purposes, they pretty much should be, but for some reason never are. Maybe MTB employees are like machinists, they all have to do it their own way regardless of what might be right wrong or indifferent.

Most certainly. There are many options than can effect the way the machines handles line segment code. Look-a-head blocks #, AICC II, nanosmoothing, high speed processing, to name a few. Not to mention also, the parameters and the way it's setup for use, I have found most builders don't fully utilize what they have enabled for options. Some do better than others, for example, you matsurra is probably setup decently well, but are there other options available that could make it even better yet? Likely. Possibly just some tuning could take it to the next level as well.

This will all depend on the machine tool builders implementation, and what options you have.

I can't look at anything in your toolpaths as I don't have a seat of router. Anyway, parallel can do anything raster can and more. My suggestion would be to create a line as your tool axis control, then setup collision control to tilt. If you are getting excessive primary movement to allow the tilt, change your default tilt line so it you are slightly biased in the direction your primary is trying to move into. With the collision control, you will be able to control more about when it decides to tilt or not vs what you can in raster.

When it tilts is it tilting on one rotary, or is it forcing a large movement of two rotaries?

Line to line is usually better, but it depends on the options you have and are using. Example, if you have nanosmoothing it's designed for short line segments. AICC, and most lookaheads will handle either very well. But results will depend on how much look ahead you have, and how smooth the path is. For the smoothest shudder free path with standard high speed options, your code needs to have a line to line angle as close to 180 degrees as possible. Point to point distance will be determined by how fast you need to go and how much lookahead you have. With nanosmoothing, the line to line angles become far less important, almost insignificant, as long as the segments are shorter than a given distance set in your parameters. What control do you have, and what options does it have? This might help tremendously. IMHO, arc filtering is best suited for code size reduction. This can help alleviate overrunning your lookahead buffer if you have basic look ahead options. But for this to be effective you have to be machining in either G17, G18, or G19, otherwise you won't get any arcs. Best thing I can suggest is look at your toolpath in backplot and see how the line to line angles are. Look for short segments next to longer ones, you might find little jogs in there. If this is the case then your geometry or strategy is causing this, you will have to adjust one or the other, but likely both.

What about using advanced multiaxis parallel path instead? You will then have far greater control over the Initial tool angles, and should be able to use angular tolerance to make finer angular movements without having to calculate a tighter stepover where you don't need it.

Agreed, not worth hijacking the thread. Hopefully it sparked some thought though for the op.

I will agree to an extent here, but the reality is, if you define it this way is no software out there is verification, the all become simulation. As the software is still emulating the real thing, it is only as good as it was designed to be, and it is not the same software as is on the machine.

Well, to an extent, I disagree. It is effective verification of machine, tool and stock clearances. It is not verification of G-Code. But in theory if setup right it is a move for move verification of the movement you should (not will) see at the machine.

It's not G-Code/NC-file per say. It's posted g-code verification. There would be no ability to do hand edits and verify those. It ends up being reliable enough for many situations, but if you feel you need a fully reliable system that you can verify offsets, hand edits, macro's, so on. Then you will need one of the ones you quoted.

IMHO, all should be set to gage length. That way if you picked up an optical or mechanical offline presetter you could calibrate using a test bar. Tool setter is usually best setup using a calibrated test bar, and the probe calibration surface would be calibrated using a test bar. Owning a calibrated L/D test bar is a must if you have a horizontal. It's the only way you will be able to make programs, offsets, and fixtures easily transferable between machines. By using a test bar you can grid shift the machines to the same nominal COR values, then by setting tool lengths based on G/L they too will be transferable. Unless it is a dual contact spindle, the spindle face to G/L won't be exactly the same machine to machine.

Z offset will be more negative by .065" Add .065" to the tool length. If this works, you should be able to just subtract .065" from 19702 and continue with the tool length and datum setting methods you have been using. (set g54 and length back to from spindle face)

G54 and tool length adjustment go together. So they would cancel. Then everything should fall in. Are you datuming Z to Spindle Face or Gage Line?

Not a coincidence, i take it you are setting lengths from spindle face not from gage length? If so, his numbers are good and your G54 is what is off. Adjust your G54 by .065 and see how things fall. Add .065 to your tool length as well, (if it is measured from spindle face)

I am thinking he didn't do his math right on the Z.... Being off .0555" from a nominal metric number sounds fishy to me. My experience, at least on the old mori's is that you are never off by more than about .005" in either direcction, and that's after about 10 years of maintenance fiddling with the zero's to keep the tool and pallet changers happy. IMHO, you never move the grid shift unless the grid shift moved.... Usually they don't without a big crash. Check his COR work, with your indicator, and your testbar. Remember, if you are zero at 0 and 180 on the side of the bar without moving X, then go to 90, and position the z so the indicator reads 0 your z machine position should be -1200mm plus test bar length plus the radius of the bar. If it isn't, well it's setup wrong. But the easy thing to do, would be to just shift 19702 and see if that corrects your problem, if it does, then you need to go about setting grids again, this time properly. Also remember, changes in Z will likely effect your pallet change. So verify mechanically that it is working right if you shift the grid to make things nominal again. Pallet should set down with little to no translational movement. Just up and down. If not, then you may need to adjust some things. Typically, if you nut your grid COR to nominal, unless they have been played with mechanically, or use a reference position for change, everything will be perfect.

This is a good way to check G43.4, but for what you are doing right now, a test bar and indicator will be far faster and easier. Doing tool plane work you don't need to worry about syncing axes.

Humor me and change 19746 bit 4 to 1. That should make the machine respect the 19696 bit 5 setting. Not sure why they have both settings but people have struggled with that setting in the past. However, I don't think this will effect G68.2 whatsoever. So I would tend to believe you have error in both directions... When he zeroed the machine to X did he verify X was at zero using a test bar and indicator? Did he also rezero the machine to reflect the -1200 in Z? I am assuming you know how to accurately find COR in both directions. Based on your numbers I am assuming your Z value is wrong by about .065" and you X is off by a smidge more than a .001". Start by changing 19702 by .065" in either direction, and see if things get better, don't play with your G54 quite yet. By the way, are you setting your G54 in COR coordinates, or machine coordinates? There is a parameter to toggle that, but I don't recall which one it is. I'd have to dig.

Are you having trouble with G68.2 or G43.4? I am assuming G43.4. My suggestion would be to do some testing with the part zero further away from the center so you don't get any sign errors confused. Start by verifying 19700 and 19702, and verify 19696 bit 5 is a 0, and 19746 bit 4 is 1. If all of that is correct and you are absolutely sure of that, I'll state the obvious, and ask if things are posting out correctly, and that the mastercam file is setup completely neutral. I have been dead sure my COR numbers were good in the past but in fact have made math errors, and wasn't, I always, no matter how confident I am in my methods, change use a slightly different method and check again, if they don't agree, figure out why.