Newsletter 2

PTC Management panel

Dick Harrison, Jon Stevenson (MCAD), Jeff Lontz (Services), Brian Shepherd (Technical Marketing), and Phil Getto (Product Development) participated in the PTC management panel, answering user questions submitted in advance. Easiest way to summarize this session is just to list major points each speaker made.

Dick Harrison

High turnover, especially recently, in field sales and service has been a consistent problem. Internal and external high sales expectations just encouraged some people to quit. More reasonable goals should reduce turnover.

PTC hasn't set a date yet for release of an ACIS translator, and hasn't completed negotiations with Spatial Technology (the developer of ACIS), but still did start work on an ACIS translator 12 weeks ago.

Pro/Toolkit and Pro/Develop will be supported beyond 2000i4.

GeomToolkit is an internal PTC tool used to create the ATB for data exchange, and it might be used to provide limited backwards compatibility.

Jeff Lontz

Asked about the assumptions and process flow of PTC's PDM products, and the configuration management rules, Jeff said that the entire services organization will become more solutions based in the future, rather than function based (this tool, that module) as now. Services will deploy offerings that address process and configuration management.

Brian Shepherd

PTC will be releasing a free viewer for Pro/E parts/drawings/assemblies, for Netscape and Explorer, in a month at the new Online Store to be announced.

Brian said he expects at every single user conference to explain upgrade fees. If you are content with ADPIII functionality, you're welcome to stay with ADPIII "as long as you like". Whenever enhancements are made to a package included in ADPIII, you'll get them. What you won't get is new packages, like Behavioral Modeling, or ModelCheck.

Kansas is the code name for a new diagramming product (apparently based on Medusa), for driving Pro/E routing (which can also be driven by Windchill data).

2000i3 includes strictly 2D parametric sketching in drawings (real news, lots of people assumed PTC had totally forgotten about 2D drawing sketches).

Foundation package has by intent only limited surfacing (Pro/Surface). There are no plans to include ASX (Advanced Surfacing extensions, or CDRS capabilities) in the Foundation package. Machine designers are one group who don't usually need surfacing and who don't want to pay for it.

Phil Getto

Although in the past PTC has considered backward compatibility too risky (possible loss of data), now the company is considering a limited form, similar to Word and other products: you might get a warning, and you might lose some features or references.

Phil said if you're now moving to Intralink, or considering moving to Intralink, go ahead. If you're on Pro/PDM, then consider whether Intralink or the Windchill based WorkGroup Server product best fits your needs.

Phil said there were obvious deficiencies with Pro/Help recently, due to an internal PTC mover away from in-house developed documentation tools to new 3rd party tools. PTC will be re-introducing the graphics and figures that are now missing from the doc. Future for doc will include show me type tutorials in the doc.

3.6 won't be the last version of Pro/PDM. There will be a 3.7 version to work with 2000i3, but decision hasn't been made whether a 3.8 version will be needed for 2000i4.

Intralink 3.0 at the end of the year should fix WAN speed problems by replicating data servers. On the client side, the old proprietary GUI has been replaced by a new GUI written in C++ and Java.

There is a long term multi year project to improve usability throughout Pro/E, with changes evolving over the next two releases. The top level menu bar will be developed, with more graphics area one result.

Top Down Design

Here was a major presentation which really needed more time. It's hard to understand when a lot of information is packed into a smaller time slot, and the demo in this case had to be cut short. Perhaps major presentations could be identified in advance, and given more time, 1.5 hours or even 2 hours.

Thomas also wrote a good article for the current, Summer 2000, issue of Pro/Files magazine (the Pro/User magazine), on defining assembly structure, "Mapping Your Good Intentions". If you can get a copy of the magazine (which is sent to everyone with a known address in an active local user group), the article makes a good introduction.

A key point in the article, and in the presentation, is that you should do a lot of top down design, a lot of work, before you ever turn on the computer. Pencil and paper work, even, or at least, word processing work. Defining the knowledge and rules of the engineering team. You can't capture knowledge in the Pro/E results if it isn't defined first. Define the design specs and constraints, understand design requirements, understand relations (not necessarily just geometry relations) between components, plan how components will be defined in Pro/E. A whole lot of work, capturing design intent. Not at this stage defining final geometry, but laying the foundation for the final geometry.

These are the planning steps, from the article:

• Identify and list the subsystems to be designed.
• Identify and list the components of each subsystem design.
• Identify and list known relationships between the subsystems and components using the design specification.
• Identify information that will drive the design data requirements (which establishes the master/slave paradigm for design intent).
• Referring to the known relations documented in step 3, and the master/slave paradigm established in step 4, determine the best tool in the Pro/E environment to capture design intent.
• Create a design intent graphical diagram for each subsystem.

So, you do all that, before you startup Pro/E. You don't even know which Pro/E tool you are going to use to capture design intent, until you've done all 6 steps.

That probably is the most important part of what Thomas said: the planning and preparation necessary to lay a foundation for what you do in Pro/E, which has to be done first if it's going to be a foundation.

But he had a good deal to say about working in Pro/E too:

• throw out the parent/child relationship model (after all, children manipulate parents all the time), and replace it with the master/slave model (no ambiguity there, who drives whom)
• deliberately avoid long dependency chains by careful upfront planning, another reason to postpone turning on the computer. Any long dependency chain is likely to introduce problems
• to reduce those dependency chains, consider abandoning the traditional single top level all encompassing Pro/E assembly. You can use a layout instead, if you have enough info that can be described in equations, or else a reference object, master model and skeleton parts. As the article says, "having a single Pro/E assembly serve as 'the' top-level object for a design is not only unnecessary but also undesirable"
• if you're using master models, make those models available within different assemblies, to reduce dependency chains from some high level master model (instead, copy the master model wherever needed, use it right there)

Problems he mentioned, Top Down Traps:

• Accuracy. But you'll have to decide on your own whether to use relative or absolute accuracy, and what values. Thomas said checking with downstream applications can be a guide
• Circular references. Keep the master/slave relationship in mind, don't drive intent from peer objects at the same level in the assembly structure. Eliminate circular references immediately
• Reference scope control. Keep the global environment scope settings to 'all', and use just the object specific settings to control references, not the environment setting. Recommended config.pro settings for object scope control are:

  Allow_ref_scope_change	yes
  Default_ext_ref_scope	all
  Default_object_scope_settings	none
  Ignore_all_ref_scope_settings	no
  Model_allow_ref_scope_change	yes
  Scope_invalid_refs	prohibit
  Fail_ref_copy_when_missing_ORIG	yes

  The demo began to show in detail using the global reference viewer and other tools to fix external reference and copy geometry problems. But unfortunately the demo was interrupted by the end of the time, and also, it was very compressed anyway, lots to follow very quickly. Perhaps the entire subject of the demo could make another Pro/Files article, would be worth it.