First off, I do not have the routed systems packages. I do limited work with components that are "per lenght" as opposed to "per each".
For this reason I have developed a custom BOM Table that uses PARAMETERS and RELATAIONS to populate a custom BOM_QTY.
IF EXISTS ("ASM_MBR_BOM_QTY")
BOM_QTY=asm_mbr_bom_qty
ELSE
BOM_QTY=rpt_qty
ENDIF
For each component that I wish to quantify by lentgth, the BOM_QTY parameter is set by a relation in the model (i.e. BOM_QTY=d0).
I use the FLEXIBILITY (varied items) for such components so that the component legth can be dictated for each assembly.
The BOM_QTY value shown for such components in the BOM TABLE (Repeat Region) will reflect this "flexibility".
This part is working well.
The dilema is that we work in both Metric (mm) and English (in). Our latest designs are Metric.
THE SCENARIO:
Existing model of wire, that was modeled in Eglish (in): WIRE_PART_ENGLISH
New Metric Assembly: METRIC_WIRE_ASSY
WIRE_PART_ENGLISH is placed into METRIC_WIRE_ASSY and made to be flexible. The legth of the tube d0 is made flexible. The value entered is 10 for 10 inches. It appears that the flexibitly window uses the units of the component, in this case inches.
The BOM table in the METRIC_ASSY drawing shows 22 (in) instead of 558.8 (mm). On another note, if the WIRE_PART_ENGLISH dimension d0 (or any other dimention of this component) is shown on METRIC_WIRE_ASSY drawing it will display as 22 (in), not 558.8 (mm). The wire that was modeled in metric displays correctly both BOM information and dimensions.
THE CHALLENGE:
Either...
Option 1. Find a way to have the BOM_QTY value of the components in the BOM display in the units of the ASSY, despite the units of the components
Or
Option 2. Find a way to have a USER DEFINED or SYSTEM paramter for the UOM displayed in the BOM TABLE that mathes the units of the BOM_QTY. If the compnent is a "per each" item, then have EA displed as the UOM.
In eiter case I had to set up the model and the repeat region:
First, for the "per length" component, the BOM_QTY parameter was set up with units (Insert Unit). The Unit Sensitive was turned on in the Relation Utilities and a relation was set up to equate BOM_QTY to the length (BOM_QTY=d0).
For the repeat region, the RELEATIONS and PARAMETERS were set up as follows:
Then I tried to implent Option 2.....
Additional PARAMETERS and RELATIONS were set up to look at the UNITS of the BOM_QTY.
I would think the way to pull the UNIT information from the BOM_QTY parameter would be to use &ASM.MBR.PTC_UNIT.BOM_QTY
Note: The syntax in the relation is to replace the "." with "_"
The issue is that I cannot get the relations to work. I get a hidden error. That is when I Execute\Verify the relations the system says Relations have been successfully verified.
However, when the UPDATE TABLES is run, the system says that "There are errors regenerating repeat region relations".
And for the "per length" items, not only do I get a "blank" value in the UOM column, but the QTY column also now shows a "blank".
Could it have something to do with replacement of the "." with a "_" when you use a PARAMETER in a REPEAT REGION RELATION?
When using &ASM.MBR.PTC_UNIT.BOM_QTY in a relation, it is written &ASM_MBR_PTC_UNIT_BOM_QTY.
I wonder if upon regeneration or update the ASM_MBR_PTC_UNIT_BOM_QTY is interpreted as ASM.MBR.PTC.UNIT.BOM.QTY? The "." between PTC and UNIT would not make sense.
This is driving me nuts!!!!!
UPDATE: 3:11pm 10SEP2012...
I tried to remove the "_" in my BOM_QY and BOM_UOM parameters, and change them to BOMQTY and BOMUOM respectively.
This time it resulted in an error when Execute\Veriry was run. So, it points more to the "_" in the PTC_UNITS being an issue???
Still driving me nuts!!!!!
Mike
Message was edited by: Michael Gwin
ACCEPTED SOLUTION
Accepted Solutions
Brian,
I know how you feel, this has been driving me crazy. You would think after 20+ years that Pro/E (Creo) would have a simple way of generating a BOM that you can easily configure (per component) to drive the qty as you wish, either by EA, LENGTH, AREA, etc. and it would also be able to automatically list the units.
Thanks for your efforts. I did try the ASM_MBR_PARAM_UNIT also and it did seem to work. However, the only hole is that if you have units defined in more than one PARAMETER, in the model then you get multiple listings in the REPEAT REGION.
I added two phony PARAMETERS in the METRIC PART and gave them random UNITS. As you can see the METRIC PART has multiple listings now. NO DUP/LEVEL is applied as an attribute of the REGION.
This alone sent my whole perception of reality back. I had no idea that REPEAT REGIONS are driven by PARAMETERS and not the COMPONENTS.
In other words, I thought the REPEAT REGION simply had one row per COMPONENT (assuming no duplicates or no dup/level) and would then fill in the other cells in the table based on their value for that COMPONENT.
So, I am down to the following two choices.
- OPTION 1: Go with the above and if by chance we have a model that has UNITS defined for multiple PARAMETERS, then we could always manually filter out those lines. (I could not figure out how to filter out through RULE)
- Pro: If you ever change the EDIT SETUP UNITS, then the BOMQTY units automatically covert and update
- Con: You have to manually filter out any other lines that show up in the BOM because of addition PARAMETERS that have UNITS specified. This could be a pain if a component is widely used and is later updated to include a UNIT SPECIFIED PARAMETER, then through associativity, all the BOMS were it is used will show multiple lines and have to be filtered manually or if you could figure out a rule the rules would have to be applied to each table in each assy drawing.
- OPTION 2: Set up every model to have UOM PARAMETER and simply just list this directly in the BOM TABLE as &ASM.MBR.UOM.
- Pro: No filtering required, no multiple lines in the REPEAT REGION
- Con: If you change the MODEL UNITS ( EDIT SETUP UNITS) then you have to remember to change the UOM PARAMETER manually since it is a STRING
- Con: Not sure if this is a big one, but process of adding UOM PARAMETER to all MODELS could be a pain. But might be easy through Pro?Intralink or even Model Check.
I did open a PTC case and referred them to this discussion on PTC Planet. I will wait to see if they have any other revelations and let you know.
Mike
Hi Mike...
You have quite a quirky problem there! I think you're right, the underscore in "ptc_unit" is preventing the relation from working. I've suspected some problems with this before. There are only a few options that have an underscore in them. This is fine except they seem to violate the "replace the dot with an underscore" rule once you get to table relations.
This problem definitely gave me a workout. Doing battle with table relations is always a bit like stepping into the Twilight Zone. That's usually fun for me but this problem just ticked me off. So... I blew off the homework and quiz due tomorrow for my programming class and, hopefully, solved the problem.
Check out the screen shot below (click to enlarge). The BOM is live and using your relations (with one small change):
So what's the change that made it work? Well, the Pro/REPORT parameters you use to populate a table are a true disaster. Just a few revisions ago, you could find a comprehensive list of all the available permutations of these parameters. Today, the help files for report parameters have magically disappeared. This is an epidemic by the way... the help files just keep getting slowly worse... and worse. Somehow there's always less information, no pictures, etc. It's almost like someone want you to take a class to learn how to operate the software.... except that no one offers a class on how to do this stuff!
Anyway, it's late and I'm rambling... sorry!
The point is... there are so many possible permutations of report parameters, you can often find several strings of parameters that give the exact same value! After I couldn't get the ptc_unit tag to work, I tried some of the other variations and found one that seems to work. Instead of asm_mbr_ptc_unit_bomqty try asm_mbr_param_unit. See the screenshot below for the modified relations:
How in the world does that work? We didn't even have to provide the name of the parameter to interrogate. I mean... how does it know which parameter we're trying to get the units from? :Shrug: I dunno! Maybe it uses the last parameter defineed using the units_sensitive option. I'd be lying if I said I understood the logic behind it. I just know from experience that sometimes you can play with similar sounding parameter strings and you'll hit paydirt. Notice there's no extra underscore anywhere in asm_mbr_param_unit to cause problems!
One thing to note here, you must add the parameter to the local parameters at the bottom of the relations window before attempting to use it in the actual relations. This happens frequently. If you try to use asm_mbr_param_unit outright, you'll get a failure. Whenever this happens, you have to either go to the local parameters section of the relations window and add it by hand or else add the parameter to the table itself and regenerate. This second option just does the same thing as adding the parameter to the local parameters manually.
To add the parameter manually, just click the green "+" sign at the bottom of the relations window. Type asm_mbr_param_unit as the parameter name then click OK (or hit enter). For a moment you'll see the parameter set to "Real Number" and a default value of 1.000 but these will disappear once you select OK (or press enter). After this is done, you can freely use asm_mbr_param_unit in your relations and no failures will appear.
Hopefully this helps! I shouldn't write these posts late at night. This message is a monster! I could've just said "Use asm_mbr_param_unit" and you'd have figured it out. 
Let me know how it works... or if there are any holes in this solution I haven't found yet.
Take care...
-Brian
Brian,
I know how you feel, this has been driving me crazy. You would think after 20+ years that Pro/E (Creo) would have a simple way of generating a BOM that you can easily configure (per component) to drive the qty as you wish, either by EA, LENGTH, AREA, etc. and it would also be able to automatically list the units.
Thanks for your efforts. I did try the ASM_MBR_PARAM_UNIT also and it did seem to work. However, the only hole is that if you have units defined in more than one PARAMETER, in the model then you get multiple listings in the REPEAT REGION.
I added two phony PARAMETERS in the METRIC PART and gave them random UNITS. As you can see the METRIC PART has multiple listings now. NO DUP/LEVEL is applied as an attribute of the REGION.
This alone sent my whole perception of reality back. I had no idea that REPEAT REGIONS are driven by PARAMETERS and not the COMPONENTS.
In other words, I thought the REPEAT REGION simply had one row per COMPONENT (assuming no duplicates or no dup/level) and would then fill in the other cells in the table based on their value for that COMPONENT.
So, I am down to the following two choices.
- OPTION 1: Go with the above and if by chance we have a model that has UNITS defined for multiple PARAMETERS, then we could always manually filter out those lines. (I could not figure out how to filter out through RULE)
- Pro: If you ever change the EDIT SETUP UNITS, then the BOMQTY units automatically covert and update
- Con: You have to manually filter out any other lines that show up in the BOM because of addition PARAMETERS that have UNITS specified. This could be a pain if a component is widely used and is later updated to include a UNIT SPECIFIED PARAMETER, then through associativity, all the BOMS were it is used will show multiple lines and have to be filtered manually or if you could figure out a rule the rules would have to be applied to each table in each assy drawing.
- OPTION 2: Set up every model to have UOM PARAMETER and simply just list this directly in the BOM TABLE as &ASM.MBR.UOM.
- Pro: No filtering required, no multiple lines in the REPEAT REGION
- Con: If you change the MODEL UNITS ( EDIT SETUP UNITS) then you have to remember to change the UOM PARAMETER manually since it is a STRING
- Con: Not sure if this is a big one, but process of adding UOM PARAMETER to all MODELS could be a pain. But might be easy through Pro?Intralink or even Model Check.
I did open a PTC case and referred them to this discussion on PTC Planet. I will wait to see if they have any other revelations and let you know.
Mike
