Creo Parametric Notebook (formerly Layout) keeps track of dependents

[jeffreyrwalker]

Does anyone know why PTC has chosen to have a Creo Parametric Notebook (formerly Layout) keep track of those objects (parts, assemblies, etc.) that are declared TO it?

It seems to be without benefit (and full of problems) for the notebook to store the names of objects that have been declared to it.  Those objects are children of the notebook.  Wouldn't it be similar to a part storing the name of every assembly to which it has been added?

When you use a set of files containing a notebook to "seed" another project, and you are in a Windchill PDM Link environment, the notebook "remembering" previous objects that were declared to it becomes problematic.

[davehaigh]

This is no different than adding models to a drawing. The drawing retains the information about what models it contains.

When you declare a model to a Layout/Notebook, the dimensions and parameters of that model are now available to be controled by the Layout/Notebook.

How do you propose to reuse a Layout/Notebook on a different model, that likely has different dimension names you would want to control?

I suppose if all you wanted to control were parameters, then what your suggesting might work.

[jeffreyrwalker]

@davehaigh, I certainly missed that functional aspect of notebooks and global declarations.  Yes, all we currently are controlling is parameters.

I see drawings as CHILDREN of parts/assemblies, don't you?  I thought Notebooks would be at the top of the hierarchy, thus a child of nothing (with the exception of another notebook to which it may be declared).

Assemblies can manipulate parts via relations but assemblies are children of parts.  If the assembly is not in session, the part acts on its own volition, so to speak.  Once the assembly is loaded into memory, it can cause the part to act differently.  The part doesn't keep track of all the assemblies it is part of (at least I don't think it does) so why should the notebook keep track of all the parts that are declared to it?

[DavidBigelow]

Notebooks are a special case relative to relationships... they are BOTH parents and children of related parts/assemblies at the same time.

We try to avoid using them as they overly complicate understanding of relationships when dealing with models that need to be driven by other input sources (e.g. declare/undeclare has always been a pain to deal with and manage).

This is also part of why we created Nitro-CELL back in the day - to avoid these Independencies and more easily manage the logic and flow of data without the odd dependent relationships.   Specifically - allow individual master models to be reused and manipulated by other Excel Worksheets (like Layouts) - without the whole declare/undeclare cycle - or just use a completely different Excel Worksheet to drive the same core design (e.g. USA version vs Europe logic).

Just my $0.02 on this.

[dschenken]

I never noticed that it did contain that information - though for certain Windchill will note all the links to it and try to drag them along. Does a declaration fail if the Notebook/Layout gets marked read-only?

[jeffreyrwalker]

You can declare objects to a notebook that is Locked (read-only) in the workspace.  You simply get the message, as shown:Objects can be declared to a Locked (read-only) Notebook.

As a matter of fact I was wondering if it might be good practice to check in a new notebook, then Lock it, before you declare objects to it.

@dschenken, do you think my analogy of parts keeping track of every assembly they've been assembled into is appropriate?

I wish someone from PTC would shed some light on why notebooks keep track of their dependents.