It would be nice if we only had to select the tool holder library ONE TIME, instead of every time we define a new tool. When I select the CT40 Holders, I don't want to have to select it from a list of holders every time - It would be nice if I only had to pick the holder library when I want to use a different one. Just a thought.

So, since I don't find any location to set or change the tolerances used in 'Compare' for Verify, Does it mean they are only going to be the huge 'metric' sized numbers? I am getting tired of changing it EVERY time I verify the part I am cutting - it keeps reloading the 'default' values every time I go to verify. This is true, even though I am not closing the verify window.

One thing I find missing in X7 Verify is the ability to 'SLICE' through a section of the part where I want to see what is happening. The 'pre-defined' views don't seem to ever be where I want to look. Or, am I missing something? We used to click on the point where the slice was needed, the click on the part to 'keep'. I really miss that.

Tell the software to use one finish depth pass of .625, and set the rough depth to 1.75. Then the moves will be what you expect.

Are the surfaces that are not flat a consistent angle? If so, get tapered tools. If necessary, get them custom made. You will save tons of time versus fixtures or surface machining.

Change the arc output to IJ rather than R. OR, you could break at quadrants, but I believe the issue is that your control is not finding the endpoint, and just keeps going on the radius until it is satisfied - hence the crop circles. Using IJ for arc moves should eliminate the problem.

tpi x fr = rpm

As noted above - Improved Verification - in views other than top. Use stock model in ALL toolpath types to minimize air cutting. Ability to define holes by finished operation and have 'prior' ops done as well. Cleaner FBM and FBD operations - without so many of the excessive 'extra' operations. Advanced HSM operations with emphasis on the full depth / light stepover on the outside of parts that WORKS without doing them over and over to get good output. Ability to copy ops from one open Mastercam session to ANOTHER open Mastercam session ^^^ ditto ^^^ for geometry.

Life is what happens while you are waiting to get a life.

As noted in a couple of posts - I am NOT seeing whiteouts or other graphics artifacts. I DO have both 64bit and 32bit computers though, and the 32bit system with 4gigs of ram DOES share memory with the graphics card. It uses a 'mapped address' system to share the memory / add to the memory of the graphics card. On the 32bit system, I have had issues - which is why I only rarely use it. On that system, even adding a graphics card with 1gig of dedicated memory didn't help. I would consider, if you are using a 32bit system, hunting down another computer you can use for a half hour or so, and trying Mastercam with your part that is demonstrating the problem and seeing if the problem doesn't go away. I don't think it will matter what graphics card it has. Just a thought.

Here in Idaho, there is about an even distribution of smokers and non-smokers in the shop. I don't smoke, but the other programmer does. Plus we are sitting in an un-enclosed area of the shop (Just a corner between two machines, actually). So, we have a LOUD, NOISEY, DUSTY, SMOKEY environment. There is no law or shop requirement about smoking in the workplace. At this point, smokers are a minor thing. You have to wear earplugs just to be able to sit there and work.

Colin, nextdc$ worked perfectly. Thank you, very much. getnextop$ was already set - but I wasn't using nextdc$. Thanks, again. Craig

So, I have a condition where I need to NOT output a spindle speed, M03, and Coolant on when using a custom drill cycle #9. Here is the code I have: pcan1, pbld, n$, *sgcode, sgplane, [if not(index), sgabsinc, pwcs], [if gcode$ = 1, sgfeed], pfcout, pfxout, pfyout, [ if not(opcode$ = 3 & (drillcyc$ = 9)), pfspindleout], [if gcode$ = 1, *feed], strcantext, e$ Which I think SHOULD output 'pfspindleout' anytime EXCEPT when outputting a opcode$ = 3 AND drillcyc$ = 9. But, what I find is that during the toolchange cycle, while opcode$ does equal 3, the drillcyc$ is 1. How do i get the drillcyc$ to be what is called out in parameters during the toolchange? It is correct during the rest of the program, just not at program start, or toolchange. Thanks

In the 'axis substitution' dialog box, you can select the direction the 'wrapping' occurs (one wraps 'over' and the other wraps 'under' ). This will reverse the direction of rotation - and the letters.

On the verify control page, if you don't really need to see EVERY STEP the tool takes, change the 'Moves/step' and 'Moves/refresh' numbers to be 10 or 20 or, I sometimes change them to be in the 100's or 1000's. It will refresh a lot less, and in the process have to render the tool and part a LOT less, and give you a much lower time for your coffee break.

Well, I can't find anything on 'G11' fit. I think your best bet would be to 'verify' the spec with the company. - If there is a G11 spec, it would be interesting to know what it is / means.

Each part is a copy of the original - it is not 'sub-programmed'. Plus, they could be in different orientation. If you want multiple copies, in a grid pattern and no change in orientation, you can do that with a 'transform toolpath'.

Excellent, it works! Thank you! I didn't catch that - both computers here had that unchecked.

So, I am starting at a new co. Each day I come in - when I start X5 - and load the prior days file - all of the operations are flagged as dirty, and 0 bytes. Is this a known issue or is there configuration issue on the computer on this end? I should also mention - surfacing ops on solid models created in X5 Multiple parts in one file. Working from muliple views. I think that covers it. Thanks Craig Madsen

Just a guess, but I don't think that Mastercam does any compensation for the accel/decel profile as your machine moves. Depending on the number and length of moves, your machine may never get to the speed programmed. (It does NOT instantaneously go to programmed feed and instantly stop - it accelerates to speed and decelerates to a stop - this takes time). About all you can do at this time is multiply by some factor by the time ESTIMATED and base that on known jobs versus those estimates. In other words, it is using the SWAG method - (Scientific Wild A$$ed Guess).

Use the wireframe toolpaths. If it really is a sphere, that is. Create an arc for the along contour, and another connecting to that for the 'across' contour. you will get arc output.

Use the point method if you want it to plunge at a particular point. If you want to control the direction, under the angle for the pattern, if you select 0 degrees it will start at the lowest point, working toward the right for the first move, then back and forth toward the top. If you select 45 degrees, it will start at the bottom right and work toward the upper left. 180 degrees will start at the top and work toward the bottom. And so on. When you select a point it will plunge at that point, then based on the angle it will move to its calculated point and work as I just stated.

did you install both into the same directory? That would be my 1st guess.

By the way, even the 64Gb Expresscard is still way slower than a fast SSD Drive replacement. Access time about 1ms. versus .1-.5ms. The SUSTAINED throughput rate is the major difference with the SSD drives.