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

[Dale_Rosema]

This is very baffling.

I thought we had fixed this with verifying the instances in the table.

I have a drawing that shows instance 9504-01<9500> in the model tree, but the BOM has the parameters from 9500 generic part. (See BOM_INST.jpg)

I checked to make sure that the instances of the part had been verified. (See BOM_INST2.jpg)

I regenerated the drawing and now instance 9504-01 <9500> shown in the model tree also is shown as 9504 in the BOM (See BOM_INST3).

What else could possibly be going on with the drawings/parts? I would like to avoid having to regenerate every drawing before printing to make sure that the BOM is correct.

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]

Hmm...

Does anyone else reading this remember if Instance Accelerators or Instance Index Files have anything to do with family table parameters? I don't believe so but I haven't used them in so long I'm no longer sure of what's in them.

Dale: Again, something is very odd with your family tables. They're behaving as though they're not regenerated yet this shouldn't be the case. Would you consider making a dummy assembly of items... maybe something not even related to whatever your company builds... and backing the whole thing up, zipping it, and posting it? Include that weird 9504 family table and your drawing with the BOM on it... but everything else can be fake.

I feel like if I can play with this thing, I can probably fix it quickly. As an alternative, I'm going to email you another possible way to address this issue. Check your email.

Thanks!

-Brian

[Dale_Rosema]

When asking my reseller (are they called VAR's in the Pro world, or is that the other software) this is some information that I got concerning Instance Accelerator Files:

(He also mentioned that CREO automatically turns this funtionallity on)

This is the description per ptc:

Description
-----------------
When does it make sense to save an accelerator file for a family table instance? Should an instance accelerator file be saved for every instance in a family table?


Resolution
-----------------
What benefit do instance accelerator files provide:

-- Accelerators are needed to view instances for the fast streaming preview of the Object Informati
on report**

-- Increase the regeneration performance of complex instance geometry containing a large number of
features

When generating accelerator files to utilize the fast streaming preview functionality, avoid creating accelerator files for those family table objects that do not vary much. In some cases, the generic will be sufficient to demonstrate the geometry of the majority of the family table. For instance, a preview of bolt or screw that varies by only it's length dimension can be satisfied by an image of the generic only. This will reduce the over all number of files and dependencies to manage in the database.

Certainly, in the example of a sheetmetal flat state, an instance accelerator should be generated. This is a classic example of an instance that varies significantly from its generic.

Finally, accelerators have always been beneficial in increasing the regeneration performance of complex family table objects. Create instance accelerator files for those objects that will benefit from this functionality.

Pro/INTRALINK users and administrators should consider the above cases when determining a policy for creating and managing instance accelerator files in the database.

**NOTE** Pro/ENGINEER does not create the required dependency between the instance accelerator and the family table instance when the object is saved to the workspace. Please refer to TAN 111802 for more information on this issue and a workaround.

Essentially, they speed up family table instance retrieval.

[BrianMartin]

Hi Dale...

Yeah I've read that tome from PTC before. It's a bit confusing in my humble opinion. I know the what the accelerator files are used for. There's also the Instance Index file which keeps track of what instances belong to each generic.

The way I see it we have several clues. First, you're working "wild west" style without any data management software. This whole process is rife with pitfalls from the start. Users will eventually start having dozen of directories with the same files duplicated all over the place. A meticulously maintained search path file is critical for operating in this environment (using the search_path_file option in config.pro).

It seems to me that this is somehow related to your problem. The instance accelerator files aren't required... but the Instance Index file might be somehow contributing to the problem. Here's a scenario...

Let's say you modifiy an instance of a library item (and you're working without a data management net), then you save the file. The Instance Index file is updated to contain data about the instance and it's generic only. All of the other instances are NOT written to the file (depending on your config.pro settings but this is the default). Let's say that LATER you want to try out some design changes- but you don't want to modify your original models. SO, you make a copy of your entire working folder for safe keeping. You go back to work making changes in the new folder. You open another instance, edit it, and save.

Now you'd have two instance index files with different information in each.

Finally, you realize you shouldn't have two sets of library parts so you delete one set. Unless you've used the Update Index command in both directories, you could hit problems. In one directory, the instances have been removed yet the index file still thinks they're available.

Maybe... just maybe... something like this is happening. Maybe the system is finding one family table before another duplicate one due to search paths. Maybe dueling instance index files are confusing the system requiring a regeneration to sort it all out.

I feel like I'm reaching here but without being able to see the problem, I have to believe it's got something to do with the way your work environment is set up or the drawing BOM itself.

Is there any way that you might have more than one copy of the same family table? Do you have many directories all being searched with the "search_path_file" or are you using the search_path options in your config.pro to control the way the system retrieves your models?

Any input might help me narrow down the problem.

Thanks!

-Brian

[Dale_Rosema]

The first thing - thanks to my predicessors, is that we have close to 45k files in one directory, no sub directories.... so I don't have duplicate files in duplicate folders becasue I don't have duplicate folders, just one BIG folder. This also simplifies my path file, because it only points in one direction, to the big massive file.

I appreciate the thoughts and am working on this as I have time.

Thanks,

Dale

[ReinhardN]

Hello Dale,

is there an option save_display yes/no in your config.pro ?

If a drawing is saved under this option

- yes means the drawing will be opened as saved. You have to update your drawing, regenerating wont help.

- no means drawing will be regenerated on opening.

This has bitten me too. Who invented this should be tarred and feathered. You open a drawing and it may show an old state of the model. You are in danger if you publish your drawing.

This option must be part of the opening dialog where I can select it when I want.

Reinhard

[Dale_Rosema]

Reinhard,

Thanks for the heads up.

save_display is set to no*, so it is supposed to be regenerating upon open.

Thanks,

Dale

[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.

WOOOOO HOOOO!