Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

Component Interfaces?!?


Component Interfaces?!?

Ok - I am going to ask a really dumb question about Component Interfaces.


I have noticed that if you define MULTIPLE Component Interfaces with the SAME Reference Types (e.g. Axis and Surface References) defined in a model.... Creo can be too greedy/generic in their presentation as options.


So.... When you go to place a component using an Interface-To-Interface Type....  Creo will automatically include ALL of the possible Component Interfaces (even if they are a different name?!?).... This seems to be dependent on the Reference Types defined vs just the Component Interface Names?


2020-08-19 at 11.12 AM.png


Is this really how this works.    Or am I not seeing / overlooking something.


I would have thought -- Assemble BOLT_AXIS in One Part would automagically only be constrained to the SAME Component Interface NAME in the target Assembly?  But this appears to not be the case - or is there another way to make that happen.  There appears to be no way to force / limit selections between two models via Interface Names - only the thing you are assembling?


We address problem  typically by using NAMED Coordinate System References... which work great...   We can wildcard the assembly of those in Nitro-CELL ... easy to do.   For example:



Also - I noticed that ONCE a Component Interface is consumed/used... they are no longer offered as options for later components?!  I guess I can see that thought process... but if you have a common reference for multiple components that need to be assembled (which is pretty common in my experience)... it does not appear to be possible.


Eager for some feedback on this... Thoughts?






You're correct in assuming that the "name" of the interface actually doesn't really affect the performance of component interfaces.


To help "limit" the list of possible options... have you tried looking into the component interface "Criteria"? This sounds like what you're looking for.


Essentially, this helps enforce rules to what possible mating interfaces are allowed. 




We use these with our Toolkit applications/automation to help define mating conditions for bolts, electrical connectors, etc. 


For example, we make it so that an Interface on a box for a DSUB connector (using the coordinate system) can only mate to another coordinate system feature of a certain name (aka "CONNECTOR_MATE"). Or better yet, by checking against a parameter on the mating feature.


My personal recommendation - try to also define each interface specifically as "Placing" or "Receiving". This helps when helping enforce the assembly constraining reference structure.




James Sullivan

President & Founder
CadActive Technologies -

Yea - we do something similar (more controlled / specific) with Nitro-CELL also - but have kept to naming conventions and wildcards for assembly to Coordinate Systems vs parameterization of a feature as the match criteria...  It could be done either way - each approach has its merits based on application.


Component Interfaces seem more useful for user interactions / decisions vs what I was thinking/hoping.  More Ad-hoc usage vs planned-for interfaces.  (I can TOTALLY see why PTC would implement that way....)


It just seems like Component Interfaces *should* work like Interface-Name -TO- Interface-Name constraints by default... vs the one-sided implementation and ALL compatible target possibilities.


Needs more research / thought on my side...  to see if a happy medium can be found ... it has some distinct benefits when used -- but also some surprises (reusability of already used interfaces can't be done apparently).




I don't fully agree with your statements : What happens if you component, either part or assembly, has two component interface to accept the positioning of additional comonents, e.g. one on the left and one on the right ? The component interface of the part added will be used twice, and the 'receiving' component interfaces will be e.g. INTF_LEFT and INTF_RIGHT since they will require different names. I sometimes tend to add datums (usually coordinate systems) and subsequent component interfaces that can be used to position more than one component. I like to place a gasket and a closing flange on the same component interface, so it should remain available after I have placed the first component. Statements above are of course valid for out-of-the-box usage, and may not be applicable when using other additional software.

Ah - in that situation - I think it is better to have a bit more logic to your process to handle it.  It is a setup problem for the automation.   Instructions for assembly operations in a sequence using named references.   The Interface capabilities in Creo become a bit cumbersome at times... They work, but sometimes you need to be more specific - standards for how you are automating things become very important no matter which direction you choose.


This is why we place a very high priority on the design and naming of interfaces... We try to encourage a viewing parts and assemblies as a box of legos - you don't care what they are, but if you can define and classify interfaces and how they work together, they can be easily organized and sequenced more freely (in our case - an Excel sequence of operations and events is much more configurable process once you have a classification and interface structure defined) - less "user clicks" is the goal).


In your situation having a INTF_LEFT and INTF_RIGHT ... within Nitro-CELL we would just use the same INTF_(Suffix) to distinguish the placement based on logic external to the model (e.g. Excel placement reference name for the final placement).  


Within Nitro-CELL - that journey to placing parts/assemblies/both on common references or specific is pretty straight forward - assuming you have planned for the naming of them (CSYSs) in your design / workflow.  Data-Centric approach is the goal (e.g. how do you transform a text file [e.g. enterprise bom] into a final product quickly).


Hope that is more clear.

Top Tags