I've just got around to setting up a tool library with solid tools and tool holders in WF2 (build M140).And I have a weird thing happening in vericut.
Within Pro/E I get the tool and the tool holder showing up in play path, while I get most of the tools and holders showing up in vericut. But..... on some of the tools I get no tool holder and strange spot drill type tools showing up. As far as I can make out the diameters are correct, but the tool geometry is wrong and the tool holders are not represented at all.
I've purged all old user files for vericut just in case there is an issue there, but still to no avail. Any ideas out there?
Many thanks in advance,
Steven Dibdin Design Prototyping Manager
Smart Design 601 W 26th Street, Suite 1820 New York, NY 10001
Steve, I had a long post dealing with this issue back in March. Look especially at the portion about tool geometry. Here is the Q&A from then:
RE: pro/manuf solid tools and Vericut 2006-03-17 16:20:00 <peterbrown77@...>
What experience does the collective mind have of solid tools in pro/M? I am trying to create a solid tool library to match the tools that we carry in stock here, and also setup all the associated 'bits and bobs'so that it all works smoothly. So far the thinking goes that we will have a library of standard cutters, and a library of standard holders (currently use 3 types in the business). Each job will require assembling the right cutter, with the right holder, and also a 'shank' part in between the cutter and the holder. This is of course all a matter of family tables, and not really the thrust of my question, although if anyone is willing to share any experience I am all ears.
The problem I am having specifically is that the tool holders are not being pulled through into Vericut. PTC say that you must specify a parameter VERICUT_TYPE = holder/tool to distinguish between the cutting part of the tool and the non-cutting, hence the need for the 'shank'part of the tool.
Has anyone had this problem? Or better yet managed to solve it? We are running wf 2 M180 and vericut 5.4.5?
We use solid tool assemblies in Pro/NC exclusively.
Each tool holder has its own model, complete with shank and mfr's description, so there are more like 130 holders and not 3. This means about 40 holders for each shank size that we use (CAT40, CAT50, BT45).
The cutting tools themselves are generally family-tabled. These encompass drills, end mills, face mill, taps, reamers, etc. I used the PTC library as the basis for them in most cases, picking a model and making it a generic. Again, the each instance has a parameter which contains the mfr's part number for ordering.
There are also ProE models for bits and pieces like pull studs, collet nuts, tap extensions, etc. Family tabled where possible, but not necessarily.
From this mix of hardware it is possible to build pretty much every tool we need. When we create a tool assembly, we assign it a number and keep it in our library for future use. Also a small assembly drawing is created with a repeat region so that the crib knows exactly what we expect for components and assembled length. Intralink makes this job bearable. There are currently about 900 tool assemblies in our database. I export the descriptions into Excel and publish to PDF so that the programmer can just look in the 'big book' (electronic, really) when he wants an M6 tap and find the tool assembly number, enter it into the Tool Manager, read in the speed/feed data from the tool database and then create his sequence. No need to stop and assemble tools, which is going to get old fast. Of course you need first to make the assemblies, but why do it more than once?
Now, getting to the crux of your question:
"Why do the holders not go into Vericut?"
First of all, it is true that you need to assign the parameter VERICUT_TYPE to HOLDER for non-cutting components. This isn't stopping the holder from converting to Vericut. Vericut assumes everything is CUTTER unless told otherwise, so you don't need to explicitly set the parameter for the cutting tools themselves. This only means that Vericut will stop and warn you when the holder hits the workpiece. It will always warn you when the cutter hits the fixture; cutters are SUPPOSED to hit the workpiece. That is all that VERICUT_TYPE does. So if you didn't assign the VERICUT_TYPE parameter, you would always be warned if the tool hit the fixture (a no-no for both CUTTER and HOLDER) but not be warned if the tool holder/collet nut/tap extension hit the workpiece. An AUTO DIFF gouge analysys would show the problem later on.
Secondly, not only is your holder not converting into Vericut, you tool isn't either! Once a component in the assembly fails to convert, Vericut 'gives up' on trying to do the rest of them and simply creates a solid of the parameter tool from ProE. What you are seeing in Vericut's Tool Manager is the parameter tool.
The REAL problem you are having converting the holder is that Vericut is very sensitive to the tool geometry it will accept. Essentially, ProE sections the model through the Z axis and Vericut attempts to make a revolve of this section about the Z axis of the tool. This section MUST be 'open' at the centerline, meaning there can be no through holes in any of the geometry (cutters included). A thru hole would create a closed section offset from the revolving centerline. Therefore, your collet nuts should be modelled as slugs, etc. Avoid geometry that "doubles back" on itself like the pull stud hole (sometimes it works, sometimes it doesn't). Avoid very tiny edges, setscrew holes, etc. Don't add setscrews to Weldon holders since they will fail because they cannot be revolved around the Z axis of the tool. Model your components in such a way that, while they should be geometrically accurate for collision avoidance, they do not create complex curves when sectioned. I mean, you don't REALLY need the key driver slot in the CAT flange. You don't need the vee in it either!
We handle all the miscellaneous hardware (collets, inserts, etc) by creating family table parts with no geometry except for the default datum planes. The family tables are just the parameters for purchasing. We then add these to the tool assembly using Insert>Include (I think you need AAX or APX for this). We just include it as many times as there are instance of the insert, for example. This way the tool's assembly drawing shows the correct insert and quantity for ordering in the repeat region table. Put these components at the end of the model tree in the assembly, because (remember?)Vericut stops converting at the first failed component.
The last thing you need of you want to use Vericut's Machine Simulation (assuming you bought it separately, it is not part of the 'base' ProE Vericut license) is the parameter GAUGE_Z_LENGTH. This lets Vericut assemble the tool holder to the spindle correctly. Ours is tied via a relation to a sketched curve in the assembly tying the gage line to the TIP csys. This allows the GAUGE_Z_LENGTH to be parametric.
All this applies to milling tools only; turning tools are converted by projecting the tools outline to 10% of the LENGTH parameter in thickness, making for some strange looking holders.
Steven, I had a similar problem with vericut at one point, and it had to do with cutter comp. Try running the same tool path without cutter comp to see if it affects your graphics. It's not a fix of course, but it might be part of the cause.