Using Blocks: Assemblies and Products

Since the release of A>V>C> plugin version 2026.06.01, many settings related to the assignment and use of blocks in plugins have been added. Let's take a closer look.

Block

First, let's remember that a block in AutoCAD | BricsCAD is a drawing within a drawing. A block consists of visible objects, such as solids or lines. All visible objects in a drawing are usually called Entities. The block itself is also called a Block Definition (or Block Table Record). A block definition is NOT a entity. It is invisible, stored deep within the DWG file, and may never be seen. However, you can add a Block Reference (or, in other words, a Block Insert) to a drawing. This reference is a fully-fledged entity, visible in the drawing and having all the properties of a entity: color, layer...

You can create multiple references to a single block. You can insert block references into another block definition, creating complex hierarchies of nested blocks. Sometimes AutoCAD creates unnamed blocks you don't even know about: dynamic arrays, center marks, tables, dynamic block instances.

It's important not to confuse block definitions and block references. Block definitions have their own properties, but they don't have the familiar color and layer properties. The important properties for us are Name, Explodable (Allow Exploding), and Annotative. A>V>C> programs use these properties to understand the purpose of blocks. You see the block name in the block reference properties, but here the name is not editable—you need to edit the block definition. You usually see the other checkboxes only in the Create New Block dialog and in the Block Editor (when nothing is selected in the drawing).

What are blocks used for? Of course, to group other entities, to insert them together, and to easily update them anywhere in the drawing. But the A>V>C> plugins add new meanings. Three main purposes (types of use) for blocks can be distinguished:

Assemblies

In engineering, assemblies are groups of parts that need to be assembled separately from the rest of the product. These assemblies can then be used to assemble larger assemblies and, ultimately, to assemble the entire complex product. In other words, an assembly is a way to group parts, purchased components, fasteners, and similar real-world objects. Separate "assembly drawings" are usually created for assemblies. However, assemblies don't need to be added to the parts list or the purchased components table. If one of the A>V>C> programs considers a given block to be an assembly, the main purpose of such a block is to extract parts from it. The program will then work with these primitives found in the assembly. Marking a block as "Assembly" forces the A>V>C> plugins to examine the internal contents of these blocks and work with nested entiteis. Some commands intrude into blocks without any settings or permissions. Other commands have a checkbox in the selected object filter settings: "Inside Assemblies."

Dynamic arrays are always considered assemblies, and parts are always extracted from them. Centermark blocks and tables are never extracted.

Assemblies are generally not needed in the parts table, BOM, purchasing table, and other tables. Simply uncheck the Block-Assembly checkbox in the object selection filter in the DataTable settings. This won't prevent you from grouping parts by their owner—the assembly name can appear in group headers and composite part names. Simply use the %owner% or %block% substitutions wherever needed.

But if you specifically need a BOM of assemblies, you can always check the Block-Assembly checkbox, and the assemblies will be listed as a separate row in the tables.

The Drawing Tree displays block assemblies in a separate branch with a separate icon.

Dynamic arrays are usually shown in a separate branch, but you can disable this branch and the arrays will appear among the assemblies.

Products

Blocks representing real-world objects in A>V>C> programs are called Product Blocks. They represent purchased and rented items, externally manufactured parts, and everything you need to manufacture your product. They can contain flat drawings, solids, and other blocks. The contents of such blocks are irrelevant. However, the Product label is used as a signal that this block should become a separate, independent row in tables: in specifications, BOMs, procurement, and any other tables that require blocks. (This doesn't apply to the Sawing Table—it works with solids, not blocks. And solids are always parts. Don't confuse them.) Thus, the purpose of Product Blocks is to serve as table rows.

Of course, no one will stop you from disabling Product Blocks and enabling Assembly Blocks in the Data Table. But think twice before messing with the entire plugin logic.

No unnamed blocks are ever considered products: neither arrays, nor labels, nor tables.

The Drawing Tree shows Products in a separate branch with a bolt icon.

Annotations

All other blocks that were not recognized as Assemblies or as Products are considered as Annotations ("other" blocks). Typically, these are blocks of legend—weld marks, elevation marks, column and zone numbers, stamps, and sheet labels. That is, text information or icons that don't represent any real-world objects. When inserting such icons into model space, they need to be scaled to fit the paper. Therefore, such blocks are usually marked as Annotative. This label is used by default in A>V>C> plugins—it's not an Assembly or a Product.

Nothing can be extracted from such blocks in any A>V>C> programs. And they usually don't appear in tables. If, for example, you need a height mark to be included in a table along with a specific product (as the height at which the product should be mounted), you should create an attribute for the product block and extract the value of this attribute both to the mark in the drawing and to the table. In other words, all data should be part of the actual products, their attributes. And never try to extract numbers from mark blocks. That's a dead end.

The Drawing Tree displays all such "other" blocks in the Annotations branch.

As usual, you can customize everything and add annotation blocks to the selected objects filter in the Data Table. Just first disable ignoring all annotations.

How to configure

To switch the block assignment, you need the A>V>C> Properties Palette. On the Block Definitions tab, there are two checkboxes: Assembly and Product.

When you select a block in the drawing, the palette opens the Block References tab. Here, you only see the Block Name and the reference properties. But you don't see any other block definition properties. You need to switch the tab and configure the block itself, not the reference.

You can uncheck both boxes, and the block will be considered an Annotation Block.

You can check both boxes, and programs will extract data from within the block, just like for Assemblies. At the same time, the block will be written to the Data Tables as a Product. This is useful for dynamic blocks with stretch parameters that contain other product blocks. For example, the Octanorm rack adjusts its length using the Length parameter. But inside it, there's a Lock block and a Support block. This means the rack is a Product, and it's needed in the tables, but we also need to calculate the number of Locks and Supports. So, add a second checkbox, Assembly.

When you switch these settings, an invisible Use attribute will be automatically created in the block. Don't use this attribute or change its value—it's purely for service purposes and is not intended for manual editing. If you haven't purchased the A>V>C> Property Palette plugin, you'll have to rely on the A>V>C> programs' native block recognition. More on that below.

Automatic Recognition of Assemblies and Products

However, assigning these checkboxes to all blocks is tedious. The A>V>C> Property Palette can do this automatically.

The A>V>C> plugins have settings for automatically recognizing Assemblies and Products. The settings are located at the very end of the A>V>C> Property Palette settings.

The fields for setting up Assemblies and Products are the same. You can include three block properties in the check: Explodable, Annotativity, and its Name.

If the check is enabled, the block property will be taken into account; if the check is disabled, the property is ignored. For example, if you use the Explodable property to actually block explosions and not as an assembly marker, then disable the Explodable check.

Please note that the name recognition setting is inverted: blocks with the specified names will NOT be considered Assemblies/Products. This means that if the "Exclude by name" field is empty, all blocks are considered eligible. However, if you enter "ABCD" there, a block with that name will NOT be considered an Assembly/Product, but all others will be.

By default, recognition of all these properties is enabled, meaning all Explodable non-Annotative blocks will be Assemblies, and all non-Explodable non-Annotative blocks will be considered Products. This is how the plugins worked before, but since June 2026, block name recognition has been added to this rule. If a block name begins with a point, it is an Annotation. If the name begins with A$, it is not a Product. All blocks beginning with an exclamation point are also excluded from Products. Annotations will also include blocks with typical annotation names: !Elevation Mark, !Drawing Frame, Stamp, Title, Point.

Note that the exclusion list uses asterisks—any text can appear in the block name at these locations. Thus, Title* refers to any block with a name beginning with the word "Title." The same name masks are used to search for files in MS Windows.

Separate block names in this list with semicolons. Do not add extra spaces.

With the correct Assembly and Product recognition settings, you won't need to configure the checkboxes for each block. Even if you receive someone else's drawing with randomly configured blocks, you can quickly adapt the A>V>C> programs to it as well.

And if recognition worked properly, and you didn't need to manually check the Assembly and Product checkboxes, the Use attribute won't be created.

Also note that if Explodable recognition was enabled and you toggled the Explodable checkbox for a block, the Assembly checkbox will also be toggled automatically.

Page updated

Google Sites

Report abuse