Family Table Failure

[JaJos]

A family table instance was mistakenly renamed in commonspace of Intralink. While the generic model will open without failures, all instances fail when verify is run.

Any assistance is appreciated.

 

[Tofflemire]

Hi Jajos,

This should not matter that it was renamed. Have you updated your workspace?

Tofflemire

 

[JaJos]

The workspace has been updated, same results. I have also tried new workspaces on different workstations.

 

[Tofflemire]

Hi Jajos,

Can you go into the family table instances and click open. Can you see why these are failing. You can freeze the failures. It sounds like you have a reference outdated or something was deleted.

Renaming something will not cause this, that is the best thing about Intralink, you can rename anything without having to worry about links.

Tofflemire

 

[JaJos]

The issue is fixed. There were missing references within the Family Table. As you said, the renaming had nothing to do with the problem. We had multiple users messing with the same family table.

Thanks
James

 

[looslib]

ALWAYS limit your standard hardware family tables to 1 or 2 people.


"Wildfires are dangerous, hard to control, and economically catastrophic."
"Fixed in the next release" should replace "Product First" as the PTC slogan.

Ben Loosli
CAD/CAM System Analyst
Ingersoll-Rand

 

[Tofflemire]

Hi Looslib,

I have to disagree with your statement. If you train people to use ProE correctly, then anyone should be able to modify family tables. The other thing with ProE is if you are lazy, then ProE will bite you in the Butt; like not verifying family tables are working correctly or letting someone else figure out why they are not!

Tofflemire

 

[RocketRonnie]

Anyone who contibutes to this forum, and has this in his signature:

"Wildfires are dangerous, hard to control, and economically catastrophic."
"Fixed in the next release" should replace "Product First" as the PTC slogan.

is not worth listening to, and should crawl back to the pathetic UG forum......

 

[looslib]

And how many votes do you have for useful tips?

Yes, we use both UG and Pro/E. UG since 1987 and Pro/E since 2001.

The first line in my sig quote was by an industry publication when WF1 was released.
The second line is mine because almost all of the complex and even some simple things just don't work in Pro/E. When you do get PTC to acknowledge the deficency, it takes a couple of releases before the users get usable code.

Now, go ride your Rocket out of here!


"Wildfires are dangerous, hard to control, and economically catastrophic."
"Fixed in the next release" should replace "Product First" as the PTC slogan.

Ben Loosli
CAD/CAM System Analyst
Ingersoll-Rand

 

[Heckler]

Rocket,

ease up a little.....a rough day at the office doesn't mean you take it out on a valuable participant in this forum. I'm just thankful we use Pro/e 2001 and SWx and not Inventor....keep up the good work Ben.

Best Regards,

Heckler
Sr. Mechanical Engineer
SW2005 SP 4.0 & Pro/E 2001
Dell Precision 370
P4 3.6 GHz, 1GB RAM
XP Pro SP2.0
NIVIDA Quadro FX 1400
o
_`\(,_
(_)/ (_)

"There is no trouble so great or grave that cannot be much diminished by a nice cup of tea" Bernard-Paul Heroux

 

[Tofflemire]

Hi Looslib,

I have to apologize for starting this wasteful out of context discussion. My point was if you spend a little more time training people, then everyone should be able to make changes without breaking family table items. Then all the users can be trusted to do things correctly. If you start limiting access to things then this creates tension among the users which reduces productivity. Pro E can be fun if all are involved with the design and improvements.

Tofflemire

 

[looslib]

I was very specific in what I said should be limited access to family tables: Standard Hardware.

The reason I say this is that we have a corporate standard hardware system and we store these items separate from other types of hardware.


"Wildfires are dangerous, hard to control, and economically catastrophic."
"Fixed in the next release" should replace "Product First" as the PTC slogan.

Ben Loosli
CAD/CAM System Analyst
Ingersoll-Rand

 

[Guest0527211403]

Ben is right: Limiting write/modify access of certain components to a couple of people is good practice for any company, and no doubt a must for a company like I-R. I wouldn't want anyone screwing with my screws (ooooh bad joke for the day)...

If users want to modify or add a component size to a family table, they should e-mail one of the people who are responsible for this in the company and request this change [or just walk over to their cube and ask]. The problem faced by the OP proves why you would want to do this.

Family Tables do require ownership of some kind. While it is good to train everyone properly, like Tofflemire suggested, that training should reflect the fact that uncontrolled changes to Family Tables can indeed be "dangerous, hard to control, and economically catastrophic." ;-)

 

[Tofflemire]

Hi All,

It looks like I opened a can of worms. Looslib and Justkeepgiviner do you use Intralink or another form of file control system. With Intralink you can go back and look at the revision history and see the changes, which made them and even delete the problem. We used to ask people to make changes like you said, but this was a waste of our guy’s time always waiting for these changes to happen or even find someone to do them. Then the person who was in charge of making changes was complaining that his own work was not getting finished because of all the interruptions...

Tofflemire

 

[Guest0527211403]

It's still a valid discussion, and on-topic...

When I was working for a consulting firm I worked in environments with Intralink, third party PDM systems and nothing at all. Each have their own nuances, and Family Tables are always a soft spot.

It depends on what you are doing, really. If it is standard hardware that looslib was referring to, there really shouldn't be a need to change the Family Table once it's done. When I was tasked with building part libraries for companies, I tried my absolute hardest to ensure that I covered every size offered by the vendor (I usually did it with a catalog in front of me). So, typically, those Family Tables should be regulated by a CAD Admin or someone who has been allocated this responsibility by the boss (maybe the boss him/herself? lol, not where I've worked.)

Now, for non-standard components that vary in size, there should still be some form of ownership over the family table. This may go to someone who is working on the project directly. Having a single person who manages the changes to the shared family parts is more of a "good practice" thing to do, since it reduces the possiblity of error and lost time spent trying to figure out how the Family Table got buggered up in the first place. Understandably, not everyone can abide by this all the time, and for that, it's good to have a tool like Intralink to find out what went wrong.

 

[looslib]

Tofflemire,

We have used Intralink until 4 weeks ago when we switched to PDMLink 7.

There is a lot of missing functionality in PDMLink compared to Intralink, but PDMLink 8 is suppossed to be an improvement.

Do you ever have a user create a part that should be in a family and then you add it to the family table later? Intralink does this fine, PDMLink 7 won't do it. This is just one area that we are hoping PDMLink 8 will improve. We keep hearing that PDMLink 8 is much closer to Intralink 3 in functionality.



"Wildfires are dangerous, hard to control, and economically catastrophic."
"Fixed in the next release" should replace "Product First" as the PTC slogan.

Ben Loosli
CAD/CAM System Analyst
Ingersoll-Rand

 

[Tofflemire]

Hi Guys,

Thanks for you responses. I work and for a long time for the same small company. We used to have delegated personnel for different things. I found and still find this to get something done through all the red tape. We now practice cross training. This is great because everyone knows what each person is doing and maybe suggests a better way. This only happens because the people get to know the systems. 2 heads are better than 1. I do agree with what you are saying at limiting access especially to the new users, but they have to learn someday, because you will be on vacation, sick or find another job. So why not just train everyone, then have no worries or one go to guy to get the work done, I like to keep my options open when I need more than 1 thing done at the same time...

Tofflemire

 

[Guest0527211403]

While not necessarily making a roadblock to changing the family tables, there should at least be a speedbump.

My experiences have shown me that how duties are delegated always varies from company to company, even office to office in the same organization. I've found that in a small company, it is inevitable that cross-training will happen and responsibilities such as this are shared. Often if you need to ask about something just to make sure it's okay, all you need to do is turn your chair around. And if the person who should be on top of it isn't at their desk, you can leave them a post-it on their monitor just to give them a heads-up.

But in other situations, where data is shared across different offices in different continents, this "ownership" is practically a must. Two heads are definitely better than one, but 20 heads won't get that much done if they don't all play their specific part.