cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X

How do you manage your Cadworker settings and ME processes for checkin, revise?

jwagh
17-Peridot

How do you manage your Cadworker settings and ME processes for checkin, revise?

Let me preface this by saying that we are beginning our digital journey, so we appreciate any help and patience you can offer.

 

Currently, out cadworker is setup to generate visualizations "As Stored", so that it captures the snapshot in time when the data was generated. However, we are seeing some issues:

  1. Engineers are making some small changes to the geometry. They are promoting just the part, and no higher level assemblies; since the assy BOM are not being affected. Does your company enforce the user to revise ALL higher level assemblies so that the step file gets updated? How does that impact downstream teams when the top-level  assemblies could be getting revised multiple times a day without any 'real' change. That could end up having a lot of wasted work where most items on an ECN are 'no changes'. In addition, we used to tell our team to check-in their work every day. Now we need to have them change this to check-in all of their work at once so that it updates properly the 'as stored'? Sometimes, the simple files are the higher level assemblies that don't get updates as often as the lower level more complex parts.
  2. Let's take this a step further. What about NO geometry changes? Let's say a title mistake in a drawing needs to be fixed. So the part title parameter is updated. Now, the Creo VIEW attributes for the higher level assemblies are wrong. Those higher level Creo View files are calling out the wrong rev for the part, and the attributes are still showing the wrong title.

We would like to solve the step file issue and the Creo View issue.

ALL help is appreciated!

 

Thanks!

40 REPLIES 40
MikeLockwood
22-Sapphire I
(To:jwagh)

Welcome to the digital journey. It's taken up pretty much every one of my limited brain cells for 25+ years 🙂

 

Publishing As Stored (rather than latest) is essential to the integrity of data - don't change the default.

 

"Parent" items (e.g. an assembly or drawing) display information in "child" objects. In general:

- All development is done using latest

- All "doing business" on the data has to be done using As Stored

 

The classic case is:

- CAD user checks in parent item (e.g. drawing).  All system-generated output (e.g. publishing) uses the model(s) that were current when the drawing was checked in (the As-Stored relationships)

- Then CAD user modifies a model; the drawing shows updated on their system but the system-generated output does not match that.

- Users have to refresh (regenerate / rebuild) all parent items after modifying child items.

 

///

Also, take full advantage of Windchill generating STEP and other nuetral files (and embedding the version in the STEP filename), instead of having users generate those files and check in.

@MikeLockwood 

Thanks for your response. What do you mean by "Users have to refresh (regenerate / rebuild) all parent items after modifying child items." Do you mean manually in Windchill with the representation?

TomU
23-Emerald IV
(To:jwagh)

I'm not sure there is a perfect solution.  Each approach has its pros and cons.

  • Creo will automatically open everything 'latest' unless you manually add the 'as stored' versions (or whatever versions you want) to the workspace first.  Normally the designers want to work on the latest versions anyway so this behavior is fine (for us).
  • We choose to publish 'as stored' but all assemblies are published as 'extended positioning assemblies'.  This keeps us from embedding the lower level component geometry into the assembly representations.  It makes the assembly publishing process much, much faster yet still allows STEP files of the entire assembly to be automatically generated.
  • It is possible to configure Windchill to automatically mark 'latest' representations as 'out of date' anytime one of the lower level dependents changes.  This can then be used to trigger automatic republishing of everything up the tree.  ('rev rolling')  Of course the challenge here is that the representations now look different than they did when those assemblies were actually created, and the CAD assemblies themselves may actually go into failure depending on what changed.
  • There was a new option added to Windchill 12 that will allow drawings to be published 'as stored' while assemblies are published as 'latest'.  Of course that means the assembly drawing you are looking at in Creo View may potentially look very different from the same assembly open in Creo Parametric. 
  • Since Creo Parametric normally shows 'latest', we actually like that Creo View shows 'as stored'.  It makes it easy to compare how the assembly was last saved to what may exist now (due to lower level changes.)

 

publish.configspec.default.drawing.useasstoredifavailable

 

jwagh
17-Peridot
(To:TomU)

@TomU 

Thank you for your response. In your organization, how do you handle the use-case where a subpart title &/or attribute was edited and therefore the part was revised? The higher level positioning assembly (which is still set to As-Stored) should point to the earlier one? Correct? Don't you want to see the latest one? Does your ME team need to revise all the way up each time these changes occur?

MikeLockwood
22-Sapphire I
(To:jwagh)

At Edwards, due to acquisitions, tremendous growth and other factors, things like this are unfortunately not uniformly handled.  They are well understood in general, but still a work in process to implement, train, enforce, etc. for all areas.

In general, no higher assembly is Revised unless the child item changes are substantive enough that the appearance really changes or function changes.  Part number changes and swapping out is much more difficult than it otherwise would be due to regulatory submissions that include part numbers - so it's an ongoing challenge.

In short, the organization understands that Creo View data (structure and attributes) are most likely incorrect?

TomU
23-Emerald IV
(To:jwagh)

Our designers have some discretion on when to revise the parent assembly and how far to walk back up the chain.  Generally the rule is, "if I can plainly see a difference on the assembly drawing, the assembly (and it's drawing) must be updated."  So, if one component changes by a few thousands of an inch, and nothing in the assembly is going into failure, they will typically not update the parent assembly.  On the other hand, if a component has entirely new features (that can be seen on the assembly drawing), or components need to be added or removed, then the parent assembly will definitely be updated.  Again, this does not automatically mean that the next level assembly above the original parent assembly is updated.  Again, can the changes made to the original assembly (subassembly) be readily seen in the next higher level assembly?  If 'yes', then update the next level assembly too, if 'no', then leave it alone.

 

As much as it would be nice to keep the entire assembly chain always up to date, it's simply not practical.  If a designer changes one component that is used in 200 other assemblies, they simply don't have the time to go bump the revisions and re-release all 200 of those other assemblies.  Yes, you could argue that a new part number is needed every time, but then you get ridiculously high numbers of nearly identical parts that the poor guy on the shop floor has to keep track of.  It's a balancing act.  I'm sure if we were a large aerospace company it would be different, but for what we do this works okay.

jwagh
17-Peridot
(To:TomU)

That makes sense from a work-load perspective. However, that means that the downstream teams need to ignore Creo View data and attributes altogether. Not something anyone wants to say at the beginning of this journey. Especially if it is to be used for Creo Illustrate and other downstream uses.

MikeLockwood
22-Sapphire I
(To:jwagh)

More on this as stated...

If a child item is not interchangeable with the parent(s) - see rules of interchangeabilitiy - then it needs to be a new part number.  If it is interchangeable then the assembly display as published will not change, and the higher Revision of the child item in the published parent will not make any change.  Super easy to state but difficult to actually follow, but essential to really work on.

If the child item really is different Rev B vs Rev A then it needs to be a new Part Number. Cutting in the new part number becomes a matter of swapping it in at the next assembly level.

TomU
23-Emerald IV
(To:MikeLockwood)

Nice in theory, but pretty much impossible to implement in an organization where it hasn't been done that way for the last 50 years.  Around here part numbers are based on 'function' not what it looks like or how it mates to everything else.  Different revisions of the same part are definitely not interchangeable in different versions of the assembly.  One of the reasons we will probably always publish 'as stored' here.  🙄

jwagh
17-Peridot
(To:TomU)

Agreed. We can have a hole too tight or too loose, and we need to tweak dimensions, GD&T, etc. Theoretically, that means it is not interchangeable. However, that is how we've been doing it forever. I'm also not sure if that solves the Creo View dilemma. Let's say one part gets swapped out. So one assembly level above gets revised with the updated BOM. However, maybe the higher level assembly above that doesn't get revised, since the BOM doesn't change. How does that get handled? 

MikeLockwood
22-Sapphire I
(To:jwagh)

That's basically been true back to days when drawings were done in pencil and the BOM was managed in spreadsheets / ERP.

Comes down to managing effectivity of changes.

In general, for a product with many levels of indentiation, it's chaos and huge additional work to Revise all the way up.

Good topic.

I know! lol. I'm trying to prepare for the 'great' meetings to come with engineering leadership and downstream teams. 😱

TomU
23-Emerald IV
(To:jwagh)

I should also add that we've implemented some custom business rules as part of our release process.  Windchill will not allow a drawing or assembly to be released now unless all of the dependent objects are either already released or marked for release (on the same promotion request.)  The quality of our released data has gone up significantly since we added automatic checks like these.

jwagh
17-Peridot
(To:TomU)

That sounds great! We could use some of those and to make sure all submodels are also released. (Car shouldn't be released if the engine is still in development).

But it sounds like this check doesn't enforce higher level assemblies from being revised at the same time.

TomU
23-Emerald IV
(To:jwagh)

I'm sure it wouldn't be hard to write a business rule check that would force the designer to update all parent assemblies at the same time, I just don't know if it would be practical to actually enforce.  The designers might all quit!  🙂

jwagh
17-Peridot
(To:TomU)

They wouldn't the only ones... that's for sure 😉.

MikeLockwood
22-Sapphire I
(To:jwagh)

See attached about system-generated STEP files

That is what we currently do. However, since it is as-stored, it would appear we need to change our check-in process. We used to recommend we check-in every day (at least). However, if the simple assembly has last been checked in yesterday, and today we made a change to the geometry (but not shown in a view on the assy drawing), the step file of the assembly will now not show the correct geometry. What is your recommended check-in process?

jwagh
17-Peridot
(To:jwagh)

And we also have to ask ourselves, "how do enforce these process changes". If the step file and creo view data accuracy is critical with this 'new' process, how can we check for it?

MikeLockwood
22-Sapphire I
(To:jwagh)

Having all users check in all every day is good practice.

When ready to "do business" on data, the parent items have to reflect what is in the child items.  So, if a model changes, that drawing that displays that model's geometry has to be regenerated / rebuilt / refreshed with that model's data, and checked in either at the same time as the model or after.  The only  way to really verify / enforce this is Last Modified timestamps.

Understood. So you have someone in your organization reviewing all timestamps on promotions/ECNs? I'm sure mistakes are made from the user-base. 

TomU
23-Emerald IV
(To:jwagh)

You can use publish rules to decide when to generate STEP files (or anything else.)  We only generate the STEP files when the object is 'Released'.  'Republish on change' is enabled in our system, so anytime something is released Windchill will automatically republish it and generate the necessary derivative objects (IGES/DXF/STEP/PDF, etc.)

jwagh
17-Peridot
(To:TomU)

Yes. We have something similar setup as well. However, the step still only gets created from the as-stored. Which means, even if the item is promoted a month later from the last time it was checked in, all development within that last month on lower level items will not be reflected in the step file.

TomU
23-Emerald IV
(To:jwagh)

Again, I think it's situations like this that caused PTC to add that new preference.  It enables Windchill to always show the assemblies up to date (both Creo View and the derivative STEP files), but continue to show all drawings 'as stored'.  Just make sure if you go down this road that you have sufficient CAD workers set up to hand the constant republishing that will happen.  Also make sure you are regularly purging unreferenced files from the file vault.

jwagh
17-Peridot
(To:TomU)

Understood. Although IT would still consider 'latest' as an issue since it doesn't represent the snapshot at that time.

TomU
23-Emerald IV
(To:jwagh)

By the way, @MikeLockwood knows his stuff.  He helped us out a bunch when we were setting everything up.  He would be a good resource when you're going into these meetings...

jwagh
17-Peridot
(To:TomU)

Thanks!

Do you know the exact behavior you require?

If yes, put the wish list/spec out for us to see. The sky’s the limit. Including automatically updating Timestamps.

Announcements

Top Tags