Using Major/Minor revisions

[estewart-2]

Hi Windchill Guru's,

This question is part Configuration management, part Windchill. We have been asked by one of our product groups to look at implementing Major and Minor revisions within Windchill. While I'm sure it can be done, I'm not sure of the effects on other product groups who may not want to change. Has anyone gone thru a similar experience? Any pearls of wisdom to share?

For reference, the product group's intent is to raise the major revision if the form, fit or function changes. Minor revision will be for documentation changes only to the drawing that defines the part.

Eugene Stewart<">mailto:eugene.stewart@comdev.ca> Senior Windchill Administrator
Com Dev

[DonSenchuk]

IME, Form, fit or function is typically a new number, not a revision. Revisions are for things that don't change form, fit or function. This is done to ensure complete forward/backward compatibility, regardless of revision.

[hwientjes]

Hello Eugene/Donald,
I've the same; major and minor revisions. The problem with a new number for the engineer is; how do you handle this in CREO/Windchill
I feel this is one of our major problems;
How do you handle the form, fit, function(FFF) modifications in Windchill/CREO. The whole downstream process(ERP system) tells me to take a new identification but as a designer I want to see in the history all modifications for a specific design part. This means FFF changes and Non-FFF changes.
To me as a designer the Non-FFF changes are shown in the history in Windchill but they are less interesting to me.
To me as a designer the FFF changes are not shown at all in Windchill when I have to take another identification. And these are the interesting changes to me.
So how do you handle the complete change history including Non-FFF and FFF changes in Windchill for a specific design WT-Part and how is this connected to the CREO-part. Do you use the "hard" or "soft" link between WT-Part and CREO-part?
Best regards,
Han

[DonSenchuk]

Windchill tracks the Save As function from number to number.

If the FFF changes, do a Save As on the old number to create the new number.

[TomU]

Sure, but how easy is this information to get to? I'm skeptical about the ability to easily construct something equivalent to the revision table/history on a typical drawing. You would have to be able to track every prior save-as (not just the most recent), plus the reasons for the change (or save-as), but exclude all other save-as events that were for other, unrelated uses. Creating a new part number every time there is a FFF change also requires a complete rework of the next upper level assembly when practically this may not even be needed.

[DonSenchuk]

The Save As history isn't as complete as I had thought. I retract that suggestion.

The revision table/history on a typical drawing would be done manually anyway, wouldn't it? I mean, I have yet to see any revision table on the drawing that was fully automated.

(Using the royal "you" here, not you specifically, Tom!)
If you don't create a new P/N for every FFF change, how do you differentiate between one rev and the next?
How do you tell downstream departments what is the proper revision to use when the FFF change may make a component incompatible for whatever they're doing to it or using it in?
How do you ensure the customer that asks for P/N 123456 gets the proper piece if FFF changed compared to when he purchased it 4 revisions ago and now he gets something that is totally incompatible with what he has?

[TomU]

I like the guaranteed interchangeability that new part numbers bring, but I think for a lot of companies it's overkill. Obviously if you are producing large quantities of a product you need to insure the replacement parts will fit. This is not our environment. The "products" we produce are for the most part one off designs. The changes/additions/replacements are all going into that one specific physical product. For this type of environment, it makes a lot more sense for each particular component to remain the same component forever, regardless of how a change to it may impact the rest of the design.

I don't think we're unique in this way. I don't think it makes sense to put a rigorous system in place to guarantee interchangeability if that is not a core requirement in your business. Of course I could certainly be wrong.... I'm learning new things every day!

As far as the manual nature of rev tables, something is going to be manual. Either someone is going to manually type the changes in the rev table or they are going to manually type the changes into some web based field in Windchill. Either way, someone still has to manually do something. It's just a question of where and how.

[DonSenchuk]

I understand the use-case for limited (or one off) designs. In the past I have worked at places where the run was extremely limited and they used the FFF change = new number. That was due to the need for replacement parts due to wear and tear on the final product.

Having said that, after seeing the messages on this thread along with a very interesting private exchange with Han Wientjes I've been thinking a little more about this problem and the framework that Windchill provides/limits us to. We may be over-thinking it a bit.

[HugoHermans]

Hi Han,

An attempt to explain our approach:

We consider CADdocuments as the instrument for the designer. FFF does not apply to CADdocuments. Whenthe designeranalyses the version history of CADdocuments,he should be able to read the natural design evolution of a particular component or assembly.

From one revision to the next of the CADDocument, the designer is allowed to couple a new WTPart, when the design turns out not to be backward compatible (or FFF). So, there is a mapping of the design history to the article history in these links. FFF (or backward compatibility) should be applied to WTParts, not the CADdocuments.

Major/Minor is the next decision (but only when FFF applied!). A minor change is a change that not has to be trackable in the future. We don't want to know on which machines these changed parts were used. This in contrast with major changes. For major changes, we want to be able to decide where these components are used, and want to be able in the future to track where they were used.

The way we are going to implement major/minor changes in Windchill, is with view versions. When CADdocuments are raised in revision, the Design-vv of the WTPart is raised as well (in the beginning of the process). But the ERP-vv will only be raised when the change is considered as a major (at the end of the process).

In ERP, since only the ERP-vv is communicated to ERP, they will only recieve major revision on articles, and document revisions on minors and majors. This way, their information is unambiguous.

Is this somewhat clear? I have to admit, it's our concept, and our concept is not yet implemented (ERP is not ready :-). The thing is that 80% (estimated) ofour changes are minor changes, and we want to avoid by all means to confuse ERP.

Regards, Hugo.

<< ProE WF5 - PDMLink 10.1 M040>>