Library Components in PDMWorks

Hi

I'm just setting up PDMworks, boy is it querky but seems to work okay
mostly.

I wanted to check in all of my standard library components/toolbox
components (I have always copy on) for backup only, not to be revision
controlled.

This seems to work okay, except that when I go check out an assy, it wants
to check out all of the standard parts too. This means there are thousands
of files in the checkout directory and it is very hard to navigate through
it. Is it possible to disable checking out of standard library parts if
they are available already in the search path for standard parts? (They
reside in a shared network dir) At the moment I have just disabled checking
in of standard parts, but it seems a shame to have to do this.

Any ideas?

thanks

Rich

 

Rich,

What is one good reason to check-in a standard part. I have yet to
find one. The hex bolt you are using today is the same size as the one
used 50 years ago!

Your best bet is to not check-in common parts, this also makes it
easier to use the design library and toolbox.

Jeff

 

Jeff

That's the conclusion I was coming to. Just thought it would make sense
initially to keep them in there for easier backup (We have lots of non
standard bought in items too, not just nuts and bolts from toolbox)

Cheers

Rich

 

Many companies use their own part numbering scheme for standard parts
(nuts, bolts, etc.) , usually because of whatever inventory program
they're using. Additionally, you don't want 1000 copies of a 5/16-18 x
1" HHCS floating around... you never know when one will be designed
incorrectly and copied to someone else's project.

I really like PDMWorks, but I'll be the first to admit it's in dire
need of some serious interface improvements. We've still not figured
out how to get the library components (Toolbox) stuff working with it
yet.

 

Rich,

I think conventional wisdom for standard parts is to keep them in a
folder (tree) that is read only to users and read/write to the person
in charge of these parts. Since the parts are standard (read found in
Machineries Handbook) they are not subject to revision so they don't
need revision/version control. Therefore a PDM system is not a good
place for them. This is especially true with PDMWorks because it uses a
folder tree to organize files. Other PDM systems that use a database
won't have the over head.

 

Thanks for the replies guys. I think i'm going to leave the standard parts
in a read only dir on the network.

cheers

Rich

 

I know this thread is about finished, but that post made absolutely no
sense whatsoever.

There is nothing wrong with keeping standard parts in your PDM system.
I would argue that it's a BETTER method of storing your standard
components (as opposed to keeping them in a network folder) because it
centralizes where the designers get their models from, both standard
and non-standard.

What exactly do you mean by "Other PDM systems that use a database
won't have the over head"??? Please enlighten me why PDMWorks has an
"overhead" problem where Database-based PDM systems dont.

 

PDMW has a "newish" way to categorize library parts as non-revision
managed files. I like to put put libraries in PDM so that PDM reports
contain the hardware, you can do where used, and anything that breaks
the link with Toolbox is a good thing. Plus PDMW allows you to drag and
drop from the vault display into the assembly, so (aside from the
preview image) it acts almost like the design library. It is also
additional security against tinkering.

 

I have a question for all those who love to store standard parts in a
PDM system. What is stopping the user from renaming the file and
checking back in? In your scenerio, I could have 100+ 1/4-20 x 1"
fasteners in the PDM system all with different names but the exact same
geometry.

Do you all have infinite hard drive space?

And yes Matt, you can drag and drop from PDMWorks. But what happens if
the PDMWorks turns into PDMDoesn'tWork? At least the users could still
continue to create new assemblies with common parts.

 

Fye wrote:

What exactly do you mean by "Other PDM systems that use a database
won't have the over head"??? Please enlighten me why PDMWorks has an
"overhead" problem where Database-based PDM systems dont.

=============

PDMWorks keeps a lot of PDM data in text files in folders. Accessing
this information this way is a lot slower than a proper database
because there is more overhead involved. A proper database keeps all
the data to be searched in a very efficient manner for searching and
retrieval. My guess is that the non-revision managed files Matt is
talking about are either in the vault without filename munging and all
the other text files, or they are in their normal locations and
catalogued by PDMWorks.

 

There are some folders that users only have read access to, such as the
library folders. If they were really determined, they could put the
files somewhere else, but they could do that in any system. If someone
is determined to throw the toaster in the bathtub, nothing will really
stop them. You can't completely prevent stupidity or maliciousness, the
best you can do is to be prepared for it.

"Infinite" hard drive space is fairly cheap, compared to what it used to
be anyway. Backing it up is more expensive than the space itself. A
reasonable rev scheme combined with a reasonable purge plan will go a
long way to keep you from getting in trouble with drive space.

If PDMW goes belly up, you have more problems than just your library. I
guess I've been lucky with it. I've had some minor problems, but never
an access problem that lasted more than 2 hours. That's partly because
it was set up conservatively, with a conservative upgrade plan and
definitely testing of new versions before rolling it out for production.

 

Ok then. Good answer. However, it may all be for naught since I've
heard through the grapevine that it's possible PDMWorks may indeed
adopt a database-based system at its core. Anyways, we store well over
4,000 parts of all types in our vault and have not had a problem yet.

It's very important to make sure to set the vault up correctly (read
the manual, you know?), and one of the big rules is to NOT let any
users "tinker around" with the file/folder structure of the Vault. As
long as everyone works through the PDM clients, everything works OK.

 

You can have either in the vault or out of the vault for library parts.
If it's in the vault, it mungs the name, although there is an option
to keep an un-munged copy.

Matt

 

It isn't just users that can tinker with the vault. If SW gets wind of
where the vault is it can start pulling files directly from it as well.
At least that is what I once saw it do a few years back. At that point
we figured out how to lock the vault down so that only one
administrative account had access. I think some users originally
tinkered, but it soon got out of hand simply because there can be some
unmunged files in the vault.

I think if you asked the average SW user how to lock down the vault so
that only the PDMWorks program had read/write privileges they would be
at a total loss. SW won't give much help in doing this either because
it is a Windows thing..

 

Paul,

That's a stretch. If you have the copy latest files switch turned on
and if a user opens a file from there which is later referenced and if
that location is the highest on the search referenced files list (higher
than the local workspace), you could have a problem. It's possible, but
it's a stretch.

The average SW user isn't administering the vault. It's usually a more
experienced SW user, a documentation type or IT. Where it is a SW
person instead of an IT person, most people at least have access to an
IT guy to help with admin shares, backup and such. Of course I
recommend using an implementer to get going on the right track and to
get some initial training.