Renaming Parts or Assemblies and maintaining Context

[Lew_Merrick]

I admit that I live and work in a different universe than most. but, in context, my Parts and Assemblies end up with a specific naming convention -- Part (Document) Number, Dash Number, (and) Revision. Thus, I am working on a Project wherein the Document Numbers begin with 17J and then have a 5-digit number following such that a number of "00100" defines things used on the Installation (or, if you prefer, Top Assembly). Primary Assemblies making up the Installation will be numbered "00200," "00210," "00300," "00310," "00320," etc. Thus, I have Model identified as: "17J00330-101 Rev New." Once that "Drawing" (read: Model and Drawing) have been released for manufacture, a "change" requires a new Revision -- which will change the Model and Drawing names to "17J00330-101 Rev A." It would be helpful could I Rename a Model withing the Context and have it apply throughout the Project.

 

[NateLiquidGravity]

Renaming is one of my big beefs. That, duplicating multi drawing projects, replacing parts, and general project management are the main reasons I started the Alibre Design Project Files thread a while back. https://www.alibreforum.com/forum/index.php?threads/alibre-design-project-files.10538/ I'd like to hear your unique input there.

 

[Lew_Merrick]

Nate -- Though I do not often see them, a Project DataBase can be a wonderful thing. It (should) start with a definition as to why the Project was begun, what will define a Project's success, and all the Supporting Documentation collected or created. [To cite one example, I have been designing a vacuum chamber to be carried by a weather balloon. It uses a window that has to transmit given wavelengths at a minimum effectivity. The customer lost that dataset and began complaining. I pulled it out of my Project DataBase and was able to give them a fresh copy as well as their acceptance letter of the decision from nearly three months ago!] You have no idea how satisfying it can be to "quash" comments being made 20+ years after a Project was delivered and functioned.

 

[JST]

Renaming is a big deal for me also.

The issue is the linkage of filename and part identifier. Ideally, the filename can be anything, and the part identifier should be independent of it.

This is YET ANOTHER issue that a "design environment" can fix..... LEAVE the filename alone, and DISPLAY the part identifier. The design environment takes care of retrieving by filename, YOU select by part identifier.

Design tree can display either one as a user choice.

Part of this is in place, as there is a "part name" field, but it is unused for anything useful.

 

[swertel]

This "design environment" that keeps getting brought up sounds a lot like a PDM system. Why not just go buy a PDM system?

 

[Lew_Merrick]

This "design environment" that keeps getting brought up sounds a lot like a PDM system. Why not just go buy a PDM system?

Scott -- The "PDM approach" has been taken over by the same people who turned DOD-9000 into a worthless (but profitable) mirage. One point that I raise constantly is that the original Project Data Management system was defined (sometime in the 1950's) under the MIL-Q-9858 definition set. It is not a Product but rather a philosophy.

 

[JST]

This "design environment" that keeps getting brought up sounds a lot like a PDM system. Why not just go buy a PDM system?

It may sound like it, but it really is different, since it is proposed as integrated in, or really "with" Alibre, and is oriented toward project level data on the design side.

That means you can see and select the parts, for instance, by their filenames OR by their part descriptors, or potentially by another field, from INSIDE Alibre.

When you open a part or assembly, the component parts, and drawings, and potentially also related non-Alibre files are all shown, so that you can easily work with them. Again, from within Alibre.

I find I often have to look at vendor data, or a specification sheet, and that could be associated with the project so that it can be directly listed within the "environment", so that one does not have to go looking for it. It would NOT need to be stored with the project, the "environment" would note the location and associate it with the project. It would then be an option to bundle all the associated input design data, specs, models, drawings, BOMs, and other data into a "project package", or split out subsets of that data, certain drawings but not others, for transmission to clients, vendors, etc.

Yes, it does resemble PDM, but I see it as a design side tool more than most PDM systems seem to be. I see it as doing what the folks who want to bundle drawings etc into one huge file with the model are really asking for, plus more.

I do not see it as needing to incorporate a lot of version control, but it certainly would work with version control.

 

[NateLiquidGravity]

Imagine if you will that it is a BOM/Parts List of the project files. With links to the files. And maintains/overrides part relationships.

Want to rename a part used in two drawings and an assembly without doing complicated and risky save-all-as delete and replace dance? This should do that.

 

[Giecon.nl]

Something like this, the root manager of zw3d. Spreadsheet like environment where you can rename, fill in description material and other properties. Double click opens the model. Copying automatic increases the numbers etc. Very very powerful it takes some time getting used to but no more jumping through hoops to get the basics done.

 

[bigseb]

Something like this, the root manager of zw3d. Spreadsheet like environment where you can rename, fill in description material and other properties. Double click opens the model. Copying automatic increases the numbers etc. Very very powerful it takes some time getting used to but no more jumping through hoops to get the basics done.

Now that I like!

 

[HaroldL]

Something like this, the root manager of zw3d.

I am lousy at remembering part numbers. Good thing it has a graphic for the parts. It needs that or a column for Description.