Regenerate for correct BOM, even after save, close and reopen.

[Dale_Rosema]

I have BOM's that are automatically generated within drawings. There are times when I'll open a drawing and one of the rows are blank. When I regenerate, the proper data fills in the lines, but why is this necessary when opening a save drawing?

Thanks,

Dale

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[BrianMartin]

Hi Dale...

I'd check that component. Go into the component that's appearing BLANK. Make sure there are no problems with it. It seems like all the other components are reporting correctly but that ONE is not- until a regeneration occurs. The regenerate command is probably updating the component... not necessarily the drawing.

What I'm saying is... I'm not sure the culprit is the drawing... maybe it's the component itself. Check there and let us know what you find.

Thanks!

-Brian

[Dale_Rosema]

Brian,

I opened up a part today and replaced one component, 1120 with 1120CTN. It. #1 which I have used before, dissappeared on the BOM (as far as description and part #) when I came back into the drawing.

After regenerating, it shows back up as It. #2 - foam pad.

Thanks,

Dale

[BrianMartin]

Hi Dale...

Take a look inside that 9770.prt file. THAT is the object which disappeared. The shifting of the item numbers occurs because Creo is sorting on the part number string. When 9770 isn't reporting, (as in your top image), it goes at the bottom because "nothing" comes first in the list. Later once 9770 DOES report, it belongs after 9711 and 9687 in the sorting order.

So I wouldn't worry about the reordering. I would still take a look inside the part that disappears, though. What parameters are there. What relations are in this part (Tools->Relation)? Are there any relations set for your BOM table that could be complication the matter (Repeat Region->Relations)?

And does this BOM update after you Update the sheet... or after your Regenerate the model. That's a big clue.

Thanks!

-Brian

[Dale_Rosema]

The part checked out OK. The parameters had already been set and were defined. The part had been saved (since when I pulled it up, the parameters were all there and defined). I have always done regenerate, but I will try updating the sheet the next time it happens.

If update works, why would I have to update the sheet when I open it, versus it being already updated from the last time I saved it?

As far as the shifting goes, I understand that, and am not concerned. It is just doing and automatic sort.

[BrianMartin]

Hi Dale...

Do you have the config.pro option auto_regen_views set? Just wondering.

Also... try this:

1. Call up the drawing and figure out which item is showing as blank
2. Open the "missing" model and regenerate it... not the whole assembly or the drawing, just the part that isn't showing up.
3. Switch back to the drawing and activate it. Does the part show up now?

If so... the part is the problem. If not, the drawing is the problem.

Do you have any relations working inside that BOM table? Some companies set relations to perform certain functions in their BOMs. You can check this by going to Repeat Region->Relations and clicking on the table.

You've said the parameters in the part look okay... but what about relations? Some companies will create a relation to construct a parameter. For example, my "company" has two descriptions called DESC1 and DESC2 (that's not what we actually call them but go with it for simplicity's sake). So we have two parameters... then we also have one RELATION that makes a new parameter. The relation says:

FINAL_DESC = DESC1 + ", " DESC2

So for example, if the parameters are as follows:

DESC1 = Cap Screw, Socket Head

DESC2 = 1/4-20UNC X 1.00 Lg

The relation would set the parameter FINAL_DESC as follows:

FINAL_DESC = Cap Screw, Socket Head, 1/4-20UNC X 1.00 Lg

Depending upon when I tell Pro/E to execute that relation (initial or post-regeneration), sometimes FINAL_DESC will actually be blank until I hit the regenerate button. If your company uses such a relation, you may have a blank parameter that only updates when you regenerate. If the above 3 steps cause the missing part to show up in your BOM, the problem is definitely in the part.

There are some options to save a "quick viewable" version of your drawing when you save it. When you open the drawing, this "quick view" is displayed instead of having Pro/E go through the computations to actually redraw the views. This can also play into the problem.

In short... this shouldn't happen. When you save, the drawing should stay as it was. If it's not doing that, there's some relation, table parameter, config option, or other oddball setting causing it. We just have to narrow it down until we figure it out.

Thanks!

-Brian

[Dale_Rosema]

When I pulled up the part that was missing on a BOM this morning and did a regen on the part, the BOM was not updated automatically. I also tried Table_Update-Tables.

I have relations, but this is the the half part quantities. This part is not one of these, and the quantity shows up correctly just the part number and description are not being pulled up from the parameters of the part.

Where do I find the auto_regen_view? I don't see it in Drawing_Options nor in Tool_Options.

Thanks,

Dale

[MartinHanak]

Dale,

the correct name of config.pro option is AUTO_REGEN_VIEWS (see S at the end).

Martin Hanak

[Dale_Rosema]

Do you know where I would find AUTO_REGEN_VIEWS ?

[MartinHanak]

Dale,

AUTO_REGEN_VIEWS is config.pro option (Tools > Options in WF5).

Martin Hanak

[Dale_Rosema]

I think I may have stumbled onto something today, but maybe someone else could explain. I am still having problems with empty spaces in my BOM's that go away when I regenerate. The part happens to be from a family table. When I open up the instance, the parameters values do not show. When I open the generic, in which the parameters have values, they show in the family table. This could be causing the values for the parts not to be showing up in the BOM of the parent part.

My question is why when you open up the instance, does the parameter values not show from the family table/generic that the part was created from?

(I just hit regen on the instance and the parameters populated).

Thanks,

[Dale_Rosema]

I saved the instance, the generic, and the parent part.
Closed. Cleared all files.

Now when I open the parent part, the BOM is propegated.

If you save the generic part without saving the instance, does this make the instance incomplete?

[Patriot_1776]

If you VERIFY each instance when you save the generic, it all should work.

[Dale_Rosema · Accepted solution]

While talking with a rep, after getting some new licenses installed, I was showing him this problem.

I noticed that the UM (unit of measure) had propagated, but not the description nor the PN (part number) parameters. (See WW_BOM_7)

I also noticed that UM was the only parameter filed in on the generic part even though the parameters had been filled in on the instances needed.

I quickly tested that discovery by adding values for the parameters of the generic. (See WW_BOM_8)

I saved the generic, the instance and regenerated the assembly and save it and then even closed out of Pro-E.

When I open the assembly, the values for the BOM table were in place and intact. (See WW_BOM_9).

The explanation that I received is that the null values in the generic are triggering the part to not regenerate the parameters of the instance into the BOM table. Once these values were no longer a null value, they will automatically propagate the table.

I forgot to add:

WOOOOO HOOOO!

[BrianMartin]

Hi Dale...

To answer your first question... "why... does the parameter value not show from the family table generic"? The answer is.. IT SHOULD!

If you save the generic without VERIFYING the instances, then the instance does show up as incomplete. Depending upon what version of Pro/INTRALINK you're using (if any) you may be prevented from saving or checking in a file unless those instances are verified.

Open your family table (in the generic) and select the verify command (hover over the icons... you'll find it easily enough). All of your instances should verify as "successful". If they do not, troubleshoot the instance and repair it such that it can verify successfully. One final save of the generic should be sufficient to lock in the values.

Now then... I have seen occurrences where a family table acts strangely. These are exceedingly rare but it's possible for a family table part to become corrupted (just like any other part can become corrupted). Again, it's tremendously rare on the order of one bad part every other year or so. Personally, I have one of these bad family table parts right now. It continues to do odd things even though I'm doing nothing special with this piece. It's the simplest possible table and yet, instances refuse to verify... or get "dropped" from the table. The only way to fix MY problem part is to remodel it. Hopefully you're having a problem that doesn't requrie such a drastic resolution.

Let us know how you're progressing. It seems like maybe you've gotten the problem resolved but who knows if it'll crop back up again!

Take care...

-Brian

[Dale_Rosema]

I found the verify button in the family table. Didn't know it even existed. And from looking at some older models, neither did my predicessor nor his. I understand that verify checked to make sure the instance works, but from a CAD stand point, what exactly does the verify botton do for you in the long run? What all is affected (effected) by the unverified models? Do I need to take a day or more and go through the many, many family tables and varify the instances and resave?

Thanks,

Dale

Also, would it be best to verify models from the top down, or from the bottom up?

It took about 20 minutes just to verify all the instances in the first / test part.

[BrianMartin]

Hi Dale...

The verify button makes sure your instances actually WORK. It's possible to create an instance in your family table which does not actually regenerate. Verify catches this. In the past, having unregenerated instances wasn't advised but it was still accepted by the data management system. Now, unverified instances are simply not allowed. You MUST verify them if you wish to process them using Windchill or Pro/INTRALINK.

You should always verify your instances. I'd verify them as you see them and save them. It sounds like you're working in "wild west" mode where you use folders on your C: drive to manage and maintain your files. This is tough to do. But I'd say in this type of environment, verifying your instances might be even more important.

Do you make use of instance accelerator files? If so, this is another good reason to verify your instances. You want to make sure ALL of those instances make it into the instance accelerator files so Pro/E (or Creo) can find and retrieve those instances as efficiently as possible.

Thanks!

-Brian

[Dale_Rosema]

Forgive my ignorace:

Instance Accelerator Files?

We are a one seat show, so we have no Windchill or Pro/Intralink.

Is there somewhere that I can learn more about this?

[Patriot_1776]

Yeah, what Brian said!

"Wild West Mode".....AWESOME!

[Dale_Rosema]

I just wanted to thank all that replied to the various threads that I had on this issue. I posted the correct answer in each for those that follow.

Brian - I unmarked yours as correct, but was very thankful for all the help that you were able to give in helping me learn about family tables and their instances. - THANKS!

Dale Rosema

[BrianMartin]

No problem Dale...

I'm really glad you finally got this resolved. This was one of those things that would've been easier to diagnose with an actual model to work with. Working online is an imperfect medium. What counts is- the problem is solved and if anyone ever expereinces it again, the solution has been well documented!

Take care...

-Brian