VERICUT Users' Forum

BillH

VERICUT Specialist

From: Irvine, CA

Registered: 2004-10-08

Posts: 146

Website

Ramblings on tools in VERICUT from Pro/E and other sources

The following is from a reply to a Pro/E user forum posting, but I thought it might be useful here ...

CGTech has spent several man-hours consulting with PTC development on enhancements to the Pro/E interface to VERICUT in Wildfire4. Much of that effort focused on enhancements to tool transfer, specifically for solid tools.

I’m not qualified to comment or pass judgment on the good or bad consequences of using solid tools in Pro/E, or Pro/E’s applicability as a tool management system. But if you do use solid tools in Pro/E, then in Wildfire4 the results in VERICUT should be greatly enhanced. There are a couple of simple rules to follow on the Pro/E side for this to work seamlessly.

I can add some “expert” comments on the VERICUT side (using the traditional definition of x-spurt, of course). When discussing how well (or poorly) VERICUT is able to create tools from external sources it is important to identify which VERICUT version we’re talking about. VERICUT 6.0 contains several enhancements to its tool definitions. The most significant are:

. STL files for tool holders.
. Define any configuration of insert cutters for milling tools.
. Removal of most all restrictions for holder and cutter profiles

The only remaining restrictions are the profile must not cross itself and
revolved mill tool profiles must not cross tool centerline.

In VERICUT 6.1 further enhancements allow for multiple insert tools for turning, including the use of “flash” tools (multiple turning tools in one assembly, which rotate different tools into cutting position). We’re trying to release 6.1 in the next few days (have been trying to do so for the past 4 weeks), but it is stubbornly hanging on to the door frame and refuses to go out into the world …

I am not a big fan of using DXF for tool geometry. However, I’m also a practical guy and realize that many of you use 2D layouts for tool design, and that’s the only data available. So we have a DXF reader in VERICUT that “attempts” to build a tool assembly from DXF.

There are some important rules to follow for successful DXF usage in VERICUT. I’ll lay out a few:

. Put each tool assembly component (holder, holder, cutter, cutter, etc) on its own layer.
. Better still, create a separate layer specific for VERICUT geometry, and ensure that geometry follows the restrictions of the particular VERICUT version you’re using (5.4 and earlier is very restrictive, 6.0 and later not so much). TDM uses the layers CUT for cutter profile, and NOCUT for holder profile.
. Make sure there are no forks in the profile geometry, .i.e. you can follow the profile continuously from start to end, with no ambiguity.
. Make sure insert profiles are closed and do not cross centerline.
. Make sure rotational profiles start and end on the tool’s centerline.
. Use the DXF X-axis as the tool’s centerline.
. Place the gage location of the tool at XY origin.

The reasons I’m not much of a fan of using DXF for tool geometry are:

. Creating 3D shapes from 2D geometry Is always a dicey proposition, unless the 3D shapes are very simple (like rotationally symmetric milling tools). Trying to do anything asymmetric in DXF, like turning tools, are a waste of time.
. DXF is inherently inaccurate. VERICUT tool profiles must be contiguous. DXF data usually has many very small gaps between adjacent geometry endpoints. VERICUT has code that attempts to fix this up, which is “mostly” successful, but not always.
. DXF inaccuracies also cause nearly, but non-tangent conditions at arcs. This can create a bad condition where what is meant to be tangent: a) does not contact, or b) intersects, creating a small unintended concavity. VERICUT also has code that attempts to clean this up, but the “near-tangent” situation is even more problematic than gaps.

If the small unintended concavities in tool profiles are not cleaned-up they can cause a reduction in VERICUT’s simulation speed (takes more time to calculate the material removals, collision checks, etc) due to the increased complexity in the geometry. In extreme cases they can cause material removal problems.

We’ve dealt with this junk for years and have invented many strategies to overcome the problems. But it is still a garbage-in/out kind of problem. And I’m sure we will continue to encounter new situations requiring new creative solutions. 3D tool geometry is critical to successful VERICUT simulations and we will always devote a good portion of our development resources to it.