Family Table Mixed Units

[wfalco]

Is it possible to have mixed units in family tables?

[Mahesh_Sharma]

Could you explain this in detail?  

[wfalco]

Please see my response to:

dschenken

[dschenken]

If you mean, can some instances have different units from other instances, then I believe the answer is no.

If you mean, can some dimensions in models have different units from other dimensions in the same model, then I believe the answer is no.

PTC allows parameters to be assigned a unit so that changing the base unit of the model will not change the scale of the parameters that have related units set, but I believe the units for parameters cannot be changed by family table.

I have had occasions when having units applied explicitly to dimensions within individual models would be handy (metric threads on an otherwise English unit part, for example) but it doesn't seem that the Creo file format supports this sort of mixed unit application.

[wfalco]

Pretty much as you say.

I know I can enter materials into family tables. This works nicely. This utilizes a PTC parameter. I thought maybe a similar approach would work for units.

The bottom line is that I'd like an instance to either have mm or inch characteristics.

For example if I wanted to mix English screws and metric screws in one table. I think my best logic for this is replacing models easily.

[HamsterNL]

I would create two different family tables (one for metric, one for imperial), then create an Interchange Assembly and map the Reference Tags for the constraints.

I would also add a Component Interface to the bolts, and add that Component Interface also as a Reference Tag in the Interchange Assembly.

[wfalco]

Ahhhhhh now I had that in the back of my head. I am not very familiar with interchange assemblies. But I needed someone to tell me that makes sense. I will now do some research on this. Thanks so much!

[HamsterNL]

We have gone overboard with our Interchange Assembly (IA)

Our IA contains 40 different Family Tables (20 different bolts, but also nuts, washers, caps and plugs), all constraint with the same Component Interface.

The end result: we can swap any bolt for any other bolt...or nut...or washer...or plug if that matters, with no constraints failing.

[wfalco]

I have envisioned this possibility. That is total bad ass!

[HamsterNL]

Another benefit of an Interchange Assembly:

If you ever need a new bolt, you just add the bolt to the IA, and that bolt is "instantly" available to all your users (after they updated their IA in their workspace).

[wfalco]

I think I know what I will be looking at tomorrow.

Any downsides at all to your setups?

[HamsterNL]

The one downside, when you are retrieving a bolt, you are also retrieving the Interchange Assembly, thus also all the bolts/nuts/washers/etc. into your workspace.

But maybe there's a (Windchill or Intralink) setting which controls that? Never bothered to look into that 🙂

[wfalco]

Hmm. That is understandable. Not sure if that bothers me. Only if it caused a slow down.

[KenFarley]

I have created screw family table parts, for example socket head cap screws (SHCS) that cover both metric and english sizes. What I had to do was initially not a lot of fun, but it works really nice now. My model is defined with inch units. I have a set of parameters that define the characteristic dimensions of the screw, like diaThread, htHead, diaHead, sizeHex, etc. These parameters are the entries in the family table. They are ostensibly in inches, but are treated like they are unitless. I have another parameter, isMetric, that is a boolean indicator of whether the instance is metric or not. The actual part geometry is defined with dimensions that correspond to the "unitless" parameters. I then use relations to calculate the instance dimensions based upon the defined parameters. Here are the relations I use for the geometry in my SHCS model:

IF ismetric
  diabody      = diamajor        / 25.4
  dhead        = diahead         / 25.4
  lenunderhead = lengthunderhead / 25.4
  sizehex      = sizehexkey      / 25.4
  hthead       = thkhead         / 25.4
ELSE
  diabody      = diamajor
  dhead        = diahead
  lenunderhead = lengthunderhead
  sizehex      = sizehexkey
  hthead       = thkhead
ENDIF

You might wonder why I would go through all this stuff. I used to just have the actual geometry dimensions in the family table, and would dutifully calculate the inch equivalents of the values for the metric instances, but it was massively error-prone and tedious. Plus, with all the parameters defined in the "native" units for the instance, I can build a nice description (that will be used in Bill of Materials) that reflects the size, thread, and length that is actually defined, not a "dumb" entry typed in the table. There are a lot of other relations to do this, but I'll not make this post any longer for now.

[wfalco]

Ken,

Wooot! Nice!

My next thought was relations.

I too thought of tediously entering converted dimensions. Then you realize 2mm = 0.078740157480315. Eeee! But how would this handle units for weight?

I like this.

Thanks for the suggestion.

I am formulating ideas for starting libraries. But I want to go into it doing my homework. I want the most flexible, yet non-problematic approach.

We add weights to out drawings. Does this all work out in properly reporting weights based on materials and units?

Wayne

[BenLoosli]

Rather than put the 'static' columns in the family table, I use a relation file that has the fixed parameters so I only need diameter of a screw and its length, plus TPI and thread class.

If nominal == "1/4"

diameter = .250

hd_dia = .625

Hd_hgt = .375

hex_dia = .188

Hex_deep = .125

end if

Not actual values, but you get the idea. Look at the spec sheets for hardware and pull out things that are fixed for a size of fastener and put them in relations.

As to weight, you need to do it special. You need a feature for the mass and then put the weight = featureID in your post-regeneration relations, not initial relations. There is a thread that gives the steps.

https://community.ptc.com/t5/Creo-Modeling-Questions/Family-Table-Weight/m-p/273477

read the final reply which is how it works.

[wfalco]

I like!

You guys are coming thru.

Thanks Ben.

[BenLoosli]

As to putting imperial and metric unit fasteners in the same file, I would question that logic.

Normally when you need to replace a fastener it is because the length is wrong, not that the fastener should be metric instead of imperial units. What real advantage do you get by having both in the same family table.

I have also separated all of my family tables by material so I can get 'better' weight calculations and use a color for each material. Metric bolts may be A2 or A4 but imperial bolts might be SAE J429 grade 5. We have a need to put that in the description lines, so it becomes a requirement to separate them.

The description lines are also relation driven. I may have 1/2-20 UNC X .750, Black Oxide as my description line. This is built using relations and the diameter, thread, class, length and finish parameters, in my case.

It does take some extra work up front to get all of the variables you need, but it makes it easy to add items to the family table when you8 get them right.

Another thing I do is to rename the feature names to be my parameter names. This must be done before adding the relations. so if I create a bolt thread with d0 length and d1 diameter, I will go into the properties of the feature and rename d0 to length and d1 to diameter. My relations will then have things like hd_hgt, hd_dia, hex_dia, hex_dp, etc.

[DPeters01]

I'm impressed with all the ingenuity here. Definitely need to let this seep in.

I can understand the thinking of simply swapping lengths or threads in same unit. Generally I'd say 60 per cent of the time that happens every time.

[HamsterNL]

---

@DPeters01 wrote:

I'm impressed with all the ingenuity here. Definitely need to let this seep in.

I can understand the thinking of simply swapping lengths or threads in same unit. Generally I'd say 60 per cent of the time that happens every time.

---

We are not only swapping different lengths, but also different types of bolts (using our Interchange Assembly).

So we could use hex-bolts when we are assembling our products to a steel construction, or a phillips screw when bolting into a concrete wall, or a counter-sunk screw when it needs to be flushed, or a self-drilling screw in another situation.

All driven by Excel ofcourse...I'm lazy 🙂

[KenFarley]

I build the descriptions from the various parameters, too. I can't recall what drove having metric and english in the same file, and now that you mention it, it probably would have been better to separate them out. That's the danger of making these decisions on my own, I guess.

I am all in on using relations to define as many of the descriptive and other parameters as possible - it prevents things being incorrectly described should anyone else add entries, including me. And I always rename the dimensions (i.e. d0 => length) so they represent what they are. It's a result of doing a lot of programming over the years. Gotta worry about the poor person who, in the future, is trying to decipher what's going on with your mathematical doings.

[DPeters01]

I'm all for making thing clear!