Ryan Lenihan

Fixing SP.Writer Run Time Error 70

If you’re like me, you haven’t used SP.Writer in a while but then if you’re also like me, you will at some point need to use it to generate a project customised shared parameters file. The first thing you do is pull out your trusty SP.Writer only to find that when you create a new parameter you get a run-time error 70.

If you hit the debug button, you will be taken to the mod_GUID module and the 4th line will be highlighted as the problem child.

The function used to create the GUID in SP.Writer was patched in the July 2017 security patches for Microsoft Office so if you’re up to date with your security patches, this is working as intended. That doesn’t help us in the slightest with creating shared parameters though, so what’s the solution?

First if you haven’t already done so, you’ll need to enable the developer toolbar in Excel which you can do by following the instructions over at the Microsoft website.

Once enabled, select Visual Basic from the developer tab on the ribbon. Alternatively you can use the ALT+F11 shortcut on your keyboard.

On the left hand side of your screen, you will see a window titled Project – VBA Project, scroll down until you find Modules. Right click on modules and from the contextual menu select Insert.. -> Module.

Copy and paste the following code into the new module.

Private Type GUID_TYPE
Data1 As Long
Data2 As Integer
Data3 As Integer
Data4(7) As Byte
End Type

Private Declare PtrSafe Function CoCreateGuid Lib "ole32.dll" (guid As GUID_TYPE) As LongPtr
Private Declare PtrSafe Function StringFromGUID2 Lib "ole32.dll" (guid As GUID_TYPE, ByVal lpsGUID As LongPtr, ByVal cbMax As Long) As LongPtr

Function CreateGuidString()
Dim guid As GUID_TYPE
Dim sGUID As String
Dim retValue As LongPtr
Const guidLength As Long = 39 'registry GUID format with null terminator {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
retValue = CoCreateGuid(guid)
If retValue = 0 Then
sGUID = String$(guidLength, vbNullChar)
retValue = StringFromGUID2(guid, StrPtr(sGUID), guidLength)
If retValue = guidLength Then
CreateGuidString = sGUID
End If
End If
End Function

You can also rename the module, I renamed mine to mod_CoCreateGUID as this is will be method we’re using to generate the GUID. If you can’t see your properties window, press the F4 button.

 

Next, open the module mod_GUID and replace the existing code with the code below


Sub GetGUID()
Dim sGUID As String
sGUID = CreateGuidString()
wsData.Cells(LastRow + 1, 2) = "PARAM"
wsData.Cells(LastRow, 3) = Replace(Replace(sGUID, "{", ""), "}", "")

End Sub

 

The final step is to make a small change to the UserParameter form. In the VBA project, find the UserParameter form and right click and select View Code from the contextual menu.

Search for the code


'generate the GUID
GUID

and replace with the code


'generate the GUID
GetGUID

and that’s it! You’re done! You can now start creating shared parameters again. The GUID looks a little longer but it’s actually just the difference in length between upper and lower case with the font used.

C4R – I’m Still Missing Too Many Elements! (Part 2)

So last week you went through how to fix the ‘too many missing elements’ error, but after clearing your cache and sourcing replacement files you’re still seeing the error.

This means things are a little more serious, but there is still a potential solution.

Search the Journal for Missing Element Warnings

This time around, you need to review the journal file and look for the error specifically related to missing elements.

The journal file is located in %LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 201x\Journals you need to be opening the journal file that will have recorded the error. If there error has just occured, it will be recorded in your most recent journal file.

The easiest way to find the most recent file is to change your file sorting by date modified with the newest files at the top.

Open the journal in a text editor (Notepad or Notepad++) and search for the name of the model causing the problem.

This time you want to search for the text missing elem within your journal file.

If you can’t find the text in your most recent journal file, don’t panic! Using Notepad++ you can actually search for a string in all files located in a folder.

The search results will appear at the bottom of Notepad++ showing which files it has found the search string in.

You will soon have a list of elements that are missing from your model. The numbers represent the element ID of the missing elements.

Repairing the damage

To recover your file, locate the most recent backup file that contains the missing elements. You can restore backups from your local cache in the same way you have always been able to restore backups with Revit, it’s just now there is an extra step in finding the GUID of the RVT file before you can restore a backup.

Search for the name of your Revit file in the journal. This will give you the GUID for the project and file.

Once you have found the name of the model,take the model GUID and search for it in your CollaborationCache folder. You need to find the folder named <revit model GUID>_backup

From the Collaborate tab of the ribbon, select Restore Backup

Paste your backup folder path into the folder name location, it should follow the format C:\Users\<user name>\AppData\Local\Autodesk\Revit\Autodesk Revit 201x\CollaborationCache\<local cache id>\<project GUID>\<model GUID>_backup

Select the most recent backup and work your way back until you find a working copy.

Save the file in a new location. Don’t open the file just yet.

Browse to where you have saved your backup file and then open the file with the audit box checked.

Once you have successfully opened the model, using the Select by ID tool, search for the elements in your backup model.

Make sure that all the elements display correctly and work as expected.

The audited model becomes your new central model. You need to run through the process of loading the model onto C4R.

If anyone else is working on the project, their local cache will no longer synchronise with the newly created cloud model. Others in the team will need to rename or delete the folders in both their CollaborationCache and PacCache folders.

And that’s it! You’re done!

One final note..

When speaking with Autodesk, they advised that the best way to prevent this missing elements error is to always open your C4R models with the audit check box ticked. It’s a little bit of extra pain, but if it saves you from having to manually recover models, then happy days!

Final note for real this time..

In addition to the above, both Revit 2017 and 2018 have had updates released since I originally wrote this post. Autodesk’s urge anyone that is experiencing too many missing element errors to update their entire team to Revit 2017.2.2 and/or 2018.1.1. The patches for both fix the problems that cause these errors.

Aligning 3D Section Boxes

A quick one that came up today.. “Ryan, how do I align a 3D section box with an object that is not at right angles to the view?”

So what we’re talking about here is when we have a plan view that is rotated away from a straight up and down orientation.

 

When you create your default 3D view, it might end up looking something like this. You can rotate the section view but it’s a “near enough is good enough” approach and you can never truly align your section box.

 

That is unless you think about things a little differently. I’ve been preaching this method for quite a few years now but it seems be be a tool within Revit that not a lot of people know about.

Simply draw a 2D section that aligns with your building. If you need, you can draw detail lines to help in aligning your section, but Revit should automatically align with elements such as grids and walls in your model.

 

In your 3D view, right click on the view cube and then select Orient to View -> Section -> Section xx

And that’s it! You’re done!

C4R – So You’re Missing Many Elements? (Part 1)

If you’ve been working on C4R for even just a little while, you have probably seen the dreaded ‘too many missing elements’ error.

When you’re opening a Revit model, there could be more elements in the central model than there is in your local model. Usually Revit will synchronise the changes with your local and the endless grind of office life moves on. Sometimes though, things just don’t work out and you’re presented with this

Luckily, there are solutions to get your files working again.

Step 1 – Clearing the Local Cache

First, we need to clear the C4R local cache on your machine. You have two choices here, either blow away everything in the cache, or just try to clean out the file that you’re having issues with.

The Cache Location

The local cache is located in %LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 201x\CollaborationCache where Autodesk Revit 201x is the version of Revit you are using.

The files and folders in the local cache are coded with unique GUIDs.

The first folder is your local machine code

The second level of folders are the projects. The files within the folders are the models related to the project.

 

In addition to the collaboration cache, there is another folder named PacCache which is located in %LOCALAPPDATA%\Autodesk\Revit\PacCache

The PacCache is where all the delta file transfer information is cached for all the C4R models that you have worked on. The PacCache isn’t split into individual projects, or even individual versions of Revit. Everything is lumped in the same folder.

This is where you take the easy way, or the (not really very) hard way.

Method 1 – The easy way.
Just Kill Everything.

It’s listed first simply because it’s easiest. This should actually be the last method you try for clearing out your cache.

The easy way is to just wipe out everything in both the CollaborationCache and PacCache folders. With Revit closed, just browse to the folders in your favourite file explorer you can delete the contents of the PacCache folder and then move everything inside the CollaborationCache folder to another location. You can delete the contents of the CollaborationCache as well, however I highly recommend moving just in case you need to restore backups. That’s right! There are local backups of your C4R projects and they’re located in these folders.

Just keep in mind that when you do this, it means you need to cache all the files with your local machine from the cloud again, so it might take some time the next time you open up your models, especially if you have quite a number of projects and models hosted on the cloud.

Method 2 – Just The (not really very) hard way.
Removing a Single File.

The hard way is to remove just the single file giving you grief. It’s actually not very hard at all, you just have to poke around in the journal file to find the specific GUID for your file.

The journal file is located in %LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 201x\Journals if you have just experienced the error, then you will need the most recent journal file.

The easiest way to find the most recent file is to change your file sorting by date modified with the newest files at the top.

Open the journal in a text editor (Notepad or Notepad++) and search for the name of the model causing the problem.

Search for the name of your Revit file in the journal. This will give you the GUID for the project and file.

Once you have found the name of the model, you need to search for the GUID by copying and pasting it into the search box and move all the files and folders with that GUID from the local cache folders.

The files and folders will be located in both the CollaborationCache and the PacCache folders. You need to delete the PacCache folder, but for the CollaborationCache you should move the folder that has the same GUID of file that you’re having trouble with without the {curly braces} to another location. Again, you can delete everything but if you do you won’t be able to restore any backups after the files are deleted.

Method 3 – Definitely way harder than it needs to be.
Clearing out a single project.

Clearing the cache for an entire project is quite a bit more difficult due to the PacCache folder is not sorted into Revit versions or even into projects and you need to clear out the PacCache because otherwise you’re going to have a bad time.

If you really want to head down this path, the easiest way to find the project GUID in your journal file.

Get the complete local path to the project folder within your Collaboration cache folder. Move or delete the project from the CollaborationCache folder. Again the same warning applies if you choose to delete the contents of your CollaborationCache.

C:\Users\<user name>\AppData\Local\Autodesk\Revit\Autodesk Revit 201x\CollaborationCache\<your local machine code>\<project guid>

Open up Google Chrome (Edge and Internet Explorer will not work), copy the full folder location to your project and paste it into the address bar in Chrome prefixed with file://

What this does is it lists all the files from the CollaborationCache in your browser. Copy the GUID of each Revit file without the .rvt extension and search for those GUIDs in the PacCache folder.

Delete any results you find from the PacCache folder.

Step 2 – Re-populate your local cache

Method 1 – Just re-open from C4R

The first method is to simply open your file again from C4R. Revit will populate your local cache with brand new copies of the files that you’ve moved or deleted so you can start fresh.

From experience this works maybe 80% of the time.

Method 2 – ‘Borrow’ Someone Else’s File

Borrowing.. Stealing.. Fixing your local C4R cache. Call it what you will. This method only really works if someone else is also currently working on the model. What you’re trying to do here is get yourself the most recent working copy of the file so that you lose as little work as possible.

You need to find someone else that is working on the project without any missing element errors, find who has the most recent copy and take only RVT file only from their CollaborationCache, do not take anything from the PacCache.

From experience this works the other 18% of the time.

Lookup Tables and You – Part 2 – Improving Your Workflow

Now you understand how lookup tables are formatted and referenced from Revit families, let’s have a look at how we can improve our workflow.

It’s clear how lookup tables are beneficial to the pipe and conduit modelling process, so how can we use them in other Revit family categories?

Originally lookup tables were only available to pipe and conduit fittings, but we can use them in any family category. We can build fully flexible families that a controlled with lookup tables, we just need to use a bit of common sense when deciding if a lookup table is best suited or not.

Valves would be suited quite well to utilising lookup tables, whereas a VAV box would be more suited to using formulas and other parameters.

Building Your Own Lookup Table

You can use dimensions, angles and integers to both look up and be looked up, the trick to working with integers is that your column header format should follow

ParameterName##number##integer

Using integers can be valuable within lookup tables to control the dimensions of specified manufacturer equipment. To achieve this, we need to take the manufacturer sizes and populate them into a lookup table. Working this way locks down the sizes so that the end user is unable to manipulate them. In this example, we’re going to work with a basic rainwater tank.

Rainwater tanks are a perfect use of lookup tables, you could have a family file that contains data for one manufacturer, then the lookup table drives the dimensions based on the volume. We use the volume value because this will drive all other dimensions of the tank.

We’re going to use an integer parameter for our tank volume, as volume parameters can not be used in lookup tables.

This is our basic lookup table to get started with. We’re going to look up the volume as an integer which will in turn drive the tank diameter, height and inlet height dimensions.

You can see that based on our basic lookup table and our lookup formulas, the correct data is being input into the family.

Once the lookup table is populated with the tank dimensions across the product catalogue, all a user needs to do is change the tank volume to a value that corresponds with one in the lookup table and all the dimensions will automatically update.

A trick that can be used with lookup tables is that we can drive a single text parameter with a lookup table, the same old restrictions apply though, if you’re looking up an instance parameter, you must be driving an instance parameter.

The secret behind bringing text in from the lookup table is to leave the lookup column in the formula blank. In our rainwater tank example, that would read as follows

size_lookup(Lookup Table Name, “”, “NOT SPECIFIED”, TankVolume)

Getting More Advanced – Allowing Custom User Input

The example water tank is great when you want to completely lock down a family, but what if you want the option to allow input form the user? We can allow for this by adding a few additional parameters to the family.

To achieve this, we’ll add a yes/no parameter to the family which can be checked when the user wants to specify a custom size. When checked, this parameter will override the lookup table.

We then need to add parameters within the family for every parameter that is controlled by the lookup table.

The new parameters that have been created in the family are CustomDiameter, CustomHeight, CustomInletHeight and CustomTankType.

We now need to change the formulas for each parameter being controlled by the lookup table so that the lookup formula is nested within an if statement.

This also allows our trick with the text lookup to make it very clear that custom dimensions are being used, as we’re changing the TankType parameter to read “CUSTOM DIMENSIONS”

Modifying Existing Pipe Fitting Lookup Tables

Now that we know everything there is to know about lookup tables, modifying existing lookup tables should be quite easy. For this example, we’re going to use a PVC pipework bend.

You can download a copy of the files I’m working with here

 

Open the family

Open the family type dialogue

Click on the Manage Lookup Tables button

Export the existing lookup table

Rename the lookup table to Bend_PVC_DWV_Iplex.csv

 

Back in the family types dialogue, import the new Bend_PVC_DWV_Iplex.csv and chance the Lookup Table Name parameter to Bend_PVC_DWV_Iplex

Apply the changes and close the family types dialogue before continuing.

Download a copy of the Iplex DWV piping catalogue from http://www.iplex.com.au/iplex.php?page=lib&lib=8&sec=186 we will be referring to the Plan Bend F&F on page 24.

We also need to refer to the Drain, Waste & Vent Pipe table on page 23 for information about pipe diameters and wall thicknesses

Open the .csv file in Excel. The out of the box (OOTB) lookup table is in inches, it is up to you if you convert the current dimensions to millimetres or not, but we will need to change the column headers from inches to millimetres (USA spelling)

Compare the dimensions of the Iplex product catalogue with that of the Revit family.

Iplex Catalogue Revit Family
L1 – L2 (from fitting table) Centre to Socket Bottom (CtSB)
L2 (from fitting table) Socket Depth (SDpt)
a (from fitting table) Angle
L1 (from pipe size table) Fitting Outside Diameter (FOD)
L2 (from pipe size table) Wall Thickness (WThk)

Something to take note of is that the L1 dimension from the pipe fitting takes into account the total length of the fitting from the centre of the fitting to the end of the fitting including the socket.

Within Revit the Centre to Socket Bottom does not include the socket, so the figure that we need to take for CtSB is actually L1 – L2

In this example, I’m going to start with the 40 dia fitting size, however if you have a need for the 32dia pipe fittings you can start there.

There are 3 different 40 dia elbows in the Iplex catalogue. 40×15°, 40×45° and 40×90° each with differing dimensions. To allow for each specific fitting, we’re going to add a row for each fitting from the catalogue.

Fill out the corresponding data to the lookup table from the Iplex catalogue, once done, save the csv file and load it back into the family and test the flexing of your new 40 dia fitting.

If you’re happy with how the family flexes for your 40 dia fitting, continue adding the remaining sizes to the lookup table.

Once you’re finished you’ll have a complete, dimensionally accurate Iplex PVC pipe fitting.

Lookup Tables and You – Part 1 – Understanding Lookup Tables

Life isn’t just about Dynamo, so here is something a little different to mix things up.

Earlier this year I spoke at BiLT ANZ 2017, I had the opportunity to present two separate talks of which one was lookup tables. It’s a bit of a dry topic, so stick with me.

Lookup tables for pipe and conduit fittings provide an invaluable enhancement to the MEP workflow that we take for granted. On every project we work on, lookup tables save us countless hours in the modelling process. Without them, modelling a pipe system would require each individual pipe fitting to be sized as you go. It may be only a few seconds lost per fitting, but multiply that by hundreds or even thousands of times across a project. Then consider the revisions across the piping network. Those few seconds wasted quickly adds up.

At their core, lookup tables are simply comma separated value files (.csv) that are used in conjunction with Revit family files. Prior to Revit 2014, these files were stored on your hard drive or in a common network location and that location was referenced by the revit.ini file.

You might have had experience with tiny pipework fittings that wouldn’t size correctly in Revit if the lookup table location was not correctly configured. Nowadays, lookup tables are stored within the family themselves, provided your family content has been properly updated to 2014 or newer the new system with embedded lookup tables should eliminate those tiny fittings altogether.

Most commonly lookup tables are used for defining pipe and conduit fittings based on the nominal diameter of the fitting. Revit is then able to automatically size and resize fittings based on the size for the pipe the fitting is connected to by using the data contained within the lookup table.

The Lookup Table Format

Lookup tables can be created and edited in either a simple text editor such as Notepad or Notepad++ or in Microsoft Excel and it’s alternatives.

The first column is a reference column, the values in this column could be ‘Tom’ or ‘Jerry’ but it’s obviously more useful to give enter data that is relevant to the family being created.

Usually when dealing with pipe and conduit fittings this is the nominal diameter, when dealing with pipework branches, I like to format my references as Upstream x Downstream x Branch so for example, 100x100x65. You could however include product names, say if it was a 5000 litres grease arrestor, the reference could be GreasePit5000

The second column defines the lookup value which is typically the nominal diameter of the fitting. This is the column that Revit will look up to determine the remaining parameters for the element.

The formatting of the headers within the csv file is

ParameterName##ParameterType##ParameterUnits

which you can see in the example above. The formatting of the headers is critical for the lookup tables to work.

In column B of the example, we have ND##length##millimeters (note US spelling of millimetres) which in this to the nominal diameter, it’s a length parameter and the units are in millimetres.

If further lookup values are required, say for example in the instance of a pipework branch, more lookup columns can be added as needed, shifting the remaining columns to the right.

As you can see in the above example, we have three nominal diameter columns to determine the size of our fitting.

The remaining columns after our lookup columns contains the data that drives the modelled dimensions of the Revit family and you can have as many lookup columns as you need to generate your family.

How Lookup Tables Are Used in Revit Families

Lookup tables are stored within the family file itself through the Manage Lookup Tables dialogue. The lookup table is then referenced using a text based parameter and lookup formulas are used to retrieve these values from the lookup table.

Importing and Referencing the Lookup Table

To import the lookup table, you first must open the family file itself. In the family types dialogue box, click on the Manage Lookup Tables button.

Once in the Manage Lookup Tables dialogue, you have the option to either import or export the lookup tables contained within the family.

If you’re starting with a family that already has an associated lookup table, it’s always a good idea to start by exporting the original lookup table so you can use that as a base and then modify.

Once you have a completed lookup table, you can import it in the Manage Lookup Tables dialogue. You can have multiple lookup tables within your family files and chose whichever is required.

Once the lookup table has been imported, you need to add a text parameter to the family that references the lookup table name. Historically this parameter has been named Lookup Table Name although you can name this parameter anything that you like, it’s best to remain consistent with the out of the box parameter naming.

When filling out the parameter data, it needs to match the name of the .csv file that you are going to use, minus the .csv extension.

Lookup Table Formulas

The formula used to reference the lookup tables is

size_lookup (Lookup Table Name, “Lookup Column”, Default If Not Found, Lookup Value) 

The format of the formula is similar to that of an if statement.

The first portion of the formula is telling Revit to find a value in the lookup table “Lookup Table Name” for a column named “Lookup Column” and then pull the value from the row that corresponds with the value from the “Lookup value”. If there is no match, Revit will provide the value from “Default If Not Found Value”.

In the example above, the formula is finding the value for the fitting outside diameter.

Stepping through the formula, Revit will lookup the table that has been defined in the parameter Lookup Table Name for a value in in the column named “FOD” that corresponds with the lookup value of the Nominal Diameter parameter (50mm). If no match is found for the nominal diameter in the lookup value column, a value equal to Nominal Diameter 1 + 9.1mm will be returned.

Note that the nominal diameter is currently set at 50mm. If we refer to our csv file we’ll see that our lookup value is ND1 which corresponds with Nominal Diameter 1 in our family.

When ND1 is 50mm we can see that the value of FOD is 56mm, this has set our family to have a fitting outside diameter of 56mm.

What About Multiple Lookup Values?

You may have noticed that the example family used is a DWV pipe branch fitting, so we need to deal with multiple lookup values. The fitting may be a reducing branch or it may have different variations in branch angles.

To achieve this, we simply need to add more lookup values to the end of the formula.

In this example we’re looking up the socket bottom to socket bottom run, we are again referencing the same lookup table however this time we’re looking for a match for Nominal Diameter 1, Nominal Diameter 2, Nominal Diameter 3 and Angle in a single row within the lookup table.

If a match is found, Revit will return the value from the column that corresponds with SBtSBR. If no match is found, Revit will return a value equal to that of Nominal Diameter 3 + 27.7mm.

This particular fitting we are working with is a 50x50x50 x 45° DWV branch

Referring to our csv file, we can see that when we look up the values 50, 50, 50 and 45 the corresponding value in the SBtSBR column is 81mm which is the value that has been set in our family.

Remember that the lookup columns need to be in order in columns from left to right to be able to lookup multiple values.

 

So that’s it for understanding how lookup tables work, stay tuned for Part 2 where we look at applying the use of lookup tables to improve our workflow.

 

Placing Multiple Views on Sheets With Dynamo

Keeping on the theme of Dynamo and drawing setup, I had a series of MEP models that I needed to setup that had 2 views that needed to be placed on each sheet, a main view and a smaller inset view.

I started from my sheet generation Dynamo graph and ran through a number of different options to enable to graph to place multiple sheets on views in the correct location.

The method I found posed the least problems in the process was to add an extra column to my Excel file for the names of the inset views

As a bit of ground work, I needed to figure out where I wanted my views to be located, so I made up mock sheet with the views placed where I wanted them to sit on the sheet

I then threw together a quick graph that allowed me to select the viewport I’ve placed on the sheet with the Select Model Element node and running that through the Rhythm node Viewport.LocationData I can get the centre point of the viewport box. This centre point of each viewport will be the values used when we move the viewports later.

Once the viewport locations are picked up, we can get to modifying our original sheet creation graph.

The first modification that we need to make is with the additional column in Excel. Copy the original section of the graph and change the code block to 3 so that we are reading from column D of the excel file.

The next step we filter our views again, but this time we’re filtering two separate lists of views, things get a little messy but it’s still reasonably easy to manage. Note that I dropped a List.Clean node in the mix as I was having views return with no data, the List.Clean node removed empty and null values.

Remember that if you’re going to clean the list, you need to feed the other nodes with the cleaned list, do not mix and match between clean and unclean lists, otherwise you’ll have a bad time.

Now we should have two lists of element ids, one for our main views and another for our inset views.

Our main views get fed through the same series of nodes from the moving views on sheets post.

So while all of this is happening, where the output of the Sheet.ByNameNumberTitleBlockAndViews node shoots off a second time to tell our insets what sheets they need to be placed on.

The problem you will stumble into when placing views in this method is that if the sheet hasn’t yet been created, the inset views won’t be placed. The way that I decided to handle it was by using a Passthrough node from the Clockwork package. The Passthrough node implements an order of execution. It will wait for the node threaded into the waitFor input to complete before sending on the data threaded into the passThrough input.

I fed the Passthrough node with the results of moving the main viewport on each sheet, once this main views have been moved the sheet numbers are sent through to the Viewport.Create node.

Running the script, we end up with views placed exactly where they want them. The example GIF below is recorded in real time and runs for 14 seconds from start to finish, which includes checking each sheet has been correctly created.

 

This is great and all, but what happens when you have two difference types of “main” views, one where you want placed along with an inset like the above example and another where you ant the views placed centrally?

The way I found best to handle this scenario is to add a String.Contains node along with an if node to control the location of the viewports depending on the name of the view itself.

In this particular example, the names of the “main” views are being checked for if they contain the string Platform Level_ and if they do, the views are being placed centrally on the sheet, otherwise they’re being placed offset from centre to allow for the inset view to be placed on the same sheet.

The nodes labelled platform view x, main view x, platform view y and  main view y are simply code blocks that I have renamed so I know exactly what they are.

Tagging Invert Levels

Over the years, I’ve seen a lot of err.. solutions for tagging invert levels. From adding shared parameters to your pipe families through to using Dynamo and everything in between.

Ignoring the fact that you can’t add parameters to system families like duct and pipework, there is a far simpler way to get what you’re after.

Ever heard of the spot elevation tool?

The key is in the settings that you use.

The settings that I use in my templates are as follows, the settings to change are highlighted below

In the units format dialogue, change the your settings to match the following

And of course, don’t forget to select the bottom elevation!

Importing DWGs to Revit While Still Displaying MTEXT Correctly

For those of you that still heavily rely on DWG based details and schematics that are bought into Revit from AutoCAD, you might have experienced issues maintaining the correct alignment of MTEXT once imported into Revit.

There is actually quite a simple solution, and no it’s not exploding the text.

In AutoCAD, MTEXT has grips that define the bounds of the MTEXT element.

The location of the grip indicates that the MTEXT bounding box doesn’t actually fully enclose the text contained within it. When the DWG is imported into Revit the text is displayed differently, it gives a completely unexpected result by placing the MTEXT word on the same line as TRUNCATED

If we modify the bounding box in AutoCAD to not truncate any of the text with the bounding box like so

And once we reload the DWG file into Revit and the text will display correctly.

 

Practical Dynamo – Moving Views Based on Another View

Okay, so we’re on a roll with practical Dynamo usage. Last week we looked at placing views centrally on our sheets, but what if you didn’t want the view centrally placed? What if you wanted views placed in the same location on all sheets maybe in the top left of the page?

As always with Dyanmo, there is a solution for that. Again we’re going to be using the Rhythm custom node package to get the work done. This method requires one sheet to be used as a template that all the following sheets are based on.

In our example this time around, where we want the view located is in the top left (shown on the left) but by default Dynamo places our views in the bottom left (shown on the right)

 

This workflow can be easily integrated into our previous graph where we created new sheets in Dynamo using Excel however for this example we’re going to create a standalone graph. For this example though, it’s assumed that this time around though that you already have all the sheets and views required created.

 

First we start by taking all of our sheets, we do this simply by using Categories and then All Elements of Category, after that we get into our Rhythm nodes.

First we get a list of all of the viewports on our sheets using the Sheet.GetViewportsAndViews node. Run the list through a List.Clean node to remove the empty list entries. This leaves us with just the viewport entries.

Meanwhile, we also need to get the viewport from our template sheet. In this instance our template sheet will be drawing H101 which we’ll select using the Sheets node and then we’ll feed that node into the Sheet.GetViewportsAndViews node which are both from the Rhythm package.

And finally we feed our data lists into the Viewport.SetLocationBasedOnOther node, which again is from Rhythm. It’s as simple as that.

Hit the run button and watch the magic happen.