Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
MIchael,
I do not believe I will answer your question directly, more likeI'll share myexperience and opinionthat may give rise to your own with regard to TDD related to Pro/Program related to relations.
I think you are in the midst of the age old issue of too much power when it comes to Pro/E's functionality. In a sense, it's not a matter of "could you do it", rather "should you do it". As is any return on investment, there is a point of diminishing return. I hold to the belief (years of pain in the making)that writing convoluted relations driving skels and/or some other type of "voodoo and magic" within Pro, for the sake of coolness and automatic results,is a losing game. The power to do it is certainly there. But when the productivity dips due to multiple hidden regens, where is the value? Don't get me wrong...I love and use the "magic" every day...just wisely.
I contend that keeping things relatively simple and explicitis the way to go. Somehow, some way, sombody is going to miss a regen, invalidate a Program, delete an equation etc.... that will make life difficult for some.Keep in mind the varying programming logic skills of your user base. If you win a trip to Fiji or win the Lotto and are out for a month...what happens? Not everyone will have a grasp of and be comfortable driving geometry with logic and equations.I am not saying do not use it. Just use discretion with the functionality and power.
Hope it helps.
I totally agree with Dean.
Relations can do a lot, but are very limited when it comes to more complex programs. You end up with monsters which even You don't understand after a while. I know one of those engineers...
We use JLink and WebLink to do the more challenging computations (which is much easier if You have an OOP language like Javascript or Java) and just exchange parameters from and to the remaining relations - most of which are just left to ensure a valid topology in case of manual regenerations. This leaves only one final regeneration, at least in most cases. If geometry updates have to be recalculated, multiple regenerations can be performed without user interaction.
The only drawback in this approach may be that logic and graphical representation are separated. However, these external programs can easily be reused even for different assemblies.
Also remember your Parent/child relationships and/or external reps can and will have an effect on regens. If someting is referenced up the food chain at any point, Mr. Pro/E is going to go look for it.
Look for any geometric links that are referenced once you have all the relations sorted out if it's still acting squirrely.
AND...Beware the Circular Reference! You can bring one of those little Nasties about in a real hurry with embedded logic and have a very fun hair pulling session untying the knot.