Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
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:
We would like to solve the step file issue and the Creo View issue.
ALL help is appreciated!
Thanks!
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.
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?
I'm not sure there is a perfect solution. Each approach has its pros and cons.
publish.configspec.default.drawing.useasstoredifavailable
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?
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?
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.
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.
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.
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. 🙄
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?
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. 😱
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.
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.
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! 🙂
They wouldn't the only ones... that's for sure 😉.
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?
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?
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.
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.)
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.
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.
Understood. Although IT would still consider 'latest' as an issue since it doesn't represent the snapshot at that time.
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...
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.