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

Pro/Program Best Practices

SOLVED
Highlighted
Regular Member

Pro/Program Best Practices

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

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Pro/Program Best Practices

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!

View solution in original post

14 REPLIES 14

Re: Pro/Program Best Practices

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.

Re: Pro/Program Best Practices

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. 

Re: Pro/Program Best Practices

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.

Re: Pro/Program Best Practices

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!

View solution in original post

Re: Pro/Program Best Practices

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

 

 

Tags (1)

Re: Pro/Program Best Practices

@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++.

Re: Pro/Program Best Practices

While I appreciate all the good replies I got on this post, as I'm getting deeper into this project, I'm starting to see the benefit of using execute, especially since I'm using lower-level pro/program to suppress components/features in subassemblies/parts. Once those parts are suppressed, it sometimes causes issues with the top-level relations that are driving those parts, though I haven't been able to pinpoint why exactly it causes those issues. I haven't noticed any of this locking up yet either, though I'm only passing about 50 parameters down maybe 3 levels, tops. I've basically decided that as long as I put my relations in a logically appropriate place, it shouldn't be too hard to find them and manage changes to this design in the future.



I agree on Notepad being rough for text editing, and I actually started looking into trying to incorporate Notepad++ in this process yesterday, since I already have familiarity with it for python coding. It'd definitely be helpful to be able to collapse the ADD/END ADD sections so I don't have to scroll endlessly trying to find the feature I'm looking for. Nitro-Program looks like a cool little app to use for this if I ever get into a more complex project. I'd never heard of it, so that was very good marketing targeting, if I do say so myself.


Re: Pro/Program Best Practices

This is what we use...

 

Notepad UDF Folding.png

Re: Pro/Program Best Practices

This is excellent, thank you. I think I'm going to mark your first reply as the solution, because I've decided to use this method for this particular project, but all replies were helpful and I may end up using the Notebook and other suggestions at some point. 

Announcements