PDMWORKS Q?

Matt,

I was responding to Kav's following question:

"Do all the PDM softwares with other cad
packages Pro/e, catia, ug work in the same fashion? They also find it
difficult to handle multiple configs or multiple sheets? "

If Kav had an understanding of how other programs solved this issue he
wouldn't have asked the question.Thought since this is a SW user group
I'd provide some information on how other people were solving the same
issues with other programs. Used PDMWorks for 3 years at JDS Uniphase
and liked the program for what it was. I had it working mult-site and a
whole slew of other things before it became fashionable. Even wrote a
specification for an ECO module that was requested by SW Corp. Got to
know Joy quite well in our email and phone discussions.
Guess my assumption was incorrect. Sorry!

I use DBWorks as the foundation for an integrated engineeing package
for small engineering and manufacturing firms (MCAD, Document Control,
Accounting, Manufacturing, etc..). Its based on a business model I
developed over the last 15 years as a mechanical designer.

As for pricing, you might want to give integrated partner solutions
www.na-ips.com a call. They are a North American Platinum Reseller of
DBworks. They could supply you with the pricing for different flavours
(Workgroup vs. Enterprise) etc.....
Like most people have discovered first hand..... its not the software
but how you incorporate the business process that makes or breaks the
application.

My appologies again if anyone was offended by my attempt to provide
information on a problem people are having. I'll keep my "sales"
opinion to my self from here on in.

Have a good weekend people.

Cheers,

Len

 

Matt,

Why are you so upset with someone posting a solution to someone else's
problem, it makes you sound like a salesman for PDMWorks!

 

I'm not upset. I'm not a salesman.

I'm also not interested in pissing contests with salesmen. With your
previous posts, I see a plonk list entry with your name on it.

Len had some useful content in his post, although his "lack of
understanding" comment was a little condescending.

 

It depends. Here I have a separate number for drawings and parts
because we have so many configuration driven parts. The drawing will
typically get its number from the first of the design table
configurations it contains but not always.

 

Manual control of revision, at a casual glance that seems to defeat the
purpose of PDMW.

If you release a drawing to a vendor and then decide to make a "cosmetic
change", you now have a different document (which is "usually" cause for a
red line, then revision roll). Of course if the document was not released,
then there is an option in PDMW to overwrite the current rev.

 

Hi,

Thanks for all your replies.
Another question. Why in PDMWorks we always have to enter the NUMBER
and DESCRIPTION although we can skip it initially. In my case
description is always same as the file name. Can it be mapped to the SW
- FILE NAME or shall I stop filling in DESCRIPTION properties and start
using SW - FILE NAME in title block and BOM?

TIA
Kav

 

Yeah, that's just one of those little annoyances. I just hit the button
that says "don't ask me again", and I'm done with it.

I did write a macro that copies the filename to the Number property.

Let me know if you're interested.

Matt

 

Thanks Matt,

Do send me that macro to . I will modify that
macro that will copy filename to Description property.

Thanks
Kav

 

oh...

Matt ..the mail id is
ksbawa
@
rediffmail.com
It will certaily be very handy..
Thanks
Kav

 

PDMWorks revisions are really file versions. Anytime a file is checked
in its version changes. But such checkins can be for reasons having
nothing to do with the intent of the drawing, model or assembly to
communicate a specific version of a part. For example, when the you go
through the feature tree and rename the features is that a revision
change or a file version change? It is not a revision change because it
changes nothing having to do with the documentation of the part. When
you add a new part to an existing model via configurations and check in
the new model is that a revision change to the pre-existing part, NO.
But it does change the version of the file. When you move the location
of a part referenced by an assembly and update the assembly to reflect
this change is it a revision change or a version change? Revision
changes are what the rest of the company understands regarding the part
being documented. Version changes are what PDMWorks understands because
it is tied to the SolidWorks software and they do not necessarily have
a direct bearing on the form, fit or function of a part.

 

Hi Matt,
I'd be interested too.
My email is mgibeault
I am at alto-design
and it's a dot com

Thanks,
Marc

 

Wtih PDMW I guess the terminology can be confusing in regards to the file,
revision or version. Although you say PDMW tracks versions, the PDMW folder
structure reflects revisions in the vault.

All I can say is , we use PDMW to track revisions and it works for us.

 

There is no confusion. What PDMWorks tracks is versions of a file and
calls them revisions. Just as a for instance. You have completed a
design of a sheet metal part in as a part document, it is approved and
you check it in as revision 1. It then goes to somebody else to make
the detail drawings. They are going to open the part when they start
the drawing. In the process they create a flat pattern and this creates
a flat pattern in the part document. It has already been checked in as
revision 1 reflecting the approved form fit and function for this part.
Now the drawing module goes and changes the file by inserting a flat
pattern configuration. You must still save the part as revision 1.
What are you going to do?

 

Ok, versions it is.

We try to keep it simple. Here is a "basic" outline.

We use 2 tables of revisions and the infamous "working copy" denoted by the
+ sign. We find that the "working copy" is great for, filling the gap
between interruptions, workdays, etc.
--, X1, X2, X3, etc...
-, A, B, C, etc...
-- is a new component. - is an OEM component.

Majority of our parts are prototyped first and will use a revision of X1,
X2, etc.

If said model is new; it goes in at rev --. If handed off to someone else
to detail, the model goes to --+ (working copy) and the drawing goes in
at --. When document has been checked and approved both roll to X1.

At this point it's possible for drawing to get ahead of model in regards to
revision (notes left off drawing, missing dims, etc...). Having said that,
when the component is ready for production, model and drawing will roll to
rev A. Once again it's now possible for drawing to get ahead of model in
regards to revision.

The following assumes the model (at rev A) changed. By default, since model
rolls the drawing rolls.
If said model is existing; model and drawing go in at rev A+. When document
has been checked and approved, model and drawing roll to B.

The following assumes the drawing (at rev A) changed.
If said model is existing; drawing goes in at rev A+. When document has
been checked and approved, drawing rolls to rev B (model stays at rev A).

 

We did something like that. It takes a lot of discipline and one
mis-checkin and you are toast. And if you have configuration parts you
are completely out of luck. In fact it is the configuration parts that
drives me to make a big deal out of the version / revision terminology.


TOP's Rule of PDM

Parts govern revision changes
Computer files govern version changes

 

I think discipline will be required for any PDM system and the procedure
associated with it. Also, I think mis-checkins are subject to happen no
matter what PDM system and procedure are in place. Just hope someone
detects the mis-checkin asap. Having the ability to roll back and/or
overwrite goes a long way to correct these unfortunate mistakes.

We don't use config's in parts to represent multiple part numbers. PDMW
can't deal with them anyway.

 

Speaking of discipline, at least as far as documents are concerned,
what do you think the top five discipline's are that PDM enforces?

 

Those just happen to be the 5 things that elude me at the moment (brain
refuses to go into gear). Any hints or answers appreciated.

 

1. One part - one filename - one file
2. One part - one person making changes at a time
3. Your turn.

 

Ok, except I prefer the term model. Model = Part Number

1. Exception: Sheetmetal Models (part + pems = assy). Part & Assy carry
same filename. The differentiating factor is the file extension. Drawing
is logically connected to assy.
3. One model - one drawing (model name = drawing name)
4. Ooops, brain locked up again.

On a side note, I think it would be more logical if PDMW hierarchy
(parent-child) had drawing as parent and model as child. Or at least have
an option to display in this fashion. The tree in vault would show
primarily drawings until being expanded. Seems nice just thinking about it.

We also use the lifecycle feature which helps automating privileges as
components are checked in and out. This and the collaboration options in
Solidworks are great features. 2006 has some nice enhancements and I'm
looking forward to upgrading PDMW.