The next package updates will use a slightly different release naming scheme – Calendar versioning, which will replace the actual package publish date I’m using now (YYYY.MM.DD) with Major.Minor.Micro scheme based on the current year and month (i.e. 2021.2.1, 2021.2.2, etc).
I will be adding sample DYN files to the package’s Extras folder and document nodes library on GitHub.
Following up with Revit 2019.2 update install issues, there is another critical point that wasn’t documented. When you install Revit 2019.2, it silently updates your current Dynamo install to the 1.3.4 version.
As a general rule of thumb, Dynamo supports three versions of Revit: the current release (2019) and two versions back (2018 and 2017).
I recently ran into an issue with shared parameters that have the same name but different GUIDs. This happens when somebody creates the new shared parameter instead of using an existing one. And the difference between parameters’ GUIDs is a huge problem: Revit knows that these parameters are not the same by looking at the GUID.
Revit does not show parameter GUID unless you export this parameter to the txt file. And this may be a problem if you have tons of shared parameters loaded to the project.
So I thought that it would be a good idea to build a Dynamo script for reporting some information about shared parameters. Firstly I queried unique Ids for the shared parameters:
Turns out, these Ids are not the GUIDs that I was looking for. This could be checked by opening the shared parameters txt file. That’s why I built a couple of custom nodes using the Revit API to extract data from shared parameters:
The first one (called “SharedParameters.GUID“) extracts names and GUIDs from the shared parameters in the Revit project. These are the GUIDs that could be found in the shared parameters.txt file.
The second one (called “SharedParameters.Info“) extracts type, group, and unit type from shared parameters in the Revit project. This data may be useful for managing parameters (like sorting / grouping) in Dynamo.
A couple of months ago I wrote about the tragic death of Flux.io – the service that allowed us to seamlessly exchange BIM data through the cloud.
One of the possible substitutes for Flux is the Speckle.works – an open source (MIT) data communication platform. Until recently it had only Grasshopper integration, and yesterday they published the very first alpha version of the Dynamo package.
For those of you missing the Flux, go ahead and download the package called “Speckle for Dynamo” from dynamopackages.com
Please note that this is still an alpha version, and there may be some issues. And in case you encounter any problems, don’t hesitate to report them @ GitHub or Speckle.Works.
Dynamo 2.0 has a conflict with Revit 2018.2’s and 2018.3’s (GitHub issue 8768) implementation of P&ID Modeler (thanks jmmkm for the tip in the comments section below) resulting in the library/browser now showing. This issue is not present in 2018.1, or Revit 2019. If you want to use 2.0 with Revit 2018.2 or 2018.3, you will need to remove the the manifest file
For custom nodes, using dot-notation in node Names or Categories will result in additional nested sub-categories. The “.” will work as a delimiter to determine the additional hierarchy. This is new behavior in the library for Dynamo 2.0.
If the network drive pointed to by “Manage Node and Package paths” is > 1TB in size loading Dynamo may take a minute or more, irrespective of actual package size. We recommend drive size of 100GB or smaller.
Toggling the freeze state can cause a node to be executed twice after editing a Code Block Node.
Installers fail to prompt for missing VC++ components which causes Dynamo to silently crash at load time
Packages that deliver DynamoServices.dll may have corrupted multi-output port nodes; instead of multiple output ports, they will be collapsed into a single output port.
Some JSON graphs may open and erroneously appears to have unsaved changes as shown by the asterisks in the workspace tab.
If your workstation contains multiple major versions of Dynamo, e.g, Dynamo 1.x and Dynamo 2.x, Dynamo Player will start with whichever version you select for Dynamo for that session.
Custom node libraries that contain the same category and node names result in unexpected library organization.
If this list of known issues is not critical for you, feel free to be an early adopter.
Imagine that you have to rename a lot of materials inside your Revit model. You could spend ridiculous amount of time, renaming all of the stuff manually. The other option would be to write a relatively simple Dynamo script that will handle this task for you.
And here it is – simple yet powerful Dynamo graph:
This script takes all Revit materials that contain “Concrete”, then adds a custom prefix “Prefix_” to material names. Of course, you could change the logic as you wish.
Please note that you should use the custom node called “Element.SetName” from the Clockwork package (available @ dynamopackages.com) to rename elements! Out-of-the-box (OOTB) node “Element.SetParameterByName” will fail with ‘read-only’ error.
It’s been a while since the last “major” Dynamo update (Dynamo 1.0 was released way back in 2016). And if you are tired waiting for something new, you can download and install one of the latest Dynamo 2.0 daily builds from the Dynamo development builds webpage.
Starting from this year’s daily builds, Dynamo team has changed the way Dynamo installs, so that it doesn’t interfere with existing 1.x installs:
DynamoCore and DynamoRevit will be installed in the folder named using DynamoCore major version instead of major version point minor version;
Installing the new Dynamo 2.x build should not affect your existing Dynamo 1.x installed;
Installing a new Dynamo 2.x build with a larger minor version will overwrite the content in major version folder.
Considering that Dynamo 2.0 will save files to a format that is not compatible with earlier versions, it is highly important to backup your existing Dynamo content folders. Please read this safety note from Dynamo team before downloading and installing daily builds:
These are the early stage builds that are leading to the Dynamo 2.0 release. Please keep in mind that it is early days for these builds, there are still a number of large moving pieces and, as always, this area should be treated as an active construction site. If you do decide to participate, please wear your hardhat!
Dynamo 2.0 brings a plenty of changes, including:
New JSON file format instead of XML-based one;
Updated node library with different organization:
New OOTB (out of the box) dictionary nodes:
Custom packages have been moved to the dedicated “Add-ons” submenu;
Usability fixes for those who work with Python (code execution button, custom templates, multiple editor windows, etc.).
And, of course, a lot of tweaks under the hood. You can view the full list of the future changes here.
Dynamo 2.0 can be installed side-by-side with existing 1.x versions, allowing you to experiment with the early pre-release tools without interfering with your existing workflows. You will be prompted to choose which version you wish to run when first launching Dynamo in Revit:
This setting will be saved per-session of Revit. Restarting Revit will enable you to switch to a different version of Dynamo. Please don’t forget to back up your existing Dynamo workflows, packages and files. And do not use unstable software in the real project environment!
Lately I’ve been working on some Revit railing enhancements. This is still work in progress, but some of the Dynamo nodes are already available online in my updated Zhukoven.com (rev.2017.8.17) package. Below you can see available railing Dynamo nodes (please note that currently all of these nodes support only one railing instance at a time):
Currently there’s no direct link between the railing element and its hosted balusters through the Revit API. So in order to get the baluster profile data, we have to explode railing geometry and extract surfaces. Output values are diameters / widths of baluster elements.
If you need to iteratively place multiple Revit elements with Dynamo, like these stadium chairs, then you are in trouble. The problem comes from element binding – a Dynamo feature which preserves the link between DesignScript and Revit elements during the current Dynamo session. This is how Dynamo works by design, preventing your model from an avalanche of element duplicates, created in ‘Auto’ mode:
Good news, everyone! Revit 2018.1 update is now available for download from the Autodesk Account portal. It comes with some cool new features (see this article at Autodesk blogs for the full info), including enhancements to Dynamo Player. Now it finally supports changing input values directly through the Player UI, which is super handy:
As you can see, there may be plenty of inputs that could be changed without even launching Dynamo. But note that there are still some limitations:
Code blocks as input strings are not supported – if you prefer to write text inputs in code block, using quotes, you’ll need to rebuild these Dynamo graphs (swap Code Blocks with Strings) to use with Player;
Custom nodes as inputs are not supported – they are not shown in the Player UI;
Frozen nodes will be shown as changeable inputs, while they’re not used in the script logic.
Anyway, this is a cool update, and I’m sure that these subtle issues would be fixed in the near future. And by the way, here is the quote from Dynamo community addressing these issues:
We will look into the frozen node and address them in the future.
For the Code Blocks it’s a little more tricky but doable if there is a strong request from the community.
For the custom nodes it would be really nice indeed to have that.
The way I see this as a possibility in the future : a third party will create the custom node on Dynamo and then will have to create the node UI representation in Dynamo Player ( using some Dynamo Player API which doesn’t exist yet ). So the third party will have control over the DB level of the node and also over node UI representation in Dynamo Player.
Good news is that things are designed internally to make this possible in the future.
However , since this still requires a significant development effort we need to have a strong request from the community so that decision factors prioritize this accordingly. So please tweet about it on every occasion !
Today I released my tiny WhatsApp Dynamo package, and it’s now available for download and testing @ dynamopackages.com. WhatsAppDynamo provides integration with WhatsApp Web platform, allowing you to send text data (like URLs, file paths, parameter names, etc.) using Dynamo. Note that due to the platform limitations, images and files are not currently supported – they could be sent only as a hyperlink.
Currently WhatsAppDynamo package consists of a single custom node called “WhatsApp.SendMessage”. This node creates a WhatsApp message (string) in appropriate format to be used in WhatsApp Web platform. As I’ve already said, images and files are not supported due to WhatsApp limitations. Input desired phone number or leave this field blank (“UsePhoneNumber” switch is set to ‘False’ by default) to choose your contact later in browser.
Omit any zeroes, brackets or dashes when adding the phone number in international format: ‘+001-(555)1234567‘ must be converted to ‘15551234567‘ . Also please keep in mind that this phone number must have an active account on WhatsApp, otherwise you won’t be able to send your message.
Please feel free to test the package, and report issues & bugs here: Dynamo packages. It supports Dynamo 1.3.0+ & Revit 2016+
Today a lot of companies and AEC professionals use cloud messengers and productivity tools to organize projects and enhance collaboration. Some of these tools have an API to interact with (Trello, Slack, Asana, for instance), making them suitable for instant information delivery. If you use one of the above mentioned tools, you’re lucky! Dynamo community has already introduced a couple of packages that may streamline your data flow:
But what about WhatsApp? Unfortunately, it doesn’t provide us with the official API, but it has a web version that recognizes special URLs. These URLs could be compiled inside Dynamo in appropriate format, and used to notify your teammates of some significant project issues!
Counting something in Revit seems pretty easy, right? You’re able to extract lots of parameters from different element categories out of the box, and use them to create schedules or count quantities. This concept works great until you get to the system families. They usually make you scratch your head and turn your eyes towards Dynamo to get things done…
Say, we want to schedule the number of balusters by railing types. How are we supposed to count things like this?
The first thing that comes in mind – is to create a Railing schedule and check out available fields. And that’s when the first obstacle comes in your way: there’s no such thing as “Baluster” in the railing schedule:
The next step is to check railing instance or type parameters. Still, nothing useful here but baluster placement, that obviously can’t help us count the number of elements. Well, what if we check out available parameters in Dynamo?