Andersen Windows

Anyone who has been around Revit for awhile knows that a long time ago Andersen Window and door came out with some families that impossibly complex and overbearing. So, since we're modeling/designing our own house, and we want Andersen Windows and Doors, I broke down and built some for myself. I've loaded them up on Revit city, you'll find single, double and triple casements & awnings (which share the same basic details). I followed the 200 series, but that generally matches the 400 series too. I did type catalogs for the casements. They all use a "core" casement or awning family that is shared nested. The cores are built with simple sweeps based on simplified Andersen details, so feel free to make more detailed if you desire. You'll also find simple interior and exterior trim that you can easily modify if you want. Find them here.

Happy Thanksgiving, and see you at AU!
-R

AU 2008 UnConference

If you follow the AU blog you know the UnConference Schedule has been released. This is the second annual UnConference at AU and for a second year in a row I will be running a session. You can also find out more information here.

My session this year is entitled: Size Doesn't Matter: A Discussion on Strategies for Complex Revit Projects Large and Small

So what would I like to see this discussion all about? In the last four years of working with Revit, I've come to realize that any number of conditions—such as multiple design firms, Integrated Project Delivery, multiple 3D models, phasing or early bid packages—can transform a straightforward design job into a knotty Revit problem. In that time I've discussed, observed and participated in several projects exploring a variety of techniques to address these issues.

This session is meant to be an active conversation by the attendees about their experiences and expertise. This will allow a broader and more detailed discussion of what works, what doesn’t, and when and where various strategies are appropriate. I'm expecting participants to use example project and conditions from their experiences to focus on Revit techniques, which may be influenced by hardware considerations but are fundamentally about selecting approaches when working in Revit. Be prepared to actively participate if you come.

My wife Krista will also be running her own UnConfernece session: Pros & Cons of 3D
Modeling vs. 2d Detailing in Revit

Hope to see you there.

A new favorite software & toy

Awhile back I bought myself a small little Bamboo tablet from Wacom. For those more familiar with the larger versions, this little $70 toy, is nice, it slips in my laptop bag effortlessly, and only requires a USB cable (no wall wart!). I can use it on my lap or at a desk without a problem.

The problem was, outside of Photoshop, I didn't have any good software to use it with, my laptop doesn't have TabletPC Edition on it, and most other programs (even sketch-up) are not really tablet friendly. You may recall I talked about Moi awhile back, adn while it is built for tablet use, I never have gotten into it, and I don't really need a modeling program like that at this time.

What I was originally hoping for when buying the tablet, was the ability to do some sketching, either on digital printouts (like PDF's), image files or freehand. Enter Autodesk, this summer they showed us a cheap little program called "Sketchbook Pro".

Sketchbok Pro is a nice little sketching program. Nothing fancy really, Autodesk says they benchmark against Photoshop as they develop Sketchbook. What is extremely nice is that its built for use with a tablet and stylus. The interface requires no right clicking and the gestures to manage the interface are tablet friendly. I've been using it primarily at the moment to work on our house, while we have a beautiful Revit model, it is often nice to sketch out ideas (check out the screenshot).

CSI Revit (Part III): Recreating a "crime"

We've discussed how to read journals, and how to use them to track down problems. Journals can also be used to recreate and create. Complex journal files built over a full working session perhaps don't work so well, but journal files created for specific purpose can be useful. For instance, Ken Stowe from Autodesk has in the past created journal files that can be used to sequence a Revit model using multiple phases to generate still frames of a Revit model being assembled. Journal files can be used to repeat tasks. Code can also be inserted into journal files to make changes or make things happen.

One useful thing you can do is insert code to create timers. Creating timers in a journal file allows us to test how long Revit takes to perform certain operations. So, we can create a journal file with specific tasks and operations that we plan to time. When creating a journal file to use for whatever purposes you need to be very specific about the tasks you do. In order to make it easier to read/edit the journal, excessive view manipulation, and "errors" should be avoided. Rather the specific tasks should carried out with the least possible mouse movement (shortcuts help). Once you've written your journal file, it is much easier to edit it if it has been cleaned (see the end of this post). When "writing" a journal file it is important that you always have the original file available that you start with, otherwise the journal will not run correctly. Another note, it is possible to save when creating a journal file, however when running the journal it must be able to exactly replicate the saving conditions. Writing journals with Workshared files also creates some difficulties, your best bet is to work with a detached copy, and not save.

With the clean journal file to create timers some basic code needs to be inserted at the beginning, after the line that contains "username":

Set fso = CreateObject("Scripting.FileSystemObject") 'create external file object
Set outf = fso.OpenTextFile("c:\My Temp\Journal Results\TimeResults.txt", 2, True) 'insert path for results file
Dim sTime,eTime,comment 'initialize variables

The first line starts the process, the second line "Set out f..." establishes where the results from the timers will be saved, and the last line "Dim..." sets the variables for the timers. After that, it is only a matter of actually creating the timers themselves.

Each timer is broke into a start and end. The end code looks like this (remember any line that starts with ( ' ) is a comment):

'stop timer code eTime = DateDiff("s", sTime, Time) 'put this at end of sequence to be timed. outf.WriteLine eTime & " Seconds of Elapsed Time for:" & comment 'end of code

I usually start with the end code, as you may recall it is easier to find "transaction complete" then the start. Once I have my end code in, I look for the start of the operation I want to time, and then I add the start code that looks like this:
'start timer code sTime = Time 'put this at start of sequence to be timed. comment = "Test Sequence Blah Blah" 'comment to specify what we are timing. 'stuff to time here

With the start code, its important to note that you need to add a comment to describe or name the timer where it says: comment = "Test Sequence Blah Blah"

A finished journal timer should look something like the image to the right.

Once you're code is inserted, you should be all set to run the journal. To run the journal, you will want to drag and drop the Journal file onto the Revit.exe icon located under ..\Program Files\Revit flavor\Program

At Burt Hill we've developed a utility that takes care of running journal files automatically, and repeatedly, so that we can gather multiple instances of results from the same machine running the same test. This allows for a better statistical comparison of machine performance from machine to machine, and makes it easier to run the same journal. We've also modified the code a little bit so that multiple results are appended to a single results file. With the code above, the results file is overwritten everytime the journal is run.

If you're interested, pop over to this AUGI thread. You'll find our benchmarker utility, and a couple of journal and revit files available for testing your machine(s). We've also tested using project files, however simply due to size, I can't release those. You'll also find a utility for cleaning the journal files, to make them easier to read.

CSI Revit (Part II): Tracking down the culprit

We left with how to read journal files, and a suggestion on practicing reading them. Today, we're going to talk about where and how they can come in use for some computer forensic detective work.

Allow me to set the scene.

• At Burt Hill we encourage and keep multiple local files when working on a workshare project. This has come in use multiple times, and for multiple reasons. We usually suggest that a user maintain a week's worth, and sequentially overwrite the files.
• A project team has been working diligently to their deadline. Annotating views, drawing details, setting up sheets, running check prints.
• They're busy working the weekend, 12 hour days to meet their Monday evening print deadline.

Sometime late Sunday or Monday morning, someone realizes all the Keynotes are missing from all the views. The team knew they had been there as they had previous copies (digital & physical) of views/sheets that were complete.

The first step, was to figure out what could be done in the short term to deal with the problem. This is where our rule about multiple local files came in handy the first time. Team members were able to immediately start rescuing views by opening old local files and copying/pasting the missing Keynote Tags from old to current.

The next step was to figure out what happened to the Keynote tags, needless to user error was the primary suspect, but, whose error, and when? How many times have we all worked on large Revit projects, and had something "go missing" or something was "deleted" and we are left to wonder, what, who, when, how... Well one of our top users decided to track down what happened.

To start, he looked through the local files, local file history, and central file history to narrow down when the keynotes disappeared. For those who don't know, for both central and local files you can pull the save history from the File menu (see screenshot).

Once he had an idea of where to look more specifically is where the journal files became useful. With some sense of the approximate time to look for, our investigator used the find command to look for keynotes. What he eventually found was this in a journal file...

One of the users on the project had used "Select All Instances" of the keynote family used in the project, and hit "delete". For some reason this user was under the impression that "Select All Instances" was valid only for the active view! As it was, the user was helping our investigator, and was the one to find the four pages of text showing every keynote being selected, it was quite the teaching moment for the whole team.

While it took the lead investigator a good chunk of his day to sort through all the related files. It was needless to say quite useful to determine what had happened, most importantly, to help assure it doesn't happen again. While the copies of files, and back-ups helped with restoring the missing work, and helped to narrow down the time period in which the mistake happened, without the user's journal file there would have been no way to so clearly identify the culprit.

Check back at the end of this week (or beginning of next), for the my wrap up on journal files.

CSI Revit (Part I): How to read the crime scene.

Do you know what a journal file is? If you have dealt with Autodesk support on an extended issue you may have been asked to submit journal files, but you may still not quite know what they are.

Quite simply journal files record all your actions during a Revit session, Revit creates a new journal file whenever you start it, and stops writing when you close it. Under the general tab of the options dialog [Settings menu >> Options] are two choices for how many and for how long you keep journal files. Revit always writes its journal files to the same location; Windows XP c:\Program Files\Revit version\Journals. I would assume that Vista installs maintain a similar structure/relationship. Journals are simple text files (in fact their extension is .txt) and can easily be opened with a program like "Notepad" (my preferred editor for such things). They are always named in the same format "journal.xxxx.txt", where the x's are four digit sequence.

Journal files are pretty interesting things, and can prove handy, particularly when troubleshooting. The reason Autodesk or Revit support likes to get their hands on journal files is because it gives them a window into what the user is/was doing, how the file is behaving, and how the computer is performing. Journal files not only record the user's interactions with the Revit file, but they also record vital computer statistics like how much memory is available, the video card installed, etc; all of which is useful when troubleshooting a problem.

The particularly nice thing about journal files is they can also be "read" by a human. While there is some esoteric code that shows up, it is actually generally possible to read a journal file and understand the actions a user is/was taking. Of course we're not talking about reading a good novel, but as you become more familiar with them, you start to understand the pattern of the language, and thus how to read it. Most commands are listed with simple descriptors like this:

Jrn.Command "DesignBar" ,
"Create a wall , ID_OBJECTS_WALL" Jrn.Directive "JournalDataChainOption" , "Walls", 1
Jrn.MouseMove 0 , 503 , 368
Jrn.LButtonDown 1 , 503 , 368
Jrn.MouseMove 1 , 504 , 367
Jrn.LButtonUp 0 , 504 , 367
Jrn.MouseMove 0 , 936 , 371
Jrn.LButtonDown 1 , 936 , 371
Jrn.Data "Transaction Successful" , "Wall"

To the uninitiated, this looks like a lot of gobbly gook (perhaps à la The Matrix), but if we break it down, we can understand what is happening in Revit. First, the command initiated is the wall tool on the design bar: Jrn.Command "DesignBar" , "Create a wall , ID_OBJECTS_WALL"

Next are any options related to the wall command in this case the chain option is checked. Then, there is a mouse move, presumably to locate the cursor where we want to start drawing the wall, after that there is a Left Mouse button click at the same location to initiate the process of creating a wall, apparently the user's hand was slightly unsteady as there is a mouse move registered before the button is released up again. After that, there is another mouse move to the end point of the wall, then another click to complete the wall. We know that the creation of the wall, and therefore the end of this particular command was completed successfully as there is a "Transaction Successful" line with the key "Wall" to indicate the wall command finished.

Almost all other commands in a journal file follow a similar pattern, I usually try to start by looking for the transaction successful line and working backwards, but you don't have to, particularly if you learn to read the journal files.

Now you might find you journal files tend to look like this:

This is quite messy, but all the lines that start with an apostrophe ( ' ) are comments, also automatically recorded, however they have nothing to do with actual Revit commands, they may just serve to provide additional information, like memory statistics, or the date time code of when a command took place. It is actually possible to scrub a journal file of much of this additional information, but, while I know it can be done, I don't know the details of how it is done.

So you say, what am I to do? Well, you can use the find command (available in even lowly Notepad) to search for specific things. Since journal files are recorded in plain English so to speak generally searching for a keyword related to the command you are looking for is a good start. So a search for "window" will start to turn up any instances of interactions with the window command, or window objects.

If you want to learn more about journals, you might want to start by starting Revit, creating a blank file, then performing some simple actions, like creating a few walls, placing a door or two, make a section, etc. When you finish, close Revit, then go find the most recently created journal file. See if you can trace your actions through the file. You should be able to identify code for every specific command you take. I will warn you that when you switch views, or modify them, you get a ton of additional code that has to do with what the window is doing, you can generally ignore most of that, and keep tracing your commands.

In my next post we'll actually take a look at doing some useful detective work with the journal file, and a real life casefile that I have to share. We'll follow that up with something that I think a great number of people will find extremely useful, so stayed tuned, the season finale is around the corner...