2012-07 frank fralick - concept to fabrication

Design to Fabrication Workflows with Revit, Rhino, and InventorFrank Fralick, The Beck Group

Class Description This class will discuss various methodologies for dealing with interoperability between Revit, Rhino, and Inventor. This presentation will also address in a broader sense the motivations behind these various approaches. As the lecture was prepared as a last minute substitution for the originally planned presentation, this document will attempt to be more detailed than just a basic outline. Any questions or comments can be directed to [email protected].

About the Speaker:

Frank Fralick has worked at The Beck Group, a Dallas, Texas based integrated practice of architects, contractors, and real estate developers, since 2006. In that time, Frank’s day to day focus has become looking for and pursuing opportunities for specialty self-performance work and unique procurement opportunities across the organization. This also includes developing technology strategies for efficiently producing digital prototypes of target scopes of work and the integration of these processes into design workflows. Past experience in this regard ranges from structural and ornamental steel to millwork. Frank is based in Atlanta, GA.

Design to Fabrication Workflows with Revit, Rhino, and Inventor Frank Fralick, The Beck Group

of 27

How we build Our aim is to create processes that support and organize construction efforts from the earliest design phases. How the building will come together is part of the concept. We start out to build this: Then this happens. All the parts and pieces show up for assembly at the site: This is what we want. The process is organizing the work at earlier times in other locations:


of 27

The parts and pieces are assembled into a seemingly ad-hoc solution:

On the next project, if this work is truly ad-hoc, the process is typically designed again. However, though different at first glance, the work fits within product-process families designed to efficiently deal with the variability of scope.


of 27

Flow of Information Marketing around digital prototyping and BIM usually involves emphasis on how digital prototyping can support building information modelling. The methods for using digital prototyping to support BIM are well documented and will not be discussed in this document.


of 27

Inventor to Revit vs. Revit to Inventor:

Inventor Revit:

Moving simplified modelled geometry from Inventor to Revit is the only direction that you will typically hear Autodesk talk about. There are built in tools in Inventor to assist in preparing a model for import to Revit, but no similar tools to handle moving data in an intelligent way from Revit to Inventor. Most people working in very traditional practices, whether design, construction, or manufacturing, can’t imagine a world where an entire team of people would design processes where each step, from conceptual design to maintenance, feeds the next step of the process.

Put cooperation into the infrastructure. Design systems that coordinate the output of the group as a byproduct of the operating of the system… -Clay Shirky

Instead of tools aimed at true collaboration, we get tools that fabricators and manufacturers use within Inventor to help someone who is farther upstream in the process do their job. Creating a model only to have someone inform me how to change it, when the information to model correctly existed previously, seems backwards. The constraints of the detail model should flow down from the design model. Ask yourself where coordination should happen. Or rather, what attributes does a good environment for coordination have? Above all else, a coordination tool should be inclusive of project participants, and make their inclusion easy. How foolish it is to imagine that a design team that receives an Inventor model of a mechanical unit will understand the best way to resolve an issue! Maybe there is another configuration that costs the same and doesn’t involve moving 5 walls and a plumbing riser. Promoting one-sided coordination is inefficient and is not in the best interest of any client. In a large internal study of subcontractor change orders, we found that the impact of issues related to system-to-system design coordination were far greater than geometry based


of 27

problems. The potential value of solving geometric coordination issues has a relatively low ceiling when compared to the value of issues that arise between system designs, and the particulars of manufactured building products. Seeing if something fits is just one aspect of seeing if it works. It may seem nice or convenient to have an Inventor model in your Revit model, but the most efficient thing to do from the perspective of an entire building project is for a party to model only their work, with all work coming together in a federated model, in a purpose built collaborative coordination platform. Also, I’m sure that many design firms feel as we do, that the inconsistency of 3rd party Revit content requires us to forbid its inclusion in Revit models as a policy. If something needs to be in the Revit model, we model it. Revit Inventor: Some readers will have to suspend their disbelief for this next scenario. Image a project team and all its participants, develop processes that propagate efficiencies all the way down from concept to fabrication and beyond. See the next section for the answer to the obligatory “but what about the risk!” question. How might the process of designing the building and creating construction documentation interact with the process of creating digital prototypes for fabrication and installation? Revit is representational. It is building scale, and is very limited on the amount of detail that can be included. This is as it should be. While Revit models are representational, critical aspects of these models are very literal. While a curtainwall mullion in Revit may just be a box, the designer very much intends for the centerline of the real mullion to be located as it is in the Revit model. Examples of this are everywhere, and paying attention to those critical, literal aspects of the BIM is one key in building efficiencies into a process where the design team is collaborating with downstream partners.


of 27

Utilization of these aspects downstream requires early involvement from the end user of the data. An architect would need to collude with the end user of their data about what it represents, so the downstream process can be set up to take advantage of this information. I will talk through some real and hypothetical examples to clear up what I mean by this.

Risk Much is made about the role risk mitigation plays in preventing collaborative workflows.

Consider… For both architects and builders, fees have dwindled in the last 40 years. This is mostly a result of business policies focused on risk aversion. In the same time period, the cost to build a building has gone up past the rate of inflation. This is for the same reasons (this isn’t true everywhere, however). There is a large cost to transferring risk that architects and builders pay for with their fee. Often, it’s likely that the cost of separating your firm from a particular risk is much higher than the cost of actually realizing that risk. It’s like taking a lower fee in exchange for inordinate amounts of clerical work, no time for those with the experience to focus on the execution of the project, project partners that by default see you as an enemy, and a disjointed process that dysfunctional, change-order-filled projects are symptomatic of. Often “risk” is not truly evaluated. Old modes of behaviour drive decisions, even when less than beneficial. The scope and responsibility held by project participants is taken for granted by most. Viewing the use of design information in this light, and re-evaluating the approach to doing business, can allow for new opportunities for designers and those building the building. Risks are real, and they require specific strategies on a case by case basis that rely on good processes and solid execution as opposed to giant contingencies. However, shifting attitudes and changing


of 27

economics around risk, partly made possible through new technologies, bring popular risk mitigation strategies into question. I’m not suggesting that insurance and strong contractural language is not necessary, only that a blanket approach to risk is detrimental to projects.

Process Design Designing processes to support new means and methods, and new division of responsibility can become complicated. Often technology processes that support innovative ways of doing things can end up like this: It may work, it may not. No matter what happens, the person along for the ride will at best be extremely uncomfortable, at worst, feel a lot of pain. Investing in testing new methodologies is essential for successful


of 27

implementation. New ideas, implemented on the fly, usually won’t get repeated, even if the idea is a good one

Examples of Work using RevitInventor Workflows: Hinman Research Building, Georgia Tech College of Architecture: Self-performed millwork and furniture scope. Beck detailed, generated g-code, installed with own labor force, etc. Project was designed in Rhino and Revit.


of 27

Examples Hinman Research Building, Georgia Tech College of Architecture


of 27

Examples

Hinman Research Building, Georgia Tech College of Architecture


of 27

Examples Tuttle Courthouse Annex. Self-performed blast glazing support structural steel. This project was a renovation to a 1915 five story brick building, modified to meet federal building blast requirements. The structural requirements for anchor location and spacing were very specific to the opening size. With hundreds of openings with somewhat random sizes, detailing the structural steel for the façade became a nightmare for the steel contractor. Beck took this work over and used a process to automate the use of the Revit model, made accurate using laser scans, to generate the unique steel frame in Inventor for each rough opening. We used this information to buy the steel direct and also hired erectors directly. While the steel contractor wanted additional money to complete this work, we were able to complete the work ourselves for the original budget and make additional fee for a few reasons. First, we were able to put a process in place to solve the problem effectively. Second, Beck was the architect on this project and the model was made with the intention of being used in the field. Third, we evaluated the risks accurately. We could have detailed 25% of the steel incorrectly and would have still broken even compared to what was originally budgeted for. This was acceptable. Measuring the risk situation realistically, combined with a technology based process that can support it, is how a risk like this can be undertaken.


of 27

RevitInventor, the basics So now that we have covered why you might want to consider more collaborative work flows, we can look at some specifics. If we want to make a digital prototype from Revit, we at least need some geometry. The easiest, non-programming based solution to this involves the use of point families within Revit. There are many tools available, some for free, made for reporting coordinates and other attributes of nested point families. Understanding where the point family is located and what a coordinate actually represents within the context of the Revit model is critical for this to be a useful workflow. After reporting points to a CSV or excel file, you can then reformat the Excel file to match Inventor’s required formatting for Excel data import. There is a freely available Autodesk Labs plugin for Inventor called Point Importer that works well for this. The drawback is that it only brings in sketch points. The upside is the sketch points will be associative to the Excel file, and changes to this file will be reflected in the Inventor model. This is the layout sketch for a large steel trellis at the Dallas Arboretum Children’s Learning Garden, created with the process described above:


of 27

Within Revit, an adaptive component was created that contained nine instances of a point family. After placing the trellis adaptive components within the Revit model, the coordinates of the critical points where reported and then sketch points were placed. The real downside to starting with sketch points is that you need work points to constrain assemblies to in Inventor. Without programming, you will be clicking a lot to place all the work points in the image above. A built in function within Inventor called iCopy was then used to place the digital prototype instances at each location. Associating the iCopy assembly with a drawing file and details prior to this means detailing is generated automatically. iCopy is a powerful feature when everything works right. Even Autodesk’s tutorials make creation of reliable iCopy assemblies sound like a voodoo science. When constraining these assemblies, unpredictable results can often occur. Here is an example:


of 27

In the end, with enough tweaking and prodding, iCopy can be made to work: The biggest single drawback to iCopy is that there are very few situations where repeating, but different assemblies can be instantiated all at once. If components aren’t parallel or along a path, you must instantiate iCopy assemblies one at a time. If you can’t program, this is better than nothing, otherwise, this limitation becomes very frustrating quickly. Internally we have abandoned the use of iCopy for API functions that are more flexible and robust. The next few sections will discuss programmatic approaches to this kind of interoperability problem.


of 27

RevitInventor Through the API’s “What about IFC???” you might ask. A lot has been invested in IFC and still is today. It still doesn’t work. Autodesk, Tekla, Catia, Bentley and others are not incentivised to invest money supporting a format that makes their own products less competitive. Bentley and Tekla’s current “OpenBIM” (read: “MakeAutodeskMatterLess”) marketing campaign about IFC should not be taken as a sign of their altruism. Rather than rely on unmotivated developers to make interoperability really work, or hope that year after year they support the new IFC standard, our approach is to focus on the scopes that this is an issue for, or that are of particular interest to us, and use each API to do the interrogation and generation processes within each platform. Software developers, especially for platforms like Inventor that have large third party applications written on top of them, are somewhat married to their API’s. Even though you may see a PowerPoint from Autodesk describing the 300 changes made to the API from one year to the next, 95% of the time, code written for 2009 will work in 2013. Some things may change, but generally nothing major that will severely break your code. Maintenance of an investment in API interoperability will not be a large annual expense.


of 27

I read a lot of API code examples for Revit, Rhino, and Inventor. With Revit and Inventor, what you will notice is that the vast majority of example code you will find will deal with interrogating the model. When I move data from Rhino to Revit, or Revit to Inventor, these processes need to be generative. I want to make the detailed model automatically using the lower level-of-detail model. As model generating code samples are scarce, especially with Inventor, there is hardly any downside to using a language that is not commonly used for these platforms, but is better for generative model making procedures. Rather than VB.NET or C#, we predominantly use Python when programming in all three of these platforms.

Why Python:

Python is an open source, incredibly popular language whose popularity is still on the rise.

It is a relatively mature language. Brian Ekins said in an article “Beginning API” on ModTheMachine that Python is a relatively new, fringe language. C++: 1983, Python: 1991, VBA: 1993, Delphi: 1994, VB.Net: 2001, C#: 2001. It is true there aren’t code samples. That is changing, and Beck will be a large part of the new Python sample codebase that is starting to emerge in the AEC technology community.

Python is optimized for speed of development, where other languages like C++ are optimized for speed of execution. For AEC applications, your Python program will not be the performance choke point, the software you are programming for will be. It is advantageous in real world situations filled with deadlines to optimize your programming process around speed of development.

Python’s syntax is clear and expressive. There is usually one right way to do something. This makes reading others code much more intuitive, and makes the learning process easier.

There are several flavors of Python. “CPython” is the technical name for what is most commonly referred to as just “Python”. IronPython is Python for .NET. There is also a Java implementation called Jython. Not to mention various packages


of 27

for wrapping existing C and C++ libraries. You can learn Python and accomplish a lot before feeling the urge to learn your next language.

Direct access to COM automation API’s like NavisWorks, MSOffice, and Inventor. Effectively becomes similar to a command prompt. .NET languages can’t offer this kind of direct access feel in most situations.

There are few differences between how IronPython is coded and Python is coded. Beginners will not likely run into these nuances.

How do we use it?:

Python is a great scripting language but its real power is in its object model. Class hierarchy and inheritance aspects of Python make it natural for relating common types of building elements. We work out of a common Python package that contains the functions and classes used to work with various platforms. At the highest level, classes are generic and contain “hook” methods for generating subclass instances that are more specific to a software platform. Subclasses contain platform specific descriptions of what the generic parent class looks like within the software platform in question. This approach, coupled with a data persistence model, offer flexibility and opportunities for creativity in solving one-off problems. In simple terms, an example might be that of a “Panel”. An instance of the “Panel” class could be several things, a metal panel, a curtainwall panel, a window, a door, a louver etc. All of these things have attributes in common. They have centroids, normal directions, corner points, and more. What we aim to do when writing code for a specific problem, is to generalize the object being represented, and then create a subclass that inherits those attributes, and describes what it


of 27

means to be a Panel in Revit, or Rhino, or Inventor, or other applications. The generic “Panel” class might have a method called “MakeRevitPanel” that allows the creation of the subclass instances. This is the basic structure for how we take one set of items in one model, and create the comparable set of items natively in a second platform. Over the past year this approach has developed into somewhat of a framework for building these types of solutions. We intend in the near future to release the package of modules we use internally as an open source project. Prior to that some clean-up has to take place. I have started testing a new implementation that uses postgreSQL to represent class objects, but can also handle migrations and changes to class structures. In addition to the class/database structure, there are several useful platform specific utilities for common tasks. Users would have the choice of either a database based project or, even simpler than the pickle system, but easier for beginners to understand, data persistence based on text files. I am also working on a method that automagically creates a Django project with our module’s class structure, which would become the starting point for developing web applications in Django that are related to model data. This is something I’m extremely excited to get to a point where I can start distributing it. The following is not to give a tutorial about how to use Python, but rather, to give a broad idea of what it looks like to use Python with Revit, Rhino, or Inventor.

Using Python with Revit:

There is a plugin developed by Daren Thomas called Revit Python Shell that is the Python access point to Revit. IronPython is required for Revit. This has some drawbacks, but does have the benefit of access to most .NET functionality available to the .NET languages. The same plugin works with Vasari. Python within Revit is great for generating geometry, placing families, modifying instance parameters, and a host of other


of 27

things. One of the more powerful aspects is you can go into a tool like Rhino that is better suited for creating freeform geometry, get a dataset out of it, and go into Revit and create native Revit geometry. The biggest benefit of using Python with Revit may be the ease with which mundane tedious tasks can be automated. There are several basic examples of using Python with Revit available on Nathan Miller’s Revit API Notebook: http://theprovingground.wikidot.com/revit-api

Using Python with Inventor:

You can use either CPython or IronPython. There are some peculiarities associated with programming a COM automation API that can be avoided by using regular Python. Python use with COM requires the creation of a wrapper that is essentially a Python mapping of the applications type library. A google search for “Python Early Binding” will turn up several examples of how to do this.

Using Python with Rhino:

As of Rhino 5.0, Rhino comes with an embedded IronPython environment. Rhino’s API is simple and powerful and a lot of fun to program with. There are many API examples available as well as a great free book by Skylar Tibbits called “Rhino Python 101 Primer”.

RhinoRevitInventor Python Example A colleague, Brandon Coates, drew this concept and created the subsequent model within Rhino. Being in conceptual design, there are a few things we want to know right away about this part of the design.


of 27

Two things we would like to know are what it will look like, and how much it might cost. There are a couple of hurdles to getting those two tasks accomplished effectively. It’s a fairly complex shape and it will be difficult to model the parts in literal way…normally that task is reserved for months into the project. But we have some tools that will make this possible. We also care about producing something very close to what might get built because we might start thinking about how we are going to buy this, because there could be opportunity to get a lower price. Those decisions need to happen now, when all there is a sketch. Even if this gets bought traditionally, we can expect inflated, non-competitive pricing for anything this representational. Rhino model of the concept:


of 27

The code samples I show here are not meant as a tutorial so much as they are meant provide some ideas about how to most effectively use Python, and reuse code. These code samples use an internal module with a variety of classes and functions that are meant to be reused. Writing most of the code you write one time is the key to gaining forward momentum with API programming. The final result of this exercise will look like a lot of work, but it will have been accomplished with very little coding. The first thing we need to do is evaluate the Rhino surface, check and make sure we don’t have any panels that have their normal directions facing the wrong direction, and create class instance objects with certain attributes. For what we are doing we don’t need many to move forward. This example uses text files to temporarily hold data, but long term you will be better off learning some other form of data persistence like pickling. The first line imports an external module that contains the functions and classes we need to obtain panel data in a way that we can use later. Again, the point is if you choose to start learning Python, learning to organize your code for reuse is the key to success. Without this module, this program would be five times as long. The second line imports Rhino’s API module and names it “rs”. The 5th line makes a call to a function calls “MeshToRhinoPanel” which does


of 27

what it sounds like. The interesting thing to note for programmers reading this coming from other languages, is that the “rs” module is being passed into the function without ever having called the function. Classes and functions are first class objects in Python and can be passed around just like variables. This is an important feature of the language. If this were not so we would have to import rhinoscriptsyntax again within the function since functions have their own isolated namespaces. After we call “MeshToRhinoPanel”, data is written to a file, and we can move on to Revit or Inventor. Adaptive components are the easiest way to create something like this form in Revit. For instantiating families for something like this, fairly custom content is required but it can be worth the effort. When we go into RevitPython Shell, a similarly short script that relies on an external module instantiates all the adaptive components: It’s hard to tell, but the program was told to create deeper louvers at the bottom, shallower at the top.


of 27

Now say we want to produce an Inventor model. Today our process, at the beginning, resembles iCopy. We make an adaptive assembly that we will copy and place over and over. This is somewhat of a trick due to Inventor’s file structure. Here is a simple structural glass module and a metal panel system unit that we will use for the façade and the roof:


of 27

The code that was written to generate the instances of these models was fairly short, maybe 20 lines. The code within the imported module it relies on to do this however is hundreds of lines. This strategy also allows intermediate and beginner Python users to be able to be able to do more and learn faster. The 20 lines to do this in Inventor is something a beginner can handle. Writing the whole thing is not very approachable for someone just starting out. The results of the program running are very informative. This information can be used to get accurate pricing as well as really inform the designer about what a proposed set of systems might look like. This was all generated in thirty minutes.


of 27

Summary The previous example showed a workflow where the doing of each step produced the information necessary to complete the next task as a by-product. This type of back-and-forth API based interoperability process will become more and more prevalent in progressive projects where a premium is placed on efficiencies through collaboration. The hurdles to improving and expanding the technology associated with these types of workflows are still relatively small compared to the hurdle that entrenched, old-school cultures can impose. Deep process innovation that is based on cooperation will protect design intent, allow architects to accomplish more, reduce the cost of work, enable new means and methods, and reduce schedules. These things will be achievable only if organizational leadership can see the opportunities, and be willing to rethink how they do business, create new business models, and start to define a new culture within the design and building professions.

2012-07 frank fralick - concept to fabrication

Documents