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.

February 10, 2016

Revit: Which Update Corresponds to Which Build Number?

This Autodesk Knowledge Network Article lists the Build Number for Autodesk® Revit® versions from 2012 through 2016, Update 1 for R2. I expect the article will be updated with any future updates/service packs for 2016 (and beyond).

The Build Number can be determined by selecting the About Autodesk Revit 20xx item on the Help drop-down list found at the upper right corner of the Revit window. Select the right portion of the Help split button (with the down arrow icon) to deploy the drop-down list.

The Build Number is located in the upper right corner of the About Autodesk Revit 20xx dialog.

(Click on any image to see a full-size version.)

January 27, 2016

ACA: Ceiling Grid Boundary Selection and Resource Manager Error

That is a pretty scary warning dialog. It makes me think that, at the very least, my AecGuiBase70 file has some form of corruption. If you receive this error dialog while adding a Ceiling Grid and using the Set boundary command option to select a Polyline as the ceiling boundary, your AecGuiBase70 is just fine. The problem is that the Polyline you selected is not a closed Polyline.

"But wait!" you exclaim. "That Polyline looks closed to me." It may very well looked closed, but when drawing the Polyline, merely snapping the last point to the first point does not a closed Polyline make. Next time, stifle the urge to add one more point on top of the first point, and use the Close command option, by selecting it on the Command Line, or by typing C and then pressing the ENTER key.
Fix the already drawn Polyline by using the Close command option of the PEDIT command or by selecting the Polyline and, on the Properties palette, on the Design tab, under the Misc category, set the Closed property to Yes.

BONUS TIP: You can double-click that Polyline to initiate the PEDIT command on that Polyline. Personally, I would get rid of that last vertex and then close the Polyline, but that is not necessary for the Polyline to be a valid Ceiling Grid boundary.

Curiously, the Set boundary option of the CEILINGGRIDCLIP command provides an informative message at the Command line, rather than the non-informative Error dialog the CEILINGGRIDADD command gives, when selecting an open Polyline as the boundary.
The CEILINGGRIDCLIP command is used to add a clipping boundary to an already-placed Ceiling Grid, and can be accessed by selecting the Ceiling Grid and then, on the Ceiling Grid contextual ribbon tab, on the Clipping panel, by selecting the Set Boundary tool.