Should drawings be integrated into the part file

[bigseb]

So this is a question I want to pose to the community. As the thread title states, should drawings be integrated into the part file?

So basically an extra tab will be added to the part workspace labelled 'Drawing' and switching to this tab will present the user with the interface from the drawing workspace and allow the user to create drawings as per usual. This means that the AD_DRW extension will no longer be required as all drawing sheets for that part will be in it's AD_PRT file. Powershape does this and I personally think it is a very good feature. It also makes saving an entire assembly along with all its drawings to a new location a much simpler task.

I feel strongly about this but would like to get some feedback on the idea before I post it to the suggestion page.

 

[Lew_Merrick]

Drawing Files should not be incorpo9rated into Part or Assembly Models. They are vewry different kinds of documents. However, they should be intimately associated with them. If a Part od Assembly Model is "moved," the associated Drawing File should be made part of the move process. The same is true of the Package (Archive) process.

More to the point, View Identities (Regular as well as Section and Exploded) should be defined and identified (read: Named) in the Part or Assembly Model. This implies a number of concurrent changes -- Reference Cylinders or Portions thereof leaps to what's left of my mind. I am sure that there are others.

 

[JST]

I don't like the idea much.

There are many cases I run into where I may want to have more than one drawing file for a part of assembly, each emphasizing a different aspect, or the like.

There are straight up part fab drawings, there are "overview" drawings that show limited dimension info (but may have other data added) and are suitable for sales literature, and app notes, etc, etc. The idea of combining all of them into being pages within one larger drawing I find clumsy and unproductive.

Unless multiple different drawings can be stored with the part, I believe it would be very limiting.

And, I don't really like the idea of storing them together anyway. The drawing should be accessible without giving access to the entire model at the same time. That is a security issue if nothing else.

 

[bigseb]

There are many cases I run into where I may want to have more than one drawing file for a part of assembly, each emphasizing a different aspect, or the like.

Try sheets

As far as I'm concerned (and going by past experience) the CAD data is general only accessible via the CAD software by the design engineer. The actual working drawing i.e. the one that is signed off by the lead engineer, is kept as a pdf and hardcopy (both controlled). Same goes for the working 3D model. As these are now controlled they are kept in neutral formats (again... pdf and step) that are accessible to all that require the file for manufacturing purposes. These do not change. Revisions can be added of course but anything controlled stays as is.

So, yes, I think making this change to Alibre would be beneficial as the actual design process is simplified and CAD data becomes easier to manage if the 3D part and the drawing are one file. Once controlled they are exported and given project-specific numbers/names.

 

[swertel]

I like having the option.

For a while, NX was not a master model concept. Therefore, you could have the drawing as part of the model file or you could have it as a separate file. Onshape, due to its cloud and project based "file" management system uses a series of tabs to change between environments. I see the benefit, but I wouldn't want to be limited in my choices.

For example, Source Control or Vendor Item drawings of bulk materials. No model, just a drawing.
Interface Control Drawings should not be in with the model. The whole reason to have an "envelope" drawing is to not sell the farm. I don't want to be giving away the model when I should only be giving away the outside dimensions.
And as others have said, multiple drawings and drawing types per model. That would be a lot of extra tabs to keep track of them all, and sheets aren't the answer. Sheets are used to continue detailing the assembly or part, not to be a completely different drawing.

 

[JST]

I do not like sheets for that purpose.

 

[MarcusWolschon]

No, as a part is often used in multiple assemblies and they have drawings too, the point of them being together for all times is lost anyway.

 

[bigseb]

No, as a part is often used in multiple assemblies and they have drawings too, the point of them being together for all times is lost anyway.

What is the connection? Same part used in different assemblies is still the same part. This integrated drawing suggestion applies to assembly files too. I thought that would be obvious.

 

[swertel]

What is the connection? Same part used in different assemblies is still the same part. This integrated drawing suggestion applies to assembly files too. I thought that would be obvious.

Exactly. You won't have access to the part's drawing via the assembly, just the model.
The assembly model will have its own drawing embedded.

It's not a bad concept and the flexibility to save file management is excellent. But I still caution to not get rid of the individual draft file types because there is still value there.
And let's not forget about the issue of translating dxf, dwg, STEP, parasolid, etc. How will Alibre know what environment to import the geometry? How will Alibre know what environment to export?

 

[DavidJ]

For such a fundamental change, I'd need to be convinced that there are big benefits with little or no down sides. It sounds to me like a potentially huge amount of development work, for not much gain.

There would have to be backwards compatibility for historic files. I'm struggling to see how this could possibly have priority over bug fixing and feature enhancement... so take that as a No from me.

 

[bigseb]

This is history in the making, chaps. Revolutionising CAD data management, decreasing number of 'working' files in directory, allow easier file saving and quick access to drawings relevant to the open part. Once you get your head around the concept of separating your CAD work from the actual controlled manufacturing files this is the best thing since, well, ever.

 

[swertel]

Compare Onshape or Fusion 360. Both of those programs don't bother to differentiate part from assembly files either. Everything is all lumped together in one big project file. No file management to worry about.

The downside, as they soon found out, was no part re-use. They had to device a way to create standard parts libraries and separate certain components into their own "file" in order to reuse it in other assemblies. That hurdle has been conquered and they are running with the benefits of providing users with the choice between project-level or file-level control of their designs.

Decreasing the burden of file management is an excellent feature enhancement, as long as users are still provided the choice.

 

[NateLiquidGravity]

I'm against this idea as I have way to many questions and cons and very little upside.

How does somebody searching the file system know if a drawing exists for the file or not?

What would the thumbnail image be - part or drawing?

Would the BOM be located inside the file as well?

How much would this slow down file loading and saving - especially big assemblies it would be accumulative - could be exponential.

 

[bigseb]

How does somebody searching the file system know if a drawing exists for the file or not?

You open the part. Generally though, drawings are made to be used so you would likely find a controlled drawing in its correct folder. Otherwise why make a drawing in the first place...

What would the thumbnail image be - part or drawing?

Part. That seems perfectly logical to me.

Would the BOM be located inside the file as well?

Good question. I hadn't considered that so off the top of my head I would say yes. Again, to me it would seem logical to have the 'BOM' tab in an assembly file. Clearly assemblies are linked so where else would one put it.

How much would this slow down file loading and saving - especially big assemblies it would be accumulative - could be exponential.

Don't see why it would be longer. Assemblies are typically relatively small as they link to part files. On the other side, I work with massive assemblies whose drawings need constant fixing as I make changes due to associativity being lost.

Powershape work in this fashion i.e. all parts, assemblies, drawings, etc all in one big file. Their interface is antiquated, as are the worksteps but the principle behind this is sound and the files always open quicker than Alibre Design. A typical mould assembly file in Powershape (for, say, a Toyota centre console) could easily be 1.5GB. The same thing in AD is about the same size, perhaps a tad larger but not much. Not saying parts should be included in assemblies too, btw.

 

[HaroldL]

AutoCAD had tabs back in version 10 and prior. I recall they were named Model Space and Paper Space.

 

[JST]

This is starting to sound way too much like the system with many programming languages, where everything is in a package, and you end up with a problem re-using code, and even in understanding where things are, plus humongous files.

I very much suspect that the term "one big file" is unfortunately quite correct. It WOULD be one BIG file. Would we then have to have a huge increase in the minimum system memory to open the files? I could see that being an issue, although it might not have to be one. I do NOT like the sound of that 1.5GB file, it smells like a problem with minimum memory.

What would then be the minimum file size for a simple cube? How would that compare with the file size now?


Now, if you wanted to do this in what I think is a more sensible way...........

Wrap a "design environment" around the program, so that once you open the project, all the pieces you are taking about are instantly available from the design environment. You could CHOOSE the view type you want to organize the parts and documents with.

In one view all the project drawings might be pulled out into a list of them only. Same with parts, assemblies, etc. Like sorting the directory by type.

In a different view, you might be able to see the related documents together.... you select a part, or an assembly, and the project documents for it are listed, drawings, models, any attached text documents, and the BOM(s) on which the part appears or the BOM for the assembly.

Other view types might be different from those. I think maybe 3 or 4 choices would be enough.

The various documents would not be all rolled into one, BUT the wrap-around design environment would let you view and select them from lists organized as you like (chosen from a list of options). The "related document" view would act pretty much like the "one file" deal, without the disadvantages. That actually seems much more useful than rolling them into one file, partly because the "PROJECT" is really the way you interact with the various parts.

How they are stored is somewhat irrelevant as long as you can treat the whole lot as one entity if you wish. The idea is that you could treat the "PROJECT" as if it was a "thing", OR as it's component parts, and have the ability to bundle the documents about any project, part or assembly together. Like a "package", but with a ton more ways to view and organize it, AND with the ability to link other document types to the part or project, such as text files, or perhaps PDF spec sheets, etc..

If need be, there could be the ability to bundle different collections of documents for different purposes, having several different "bundle styles" that include different "document levels".

You could have a dozen drawings for one part if you wanted, and select some for "bundle type 1" and different ones for "bundle type 2 " or "type 3".

 

[bigseb]

I very much suspect that the term "one big file" is unfortunately quite correct. It WOULD be one BIG file. Would we then have to have a huge increase in the minimum system memory to open the files? I could see that being an issue, although it might not have to be one. I do NOT like the sound of that 1.5GB file, it smells like a problem with minimum memory.

Some of us work with big files. No way around that unfortunately. The similar assembly in Alibre is not much different in opening time and 'total' file size. Downside is that everything is separate so I lose a lot of time hop around between various parts, sub-assemblies and drawings...

So far, when I do this sort thing in Alibre I have a top-level file (eg: XXXXX-00001-XX) that is a drawing file. In it is a top-level assembly. So I open the drawing file and from that the assembly and from that all the sub-assemblies, then parts, etc. This is the best way to keep everything nicely glued together in terms of associativity. Downside? Alibre isn't exactly the most stable software and tends to crash randomly and since it doesn't allow one to save without going to the top-level assembly one can lose a lot of work.

For the last year I have been using Moi for this sort of work. Moi is much easier to handle these sort of files, has a similar set-up to Powershape in terms of its level set-up (called objects in Moi). One file with everything in it. Plus it doesn't crash anywhere near as often as Alibre and doesn't go nuts with bad surfaces (these are easier to fix in Moi too).

Moi V4 is due for release soon. Hopefully. It will be x64 (huzzah) and include dimensioning/drawing capabilities, along with all the other bells and whistles that AD doesn't have yet.

Streamlining a process isn't necessarily a bad thing, although it could be a departure from 'the norm'. If it makes the software more robust, gives better project oversight and makes data management significantly easier then it should, at the lest be considered.

 

[Giecon.nl]

The system I use mainly has everything in one file. It is possible to use separate files but I keep everything in one file. Project management is so much easier. File opening times are really much faster 15 second is long on average. In my impression the fact that you only have to read one file instead of hundreds makes much of that difference. I can rename any part at any time without loosing links or jumping through hoops without thinking or planning ahead. Big files are no problem 1.5Gb file no problem memory usage is much less on the same system.

 

[Lew_Merrick]

Is the concept of Project Data Management so hard to understand? The key is to segregate your Projects to the greatest degree possible, document your design decisions, and archiving your work such that you can find and recover it in the future. None of these tasks are or should be the responsibility of your CAD Toolset. This is what documentation tools (such as editing tools, spreadsheets, and databases) are for.

If I have a Part file (let's call it a Separator) that was originally designed for (say) Project B and it can be used (unmodified) on (say) Project K (A) What is the harm?, (B) So long as dual usage is noted, documented, and (as may be required) justified, who is going to care? The issues for the CAD Toolset are "recovering" the Design Datasets and "incorporating" them into the new Project Documentation Set. My "point" is that, except for internal file relationships, this is mostly a "task" left to database management tools. If I have Part 06C00905-104 Separator associated with Drawing I06C00905-104 Separator, then calling up one file should notify me as to the existence and relationship of the other file.

 

[bigseb]

As usual I appreciate your input, Lew. But in this case, having read your post, I feel we may be talking about two different things...