Skip to main content
C
cwilkes1-Visitor
1-Visitor
October 11, 2019
Solved

Pro/Program Best Practices

  • October 11, 2019
  • 3 replies
  • 10086 views

I'm getting into a fairly complex assembly using a combination of Pro/Program and Relations. This is the first time I've gone this deep into a model using assembly-level Pro/PROGRAM, so I'd like to know if anybody has any tips or best practice advice for using both P/P and Relations together.

 

For instance (and my main question), is it best to write relations in the top assembly that drive features in lower-level subassemblies or parts, or is it better in the long run to pass parameters down to lower levels through the use of EXECUTE statements? I can see merit to using either way, but I'm hoping to avoid running into unforeseen problems in using one way over the other. 

 

FYI, I'm using top-level parameters to do two things mostly: 1) Drive lower level dimensions and 2) drive lower-level conditional statements (if/then/else) within Pro/PROGRAM.

 

Thanks in advance

Best answer by HamsterNL

We are using EXECUTE statements exclusively in our designs.

 

We put all our relations at the "top-level" of an assembly or a part, not burried somewhere in a feature (or even worse, inside a sketch!).

 

It takes some time to build a model driven by EXECUTE statements, but you can reuse (sub)assemblies and parts much, much easier. You just duplicate your entire assembly and change the INPUT parameters...and you're done!

 

If you have any specific questions, let me know!

3 replies

T
23-Emerald IV
TomU23-Emerald IV
23-Emerald IV
October 11, 2019

As I understand it, under the hood there is really just one big table with all of the parameter (and dimension) values.  It doesn't matter which feature or set of relations is changing the parameter values, they're really all changing the same thing in the same place.

 

Now there can be a significant difference in behavior (and sometimes performance) depending on where your relations are placed.  If you have multiple features that depend on a parameter (or dimension value), changing this value after some of the features have already regenerated will cause them to regenerate a second time.  If at all possible, you want everything to only regenerate once.

 

I am a huge fan of placing the relations that control a feature inside that specific feature.  Relations inside a feature will execute every time that feature is modified.  This means if your're changing a feature's dimension, you will instantly see the impact of the relations every time a value is changed.  The behavior is not the same if the relations are located in some other feature or in the top level model.

 

If there are lots of inter-connected relations/calculations that need to happen, I'll place those in one of the first features and then create parameters in that feature that subsequent features can read from to get their specific values.

 

Disclaimer:  I've never used EXECUTE statements for anything.

    C
    cwilkes1-VisitorAuthor
    1-Visitor
    October 11, 2019

    Thanks for the reply, Tom. I'm with you in liking how lower-level relations keep things nice and neat (and tend to require less commenting in the top-level relations for them to make sense to another user); however, I've had problems from time to time finding exactly where the relation is that's driving a dimension. It's a give and take, for sure. For this model, I've decided to mostly go with top-level relations (aside from simple sketch-level stuff like dX = <parameter>/2, or what have you).

     

    I see that you haven't used EXECUTE statements before, but just to clarify my question a bit for other users, my main question is about which way I should go in this situation: 

    Let's say I have my top-level assembly called BUILDING with a parameter called HAS_HANDLE in it. Now, there's a subassembly within BUILDING called DOOR, which may or may not include a part called HANDLE in it. I would like to use the HAS_HANDLE parameter to create an IF statement in the Pro/PROGRAM file for the DOOR assembly. I could do this one of two ways:
    1) Add a duplicate parameter in DOOR also called HAS_HANDLE.

    Add a relation in BUILDING like "HAS_HANDLE:0 = HAS_HANDLE" to fill in the DOOR-level parameter.

    Then in DOOR-level P/P, add essentially this:
    IF HAS_HANDLE

    ADD PART HANDLE

    END ADD

    END IF

     

    2) Add to BUILDING-level P/P:
    EXECUTE ASSEMBLY DOOR

    HAS_HANDLE = HAS_HANDLE

    END EXECUTE

     

    Add to DOOR-level P/P:
    INPUT
    HAS_HANDLE Yes_No

    END INPUT

    ...

    IF HAS_HANDLE

    ADD PART HANDLE

    END ADD

    END IF


    (By the way, this isn't my actual example, so please just take my word for it that the hierarchy has to be arranged this way, despite it looking like HAS_HANDLE should maybe just be a parameter in the DOOR assembly)

     

    Both do essentially the same thing, but I wonder why the EXECUTE command even exists if it's so much more cumbersome than relations. I figure there has to be some benefit to using it. 

    tbraxton
    22-Sapphire II
    tbraxton22-Sapphire II
    22-Sapphire II
    October 11, 2019

    If you have not worked with Layouts/Notebooks, check them out. Layouts (Pro/Notebook) are intended to define parameters and relations within the notebook that then can be declared/undeclared to models. They are one of the top down tools intended to be used to manage relations and control other models. There is no requirement to include any geometry in the layout they can be comprised of relations exclusively.

    D
    DavidBigelow17-Peridot
    17-Peridot
    October 22, 2019

    Layouts/Notebooks create dependent relationships with whereever they are declared - hampering reuse of designs in other designs..  For this reason, we avoid them.

     

    Pro/PROGRAM can be awesome for some very well structured design automations, but they have their limitations and frustrations.   They are great for toggling feature logic within parts and assemblies - but can lock things up quite a bit if you start using execute statements to pass data from one level to the next (assembly top-down execution).

     

    It really depends on what you are trying to accomplish.  If you have family tables and are trying to switch configurations based on instance name - that is quite handy using variables within the Pro/PROGRAM.  But often the logic / input of the changes can be a struggle.

     

    Another HUGE problem is the "text editor" - it just is painful for editing Pro/PROGRAM - the bigger the more painful.

     

    If you have not checked it out - look for Nitro-PROGRAM - a graphical Pro/PROGRAM editor.  (Disclaimer: we make that product -- and use the heck out of it for our customers automation projects it saves a lot of time and headaches for debugging).

     

    To truly automate Creo we try to avoid all the Component/Session ID relations and pass the data directly to the model that needs it at the time using Excel.  But that is a whole different subject - it really depends on what your goals are for the automation.

     

    Hope that helps.

     

    Dave

     

     

    HamsterNL
    HamsterNL18-Opal
    18-Opal
    October 23, 2019

    @DavidBigelow,

     

    "...but can lock things up quite a bit if you start using execute statements to pass data from one level to the next (assembly top-down execution)."

     

    We have been building parametric models using EXECUTE statements for over a decade. We have never seen anything starting to "lock things up". In fact, we have increased the number of parameters which drive our assemblies to over a thousand, and still no problems.

     

    Could you elaborate your statement?

     

    "Another HUGE problem is the "text editor" - it just is painful for editing Pro/PROGRAM - the bigger the more painful."

     

    I have to agree, the standard text editor is just plain bad. That's why we recommend to use Notepad++ with a User Defined Language (UDL). Check this post "Notepad-User-Defined-Language-files-for-Creo-Parametric-and-Pro" 

     

    We have looked at Nitro-PROGRAM before, but for now we are sticking to Notepad++.

    HamsterNL
    HamsterNL18-OpalAnswer
    18-Opal
    October 14, 2019

    We are using EXECUTE statements exclusively in our designs.

     

    We put all our relations at the "top-level" of an assembly or a part, not burried somewhere in a feature (or even worse, inside a sketch!).

     

    It takes some time to build a model driven by EXECUTE statements, but you can reuse (sub)assemblies and parts much, much easier. You just duplicate your entire assembly and change the INPUT parameters...and you're done!

     

    If you have any specific questions, let me know!

    Terms & ConditionsAccessibility statement