To support the demands of many companies wanting to develop a "model centric" or Model Based Definition (MBD) to leverage the 3D model data there is a need to allow the parametric data from the model to drive information on the drawing. Even in the most vertically integrated organization there will be a need for at least some 2D documentation. By making it difficult to drive this information parametrically it leave the potential for this data to be misalligned.
Please see the link below for an explaination of the current "work around"
Agreed, this should be something that is much easier to control. It should also be much easier to link the parameters on the drawing and the model so that they can remain identical if they should be by the requirements of the organiczation.
Additionally see related issues about PTC_COMMON_NAME.
I made a simple test and was able to show model parameter value in a drawing. If you want start new discussion and describe your problem on specific example.
Read the support page he linked to. The issue is that checking the template into Windchill automatically creates Windchill parameters for the template and then the call outs for those Windchill parameters that are intended to pull from the model get tied to the template, and consequently, to any drawing created from the template.
Standard user created model parameters that do not exist in the template work fine.
The notion that this works to specifcation may be technically true, however, does PTC really want to say "Yep, that's what we wanted to happen." in this case?
Doug is correct. This problem is with templates. The most viable work around I've found is to create a template part and then create a drawing from the template. In the drawing you can show the model parameters. Now you can use the part template and select "Copy associated drawings" when creating the new part from the new part template. This is counter productive for any companies wanting to adopt a model centric approach.