Pro/Program and Windchill

[dmorg]

We are heavily into using Pro/Program along with Pro/Notebooks to drive large assembly model automation.

In the past we were told that Pro/Program and Windchill are not a good match for design iterations and modifications

and automation. (currently using CREO 2.0)

Does anyone know if this is still the case?

[TomU]

If I had to guess, I would say the concern probably has to do with models getting marked as changed (or modified) any time the upstream data is changed (when driven from Pro/Notebook, relations, etc.)  Windchill is going to flag anything that Creo marks as changed, even if the model has no visible changes to its geometry or parameters.  This same issue also occurs with shared references (copy geometry, merge, inheritance, etc.)  If the parent model changes in any way, all of the downstream models will get flagged as modified as well (assuming they're in session, regenerated, and saved.)  There are definitely ways to both manage and control this behavior.

Using automation to drive changes to objects that are new or that you want to change works fine.  On the other hand, if you want to use a "dynamic" assembly over and over again without creating copies but showing it in different configurations, you might want to look at flexible modeling (or family tables).  It's fairly straight forward to "flex" dimensions and parameters (even those that drive automation) to allow an assembly to appear different without actually altering the underlying original assembly.

[rmcboaty]

what are these pro/notebooks, mathCAD notebooks?

[TomU]

Think of them like drawings but with both parameters AND relations, and with the ability to link their parameters to the same parameters in other models (drive the model from the notebook.)  They used to be called layouts buy now they are called notebooks (even though they still have the .lay extension.)  They can only be created if you have the Advanced Assembly Extension.  You can read more about them here:  http://support.ptc.com/help/creo/creo_pma/usascii/assembly/asm/asm_three_sub/About_Notebooks.html#

[BrianMartin]

My reaction to Notebook has always been the same... RUN AWAY AS FAST AS YOU CAN!

I'd love to know more about the original poster's application. Over time the need for Pro/PROGRAM and Notebook has been severely cut with the advent of more flexible techniques which require less overhead and hassle.

[TomU]

Something I think would be really helpful is the ability to push parameter values down to other models in a clean, controlled, robust fashion.  The problem with layouts is that everything goes.  This includes any system controlled Windchill parameters.  Layouts would be much more useful if you could select which parameters you want to declare to each model.  I've made the suggestion to PTC product managers in the past that it would be really helpful to be able to add parameters to copy geometry features.  This way the values would propagate in a controlled fashion and you'd only get the ones you want.  (Yes, I realize you can do this with relations, but it's not as easy, robust, or apparent to the end user.)

[BrianMartin]

Here, here, Tom! I think this is a great suggestion.

Setting a parameter at the top and being able to push it down intelligently would be tremendous. I have a current application where I'd like to set a common sheet thickness through numerous levels of components and assemblies. To drive this from the top with relations is untenable. I could never assume future designers would understand the models or my design intent. The technique is too opaque and rarely understood by even most experienced users. Therefore, it is too risky to use. The slight gain I'd achieve in the short term would evaporate when future designers struggle to understand and flex my model.

Leveraging Notebook to push down parameters in lieu of relations would, at this point, be an even worse solution. However, if Notebook were changed to be less cumbersome, I'd certainly consider it!

For now, I've used a very carefully controlled top-down skeleton design. Generic requirements like sheet thickness flow down from the top through several layers of skeletons. I don't "love" the approach - but it makes sense and can be more easily understood by future designers. I've added some annotations to help document how the model works.

The setup wasn't fun - but the results are certainly impressive.

[dschenken]

There must be more to this story.

So nothing to the story. OK.

[vzak]

Few thoughts on the topic above , sorry for late comment.

1. Usage of Pro/PROGRAM to push parameters from the top to bottom (I suppose using EXECUTE statement) definitely revision the model in WC. Still there should be a control possible over this this i.e. EXECUTE command can be put under additional IF condition. So that upon regeneration one can decide to execute certain model Yes/No. This can be done both via regeneration interruption, or by loading pre defined parameters file i.e. controlled by supervisor. Not saying this is simple - but request of that level of control is not simple by definition.

2. Notebooks : here indeed all global parameters will be pushed, no news on this one.

3. Still if you require more intelligent and fully controlled way of top-down propagation of parameters - you can use classical CopyGeoms for this, utilizing nice feature that CopyGeom copies surface / curve parameters along with entity itself. So you can create special "parameter holder" geometry at a top level skeleton (name it appropriately) and Copy it to lower levels by dedicated Copygeoms, named say "PARAM_PROPAGATOR".

If it is important for you to have these parameters at a model level (and not at a quilt / curve level) this can be done by a relation MODEL_PARAM_A = COPIED_QUILT_PARAM_A.

Then controlling these copygeoms dependency you can control top/down propagation of these parameters straight forward. This control is simple and visual by adding "Update Control" tree column.

Hope this helps,

- Vlad