I want to create a library part of a screw, as a skeleton. The screw geometry will then be copied over to another part via copy geometry, with a specific length to suit the design need. How do I allow the user to adjust the length each time the geometry is copied over? I tried using pro/program with an input prompt on the length but it will prompt for the length input each time it's regenerated, not good. I just need the length input once, how to do it? Thanks for your help.
Yes, Family Table is one way and it's easier to deal with. But the table can only cater for predefined lengths. In my case, I would like the length to be a variable and to be set by the user prior to the copy geometry. Any idea?
I've found, the hard way, that having only predefined lengths of screws and other fasteners is the way to guarantee that only available hardware is being used by designers. Otherwise, I end up with the (not a hypothetical situation) use of things like 13mm long M6 screws, or 2mm long 4mm diameter dowels (?). And it's not just with regards to dimensions, but also materials; an M6x1.00 may be available at 14mm length in steel, but not with a zinc plating, etc.
I tried using pro/program with an input prompt on the length but it will prompt for the length input each time it's regenerated, not good. I just need the length input once, how to do it? Thanks for your help.
You could try this. Your part will need to have a default length of 999. If you regenerate, PRO/Program will ask for input because ASK_FOR_INPUT is YES.
As soon as you enter a different value, ASK_FOR_INPUT will become NO, and PRO/Program will stop asking for input.
VERSION 4.0 REVNUM 527 LISTING FOR PART PRT0001 INPUT IF ASK_FOR_INPUT == YES CUSTOM_LENGTH NUMBER END IF END INPUT RELATIONS IF CUSTOM_LENGTH <> 999 ASK_FOR_INPUT = NO ELSE ASK_FOR_INPUT = YES ENDIF END RELATIONS
ASK_FOR _INPUT is just a user defined parameter (type YES_NO), so you can name it anything you want. 🙂
You might need to create that parameter first before putting all the other code in.
In the end, you can simplify this to:
INPUT IF CUSTOM_LENGTH == 999 CUSTOM_LENGTH NUMBER END IF END INPUT
So you won't need the ASK_FOR_INPUT parameter, nor any code in the RELATIONS.
Then save your part as a Start Part.
If a user want to use that screw, he starts a new part, deselects "Use default template", then selects your start part. After the new part is open, he can regenerate the part and enter a length for CUSTOM_LENGTH. He can then save the part.
Your only problem now is how your users will name that screw 😉
Thanks, this works to a certain extent.
The screw skeleton that I have needs to cater for different lengths depending on the design scenarios and may end up 2 or 3 types but only different in length for a same project. I want to make that skeleton as the generic just like the way how family table works.
You are right, if we generate from a template and store them separately then there won't be any relation between them.
You suggestion is still helpful and I will think how to make use of it.
Another thought would be to use an inheritance feature instead of a copy geometry. In an inheritance feature, you can allow certain items to vary, so the screw could be modeled complete as the generic and each inherited model would allow for the length to vary. Not sure how you'd integrate a prompt for length in there, but editing one feature isn't that difficult.
I would tend to agree with @KenFarley, however. A predefined family table with specific screw options may be better. This will prevent specifying screws that don't exist and can encourage your designers to limit themselves to the screws that you typically stock.
A predefined family table with specific screw options may be better. This will prevent specifying screws that don't exist and can encourage your designers to limit themselves to the screws that you typically stock.
We have added an extra parameter to our fastener called STANDARD (YES_NO)
With this parameter, we can define which instances of the family table is considered standard.
By using a mapkey, our users can quickly place a fastener (screw/bolt/nut/washer/etc.), and the family table will be "filtered" by this parameter.
If a fastener is no longer considered "standard", we can set that parameter to NO. That will also display a large cosmetic in the instance, a visual reminder that a non-standard fastener is being used
P.s. if we ever re-create our fasteners, I will change that parameter to a NUMBER. Why? Because the lookup_inst function of Creo does not accept YES_NO as an input.
Coming in after many suggestions with my $.02.
The problem I see with the pro/program, copy geom or inheiritance features is that you have to do a save as when done to capture the length for future use. Unless you have a defined method of naming hardware, designer A names the 3/8-16 x 1.000 Zinc plated one way and designer B uses the same part but names it differently. Now you end up with many parts that are identical. The flexible part always uses the generic for its base, but you have to stretch each item every time you use it. You also have no control over the length that a designer may use and they may use a non-standard length.
I am a fan of family tables. They allow you to build every combination of standard lengths into the table and each has a unique part number that can be searched for and reused. Adding a Standard column may be desirable but that also leads to more modifications of the family table when lengths get added or removed from your standard length usage. I built my family tables for socket head cap screws to be all diameters from #0 to 1-1./2 and lengths up to 6". I used both Fastenal and McMaster-Carr catalogs as my references for the standard available lengths. It gives the designers a nice range of parts to select from and very easy to change if they need a longer or shorter length. Our finding is that seldom does a designer increase/decrease the diameter of a fastener, but it is just as easy to replace that too.
To prevent random text being assigned to the fasteners I've adopted a "build the text" approach, where the stuff that gets put in the description column of a bill of materials (I call it DescriptionBOM) is built based on the dimensions of a particular instance, like "M6x1.00, BlkOX, 20MM LONG". It took a while to define, but with 100s of fasteners it's saved me tons of time every time I need to add a bunch of new instances for a project.
That is also a good reason for using family tables. You can control the text in the description fields that go in to the BOM text. My diameter, thread, length and finish are all derived from parameters that are carried in the FT. Change one and verify the table and everything is updated.