Flexible assemblies

Nope. You can't have a sub-sub assembly be flexible. Send in those enhancement requests, folks.

Deb

You can if the sub assembly and sub-sub assembly are both flexible

...and you have enough configurations.

If the top assembly has two flexible subs, then each of those subs must have a configuration corresponding to the configurations of the top assembly. If each sub has a sub-sub, the sub-sub must have 4 configurations to be flexible. One for each flexible instance in the top assembly, essentially.

Poor old user goes and puts this conundrum to the group:

Now suppose subassy (A) has been designed, approved, released and put in the vault at Rev. 0. The subassy is then placed two or three levels deep in an assembly as previously pictured and the assembly wants to be parametric as to the number of sub-assemblies that contain (A).

Quiz question: How many identical configurations should be put into sub-assembly (A) on the off chance it will be used multiple times in an assembly (flexible assumed)?

a. 100 b. 1 c. 1000 d. 2^n where n is the number of levels deep the sub-assy is placed.

How do you handle vaulting the sub-assembly with PDM?

a. Generate a new revision each time you increase the number of configurations. b. Stop the PDMserver and hack the version with new configuration into the vault. c. Turn on "Allow check in at same level." d. Don't bother, just keep the assembly stored locally.

If the API had all the calls necessary to c> ...and you have enough configurations.

Look deeper into your PDM system's functionality. Ours (Meridian by Cyco) differentiates between "versions" and "revisions". A "revision" is an official change, with a rev. letter change and ECN, etc. A "version" change is any change at all. This is used when doing things like adding or changing configurations or minor adjustments that don't merit a full ECN revision.

The PDM archives all versions for posterity, and allows "rollback" to different points in time.

Our system (Conisio) won't let you change a file unless you lock it, it's read-only. Therefore, in your scenario, the person doing the drawing must lock the model file in order to save the newly created flat pattern config. Then when he unlocks it, the version is updated.

WT

configurations

subassemblies.

We did this with SimplePDM as well and called it Major and Minor revisions. The suggested definition for a Major revision is a change that affects the fit, form of function where as the Minor revision is for mispelled adding dimensions for ease of use in the shop, etc.

Best Regards,

If I were faced with that choice, I would probably re-examine why I'm so dead set on using flexible subassemblies. If it's gonna cost me that much work, I would either skip it or rearrange my subassembly structure to accommodate it better (or try to do something creative like making an alternate structure using envelopes which would show the motion).

Again, why are you so concerned about the rev level? Why not just make the changes and let the rev do what it will? You could overwrite the current rev, but if you do that, inevitably there will be some problem where something changed in another configuration that you didn't count on.

I usually manage the drawing and the model separately, and allow the revisions to be independent. It's too much work to do it consistantly keeping the model and drawing revisions in lockstep.

I would never recommend hacking the vault. Sometimes you can get away with it, but I would do it as a last resort. The cost of really effing it up is just too high. In fact, I have seen SolidWorks refuse to help people who have hacked their vault and made a mess of it.

I would also recommend against keeping the assembly stored on your local machine. That approach will work, but keeping track of things is why you're using a PDM system in the first place. Multiple copies of files will get you in trouble somewhere down the line.

matt

Yeah, that's an interesting question. I think there are two answers:

1) make sure that you make a flat pattern config of sheetmetal parts before you finish with it, in the same way that you make a scaled config of molded or cast parts. 2) if you forget to do 1), you will need to take ownership and check it back in after the drawing has automatically created the flat pattern derived config in the part.

If you make the drawing, but don't check the sheetmetal part with the new flatpattern config back in, your drawing will be incorrect next time you open it (unless it has been made as a "detached" drawing).

That's a scenario I hadn't thought of before. I'm gonna remember that. Thanks for bringing it up.

matt

kellnerp wrote in news:i3YEb.407632$Dw6.1264402 @attbi_s02:

Well, don't do that. Har har.

Form what you describe, it sounds like the vault is ignorant of the fact that configurations have legitimate uses other than families of parts or parts in process. It makes me glad that I'm not a PDM user. Unless I'm reading you wrong, the PDM wants revision control of every configuration of every document? That would just not even begin to fit with my way of working.

Humbug.

Dale Dunn wrote in news:Xns9457B3E5C8B70daledunnatjamestoolc@65.24.7.150:

No, PDMW doesn't manage configurations separately, but it does make new revisions to files that have been changed. When the sheetmetal flat pattern drawing view is created, it automatically creates a new config in the part, which constitutes a change, so the part should be up-revved.

There are some PDM apps that allow you to manage each configuration as a separate document. Sometimes it has uses, but I'm not a big fan of that either.

matt

I am faced with that choice because of the nature of the equipment I am designing. The same assembly is repeated over and over and must be shown in the appropriate location in each instance in the same assembly.

The point of this question is that one doesn't know apriori how many times an assembly may need to be used in another assembly and that PDMW in particular seems not to be able to deal with this sort of thing.

During development this is fine. Just let the rev level bump up. One of the beauties of PDM during development is that a snapshot of the project can be had at various stages and one can go back to a previous state if necessary. After release to the outside world the rules change.

My current working method with PDM is that a revision level must be changed when one thing occurs. Any change to either the model or the drawing that effects the way the part is to be made is a revision. So changing a note is a revision and changing a dimension is also a revision. I have to have this definition because when I release parts for quote and production based on revision level I must have record of their changing. For example specifiying red paint instead of blue paint in a note on the drawing would be a revision. Changing tolerance on a hole from +/- .01 to +.001 -.000 would also be a revision even though it occurred on the part level. Adding a configuration to a sheet metal part for the sake of making a flat pattern drawing would not be a revision.

They don't document the vault structure and there is limited instruction for manually going into the vault and changing things. So, yes, vault hacking is at your own risk.

There actually is an out in PDMW and that is to check the box for allow same revision checkin. So vault admin can allow this to happen when appropriate.

I agree with you whole heartedly. One copy in the vault, the vault backed up and on tape every night and everyone can sleep better.

One of the seeming difficulties in managing SW models is that SW will change a file for its own internal bookeeping purposes without user knowledge that it has done so. This is especially true with assemblies where the face numbers used in mates can change due to changes in a part. When this happens the part and assembly may have to be checked back in with the assembly at the same rev level and the part at a new rev level.

Dale,

PDM is as much a discipl> Dale Dunn wrote in

Don't do that.

In our system, all changes increment the "version" number (generated by the PDM system) up by one. For revision (ECN) level, we use a separate property that is not manually incremented.

Since the minor revision is a seperate field in the database, it is up to the company's requirements how they wish to use this. In the case of those who use the minor revision, it does not warrant a major revision therefore it also does not require an ECN to add a new configuration, fix a misspell, etc., but again it is up to the individual company.

Best Regards,