Simplified representations viewed in ProductView

[cc-2]

Hello,

it may not be the right place to post this message but as it involved ProE, ProductView and PDMLink I thought I have a go here.

We are confronted to a particular situation with some of our models.

I am going to try to make it sample. We have a component and it is a pin (cyclinder). When the pin is assembled it is riveted at both end. Our designers used to create 2 different models. One to represent it unriveted and one riveted. We need the unriveted for the production of the pins. This was not really creating any issue at that time because the ProE data were created locally and BOM edited manually. We now have implemented PDMLink and added more automation such as automatic BOM. Therefore we do not want anymore 2 different models for the same pin. We are struggling to find out the best technique.

From a Proe standpoint, it seems that using simplified representation is the best approach. We only have one model and use either representation depending if we want to show the pin on its own or assembled (and riveted). The BOM is also always correct.

Unfortunately, PDMLink/ProductView does not "understand" it the same way. When I opened the pin only in ProductView I see it riveted at both end (which makes it look as if it was headed at both end). Our explanation is that ProductView will only show the master representation. Good, so we will have in the master representation the unriveted pin and in the other representation the riveted pin. Unfortunately it does not work because in ProE, you can only remove feature in the simplified representation, so we have no other choice than having the riveted pin in the master rep. It seems that we are stuck and cannot achieve what we want to do.

Maybe some of you has been confronted to this type of situations and may have found a nice way around it

Thank you in advance for any suggestion of help.

Best regards

[mdebower]

We have a similar situation, but have been using family tables instead of simplified reps. The problem with family tables is that if you create the generic as the unriveted pin and a instance as riveted, the assembly uses the riveted. This means that where used will only report on the instance, and it looks like the generic is never used.

I am wondering if an assembly simplified rep and substitute the unriveted pin for a riveted one would work...

-marc

[cc-2]

Hi Marc

Are you using a PDM system ? The problem I have with family table or having to separate prt for each representation is that it generates a number for each which is unique but it is for the same component indeed. We also use the WTpart that we will link to our ERP sometime in the future. Therefore we cannot have 2 different BOM

Thanks

[mdebower]

Yes, we are currently using PDMLink 9.0 m060.

I think that there are two interesting options. The first as I mentioned is Simp Reps and substituting a staked rivet for an unstaked version. The family table is just a single instance. For example, the generic is the unstaked version, and named PARTNUMBER.PRT The staked instance is named PARTNUMBER-staked.PRT Astructure report does show both the generic and the instance, with the generic shown as a member of the assembly and the instance as a substitute member. A Where Used report shows the correct relationships.

The second option is to use flexible components. You have to create the rivet to be able to do this from the start, so that you have dimensions to make flexible. Since there is only one component, the BOM structure and Where Used are automatically correct.

-marc

[mdebower]

Sorry for the double post. I forgot to talk about WTParts. One way to handle the info transfer to ERP would simply to be not to create a WTPart for the staked versions. No WTPart, no transfer of info.

-marc

[cc-2]

Thanks Marc

not a bad idea about the WTpart,

We will investigate what you call flexible components. We will see if it works for us.

Thanks

[cc-2]

Hi Mark

this has done the trick. It is working as we wanted. Thank you for the tips.

Best regards

Christophe