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
Reply to
Rich
Loading thread data ...
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
Reply to
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
Reply to
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.
Reply to
Fye
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.
Reply to
TOP
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
Reply to
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.
Reply to
Fye
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.
T> Rich,
Reply to
matt
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.
Reply to
Jeff
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.
Reply to
TOP
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.
Jeff wrote:
Reply to
matt
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.
Reply to
Fye
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
Reply to
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..
Reply to
TOP
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.
T> It isn't just users that can tinker with the vault. If SW gets wind of
Reply to
matt

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.