Implementation of ProE/ProI <BEST PRACTICES>

[patent_pen]

I would like see best practices on the implementation of ProE/ProI using 2001. If anyone has this information or other useful tidbits they would be willing to share, I would greatly appreciate it.



We are converting from I-deas 7. The general user population has little experience with ProE. A couple of people have run ProE back prior to Rev 18, so there is a little apprehension. I am very comfortable with ProE through 2001, but my experience on the new implementation side of the world is limited.

 

[bhayden]

Yikes, how many users? Is there one license per user for both Pro/E and Intralink? How much legacy work will continue with I-deas? Do you need to convert old designs or reuse parts from I-deas in Pro/E? What is the immediate work load? I think you need to outline the answers to these questions and use that info to establish goals regarding the implementation and change over.



As far as getting designers and/or engineers up to speed on Pro/E I'd recommend that they not start right in on a big colaborative project under Intralink control. The massive amount of rework and changes that are inevitable when learning the best way to implement a new tool will leave you with a big mess right from the start in the Intralink database. On the other hand, trying to go back and import a large amount of data can also be a headache.



Why are you switching to Pro/E? Did you previously have a PDM solution in place? Why 2001 instead of Wildfire? Supposedly Intralink 3.3 will be out next month and if I could avoid the inevitable change over down the road I'd most certainly take that route.



I guess I've thrown out a whole lot more questions than answers but I think they will provide a valuable framework on which to construct your plan.



Bernie Hayden

XKL LLC

 

[patent_pen]

I realize this is a little open ended so I will try to add some color.



Our licence useage will be 1 to 1 for ProE and ProI via licence server.



The user group is 'under-experienced' with ProE, that is they have heard rumors of what to expect from individuales that have run ProE prior to rev 18. Initally there will be 5-7 users (co-located) trained that will begin work immedately on a new 'widget' design. I-deas data will not be transfered, initally,1 for 1 into ProE via IGES or STEP due to loss of design intent, but some information could be transfered for reference.



Phase 2 of the implementation will include the training of 25 additional users that will begin work on new 'widget' designs.



The thinking at this time is that ProE will only be used on new projects. Legacy data will be maintained by the legacy systems until obsolescence.



I guessI am looking for things to avoid or watch out for as things progress . .



Thanks



We are going to be running 2001 since it is what the parent company is running. The switch to ProE is to gain productivity and a common engineering CAD platform with centralized company support.

 

[proed]

We've previously used SDRC/Ideas here with about half of our people (40+). Within a year, most have transferred over to Pro/E. Like you plan to do, we started by putting new projects on Pro/E. Eventually, a fair amount of legacy information has been remodelled too.



Recently I polled our users to check how often people use the different CAD packages. The results show that almost all users hardly touch SDRC now (a couple are still working with legacy).



In answer to things to watch out for - the main gripe people have is: SDRC was great for doing quick 2D layouts. Pro/E often falls down in this area. You have to think ahead too much...

I would recommend you get your people trained how to develop sketches, skeletons, etc in Pro/E, so they can still work productively.

As with all progress, the change of mindset is a major factor here. Once they start thinking Pro/E they'll be much happier...

 

[swcalvert]

Well, patent_pen, I'm in the same boat as you, only with 10 UG users that have little Pro/E experience. We have just finished our installation of Intranlink 3.2 and will be starting new design work in 2001 (only because 3.3 won't be out until next week, maybe we'll wait for 3.3 so we can just jump right into Wildfire). If you're not familar Intralink, I'd suggest you take the Pro/Intralink Admin class. This class takes you through areas you need to become an Intralink user/Admin.



As far as data translation, I'll export parasolid UG data as required, but we'll be doing some re-modeling in Pro (which is a good way to learn it) for components needed.



Steve C

 

[patent_pen]

proed,



Here we do not use 2-D layout at all. We create models / assy's and detail them out(70% sheetmetal). Many pieces of geometry such as hole patterns (~100+) are all drawn in as 2-D enities. As you can image this is a huge time burden on top of the fact that there are no parametrics, so updates are a redraw of the drawing.



I have noticed some similarities between I-deas and ProE when it comes to geometry sketches. Constraints and assumptions are similar to that of ProE, but interpreting what constraints actually mean is very difficult in I-deas.



Since changing what people think is one of the most difficult tasks, how did your transition deal with users that were thinking I-deas and running ProE?





Our user group only has experience with I-deas so they see this change as moving away form a best-in-class system (which I do not buy into at all).

 

[bhayden]

=======

Here we do not use 2-D layout at all. We create models / assy's and detail them out(70% sheetmetal). Many pieces of geometry such as hole patterns (~100+) are all drawn in as 2-D enities. As you can image this is a huge time burden

========



I'm doing mostly sheetmetal. I don't understand what you mean by detailing out hole patterns as 2-D entities? Are you working with imported data or drawing 2-D entities on solid parts rather than using the hole function? If you've got a lot of reuse of patterns then save them as sketches and they can be retrieved as needed. I'm fortunate to still have Cadkey around for drawing 2-D stuff of any complexity. IMHO the sketcher tools are like using a kindergarten crayon.



If part of the reason for the change over is to be in sync with the parent company are you going to be sharing design data via Intralink? There's several schemes for accomplishing this. I'd recommend you push hard to get the main Intralink Admin from the parent to come out and work out the set-up with you.



With the large amount of information you have to control I'd go the route of setting up Intralink before any engineering work is shifted to Pro/E. You can also use Intralink to manage Revision control and possibly BOM information of the IDEAS files.



The PTC Intralink Admin class is good. My only grip is that our license is what they call Single Site and much of what they teach you in the class is only available with the Multi Site license. This left me to discover by trial and error what features I could use to trace design history. This will be even more of an issue with multiple users. I don't know if you can have one multi site license for admin and then use single site licenses for access. I think you can.



I'd try to find out if the parent company has imminent plans to switch to 3.3 and or Wildfire. If you can avoid a transition it would be nice.



-Bernie-

 

[patent_pen]

Due to the system performance issues with large patterns of holes, we currently just draw the pattern on the drawing and leave the model with no holes. I realize this is a poor way to operate, but this will change once we are on ProE. I-deas has no way to handle cumbersome feature sets like ProE does (part simplified rep, family tables, etc). This has only been a work around.



We have multi-site license for Intrallink, so that will be beneficial as far as the training goes.



The reason for the change to ProE is not to share data so much, but to gain help in the admin/ support department as well as a productivity increase.

 

[bhayden]

======

Due to the system performance issues... we currently just draw the pattern on the drawing and leave the model with no holes. .... I-deas has no way to handle cumbersome feature sets like ProE does

======



Wow, this is the Best in Class system some are worried about leaving? Is there a way to output the I-deas drawings so that you can end up with the hole patterns in AutoCAD .DWG format. I've found this is the best way to import that sort of data to Pro/E. DWG is (I believe) the only format that you can access directly in Sketch mode. The down side is that Sketch mode blows up importing anything more than about a dozen holes at a time. You're forced to create patterns in the model or break down a large pattern into several chucks (not very efficient). Still, it sounds like you'd really benifit by creating a company library of sketch sections if you have any reoccuring hole patterns. Intralink can handle tracking the saved sketches in common space.



-Bernie-

 

[patent_pen]

I agree with you 100%.



The benefits and capibilites of ProE are only deamed about with I-deas.





Would it be better to create UDF's for particular geometry (holes/sections) rather that import sections? It seems like with a UDF you can better take advantage of patterning and take some of the guess work out of non-novel geometry creation.

 

[dougr]

Hate to pop your balloon, but it's just as cumbersome to pattern holes in Pro/E.



We've resorted to defining them as datum-curves in the past due to the regen times of larger patterns.

 

[patent_pen]

dougr,



Thank You for the heads up. . . .



How large is a larger pattern?



My thoughts were to create part Simplified reps that showed the start and end of the pattern with the bulk of the holes turned off to aid regen times. Have you tried this?



Our base geometry is very simple ~10 to 15 features.



I have worked with 400 to 600 feature machined castings made from 400 to 600 feature as-cast merged models. Those regen times could be anywhere from 5 to 10 min, but that was very complex geometry. I would hope that comparable feature counts of a simple hole pattern would not take that long on regen, but I have never tried it.

 

[dougr]

I'd agree with the 100+ holes to a pattern listed above.



Hole patterns are a double-whammy - large pattern will result in longer regen.



In addition, view functions (spin, zoom etc) are also slow due to the number of features.



PS I'd definitely recommend hole representation by datum-curve rather than drawing entity - much more stable and are good for any drawing view orientation.

 

[bhayden]

=======

Would it be better to create UDF's for particular geometry ... than import sections?... With a UDF you can better take advantage of patterning ...

========



To be honest I've avoided UDFs just because of a lack of experience. I've done some work with UDFs for punch patterns like D-sub connectors and I'm now forced to confront it again for a form punch. The advantage of importing sketches is it's simpler and you have greater flexibility in modifing the section. I think judiciously placed datum points or dimensions from the placement of the section to it's origin will allow you to pattern the imported section in the same manor as a UDF. However, well constructed UDFs may save some time and lead to more uniformity amongst designers.



====

Hate to pop your balloon, but it's just as cumbersome to pattern holes in Pro/E.

====



I don't know how bad I-deas is for patterning but it's hard to imagine anything worse than Pro/E. At first I bought into the it's complex because it's so powerful BS. Now I know it's simple a case of PTC threading the canine :+) That's why I draw hole patterns in a CAD system that's simple and import saved sections.



It seems strange but I'd swear it takes longer to regen a simple hole pattern of say 100 holes than it does to regen a complex model with 100 features. It seems wrong but there doesn't seem to be any performance advange to patterns. However, there are a number of ways you can deal with the pattern as a single feature to address this (suppress, hide, simp. rep.).



Bernie Hayden

XKL LLC