Exploding Blocks - Why would you?

[lou.branchaud]

I've been tasked with updating my company's CADD Standards.

As I'm going through it, I'm seeing relics that need updating. For example: They reference a mechanical standard from 1982, which has been updated several times since.  Yes, some things are out of date, but I can see why they were implemented.

However, this one baffles me:

"Blocks and groups may be created and inserted into the drawing. All blocks and groups MUST be exploded and purged from the drawing before archiving the drawing file."

What is the possible benefit of this?  I think this is unacceptable, but I also want to have a solid argument to management people (who don't use CAD) and are more likely to side with the ancient author of this document.

If anything, this proposes a world of undoing work and errors.

The only benefit I can think of is that maybe this saved some space / processing power when computers had MBs of ram rather than GBs.

Any ideas? 

[cadffm]

>"I also want to have a solid argument to management people (who don't use CAD) "

Perhaps the content of this sentence is (or was)  another one that you mean?*1

MY problem is: English isn't my native mother language..

>"The only benefit I can think of is that maybe this saved some space / processing power when computers had MBs of ram rather than GBs."

No, for blocks the opposit is the case (when the block are inserted multiple times in the file).

Possible things i think about:

a) When the project is ended, you "archiving" the files and from then you import these files as block or xref into other files?

Sorry, you don't write about what kind of drawing they are.. but it isn't unimportant for creative brains HaHa.

If so, BLOCKs can be a problem.. ab BIG problem until today..  exploded blocks not!

(but this is not apply to groups, or can you copy group-informations from one to another file in older versions?).

b) Perhaps they thought: Our Users, not all of them can handle well with blocks and groups,

     so it is better to explode them before archiving. When another user open&edit these files later, it is more "simple" to understand what is inside the file / how can he handle the content.

c) A third part program in the past that can handle dwg file (or was it the DXF format earlier?)

BUT

But it's very easy today: Say you want to change this rule and another one have to and another one

must then explain to you (and the managment) "why not".
Otherwise, you know enough things that speak for the change.

[lou.branchaud]

Thanks for the input!  I should've mentioned; This is a generic CADD Standard.

So that captures: Mechanical, Electrical, Assembly and a few other document-style drawings.

So the more complex blocks would definitely be mechanical. However, for that, we tend to use Solidworks so I'm not too concerned.  And I would agree to explode those blocks if you're going to make a 2D representation.

My main expertise is Electrical.  I use AutoCAD Electrical, but in a sense that someone using AutoCAD LT should be able to make revisions after the initial release.  Electrical or LT, it's nuts not to use blocks.  Especially since they're not terribly complex.

[dbroad]

1. Never explode blocks unless you are deliberately trying to destroy content or reduce the usefulness to someone you are turning originals over to.  I would think that transferring such crippled drawings to a client, for example, would violate the spirit of a contract to transfer the content, if not the letter.  Here are a few bad things that happen when blocks are exploded:
   1. Attributes can revert to tags, losing all the content information.
   2. Data extraction tables get broken.
   3. The drawing size can increase tremendously.
   4. Editing the drawing becomes much harder since selecting blocks is more difficult.
   5. Objects inside blocks that are on layer 0 and that have byblock and bylayer properties, lose their layer and appearance properties.
   6. Dimensions lose their association to the exploded blocks.
   7. .......many other things are possible. In general, exploding blocks cripples functionality, making the drawing little more than an electronic plot.
2. Groups can take up a lot of space if there are hundreds or thousands of them but they also can be very useful if the drawings ever need to be edited again. I typically only use a couple of groups, if that, per drawing, usually temporarily.  Unless wipeouts and text are grouped a lot, then there may not be a downside to deleting the groups.

[cadffm]

@dbroad 

Beautifully written, really. But it has been the lived reality in this company for ages and he wants to change that now.
But before he suggests this, he would like to know the possible reasons why this rain was set up last millennium in the company.
Exactly to this question did you make any comment, or did I skip this because of my lack of language skills?
(With the exception of groups, which can only arise in problematic masses through export, not by users)

[lou.branchaud]

@dbroad

I fully agree with all these points.  These are things I'm trying to explain to my colleagues.

Most of which are engineers primarily, and not AutoCAD users.  Not to slight their capabilities, it's just CAD isn't their strong suit.  If they want to make an edit, they want to double click, write something new, and draw a new line (and I cringe as I watch them draw a crooked line that "looks straight enough").

Furthermore, I'm trying to show them how you can edit 100+ title blocks if you have them set up as actual blocks in the matter of minutes, rather than pay someone to spend 2 days to fix title blocks and eventually be filled with errors.

I meet a lot of resistance because "well we've done this for xxx years", "it's our standard" and so on and so on.  That being said, I also have to cater to AutoCAD LT users who are at a novice level.

I think even at a beginner level, one should be able to:

1) draw a straight line

2) be able to switch between layers

3) know how to use blocks (and know the difference between text and attributes)

[dbroad]

One reason to explode a block upon insertion is if it contains a library of blocks and if you're not really trying to keep the drawing definition, just the internal blocks. 

Another could be where improperly designed blocks are wrapped several levels deep.

BTW: If the blocks were created in AutoCAD, exploding them also risks losing any parametric and dynamic behavior.

Exploding to improve the drawings, however, is a decision that needs to be made based on trial and error or previous knowledge, not in bulk, hoping for the best.  I use palettes rather than to insert block libraries. A mass explode of blocks is almost always a mistake and an extremely poor standard to set up without further qualification.

[s.borello]

That part sound ludicrous... perhaps written by someone who hasn't the slightest idea about AutoCAD? This should be removed from your office standards in my opinion. 

[neaton]

Good list @dbroad.

Maybe show it from a monetary standpoint:

- Server size is at capacity sooner because files have increased in size, not decreased.

- Determine how long it takes to explode all the blocks

- How much time does it take to fix everything when you have to modify the file after archiving? Especially title blocks, disassociated dimensions and attributes that are now tags instead of the actual text.

- How many times has an archived set been needed for a project because the developer added on to whatever was built five years ago and you need the old plans?

Sorry, even some experienced CAD operators think "close enough".

         I think even at a beginner level, one should be able to: 1) draw a straight line.

Nancy

[RobDraw]

Archiving is approached differently as much as standards are. Some use .dxfs, some use only PDFs. Archived files are only record files of a finished project and sometimes for milestone submissions. They shouldn't be "working" files. Exploding is an effort to thwart manipulation by nefarious parties. These files are stored as proof of how the job was published and should not be easily editable in case of litigation issues that might require proof of how the company published the final documents. Archived files should not be thought of as back-ups. They really should be locked down (not easily editable) in some fashion. If they were kept in their "working" state, someone could easily go in and alter things with minimal effort. A good suggestion would be to change the format of the archive files to something other than .dwgs.

[lou.branchaud]

Hi Rob,

Those are legitimate reasons.  However, I think in this case, our "submitted" drawings usually consist of signed copies along with P.Eng stamps with a zipped CAD folder for future reference.

It's rare we don't re-visit a project, so in my opinion, we shouldn't "explode" everything since it's almost inevitable that we will have to make upgrades or change according to evolving standards.

[RobDraw]

You need to separate the idea of archiving files from backing up files.

Archives are record files and should be locked down. Back-up files are for future use. Two different processes.

[lou.branchaud]

Rob, I know what archiving is.

A signed PDF on a limited-access server along with it's source CAD files is a sufficient archive.

[RobDraw]

---

@lou.branchaud wrote:

Rob, I know what archiving is.

A signed PDF on a limited-access server along with it's source CAD files is a sufficient archive.

---

There are other ways but yeah. Is that in the standard under archiving?

If not, then standard needs to be corrected from reading  "archiving" to "backing up" .dwgs and the workflow should be changed so that the functionality of the drawings remains intact. That is unless there is another procedure for backing up .dwgs for future use.

Disclosure: Without knowing the entire standard, I can only comment on what you provide.

[GrantsPirate]

I guess I would want the archive to be a PDF where you can be certain that it won't change so easily.  The .dwg file would be audited and purged and saved, with possibly exploding the groups only.

[dgorsman]

One reason I can think of for exploding blocks, is the drawing was created automatically by a third-party program.  Some of those create a bunch of "junk" blocks which don't really mean anything, other than a means of organizing their content.  In those cases I could see needing to explode and purge, if just to not have a bunch of block names that would have people scratching their heads over "where's the definition for this?".

Another possibility is using "assembly" type blocks - definitions consisting of entities (possibly including other block references) which are intended to be individual in a destination drawing.  You don't necessarily want the assembly-definition hanging around in the drawing, although if there's nested blocks then there shouldn't be an "explode EVERYTHING!" mantra too.

[tfehrman]

I have had sporadic issues with 2019-2022, enough to make you think you've lost your mind..... when we receive company mandated updates to the next version it is very painful to open an old drawing with 500 terminal blocks and devices only to find out they've now been exploded !!!!  I have been unable to determine what commonality causes this. It does not happen on every drawing (all saved from cad 2013,2018,2019,2021,2022) I open but as of every version implementation it is the first thing I check.  AUtodesk 2017 seemed to be the fastest and most stable for blocks and xrefs, later ones not so much. 

(xref'd dwgs in cad2017 took me 5-10 seconds to open , while cad2019 was often 6-8 minutes IF it didn't lock up, having to be shut down with task manager)

Is there anyone else running into this out there? and have you found a cause.?

[murray-clack]

We have a client (a well-known international company who shall remain nameless) who insists on blocks, dims, MText/Leaders, title-sheets in modelspace, and yes, HATCH PATTERNS be exploded because they still use an archaic database - that still runs under DOS - that gets "confused" with intelligent objects when the drawings are searched.

Took me FOREVER to convince my coworkers to create the drawings PROPERLY for easy editing during the design/construction/record process, and then export them using the EXPORTLAYOUT command to create a dwg for each sheet and then explode accordingly.  This way, we could build on each previous project, and then close out that phase with the export and keep Mic.....  uhh..... the client happy   

[pendean]

Excellent workflow @murray-clack

[cadffm]

>>"it is very painful to open an old drawing with 500 terminal blocks and devices only to find out they've now been exploded !!!!"

This will never happen by the software, only by users.

>>"I have been unable to determine what commonality causes this. "

Users.

And if we NOT talk about plain AutoCAD/LT (which product are you using, plain AutoCAD, or which Toolset?)

>>"It does not happen on every drawing (all saved from cad 2013,2018,2019,2021,2022)"

It happend before or by save process, not by using open function in the newer version.

>>"I open but as of every version implementation it is the first thing I check."

You don't need a check of the standard product, there is no option to explode blockreferences.

If this really going on, you need to search at another place (3rd parties / own custom stuff).

Problems... espacially with dynamic block, okay - but exploded blockreferences? No.

>>(xref'd dwgs in cad2017 took me 5-10 seconds to open , while cad2019 was often 6-8 minutes "

Seconds vs Minutes? This isn't normal, you should search for the issue!

For example: Copy this cad2017 project, save all files (incl. Xrefs.. = ALL files) to the native file format

as you use also the native fileformat in 2017 (= dwg2013) - or?

So the native Fileformat in 2019 is dwg2018.

And there are 20 other settings you should make sure they are set to the same value.

And: For tests, use files which are on local driver only.

Make sure that the prodct will find all needed (same) resources as in 2017,

for example fonts..

>>"Is there anyone else running into this out there?"

Depending on product, settings and fileformats - a lot of people,

but if all is right, there should be such an issue.

>>"and have you found a cause.?"

This list of possible causes can be long.