AU2016 Class submittal

I have been ignoring the blog for the past two months as I have been spending a lot of time on site for a project I'm on. I have been doing more work in the background however. At the end of May I have finally managed to submit my Autodesk University 2016 proposal. Fingers crossed it will get accepted.

Have you submitted any classes ? I would be interested to hear your subjects and if you are planning on attending. If you have submitted yours, good luck and hope to see you there.

UK Dynamo User Group Meeting

The UK Dynamo User Group South is organising its first meeting in London in April. I'm really excited to see what other practices are doing with Dynamo in the UK. A really great opportunity for exchanging ideas over a few beers. Fingers crossed for a few MEP implementations for Dynamo.

Outline agenda for the evening is:
- Opening at introduction
- Aims of the group and feedback on what you want
- 2 x Case study presentations of uses of Dynamo
- 1hour practical hands on breakout workshop session
- Feedback from breakout session
- Summary and Close
8pm - Optional BIM Beers & Networking at local pub. 

For more details about the agenda and for Registration please see the UKDUG website. You can also find them on twitter @UKDynUG. Hopefully I'll see a few of you there. 

Window Forms via Dynamo

Within our practice we are looking at ways of deploying the Dynamo graphs to engineers and technicians that don't have much or any experience with Dynamo. Opening the graphs can become very daunting at times for most people so this could become a reason not to use them.

Last December Dyno by ArcProjects was mentioned in one of the AU classes. The tool would allow you to run Dynamo graphs just by double clicking on a button without opening Dynamo's main window at all. This has the potential of being a very great tool, as it will allow you to run Dynamo graphs as Macros instead.

This workflow however raised a few other questions. If the users are not going to open the Dynamo graphs at all, how are they going to interact with the graph when an user input is required ? It turns out that you can (not easily however) create window forms in IronPython. Who knew, right ?

Code snippet:

 
 import clr  
 import sys  
 clr.AddReference('System.Windows.Forms')  
 clr.AddReference('System.Drawing')  
 from System.Windows.Forms import Application, Button, Form, Label, TextBox  
 from System.Drawing import Point  

 # The input to this node will be stored in the IN0...INX variable(s). 
 dataEnteringNode = IN[0]  

 # Store the user input in this variable
   def saveDataFromForm():  
      UserInput.append(form.textbox.Text)  

 # Windows form structureclass SimpleTextBoxForm(Form):  
   def __init__(self):  
     self.Text = "Simple TextBox Example"  

     self.Width = 300     
     self.Height = 200  

     self.label = Label()  
     self.label.Text = dataEnteringNode  
     self.label.Location = Point(25, 25)  
     self.label.Height = 25     
     self.label.Width = 250  

     self.textbox = TextBox()  
     self.textbox.Text = "The Default Text"     
     self.textbox.Location = Point(25, 75)  
     self.textbox.Width = 150  

     self.button1 = Button()  
     self.button1.Text = 'Press Me'     
     self.button1.Location = Point(25, 125)  
     self.button1.Click += self.update  

     self.button2 = Button()  
     self.button2.Text = 'Reset'     
     self.button2.Location = Point(125, 125)  
     self.button2.Click += self.reset  

     self.AcceptButton = self.button1  
     self.CancelButton = self.button2  

     self.Controls.Add(self.label)  
     self.Controls.Add(self.textbox)  
     self.Controls.Add(self.button1)  
     self.Controls.Add(self.button2)  

   def update(self, sender, event):  
     self.label.Text = self.textbox.Text  
     saveDataFromForm()  

   def reset(self, sender, event):  
     self.label.Text = dataEnteringNode  
     self.textbox.Text = "The Default Text"  

 UserInput = list()  
 form = SimpleTextBoxForm()  
 Application.Run(form)  
   
 #Assign your output to the OUT variable 
OUT = UserInput  

The code above will create a Windows Form with the description inside the form introduced via a string in Revit. The title of the Windows Form can also be formatted in the same way, by using IN[1]. The user introduced a value or text in the text box. This user input will then form the Output.

Windows Form in Dynamo Example

As it stands, the form won't close unless one presses the X button. If the PressMe button is pressed multiple times, then the Output will generate a list. If this is not the desired behavior, then this can be tweaked by making the button close the form when pressed.

The Window Form can open the door for multiple applications in a Dynamo graph, however it is quite tedious to build. What could have been easily done in C# with a few lines of code, in IronPython we are looking at easily 10 times more lines.

Special thanks to Michael Kirschner and the Autodesk Vasari community, as well as Voidspace for offering all the material and inspiration. Further reads here:

Autodesk Vasari community : Python import statements for Dynamo Thread
Voidsapce website : IronPython and Windows Forms

Revit Circuit Tag Customisation

I had a request the other day from one of my electrical colleagues to help out with a Revit Circuit tag problem. They wanted on their project to reverse the order of the Phase and Way in the tag to comply with the industry standard in the UK.

The Revit standard circuit tag we are using is formatted Panel Name / Circuit, with Circuit being (Phase/Way). The industry standard for circuit tagging in the UK is however Panel Name / Way / Phase. From what I can tell there is no way of customising this directly into Revit. After a bit of research online I've found that this problem came up quite a few times on forums, with no particular fix however. 

To work around it I assigned two shared parameters to the Wires category in Project Parameters. These two parameters would then allow me to modify the circuit tag with the format I needed. 

Revit Wire Properties

However this workaround would require someone to manually populate the newly created Phase and Way parameters. One quicker way of doing this would be to export the circuit parameters into an excel file and manipulate the data there. Even though this would be slightly faster, it would still be quite a time consuming workflow by introducing excel into the scheme. Whenever possible I try to avoid data manipulation in excel if it can be avoided. 

The task seemed perfect for Dynamo and a good opportunity for me to put my limited Python knowledge to use. 

Dynamo Diagram

Python - Circuit Phase data extraction

Python - Circuit Way data extraction

The Dynamo diagram would read all the Wire Circuits Parameter values in the model and then using the Python script it would break the data into two. In my case I had L2/1, L2 being the phase and 1 being the Way. The new data would then be pushed back to Revit and the newly created parameters (Phase and Way) would be populated based on the Circuit data. 

Last step of the exercise was to modify the Revit Wire Tag Family to work with the newly created parameters.

Revit Wire Tag Family - Edit Label window

D-day is here

I started this blog as a personal archive of thoughts on BIM for MEP, Dynamo for Revit as well as to keep a record of my progress with learning Python and Dynamo for MEP design.

I initially started collecting this kind of information using oneNote, however everything has become very hard to manage. The idea of using a blog for tracking my Pyton/Dynamo learning curve as well as storing other useful information related to BIM came from listening to episode two of CodingNewbie. In this episode Brian Douglas talks about his experience with learning Ruby and the steps he took from being a complete newbie to a professional programmer.

I am a mechanical engineer at Arup. I was first introduced to Revit in September 2011 when I joined Arup as a graduate mechanical engineer. Since then, I feel in love with how Building Information Modelling (BIM) and Revit have revolutionised the buildings industry by ensuring better coordination and management of construction information. My main focus as an engineer and as a BIM enthusiast is finding ways of using the "I" in BIM, that is the information in the models to inform the design process and project deliverables.

I have always been interested in programming and since I was ten I had various attempts to get in the programming world. I started with learning Pascal programming language in school and continued with Visual FoxPro in high school. I wrote a few small programs in Visual Basic and C# along the years, however due to my job I got a bit disconnected coding and never took it further than the basics. With no practice, I can say I forgot most of the syntax but still remember some of the concepts.

Almost one year ago I stumbled across Dynamo, which is a Visual Programming medium that helps create add-ins for Revit. It can also be used for solving problems not related to Revit, however the Revit interface is what it is typically used for. After playing around for a few months and creating small add-ins, in December 2015 I had the opportunity to participate at Autodesk University 2015 as a co-speaker with Andrew Duncan. We presented the An MEP Engineer's Guide to Dynamo to a class of 200 people. This has really opened my appetite for Dynamo and I stated researching more about it.

Dynamo comes with a number of standard nodes which you can use to create the programs. The community also generates loads of new nodes almost everyday. However, sometimes that is not enough or you would like a node that would do what you want instead of using 15 nodes to achieve the same thing. For these kind of situations Dynamo also supports Python script based on the IronPython platform. I decided to use this as an excuse and try to make a comeback in the coding world by learning Python.

With this blog I aim to monitor my progress both with Python and Dynamo, but also keep track of other BIM related topics.