Skip to main content
P
ptc-43929501-Visitor
1-Visitor
September 5, 2012
Question

small change on asm level, has effect on every component...

  • September 5, 2012
  • 2 replies
  • 4950 views

Hi,

i have an irritating situation that not always occurs, but at random occasions (what in fact bothers me even more).

When making a change to an assembly (ex, regenerating relations), ProE (WF4) asks me to check out every component of the assembly + their generics + all the other instances of those generics... that does not make any sense because Nothing has changed to any component!

and when saving the assembly and going to my workspace, all the components (those can be a lot, considering the entire family table of every component), they are all marked as Modified.. but absolutely nothing has been changed, modified, whatsoever to the models.

is their a logical explanation why this happens? because, if i don't check out and "modify" all the parts, I can't save my assembly.

p.s.

I have tried to select "continue" instead of "check out", but then (not kidding) my workspace is full with Newly created parts of all those models (entire family tables) that 'needed' to be checked out.

Grtz,

Arno


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.

    2 replies

    B
    BrianMartin13-Aquamarine
    13-Aquamarine
    September 5, 2012

    Hi Arno...

    A few things to note... there are actually quite a few reasons this can happen. You can resolve most of these reasons quickly and easily. First, try setting these two options in your config.pro:

    relat_marks_obj_modified no

    bump_revnum_on_retr_regen no

    The first one stops Pro/E from marking an object as modified due to a relation regeneration. The second stops Pro/E from bumping the iteration when a model is regenerated upon opening. Either of these could be causing your problem. If Pro/E thinks your model is being modified, it will ask you to either Check Out or Continue. You may also be able to select Make Read Only.

    If you make the model "Read Only", no modifications will be made to the model... and when you save, the affected models will not show up as "New". If you choose to make use of the Make Read Only option, you may also want to set this config.pro option:

    regenerate_read_only_objects no

    That last option stops Pro/E from attempting to regenerate objects marked as "Read Only". Note that this is different than setting the Read Only feature under the WF4 Edit menu. The Make Read Only option actually locks your file to prevent changes. To unlock it, you'd go to the File menu and deselect the Lock File option. Note: I do not have a running copy of WF4 so the command locations/options may be different. I'm using WF5 currently.

    If you choose the Continue command and save, you can remove the "New" models from your workspace. Simply remove them before attempting to check in your work to prevent errors. You may also be able to select all the modified/new objects and overwrite them with the last good non-modified copy from your Commonspace. Simply select the checkboxes for the modified/new objects you wish to replace and select the Add to Workspace command (or icon). This will pull down unmodified versions from the Commonspace and remove the "New" or "Modified" status.

    Finally, if NONE of these options work for you, there's an additional problem which can cause the auto-modification. It has to do with mass properties and family tables. If you're using the variable mp_density in your family tables to capture different density values for different material types, this can actually cause the problem, too. It's a total mistake from PTC... but they're not admitting it.

    For years adding mp_density to your family table was the only way you could have two different material types in the same table and have the mass properties come out correctly. If you wanted steel and aluminum represented in the same table, mp_density might be .286 (lb/in^2) for steel and .098 for aluminum. This was the only approved method for achieving this.

    Within the past couple of years, the ptc_material_name parameter is the preferred method to achieve the same effect. You load multiple material files into your model and use the ptc_material_name parameter to swap in the active material for difference family table instances. The assigns density based upon values in the material file. This is the "new" method... but supposedly the "old" (mp_density) method worked, too.

    Well... even since WF3, the "old" way causes your model to be marked as modified if mp_density is modified. The only way to stop this is to use the "new" method.

    So, in conclusion, if none of the config.pro settings alleviate the problem, look in your table for mp_density. If it's there, you'll need to remove it. You'll have to check out the entire family table, remove mp_density, incorporate ptc_material_name into the table instead, verify all of your instances, and check the generic and all instances back in. It's a monumental pain in the neck that should never have occurred...

    Now you know the rest of the story. This took my employer 6 months, several contentious email exchanges with PTC, and hundreds of lost hours in productivity to figure out. I hope you can benefit from our pain!

    Thanks!

    -Brian

    P
    ptc-43929501-VisitorAuthor
    1-Visitor
    September 6, 2012

    Hello Brian,

    Thank you for the extensive explanation, but I can't find these two parameters in the config.pro.

    relat_marks_obj_modified

    bump_revnum_on_retr_regen

    Perhaps these have to be added manualy? or...

    Grtz

    B
    BrianMartin13-Aquamarine
    13-Aquamarine
    October 7, 2012

    Hi Arno...

    I'm sorry I fell off the map for awhile. To respond to your last message... if you can't find these options in your config.pro, add them by hand. Trust me, they work.

    This will at least fix the problem with modifications occurring due to a regeneration of relations. Implement this and write back with any other problems. You may still see some issues with files being marked as modified. if so, that's fine... but write back and let me know. I've spent a significant amount of time working to resolve this kind of issue and I've gotten pretty good at it. There are many reasons these modifications can occur. I've given you some of the most common fixes. These should lessen the problem... but if issues still exist, there are other things we can try.

    Write back if you still want to investigate and I'll try to help.

    Thanks!

    -Brian

    T
    TomD.inPDX17-Peridot
    17-Peridot
    September 5, 2012

    This is a common problem across many platforms. Normally, hitting the ignore button took care of it but it also jumped right past legitimate issues.

    Brian's input is spot on to help determine the problem and some wise solutions from PTC. I think the diligence of the change control people and ECO incorporation is key in making sure someone doesn't destroy good data that only surfaces at another time. People don't always appreciate the connectivity of parts and assemblies across an organization when it comes to CAD tools.

    in UG NX, you change the color of a part in the assemly and it wanted to write that to the original part... which sure enough, was locked in Teamcenter. Yep, just hit "ignore" every time you save and exit

    Terms & ConditionsAccessibility statement