Making files read-only

We use a "read-only" system, and find it generally satisfactory.

The big trick in getting it set up was to have a good document control procedure. The released documents are all on the server --only the doc control guy has write access to the relevant directories. Everybody else has read-only access

...

External / in-context references can get hosed up in a hurry, but in general, your released data needs to be protected in some way, so you're doing the right thing.

I PDF drawings to a released folder then print from there, when they get up issued I suffix the part with -B -C etc to keep the history, this also enables quick batch print. you really need to buy Adobe 7 pro, this makes life much easier

steve

Kalle,

I understand exactly what you mean. I do use a lot of in-context stuff here.

It is because of a SIMILAR situation that I opted NOT to go with a PDM system here as well. Picture this: You have an assembly that does have a lot of in-context references. You make a change to one of the parts. Since other parts have references to this part, they automatically rebuild. That makes sense. However, the change that you made to the first part, didn't actually change the geometry of the second part. Yeah, it had to rebuild, since the first one did change. But the geometry ends up staying the same. Since the second part did rebuild, it will have to get saved when you save the assembly. That's fine. Although I personally wish that SW was smart enough to know that if the geometry didn't change, it don't need to be saved again. That ain't gonna happen! And I do somewhat understand why.

Back to the point. The PDM systems that I looked at several years ago would look at the save date to help determine whether it was a new revision. Well, if the geometry didn't change on the second part, why would it need to be a new revision?!?!

Since none of the PDM systems that I looked at had a foolproof way of determining the difference between a model that actually changed, or a model that just got saved more recently, I opted to go the route of making my files read only when I am done with a project. I use PDF files to track any drawing revisions. And to track model revisions, I will either export to parasolid, or simply make a copy of the file and rename (depending on the situation).

This scenario brings me to a second point that has always bugged me. Let's assume that the change to the first part did in fact cause geometry in the second part to change. It might have been minor. But it did change. I wish SW had a way of actually showing you what changed on referencing parts. Sometimes it is impossible to tell graphically. I usually have to rebuild the drawing for that part and print it. Then print the original PDF, and sit down with the 2 drawings side by side and compare dimension to dimension with a highlighter pen. This is a major PITA. I hope someone will be able to tell me something that I have always been missing here.

Kalle,

The easiest way to do this is to disassociate the released drawings from the drawing/model in the form of master PDF documents.

The way I would handle this to have the PDM system create a released database. This database, which manufacturing personel have access to, maps only approved drawings and models (i.e. Major revisions such as A, B, C, etc..). Thus, the engineers can play all they want with prototype revsions (X1, X2, X3, etc...) and reworked production drawings/models (A.1, B.2, C.3, etc....). PDM system is smart enought to know that making changes to one referenced model may update the other - if not all ready checked out - it will advise user that in order for the changes to "stick" they will also have to check out the referenced part/assembly as well.

It is only when the approved drawings/models make it through workflow that they are released and the production (released) database is updated with the correct drawings and models.PDF's of the drawings are automatically created and linked to the released database such that any manufacturing personnel will only get the approved PDF drawing. PDM system sets ACL permissions on individual files which negates the need to move files to read-only folders. It also renames previous PDF versions of the drawing and archives them in order to maintain revision history of the design.

I am just in the process of testing out the released database using the PDF senario described above (It all ready shows only major models and drawings) just playing with the master drawing mode functionality to see how it automatically manages the PDFs.

And no I"m not using PDMWorks to do this........

Regards,

Len K. Mar, P.Eng. President, E-data Solutions

"If sense is so common.....why is it in such short supply?"

Kalle wrote:

Kalle,

The easiest way to do this is to disassociate the released drawings from the drawing/model in the form of master PDF documents.

The way I would handle this to have the PDM system create a released database. This database, which manufacturing personel have access to, maps only approved drawings and models (i.e. Major revisions such as A, B, C, etc..). Thus, the engineers can play all they want with prototype revsions (X1, X2, X3, etc...) and reworked production drawings/models (A.1, B.2, C.3, etc....). PDM system is smart enought to know that making changes to one referenced model may update the other - if not all ready checked out - it will advise user that in order for the changes to "stick" they will also have to check out the referenced part/assembly as well.

It is only when the approved drawings/models make it through workflow that they are released and the production (released) database is updated with the correct drawings and models.PDF's of the drawings are automatically created and linked to the released database such that any manufacturing personnel will only get the approved PDF drawing. PDM system sets ACL permissions on individual files which negates the need to move files to read-only folders. It also renames previous PDF versions of the drawing and archives them in order to maintain revision history of the design.

I am just in the process of testing out the released database using the PDF senario described above (It all ready shows only major models and drawings) just playing with the master drawing mode functionality to see how it automatically manages the PDFs.

And no I"m not using PDMWorks to do this........

Regards,

Len K. Mar, P.Eng. President, E-data Solutions

"If sense is so common.....why is it in such short supply?"

Kalle wrote:

Hi,

setting the files to read-only bears one big problem (or leaves one big problem) that hasn't been solved by any PDM-System that I know. Picture this: You have an assembly with some parts created in it with references to other parts in this assembly. Now all your parts are read only except for the part that you want to modify. You modify it and some other part (set to read only) that has references to the part you change gets changed (due to the read only state only on your harddrive). If you now open the drawing for that second part it will show the changed state because SolidWorks has changed the part in memory (even though you won't be able to save the changes - the part is still read-only). Now you print that drawing and voila you have a wrong drawing that might get into the workshop. Try it out. Every PDM-System that I tried had this critical mistake in it. There is just one solution I can think of that prevents unwanted changes to parts with external references. Lock the external references when you check in the part (or - without a PDM-System - before you save the part). That this is a major PITA should be obvious. There needs something to be done about it by either SolidWorks (which would be good for all the people without a PDM-System) or by the PDM-System developers.

I hope you understood what I mean.

Cheers, Kalle

"Seth Renigar" wrote in message news:GFsIf.20196$ snipped-for-privacy@tornado.southeast.rr.com...

I don't know which PDM systems you looked at, but I know that Activault and ProductCenter are able to handle your situation. Basically, if you haven't checked out the supposedly modified files, then nothing changes in the data base. The files are loaded into your working directory read-only. When you check in the parts with real changes, the read-only files with their imaginary changes get thrown out. I'm guessing that most PDM systems work the same way.

Jerry Steiger Tripod Data Systems "take the garbage out, dear"

When I first installed PDMWorks the revision jump just for opening drawing and moving a view drove me nuts!

I opted to map the PDM Revision not to the standard ?Revision? property in SolidWorks but to a property called ?PDMRevision?.

Thus revisions on the drawing are driven from the part files "Revision" property which is manually controlled. If I make a change to an in-context part I can up the revision for that part only, all the other related parts get there ?PDM_Revison? updated automatically but not their manually controlled ?Revision? property.

Link below to my drawing title block explaining above.

John Layne

Seth Renigar wrote:

John,

You have uncovered one of the major fubars in PDMWorks. It wasn't till after a long chat with my very knowledgeable VAR that I came to realize this problem. PDMWorks tracks versions, not revisions, but they call it revisions. So all the functionality they put in for revision numbering and lifecycle management is basically crippled. Revisions have to do with your document control system for your product, versions have to do with a computer software's need to track changes which may or may not affect the form fit and function of the item being documented. Versions can change just because SW changes something in a file even when it does not effect the item being documented. For example, add a sheet to a drawing for a 1:1 view of a sheet metal part solely for dxf export. PDMWorks will insist a revision has taken place. Has the part changed? NO!, a sheet has been added to the drawing doc. and that is all. Nothing has changed on the drawing. Ditto if you change the print setup or a host of other settings. PDMWorks will insist a revision has occurred, but to your mfg. software nothing of the sort has happened.

Thanks for the replies. My thoughts:-

1) Changing finished parts/assys to read-only seems to be the consenus thing to do, if you don't have a PDM system to do it for you. Does anyone know of or have a system (macro/VB program) to automate this, as finding the right files manually and changing their properties will be a PITA.

2) Kalle wrote:- "You have an assembly with some parts created in it with references to other parts in this assembly. Now all your parts are read only except for the part that you want to modify. You modify it and some other part (set to read only) that has references to the part you change gets changed (due to the read only state only on your harddrive). If you now open the drawing for that second part it will show the changed state because SolidWorks has changed the part in memory (even though you won't be able to save the changes - the part is still read-only). Now you print that drawing and voila you have a wrong drawing that might get into the workshop."

Is this true? - if so, it's a big weakness of SW, and one that presumably applies whether or not you have a PDM system i.e. if SW can rebuild a read-only part in memory because the part driving the in-context relation has changed, then this will happen woth a PDM system too.

Jerry said that using Activault or PrductCenter that the database would remain unchanged - I'm sure that is true, but does not mean that what you see on the screen is valid, if Kalle's sceanrio is correct.

3) Seth wrote:- "Since none of the PDM systems that I looked at had a foolproof way of determining the difference between a model that actually changed, or a model that just got saved more recently, I opted to go the route of making my files read only when I am done with a project."

I was an I-DEAS user, and it had a "part compare" function that compared the surfaces and highlighted what had changed. I think you could also do an "assembly compare" that compared what instances/components it comprised.

4) John Layne wrote:- "I opted to map the PDM Revision not to the standard "Revision" property in SolidWorks but to a property called "PDMRevision". Thus revisions on the drawing are driven from the part files "Revision" property which is manually controlled. "

This sounds dangerous to me - what happens when you change the drawing but not the part? e.g. change the "finish" details, change a dimension tolerance, add a note. The drawing needs up-issuing even though the part has not changed.

5) TOP wrote about versions and revisions, a distinction that I'm comfortable with. However, are you saying that PDMWorks makes no distinction between the two? If so, is it still not possible to create a custom property called "issue" that the user manually assigns when checking parts back in, and then your manufacturing system only looks at the status of this "issue" field? The I-DEAS pdm system prompted to manually assign a revision when checking items in, so if you've only corrected a spelling error on a drawing, you could check it back in with the same revision, even though a new version was created.

6) Len Mar (and others) suggest having a separate folder/database with "released" pdf's of drawings in it, and that this is all that is accessed by non-designers. I have used such a system before, and it has benefits. If your PDM system is smart enough, the creation of the pdf file can be automatically triggered by someone signing-off the item, separate from the act of checking it back in the vault.

A drawback of such a system that only does this with pdf's of drawings, is that there is frequently the need to exchange data with suppliers & customers in many formats such as dwg, dxf and 3D geometry in parasolid, STEP, IGES etc All these other formats may still be uncontrolled, unless the PDM system also handles this well. Can PDMWorks do this? - if not, are there other systems that are affordable for a small company (20 employees, 5 designers)?

Cheers, John Harland

On Tue, 14 Feb 2006 23:52:33 -0100, Jerry Steiger wrote:

But the copy of the part in the computers memory (and that is what SolidWorks works with) ist not read only, therefore the part can change due to external references. And no PDM system prohibits that. And when you now export the changed file (that has not been saved and cannot be saved due to read only state) in Parasolid or whatever your export model is not the same as the file in your database. For example: You have two plates. Some holes in plate A drive holes in plate B. Plate B has aleady been manufactured. You suddenly realise, that you have to make a change to plate A which affects the holes but you can't remember that plate A drives plate B and you change it. The model rebuilds and the holes in plate B moved in accordance to the changes in plate A. For you everything looks like it's ok. No interference because the bolts that are in the holes moved too. You say to yourself: "Well everything is fine, release plate A and have the guys in the workshop make it." You want to assemble your parts and notice that the bolt doesn't fit because plate B was made in steel before plate A changed. You open up your assembly (plate A still drives plate B). The old (and already manufactured) version of plate B is loaded along with the new version of plate A. SolidWorks tells you that the assembly needs a rebuild (or does it automatically upon opening it). Plate B changes in accordance to plate A and you are unable to find out what's wrong. In my opinion this problem can only be solved if the checked in and released parts get a lock on their external references. Which PDM-System does that? I don't know any - though I won't claim that I know every PDM-System out there ;-)

And that way is just the half way and lets room for errors.

Jerry,

I understand what you are saying. But, if you are modifying parts from an assembly that does contain in-context references, you NEED to check out all of the parts since you may not be sure what parts the change your about to do will effect.

I am not the most PDM savvy person in the world. But, several years ago I had a few demos done in house where I supplied the files for this very scenario. None of them worked the way I was under the impression that they were supposed to work. Every one of them tried to up-rev files on check-in that didn't actually change. Of course maybe I'm not understanding the PDM methodology correctly either.

Are you saying that I-DEAS would actually show you what geometry changed in a model? I am not familiar with I-DEAS. But, using SW mentality here, how could it do this unless there is another version of the file somewhere? Did it compare it to a previous version in the vault or something? And most importantly, was it automated? Meaning, if you had, lets say, a

100 part assembly with lots of in-context references, and you made a change to one of the parts. This in-turn changed geometry on 37 of the 100 parts. Would I-DEAS compare all 100 parts and tell you (or show you) wish parts actually changed? Or would you have to manually compare each individual part to a previous version in order to determine which parts changed?

SW utilities has a geometry compare function which I use often. The limitations are that you must have a backed-up copy of the model before changes (I assume this is not a problem with a PDM system), and the filenames cannot be the same.

Yes, this is true. Kalle summarized it quite well.

Yes, that's right. This is one of the big dangers of doing in-context design and a reason that many people break the relations at some point in the design, often when they release to production. Of course, this means that you now need to remember how changes would have happened and make the changes manually, but at least you can often see what needs to be done.

Jerry Steiger Tripod Data Systems "take the garbage out, dear"

Hi

Everyone I know, clients and subcontractors, who use SolidWorks store information such as finish part number etc in custom properties in the part file. These custom properties are reported on the drawing. Hence if you change a finish property you also have to change the revision.

IMHO the revision of the model and the drawing should always be the same. I understand your reasoning, for example if I have left a dimension off a drawing that has been issued and I then add that dimension the drawing has changed but not the part. In this case I would still bump the revision of the part which is also driving the revision on the drawing. The description in the revision table would just note "dimension added"

What if you make a change to the model which requires a model up-rev, but doesn't require a drawing rev. Something like fully dimensioning a sketch, changing a color, or modeling the same finished geometry a different way, adding comments, feature names, cleaning up modeling errors or removing external references? Plus, does this mean that you can't have rev levels of your part before you start your drawing?

I always encourage people to keep the part and drawing rev separate, but to add the model (assy or part) rev as a note on the drawing title block. Keeping them the same seems like an unnecessary requirement that invites mistakes.

matt

I must not have had my first coffee before I wrote that.

In the situation you describe I would leave the revision in the part and hence the drawing the same. The drawing would change slightly, two property fields would change (the two with the blue arrows in the gif below) but the Revision would stay unchanged.

The revision (the one the red arrow pointing at it, in the gif) controls whether the drawing will be reissued to suppliers or even if it is reprinted for the document file.

The ?PDMRevision?s? (blue arrows pointing to them) of the part and the drawing are for in-house document traceability only and will quickly have differing revisions (or as TOP put it versions). Notes relating to the "PDMRevision" are maintained solely in PDMWorks if necessary.

John Layne