We actually have X sitting on the shelf. The machinists here don't want to learn X. The problem they have with parasolid is that it doesn't import line information in the form of edges (as far as I know). We do a lot of 2D cam work on Bridgeport EZtracks that only have 2 axis capability. Importing as a parasolid doesn't make it easy to recreate and analyze all the edges reliably. I may be speaking filth. I'm the lowest on the Totem pole, so I was tasked with solving this. If there is a straightforward way to import files with all relevant info I'm all ears.

We are still using 9.1 SP2 in our instrument shop. We upgraded to Solidworks 2007 recently, and the SAT (acis) file format no longer translates. Any ideas on a patch or workaround? The parasolid file format will open, but the default file used here is the SAT. Thanks.

I reposted a mold I was cutting with a new post edited to spec, and it did the same thing as before, but did it sooner this time. As an example, check out this link. This isn't the mold referenced above, but it is an example of what happens. ftp://cnczone:[email protected]/CN...e/New%20Folder/ Save the picture Mill2 to desktop and take a look. Notice in the code I posted there is a comment that says "(problem starts here)". At that point the cutter deviates from the expected path and cuts through the expected mold wall and to the minimum Y limit (less than 0 on the readout), before the table errors out. Ideally I'd cut the mold out of aluminum first, but that can't happen until the post works reliably. I can get Mastercam to output files that work by choosing differing methods of generating roughing passes, but it is hit or miss, and I don't like getting errors 3 hours into a 3.5 hour cut. Thanks.

Well, tried those settings (arccheck :2 with atol: .058), and it still goes out of control. Only on small arcs with large radii (the easiest way to have very small arc angles). Any other ideas? The code will verify fine in multiple toolpath viewers. It is always a machine control issue. Thanks.

Does changing to IJK output affect the arccheck functions?

Last thought for the night, I promise Is there a maxrad function? I could try and force the post to output arcs of smaller radius while maintaining a minimum arc length. This would in effect make the angle of any arc cut bigger. .001 radians is .057 degrees. .057 degrees is .0001583 of a full circle. (.057/360) Circumference is 2(pi*r). Ltol defines the smallest segment of anything to be .002. If we multiply the circumference by the smallest angle wanted, and set that equal to minimum length, we get max radius. Any bigger than that and you could define an arc length to be .002 long, and have an angle smaller than .001 rad, which is what causes the bad things to happen. Sooooo.... r*2*pi*.0001583=.002 solving for r, r=2.01 This could be problematic in application. A bit small... Thanks for listening.

One more thought for more explanation I was reviewing updates available, and saw this one... How are minarc and minrad measured? Arc length, arc radius, arc radian? MP_V918.ZIP 146 KB MP.DLL (v9.18) Changes made to the v9.18 posting DLLs and EXEs (MP, MPL, MPWIRE) Update tolerance variables and usage.- Added ‘minarc’, ‘minrad’, ‘max_atol’ and ‘trunc_mtol’ to make MP and Mastercam more consistent. ‘mtol’ is used as the actual comparison value for general motion. Add wire metric defaults and implementation. Fixed bug with breakarcs linearize and not restoring arc gcode on remaining segments.

Won't removing all filtering make really long posts? At this point I'm not sure length is the primary concern of course... How would this make cutting intentionally circular objects different... Would you end up doing a whole bunch of tiny linear movements instead of one circular interpolation? When eliminating all filtering would you alter the masking on an IGES input file to not include Arcs? Seems like you would include them, but just asking. I'd still like to try and understand the arccheck function more thoroughly.

Glad to hear that someone else has heard of this This problem is difficult to check for me because the code generated is correct, it is an interface error. Even the backplot by the machine controller is correct. I have to run the code and hope it doesn't fail, which gets to be expensive and frustrating when it does.

I'm trying to edit a post to work with a machine controller that won't accept arcs with an angle of less than .001 radians. This presents a problem mostly when finishing surfaces. If an arc with a very small angle is encountered the Machine controller will try to cut a full circle, rather than a tiny arc. So to clarify... arccheck :1 will use the length tolerance to determine whether an arc length is bigger than ltol. This is the current configuration. It fails when the arc to be cut has a very large radius with a small angle. Thus the arc length could be bigger than ltol, but with an angle that was smaller than .001. arccheck :2 will use angular tolerance atol. This may work. What unit is atol in? What happens if an arc is smaller than atol? Is is ignored? arccheck :3 will check for small arcs and convert to linear. This seems like the best solution, but I still need to know how arcs are evaluated. Does this option evaluate arcs against atol or against ltol. Thanks for any help. Most appreciated.