July 29, 2016

ACA/AMEP: "BIND" Bound External Reference Named Object Naming

Whenever possible, I try to avoid binding External References with the BIND option; I prefer to use the INSERT option when I cannot leave the references as external. In cases where the "root" layer (for example, A-Door) has the same layer attributes and is treated the exact same way, whether as a "live" layer in the host file or a layer within one or more external references, using the INSERT option simply combines all of the various layers with the same root name into one layer (A-Door in the example here). But there are times when one has to work on a project done by others (perhaps, many others, over a long period of time), where the various layers with the same root name (A-Door, External01|A-Door, External02|A-Door, etc.) are not treated the same way, in particular, with regard to on/off, freeze/thaw and/or viewport freeze/thaw status. If A-Door is on, thawed and viewport thawed, External01|A-Door is globally frozen and External02|A-Door is viewport frozen, using the INSERT option of the BIND command will not preserve what is seen in the sheet. (Or, maybe it does, if nothing on that layer is visible in the viewports on that sheet - but if you are tasked with preparing hundreds of files for turnover at the end of a project on which you did not work, including disciplines other than your own, you will likely not have time to carefully note what is visible in each viewport on each sheet and then reproduce that.) Using the BIND option of the BIND command may be the best course in this case.

I have been involved in such an effort lately, and in the course of that have come to a clearer understanding of how named objects are renamed when using the BIND option of the BIND command. I knew that the named objects in each external reference were renamed, using the external reference name as a prefix, with the vertical bar (|) delimiter being replaced with, typically, $0$. So, External01|A-Door would become External01$0$A-Door. A long time ago, when all this was new to me, I (erroneously) thought that the "0" in the delimiter was the layer name on which the external reference resided, as back then most, if not all, of our external references were placed on Layer 0. At some point, I did a "bind-bind" on an external reference on a different layer, and still got $0$ as the delimiter, and realized that the "0" was not the layer name on which the external reference was at the time of binding, but did not give it a whole lot of additional thought.

In my current effort, I am writing AutoLISP code to help automate certain processing tasks which involve being able to specify layer attributes for the root layer name, and have those applied to all variations of that root layer name, whether or not the layer has a prefix/delimiter from having been "bind-bound". I wanted my code to be able to identify the final delimiter in a layer name, so that the root name could be extracted. I made a very brief attempt to find something in the Help that described how the delimiter is determined, without any success. (It may be in there, and I just did not have enough patience to find it.) So I played around with some test files, with a very small number of layers, to figure out if the delimiter could ever be anything but $0$. As it turns out, it can, but, at least for the way we work, it will almost always be $0$. Your experience may vary, as your workflow may differ from ours.

When you bind-bind an external reference, AutoCAD® will create unique names for all of the named objects in the external reference, whether or not there is a named object of the same type and name in the host file. It does this as previously noted, by starting with a prefix that is the same as the external reference name (which may or may not be the same as the external file name), adding a delimiter consisting of a $ character followed by an integer followed by a $ character, and finally the root name of the named object. The first time you bind-bind an external reference of a given name, that integer will be 0. Should you later add an external reference of that same name (having renamed the bound block -OR- exploded the bound block and purged the definition), and then bind-bind that reference, AutoCAD will see that there already are named objects using the $0$ delimiter, and will increment the integer to "1" - $1$. Do all of that again, and the delimiter will be $2$. Do it eleven times, and the delimiter becomes $10$.

Armed with that knowledge, I was able to write code that would examine the layer names character-by-character, starting at the right end, and would collect the root name in a variable. Once a $ character was found, if it is preceded by one or more integers and then another $ character, that delimiter was saved and the routine then had both the root layer name and the last delimiter in the layer name, allowing the routine to be able to process things accordingly. (If you externally reference a file that has itself had an external reference bind-bound, and then bind-bind the reference, you can get named objects with multiple delimiters, such as External01$0$PreviouslyBound01$0$A-Door.)

June 28, 2016

ACA: AEC Modify Tools, Part 7, AEC Crop

First post in series [AecLineworkExtend]
Previous post in series [AecLineworkMerge]

The AecLineworkCrop command can be found on the Home ribbon tab, on the Modify panel flyout, by selecting the Crop tool from the Obscure/Crop flyout. If the Crop tool is not displayed on the Obscure/Crop flyout, select the right side of the split button (down arrow icon) to deploy the flyout and choose the Crop tool. Or, with no command active, you can right click in the drawing window, and choose AEC Modify Tools > Crop from the context menu.

The AecLineworkCrop command is used to modify the extents of closed Polylines, Circles, Hatches, AEC Polygons, Mass Element Extrusions that have an embedded profile and Spaces, as well as Block References which contain any of these objects by "cropping" the original object to a boundary defined by one or more other objects. In lieu of selecting one or more objects to serve as the crop boundary, you can also specify a rectangular area by selecting its opposite corners. You will be given the option to erase any object(s) selected to define the crop boundary; the default is No, which leaves the crop boundary object(s) in the drawing file.

If you select multiple objects at the first prompt, the AecLineworkCrop command is applied to each of those independently, using the objects selected at the second prompt on each of those selected at the first prompt.
Here are some additional notes regarding the AecLineworkCrop command:
  • Open linework (Lines, Arcs, open Polylines) can be selected as objects to be cropped. If they extend beyond the crop boundary, they will be trimmed to it, but will remain open items of the same object types as the pre-cropped objects.
  • Closed objects, including Circles and closed Polylines, can be selected as objects to be cropped. If a Circle is modified by the AecLineworkCrop command, the result will be one or more closed polylines.
  • MText, Text, Ellipses and Ellipse Arcs cannot be selected as objects to be trimmed, but they can all be used to define the crop boundary. For MText and Text, the bounding box of the text is used as a rectangular crop boundary.
  • Mass Elements with a shape other than "Extrusion" and Mass Element Extrusions that have an external Profile can be selected as linework to be cropped, but will not affected by the AecLineworkCrop command. These types of Mass Elements can be selected as an object to define the crop boundary.
  • If a Block Reference is selected as an object to be cropped, only those nested objects within the block on which the AecLineworkCrop command works will be affected.
  • Attributes within a Block Reference will not be affected by the AecLineworkCrop command.
  • If a Block Reference is selected as linework to be cropped, it has nested elements that can be affected by the AecLineworkCrop command and it is the only instance of that Block Reference in the drawing, then the original block definition will be redefined to include the effects of the crop. If at least one instance of the Block Reference remains unaffected by the crop, then the original block definition will remain unchanged and the affected instance(s) will become instance(s) of new, anonymous block definition(s).
  • If a Block Reference is selected as linework to be cropped and it has multiple nested elements which can be affected by the AecLineworkCrop command, the crop will be applied to each of those elements independently.
  • Multi-View Blocks can be selected as linework to be cropped, but will not be affected by the command.
  • If the active View Block of a Multi-View Block contains linework or objects that can define a crop boundary or part of a crop boundary, it can selected as such.
  • Selecting an associative Hatch as linework to be cropped will result in a non-associative Hatch, regardless of whether or not the boundary of the Hatch is also selected as linework to be cropped the same AecLineworkCrop command.
  • Associative Spaces, Walls, Doors, Windows and Door/Window Assemblies can be selected as linework to be cropped, but will not be affected by the command. These objects can be used to define a crop boundary. Non-associative Spaces can be modified by the AecLineworkCrop command when selected as linework to be cropped.
  • Selecting a single line as the crop boundary will result in no change to the linework to be cropped. You will see this message at the command line: Failed to create a crop boundary from the selected objects. Selecting two lines, even if parallel, will allow a crop boundary to be calculated and applied, but the results may be unexpected.
  • The object(s) defining the crop boundary do not have to form a closed loop. If multiple objects are selected, they do not have to meet endpoint to endpoint, although the results may be unexpected if there is overlap or a gap.
  • Use a closed boundary (or a series of objects forming a closed boundary) for more predictable results.

There are object types and combinations of objects within a Block Reference that I did not test. When using the AecLineworkCrop command in a situation that you have not previously encountered, you may want to use the Mark option of the UNDO command, so that you can easily UNDO Back to the point before the command was used if you get unexpected results.

May 30, 2016

Dynamo - Filter by Type Parameter

I created another custom node for my fire/smoke rating Detail Item placement graph, previously discussed here and here. The previous two nodes gave me a list of all of the straight Walls visible in the current plan View, whose Base Constraint matched the level of the current View. In order to apply the correct Detail Item to each fire/smoke rated Wall, that list needs to be filtered, based on the fire-resistance-rating and whether the Wall is a smoke partition or smoke barrier. This information is stored in a type-based parameter for the Wall Types. I needed to repeat this multiple times in this graph, and since it also seemed to me that this was something that will have use in future projects, I created a custom node.

The custom node takes three inputs, one for the list of Elements (Walls) to be filtered, one for the name of the Parameter that is the basis for the filter and one for the value of the Parameter that will determine which Elements are "in" and which are "out".

The filtering is done in a similar way that the straight Walls were filtered, except this time, instead of using the fact that an empty string would be returned as the value for an instance-based parameter that was not present on the straight Walls, the Element Type of each Wall needs to be retrieved, using an Element.Type node, and then the value of the filtering parameter obtained from that by an Element.GetParameterValueByName node. An == (x equal to y) node is again used to generate a Boolean Mask list of trues and falses.

The Boolean Mask list is then used in a List.FilterByBoolMask to put the Elements that match the parameter in the "in" output and those that do not in the "out" output.

The entire graph of the custom node is shown below.

May 26, 2016

Dynamo - Filter Straight Walls

As part of the Dynamo project for which I developed the Active View Walls at Plan View Level custom node, I also needed to be able to operate on straight Walls and radiused Walls separately. I ended up making a custom node to handle this, to both make the main graph easier to read and so that I could easily reuse the "code" should I need to do this in a different graph in the future.

The graph of the custom node is fairly straightforward, as you can see in the image below. (Click on any reduced-size image to see the image full size.)
A brief description of the various parts and what they do follows.

While my current application passes this node a list of Walls, I decided that may not always be the case in future graphs, so the first set of nodes uses a RemoveIfNot node to strip out any element in the list that is not a Wall.


While poking around in the properties that were available on the Walls in my test project, I noticed that radiused Walls have a parameter called Center Mark Visible, while straight Walls do not. When getting the parameter value for Center Mark Visible, straight Walls will have an empty string value, while radiused Walls will have a value of 0 (center mark not visible) or 1 (center mark visible). I chose to use this as the way to determine if a Wall was straight or radiused. The next set of nodes generates a list of Booleans (true or false) that parallels the list of Walls. The corresponding Boolean will be true if the Center Mark Visible parameter value for the Wall is an empty string (straight Wall) or false if the value is not an empty string (radiused Wall).


The list of Booleans generated by the previous set of nodes is used as a "Boolean mask" by a List.FilterByBoolMask node and applied to the list of Walls to generate two separate lists. The "in" list contains all of the Walls with a corresponding Boolean of true, or all of the straight Walls. The "out" list contains all of the Walls with a corresponding Boolean of false, or all of the radiused Walls.


The in and out lists are connected to the Straight and Curved outputs of the custom node, so that the main graph has access to the two filtered lists. This custom node was developed in Dynamo 0.8.2, but has been successfully used in the 0.9.1 and 1.0.0 versions as well.

April 30, 2016

ACA/AMEP 2017: Styles Browser Enhancements

Several enhancements have been made to the Styles Browser, first introduced in the 2016 release of AutoCAD® Architecture and AutoCAD® MEP.

Add Directory to Content Library
For reference, the image below shows the Content Drawings Library dialog, as it appears in the 2016 release.
When adding files to the Styles Browser Content Drawings Library, instead of specifying individual files, you can specify a folder, and all of the files within that folder will be included in the library.
As always, you can click on an image to see it full size.

Once a folder is added, you can choose whether or not to include all of the files within any subfolders of that folder as well.
The big advantage here is not in saving a few clicks when setting up the Styles Browser Library (you can add multple source files in one operation), but that once a folder is selected, you can add a file to it at a later date and that file will be included in the Styles Browser Content Library automatically. That will save a lot of effort in a firm with more that a handful of users. One note of caution, including a large number of files in the Content Browser Content Library can result in slow performance as the Styles Browser generates preview images. That applies whether or not you are adding folders, but, particularly with the subfolders option checked, it is easier to add a lot of files, perhaps without even realizing it.

Object Type List Auto Scroll
In 2016, when working in the Object Type drop-down list, expanding a category at the bottom of the list did so, but you would then often need to scroll the list to see some or, in some cases, any of the items under the expanded category.
In 2017, when expanding a category at the bottom of the list, the list will automatically scroll to show the items in the expanded category.
A small, but welcome improvement for those making frequent use of the Styles Browser, particularly for MEP users, as they have more categories and the number of items in those categories is greater than the Multi-Purpose Objects category.

MEP Enhancements
  • Additional Objects: Panels, Devices, Schematic Symbols and Plumbing Fittings, which previously used the "old" Select Style dialog, are now integrated into the Styles Browser.
  • Additional Categories: The addition of the previously noted objects has prompted the replacement of the 2016 all-in-one MEP Objects category with five separate categories: Electrical Objects, HVAC Objects, Piping Objects, Plumbing Objects and Schematic Objects. These five categories remain grouped together, after Multi-Purpose Objects, rather than arranging all categories alphabetically, which would place Multi-Purpose Objects between HVAC Objects and Piping Objects.
  • All System Definitions are now selected in the Styles Browser, rather than the two methods used in 2015 (some objects in Styles Browser, some in the Select System dialog).
  • Routing Preferences for Conduit, Duct and Pipe have been added to the Styles Browser, and a single Routing Preferences content drawing has been provided with the out-of-the-box content as the source file. This will allow these routing preferences to be omitted from template files, and imported only as needed from the source file.

Closing Styles Browser
A new command, STYLESBROWSERCLOSE has been added to allow closing the Styles Browser from the command line. The Styles Browser ribbon tool (Home ribbon tab, Build panel, Tools split button drop-down list, Styles Browser tool) now toggles the display of the Styles Browser. If closed, the tool opens it; if open, the tool closes it. In 2016, the tool only opened the Styles Browser (and, if docked or auto-hidden, deployed it).

This Screencast demonstrates some of these new features, in AutoCAD Architecture.

April 20, 2016

Autodesk Answer Day

The next Autodesk® Answer Day will be on May 18, 2016, from 6:00 am to 6:00 pm U.S. Pacific Time. Unlike previous Answer Days, this one will not apply to just one featured software; Autodesk team members will be scouring the AutoCAD, AutoCAD Civil 3D, Revit, Inventor, Vault, Maya and 3ds Max forums.

Read more about the event here and mark your calendar.

April 08, 2016

ACA 2017: CReate type Command Option

Another new feature that some may find of use is the addition of a new command line option, CReate type when adding Walls, Curtain Walls, Railings, Slabs, Roof Slabs and Roofs.

Selecting the CReate type option results in a new command line prompt. The default action is to create a Rectangle shape (by picking the opposite corners of the rectangle). Other shape options are Circle, POlygon and PLine.
Command prompts for those options follow those of the AutoCAD object commands of the same name. While you may not have many occasions for wanting to draw Walls along the lines of a regular polygon, do check out the PLine option, particularly for the object types that do not offer Arc as a command line option (Railings, Slabs, Roof Slabs and Roofs) in the "regular" Add command. For Walls and Curtain Walls, the PLine option makes it much easier to create arc segments that are tangent to the previous segment. And an added bonus when creating Slabs and Roof Slabs, you do not have to explicitly close your shape, as you do when drawing segments under the "regular" Add command. Finally, when using the PLine option when creating a Roof object, you can use object snap tracking to align the next vertex with previous vertices, which you cannot do in the "regular" Add command. This makes it easier (possible) to align your last vertex with the starting vertex on initial placement, rather than having to edit it afterwards.

April 03, 2016

ACA 2017: Grip Editing of a Roof Object Outline

It is that time of year again, when the new releases of Autodesk software come out. One of the new features you can look forward to in AutoCAD® Architecture is the ability to grip edit a Roof Object's outline, allowing you to modify it after the original placement.

As you can see in the image above, in 2016, all of the grips on a Roof are single-function square stretch grips. In 2017, the grips on the Roof outline are enhanced, multi-function grips. Hover over the round vertex grips or the rectangular mid-segment grips to get a pop-up menu offering several grip-edit options.

Vertex Options
For a vertex grip, the Move option is the equivalent to the grip behavior in 2016 and prior. Moving the corner grip moves just the corner point; the other vertices remain in place.

The Remove option does just that, it deletes the vertex.
Of the two roof edges that are deleted, the resulting roof edge will assume the properties of the lowered numbered edge. To see what those properties are, on the Roof contextual ribbon tab, on the Modify panel, select the Edit Edges tool and select the edges on either side of the vertex you plan to remove. The properties in the top row (edge "0") will be applied to the resulting roof edge when you remove that vertex.

The Offset Edges option also allows you to move the vertex, but, unlike the Move option, when you use the Offset Egdes option, the two adjacent edges will remain parallel to their original orientation, and the vertices at the far ends will move as required to allow that.

Mid-segment Options
The Offset option offers the equivalent of the 2016 and prior stretch grip. Selecting this option will allow you to move the entire edge, which will remain parallel to its original orientation. The vertices at either end will move as needed, maintaining the line of the adjacent edges.

To add a new vertex to the Roof, choose the Add Vertex option. The two new Roof edges will inherit the edge properties of the edge they replace.

The Convert to Arc option will convert that roof edge to an arc, and the arc edge of the Roof will be approximated by six straignt segments with the segment endpoints on that arc. (You will not get a conical Roof.)
The arc segment will continue to be treated as one Roof edge; if you desire a different number of segments on the arc, on the Roof contextual ribbon tab, on the Modify panel, select the Edit Edges tool and select the arc edge. In the Roof Edges and Faces dialog, change the value in the Segements column to the desired number of edges.

As with other enhanced grips, in addition to selecting an option from the pop-up menus as noted above, you can select the grip and then, before selecting a new point, tap the CTRL key to cycle through the available options. Preview graphics will show the effects of the currently active option, and, for the mid-segment grip, with ORTHO or POLAR active, if you stop moving the cursor, you will get a tool tip with directions for the current option and a listing of the other options. (For POLAR, a tracking vector must be active for the tooltip to show.)

The brief Screencast below shows the various Roof Object outline grip options in action.

March 28, 2016

Dynamo: Active View Walls at Plan View Level

We use several line-based Detail Items to show fire and smoke ratings on Walls, based on NFPA standard symbols (filled diamonds, one for each hour of fire-resistance rating, with an "S"appended if the wall is also a smoke barrier; unrated smoke partitions get just the "S"). Placing these in plan views is tedious, at best, and it seemed to me that since the fire/smoke rating information is already attached to the Walls in a parameter, and the endpoints of the Wall and the endpoints of the line-based Detail Item are one and the same, that a Dynamo graph ought to be able place the correct family on each Wall. NOTE: This graph was developed using Dynamo 0.8.2.

For the purposes of my proof-of-concept first pass, I chose to focus just on straight Walls. Several early experiments revealed that simply grabbing all of the Walls in the active view would not work if there were Walls within the current View whose Base Constraint was not at the same level as the level associated with the View, as the node that creates the Detail Items would crash if passed a Wall whose Base Constraint was at a different level. I assume that is because the node was trying to create a Detail Item (annoation) at a level other than the current level. Some of these Walls were Walls at a lower level, not seen because they were hidden by the Floor, but due to the View range Bottom being set below the associated level. We would not want to have the line-based family drawn for these. Others could be multi-story Walls, with a Base Constraint at a lower level, where we would want to show the fire/smoke family. For the first pass, these Walls will still need to be done manually; I do not expect there will be many of these in a project.

So my first task was to be able to get a list of all Walls in the current View whose base constraint matched that of the currently active View. I ended up creating a custom node that takes no input, and has three outputs: in [Walls in the active View whose Base Constraints match the associated level of the active View], out [all other Walls in the active View] and level [for plan views, a text string indicating the name of the associated level; for all other views, a text string indicating "Not a Plan View"]. The in output is the one on which the main graph will operate; the other two are there for diagnostic purposes. If the main graph is not behaving as expected, it can be useful to see whether Walls that you expect to receive a Detail Item are in the out list. If all of the Walls end up in the out list, checking the level output to see if there is an unexpected value or that the graph was mistakenly run in a non-plan view can also be helpful in troubleshooting.

There are a number of nodes inside the custom node. One group extracts the level name of the currently active View, by using the Document.Current, Document.ActiveView and Element.GetParameterValueByName nodes, along with a Code Block to provide the name of the parameter of interest, which is "Associated Level". For plan Views, this will be the name of the level with which the View is associated. Non-plan Views (such as elevations or section) will return an empty text string, as they do not have this parameter.

Another group generates a list of all of the Walls in the active View, starting with the All Elements in Active View node. This list is winnowed down to just the Walls by using a RemoveIfNot node, with the type set to "Wall".

A list of names of the level to which each Wall's Base Constraint is associated is derived using two Element.GetParameterValueByName nodes. The first gets the value of the Base Constraint parameter of each Wall; the second gets the name of each Base Constraint.

The level name with which the active View is associated is then compared to the list of level names of the Base Constraints of the Walls using an == (x equal to y) node. This creates a list of true or false values, indicating whether or not the corresponding Wall's Base Constraint level is the same as the active View's level (true means they are the same, false means they are different). This list is used as the mask by a List.FilterByBoolMask node, which splits the list of Walls in the active View into two lists: the "in" list, for Walls where the Base Constraint level matches the level of the active View, and the "out" list, where the levels do not match.

The outputs of the List.FilterByBoolMask node are the "in" and "out" outputs of the custom node. The "level" output is generated by an If node. The test for the If node is an == node, which compares the name of the active View's Associated Level to an empty string. If the level name is equal to an empty string (active View is not a plan view), then the If node result is the text in the Code Block node, "Not a Plan View" (true input). If the active View's Associated Level is not an empty string, then the name of the active View's Associated Level is the result (false input). The If node result is the "level" output of the custom node.

The entire graph of the custom node, which includes a few Watch nodes that were not shown above and which were useful during development but which could be deleted from the custom node, is shown in the image below.

February 26, 2016

Dynamo: Exporting All Schedules in a Revit Model

Autodesk® Revit® allows you to export the contents of a single Schedule View to a tab-delimited text file which can then be opened in a spreadsheet program, such as Microsoft® Excel® [Application Menu > Export > Reports > Schedule]. Handy enough, but what if you have multiple Schedule Views that need to be exported multiple times during the life of a project, as part of a defined information exchange? Individually exporting each Schedule View could quickly become tedious.

Let Dynamo deal with the tedium. A fairly simple graph will export all of the Schedule Views in a project.
This graph is set up to be run manually, as the user will need to use the Directory Path node to specify the folder into which the exported Schedule Views will be placed. The Element Types and All Elements of Type nodes gather all of the Schedule Views [ViewSchedule objects] in the project. The Element.Name and Code Block nodes create the file name for each exported Schedule View by concatenating the ViewSchedule Name with a ".txt" file extension. The Python Script node does the heavy lifting, taking a list of ViewSchedule objects, the directory path and a corresponding list of file names, generates the exported files, and returns a list indicating whether or not each item was exported.

Credit for the Python Script belongs to Dimitar Venkov, who posted a script for exporting a single ViewSchedule in this thread in the Dynamo forum. I modified that script to work with a list of ViewSchedules and a corresponding list of exported file names. A for loop processes each ViewSchedule in turn, and a list of the results is gathered and set as the node output.

Variations on this can be done to export a selected number of ViewSchedules. A simple version is shown below, in which the user has to set up a series of Views nodes, one for each desired ViewSchedule, and then generate a list by passing each one to an input of a List.Create node. A little labor intensive, but if you need to do this multiple times for a given project, you could save a copy with the needed ViewSchedules set up and then run it when new exports are needed

Antony McPhee posted examples using a string filter to export all of the ViewSchedules with a Name starting with a specified string to that same Dynamo forum thread.