System Parameter Values in family table

[crichard]

Hey everyone - we've recently upgraded from Pro2001 to Wildfire 2.0 and are running build M080. After working through all of the bugs in M040 & M070 we've amazingly landed on M080. However, regardless of the build when we open most of our 2001 assembly's we get an error that says "system parameter values in family table may not be up to date for XXXX<XXXX>prt" as the assembly loads. It doesn't seem to cause any noticeable problems other than slowing down the opening of an assy.


Has anyone else seen this? I put a call in with PTC on Monday but as of today they are still working it. Any ideas at all?

 

[slashct]

Yes we get that as well and there are a couple of causes that PTC has told me will cause this, and I am sure that they will put you through similar hell, once these are done it seemed to get rid of the problems on most still some cause problems. I assume that you have Intralink as well, so get ready and get the vaseline out so things go smoother:


1. All Family tables need to be opened and verified, and saved in WF2.0 (weeks of work for me) since the format changed.
2. Any value in the Family tablethat is an * (default) needs to be set to an actual value (causes the error message)
This is true for parts as well as assemblys.

 

[slashct]

Oh I forgotone last thing they might tell you to set some environment variable cannot remember what it wasits bogus dont.

 

[crichard]

Thanks for the response.. PTC just made my christmas week.

 

[crichard]

Hmmm.. something interesting happened.. I was in the process of bringing all of our standard parts up to WF 2 and it's crashing a couple of our assemblies. Any ideas on that???? Assembly just starts to open and then blows out to the desktop.

 

[slashct]

Heres what the problem might be. For some reason in Intralink if the family table is not updated it begins to check the instances in the family table out one at a time. If the database is not connecting correctly this could be the culprit. I had 25 part assemblys that were taking 15 minutes to bring up because it was checking out 100s of parts of the standard fasteners and such.
DId not have it crashing out, only when the network connecting was broken.

 

[[email protected]]

The option is:



verify_on_save_by_default no*



(no is default)



I have had issues with this verifying as I use Pro/INTRALINK and unless
you set everything to read-only off, you'll be verifying forever as the
verify status will not be saved to parts marked as read-only or locked.

 

[crichard]

I've had numerous assemblies crash out... still have one that isn't working.. but one thing that fixed a few assy's is the /3GB switch in your boot.ini. PTC has a lot of information on this as I called them. However, it only works on XP and make sure you have Sp2 running other wise you blue screen on boot up (bah). Anyhow, type in "boot.ini /3GB" in google.. you'll get a ton of info on it... this resolved a lot of our assy's crashing because when your xtop.exe process uses more than 1.6gb of ram it starts to blow out (windows has limitations which limit how much memory a single process can use. Windows claims 2GB, but PTC claims there are issues between 1.4gb and 1.9gb of ram for the XTOP.EXE process). When you flip the 3GB switch it allows up to 3Gb for xtop.exe.





With that said, we're still got an assy that blows out to desktop at 272mb of ram.. no idea whats wrong. Opens fine in WF 1.. but not in 2. Bah.

 

[[email protected]]

also on the /3gb... you HAVE to use certified XP drivers for all the
hardware, as rumour says you'll get BSOD or really crappy performance.

 

[crichard]

Oh really? I missed that - thanks for the input. We are preparing to implement here on a few machines. I will definitely make a note of that to tell our tech guys.

 

[Dell_Boy]

1. All Family tables need to be opened and verified, and saved in WF2.0 (weeks of work for me) since the format changed.
2. Any value in the Family tablethat is an * (default) needs to be set to an actual value (causes the error message)

Will someone please tell me that this is a bug that only affects M080
and that an urgent SPR has been filed for it because this will cause
huge problems for me and lots of other users who have been using Pro/E
for years and have built up extensive databases of parts and assemblies.



I use *s a lot in family tables particularly when dimensions relate to
a feature that is turned off in one or more instances. Having *s in the
fields to me means the dimensions do not matter as the feature has been
suppressed.





Dell Boy