Attributes which are on wtpart and caddoc should be synchronized bi-directional

[OliverDroop]

OOTB attributes are only synched from CAD Doc to WTpart on check in or build operation.

Due to requirements for searching, workspace listings, cad integration which can not be solved by the ModelAttributDownload Delegate several attributes need to be persisted on both objects. In this case attributes can get out of synch due to differnt user groups for wtpart or cad or just by user error.

A bi-directional synchonization for certain attributes would be a great enhancement to improve data quality.

Challenge is to break the circular reference when to publish from WTPart -> CAD -> WTPart but it is possible by some evaluation if update is really needed.

[OliverDroop]

If Alias attributes would be supported in workspace, search and cad application then this could be an alternate solution

[JenniferPierron]

Hi Oliver.

Not sure if this would address your concern; but you can automatically "Build" after either the Part or the CAD Document changes.

For CAD Documents, you are familar with the default behavior to Build the related Part after check in.

In Windchill 11.0, you can also automatically build the CAD Doc after Part check in.

• You can set the server-side preference Part Management > Publish to CAD after Check In to Yes (by default it is No (the old behavior))
• The preference above controls the behavior in the Part check in UI:
• 
• If this is checked, then the system will update the built attributes (and valid structure changes) on the CAD Document.

Thanks

Jennifer

[GregoryPERASSO]

We have done a little customization

a new DataUtility for Attributes.  based on the OOTB mapping preference for defining IBA mapped between CAD and WTpart

and another to define IBA that we want to be only mapped from CAD to Part and forbid the reverse build  (for example dimensions )

1- we display a CAD icon near the value to inform that the attribute is mapped from CAD based on the OOTB mapping preference

2- we gray out the field in edit actions to prevent the change of this value on Wtpart side (so the reverse build) , based on a new pref

It would be great to define  3 cases

• attributes mapped from CAD to WTpart
• attributes mapped from Wtpart to CAD
• attributes mapped bi-directionnal

and that littkle glyphs inform the user of the case

[JenniferPierron]

Hi Gregory.

I think these are good ideas.  It would be good to have a formal concept of how the attributes are used.  I think you should also comment on how you want that configuration to be set up (e.g. per site, org, context, etc.).

The current tools in the Type and Attribute Management UI can prevent editing on one or both sides.   They do not show any Icon (like in your customization); but we can make the fields read only.

Anyway, I just wanted to make sure others knew about the tools available today:

- For CAD to WTPart ONLY (e.g. the Creo designated dimensions), you can do this out of the box using soft-type constraints, right?

• Add the global attribute to both CAD Doc and Part soft type.
• CAD Doc you can use the default constraints
• For Part, you need to modify the constraints to be immutable
  • 
• Then Windchill UIs will prevent their modification for Parts only:
  • 
  • 
  • ** Note:  Good or bad, the build service will not honor this constraint and will continue to update the attribute.

- For Part to CAD:

• Add the global attribute to both CAD Doc and Part soft type.
• Part you can use the default constraints
• For CAD Document, you need to modify;
  • the constraints to be immutable
  • The visibility to be Read Only for all fields
  • 
• This should give you the result that:
  • Windchill UIs don't allow edit
  • 
  • Creo cannot upload
  • 
• Additionally, to push the WTPart attribute changes to the CAD Doc, you would need to build after Part check in (original post)
• ** Note:  Good or bad, the build service will not honor this constraint on the CAD Doc and will continue to update the attribute.

- For bi-directional

• no constraints required.
• to push the WTPart attribute changes to the CAD Doc, you would need to build after Part check in (original post)

Thanks

Jennifer

[GregoryPERASSO]

Hi Jennifer,

Your right.  As we manage different Brands (with different needs in term and attribute mapping) in a single Windchill instance, but want to keep at least a common WTpart and CADdocument data model, we need to be able to specifiy that mapping:

-at Org level to separate each Brand

-and also at container level cause each Brand have different business with different methodologies :mainly 3 differents cases : watch Movement , watch Casing , jewelry

Your tips and trick is perfect Out of the Box for customers who need a single mapping accross all the Windchill instance, or if subtyping per organization

Thanks

Gregory

[OliverDroop]

Jennifer,

Thanks a lot for the detailed comment. This needs to be communicated on the next PTCLIVE events. This is a great step forward and we can get rid of one more customization.

Oliver

[cmilligan]

How about we take this a step further and just eliminate having two records for the same object in the first place. Why am I maintaining two sets (really many more, with multiple sheets, CAD software packages, 2D vs 3D, etc) of attributes. All of the records describe and create the same object but are all maintained as independent records in WC and therefore require syncing and other efforts to keep them all correct.I just ran across another idea complaining about the difficulty in keeping the revisions matched between the two. If there were not two in the first place the problem goes away.

[JenniferPierron]

Hello Courtney.

Thanks for this feedback.

Right now we don't have plans to change Windchill to have just a single object.  The Alias attribute suggestion from Oliver is a way to suggest that there is one common attribute for both; but not one common object.

The reason we have Parts and Documents separated is to allow the Part to be described by and related to several documents each of which are access controled differently.  Although you many not need this functionality (yet?) it allows a flexibility that is not possible with a single object.   For example, what happens if you want to "freeze" the 3D model; but the drawing is not ready yet.  How do you set the state on the single object to allow the drawing content to change; but not the model?   What if you want to "freeze" the document that contains the requirements or a spec; but the models are not yet started.  With a single object, you cannot prevent them from being modified.  Content on an object is not independently revised/access controlled.  They all have the same revision and state.

There are pros and cons to each approach; but I just wanted to let you know the approach to have a Part and CAD Doc was decided to allow this type of flexibility.    If you feel like you don't need it, I would suggest you start another IDEA explicitly stating that and advocate for it.   The more votes, the more likely we'll do it.

Thanks

Jennifer

[OliverDroop]

I know that WT10.2 Best Practice was to keep Revisions in synch to make live easier and to have a clean situation with the links.

As far as I know R&D was working on this topic to improve usability in WT11. Maybe Jennifer Pierron can comment on this as well. Maybe in a new thread

From the process point of view it is not required nor usual that the revisions are kept in synch. There are too many use cases which make this unefficient.

Therefore to revise only the object which needs a new revision is the correct approach. However if you start revising each objects independently you run into some complexity with the links and access control which needs to be managed. We handled this in 10.2 by some customization of some revise listeners which we would like to get rid with WT11 as well

[JHall]

@JenniferPierron
First of all Jennifer thank you for your attention to detail in this issue. It's quite complex. 

I have a question about your Publish to CAD after checkin comment above.  I am currently using Windchill 11.0 M030, WGM 11.0 M030, Inventor Pro 2017, Windows 10.  We are installing a new, first time at this company environment.  Go live is expected in mid to late May.  

I'm wondering if checking the Publish to CAD box will push attributes from a WTPart to its owner/image/content linked CAD, using Inventor?  Not just the structure, but attributes inside the CAD file.  

Our VAR doesn't appear to think this is possible, but we do seem to be getting some attributes publishing to a read only custom field in Inventor. (they call it iProperties). 

We would like attributes to be editable in the CAD object and the WTPart and update on change during checkin and this seems like a possible solution.
 

[JenniferPierron]

@JHall

Hello.

Unfortunately, we do not support "Publish to CAD" for Inventor.  Currently, it is only supported for Creo, CATIA V5 and NX.

The Inventor WGM, however, does support passing some Part information (as read only iProperties) to Inventor files.  You can see the list here:

http://support.ptc.com/cs/help/windchill_hc/wc110_hc/index.jspx?id=IEUG_TaskMngmentWebjects&action=s...

Related Part information is:

PTC_WM_PART_NAME

String Type Initial value: Not Applicable. This system attribute should never be created on initial creation of the CAD document. Corresponds to the string used for the name of the actively associated part to this model’s CAD document. May be created and set before the initial auto-association if the naming policy is set to use a custom parameter. Otherwise, the value is ignored and set upon Save. For new or existing CAD documents, if the user associates, then the system parameter should be available to be updated upon next retrieval in or save from the authoring application. When checking out an existing CAD document, the system parameter should reflect the name of the CAD document’s actively associated part. If none exists, then the system parameter is not created in the authoring application.

PTC_WM_PART_NUMBER

String Type Initial value: Not Applicable. This system parameter should never be created on initial creation of the CAD document. Corresponds to the string used for the number of the actively associated part to this model’s CAD document. May be created and set before the initial auto-association if the naming policy is set to use a custom parameter. Otherwise, the value is ignored and set upon Update. This attribute is not predicted. For new or existing CAD documents, if the user associates, then the system parameter should be available to be updated upon next retrieval in or save from the authoring application. When checking out an existing CAD document, the system parameter reflects the number of the CAD document’s actively associated part. If none exists, then the system parameter should not be created in the authoring application.

If you would like support for "Publish to CAD" for Inventor, please add it as an Idea. We are using those to help us determine customer need and thus priority.

Thanks

Jennifer

[Ruediger_Scholz]

Functionality delivered in Windchill 11.1