Downloading free Revit families vs. buying stock families vs. modelling your own is under constant debate within most practices. Personally I think there is room for each, but before using any family within a project - you should take time to understand what it contains and what LOD it has been modelled to.
The 'grey hairs' are often misled into thinking there is a sea of free families out there, perfectly modelled that will insert themselves directly into a project. As Steve points out in his post (below), it's still the wild west out there...
http://revitoped.blogspot.com/2011/11/content-critique.html
...aimed at educating, promoting good practice and demystifying the use of CodeBook within Architecture.
Monday, 28 November 2011
Sunday, 20 November 2011
CodeBook v10 - sneak peak!
The Revit Application Programming Interface (API) has been somewhat restrictive in recent years and whilst it is still not as "open" as many developers would like, it is significantly better now than it was 5 years ago when the first incarnation of CodeBook for Revit was unveiled.
CodeBook International's (CBI) development focus during the past 12 months has been to refine and optimize core functionality for Revit, enhance reporting and improve interoperability with 4, 5 and 6D systems. CodeBook also has a SQL server version and as one of the users involved in the beta testing for v10, I'm very excited about the official release!
CodeBook International have been increasing their global presence during the last few years and alongside releasing v10, CBI have a fresh new website, re-juvenated brand and clearer definition about what CodeBook is and how it's used by designers, construction companies and building owners
So you may have already seen some of the new functions and utilized them in your projects through a beta, however, there have been over 100 enhancements, tweeks, or new functions added in 2011 alone. For a full list review CIS-003 when you upgrade - but in the meantime below is a summary of the major updates:
CodeBook Interface:
_Equipment ID range extended
(10,000-79,000)
_Import equipment from another Library
_Add 6 Assemblies to Room Types
_Omit, remove & replace multiple equipment
Interoperability:
_Maximo integration enhanced
_HFBS import enhanced
_ESRI export
_Export to COBie
Reporting:
_FF&E reports added
_Flex custom report system introduced
_Word reports also export a pdf
Revit interface:
_Assign family to a room
_Edit / delete parameters
_Nested family parameters updated
_Link Doors in separate model to rooms
_CB shared params always added
...and last but by no means least CodeBook shuttle is back which deserves a separate post.
There are a few functions that I think will be very useful, so here's a bit more info on them:
Troubleshooting Room links is accessed through the Revit Add-ins menu>Build>Troubleshoot and this allows you to put a marker into the rooms identifying which are linked, duplicates and unlinked rooms. You can also unlink all duplicates, which is sometimes easier than working out which is correct and you can also remove "phantom" rooms (not placed rooms).
Updating the value for a parameter en-masse is now possible and you can also delete a parameter from your project. Whilst this can be a very useful tool, take some time to double check what you are doing so that you don't overwrite or delete data that is in use.
When updating from the BIM model, CodeBook will also now place a red marker and generate a text file to list out the families that are not being reported (i.e. inside a room). This is a hugely valuable tool and knowing unequivically which items are not being reported immediately after updating will save lots of time.
In the case of items falling outside a room, that should be reported, for example a window blind there is now the function to assign these to a room. I know this has been high on people's wish list for some time.
So that gives you a taster of what to expect from CodeBook version 10 when it is officially released, which I believe will be in the next fortnight, to coincide with this years Autodesk University.
CodeBook International's (CBI) development focus during the past 12 months has been to refine and optimize core functionality for Revit, enhance reporting and improve interoperability with 4, 5 and 6D systems. CodeBook also has a SQL server version and as one of the users involved in the beta testing for v10, I'm very excited about the official release!
CodeBook International have been increasing their global presence during the last few years and alongside releasing v10, CBI have a fresh new website, re-juvenated brand and clearer definition about what CodeBook is and how it's used by designers, construction companies and building owners
So you may have already seen some of the new functions and utilized them in your projects through a beta, however, there have been over 100 enhancements, tweeks, or new functions added in 2011 alone. For a full list review CIS-003 when you upgrade - but in the meantime below is a summary of the major updates:
_Equipment ID range extended
(10,000-79,000)
_Import equipment from another Library
_Add 6 Assemblies to Room Types
_Omit, remove & replace multiple equipment
Interoperability:
_Maximo integration enhanced
_HFBS import enhanced
_ESRI export
_Export to COBie
Reporting:
_FF&E reports added
_Flex custom report system introduced
_Word reports also export a pdf
Revit interface:
_Assign family to a room
_Edit / delete parameters
_Nested family parameters updated
_Link Doors in separate model to rooms
_CB shared params always added
...and last but by no means least CodeBook shuttle is back which deserves a separate post.
There are a few functions that I think will be very useful, so here's a bit more info on them:
Troubleshooting Room links is accessed through the Revit Add-ins menu>Build>Troubleshoot and this allows you to put a marker into the rooms identifying which are linked, duplicates and unlinked rooms. You can also unlink all duplicates, which is sometimes easier than working out which is correct and you can also remove "phantom" rooms (not placed rooms).
Updating the value for a parameter en-masse is now possible and you can also delete a parameter from your project. Whilst this can be a very useful tool, take some time to double check what you are doing so that you don't overwrite or delete data that is in use.
When updating from the BIM model, CodeBook will also now place a red marker and generate a text file to list out the families that are not being reported (i.e. inside a room). This is a hugely valuable tool and knowing unequivically which items are not being reported immediately after updating will save lots of time.
In the case of items falling outside a room, that should be reported, for example a window blind there is now the function to assign these to a room. I know this has been high on people's wish list for some time.
So that gives you a taster of what to expect from CodeBook version 10 when it is officially released, which I believe will be in the next fortnight, to coincide with this years Autodesk University.
Tuesday, 8 November 2011
CodeBook appoint reseller in South East Asia!
Having lived and worked in S.E.Asia for several years, I can say from first hand experience, that CodeBook has a captive market and real growth opportunities there.
National and local government's in the region are switching onto BIM and coupled with their desire for brief conformity, whilst developing large numbers of similar schemes - CodeBook is a great fit.
CodeBook has a translation editor so you can re-create CodeBook in any language (providing you also know english!)
Also with tools like Google Translate, which is able to convert a webpage from one language to another I predict news will spread like wildfire!
Here is the announcement in Chinese:
http://translate.google.com.au/translate?hl=en&sl=en&tl=zh-TW&u=http%3A%2F%2Fwww.codebookinternational.com%2Fmedia%2Fnews-releases%2Fisbim-reseller
Vietnamese:
http://translate.google.com.au/translate?hl=en&sl=en&tl=vi&u=http%3A%2F%2Fwww.codebookinternational.com%2Fmedia%2Fnews-releases%2Fisbim-reseller
Korean:
http://translate.google.com.au/translate?hl=en&sl=en&tl=ko&u=http%3A%2F%2Fwww.codebookinternational.com%2Fmedia%2Fnews-releases%2Fisbim-reseller
Plus the english version:
http://www.codebookinternational.com/media/news-releases/isbim-reseller
National and local government's in the region are switching onto BIM and coupled with their desire for brief conformity, whilst developing large numbers of similar schemes - CodeBook is a great fit.
CodeBook has a translation editor so you can re-create CodeBook in any language (providing you also know english!)
Also with tools like Google Translate, which is able to convert a webpage from one language to another I predict news will spread like wildfire!
Here is the announcement in Chinese:
http://translate.google.com.au/translate?hl=en&sl=en&tl=zh-TW&u=http%3A%2F%2Fwww.codebookinternational.com%2Fmedia%2Fnews-releases%2Fisbim-reseller
Vietnamese:
http://translate.google.com.au/translate?hl=en&sl=en&tl=vi&u=http%3A%2F%2Fwww.codebookinternational.com%2Fmedia%2Fnews-releases%2Fisbim-reseller
Korean:
http://translate.google.com.au/translate?hl=en&sl=en&tl=ko&u=http%3A%2F%2Fwww.codebookinternational.com%2Fmedia%2Fnews-releases%2Fisbim-reseller
Plus the english version:
http://www.codebookinternational.com/media/news-releases/isbim-reseller
CodeBook Health Secrets revealed!
OK, so I needed to use a catchier title than "Database maintenance" in order to get anyone to read this post... well you're here now so you may as well carry on reading!
In this post I've outlined some of the common "health problems" that CodeBook projects can suffer from and how to resolve them. After reading this post, your very next step should be to implement a database maintenance policy on your projects as soon as possible.
Most AutoCAD files need to be purged once in a while, sometimes even "super purged", Revit models too can get clogged up with redundant data and need to be purged, compacted and central files periodically rebuilt - well CodeBook files also require the odd bit of maintenance.
The technical reason for this is that when you add information to a database, space is allocated for that information and when you delete something the space allotted for the information continues to be held in reserve by the database and it is not released for re-use. Likewise, extra space, created by modifying and shortening records, is not released for reuse.
So there are several ways to tidy up or compact your database, you can simply open the database in Microsoft Access and from the Office button select Manage > Compact and Repair Database. If you don't have Microsoft Access installed, or opening up a database in Access scares you - you can do this in CodeBook through File > Compact Project.
From within CodeBook you can also set the database to Auto-compact once it gets to a certain filesize. From the Project Properties window > Database Settings, there is a box labelled "Auto-compact database at size" in which you can enter a number.
Note: choose a number to small and you're database will perpetually auto-compact, choose a number too large and you won't get any real value out of this.
As mentioned in a previous post, you can have a single database which stores all of the buildings, departments and rooms - but you may also choose to split this up into several more manageable databases when working within a team environment with multiple Revit FF&E models and users accessing and contributing to the data. This has it's pros and cons of course, typically I try to keep project database size to under 15mb wherever possible.
In addition there may be redundant data lurking in your database, which should, but has not yet been deleted. What I mean by this are things like, unlinked rooms no longer in use, duplicate rooms, lookups created by mistake, room data templates copied in error and equipment that someone else must have created??
I'm stepping into slightly dangerous turf here... but I'm a firm believer in not carrying around unnecessary baggage within files and blasting away data that is not actively in use. BUT, before doing so take some time to double check the data is definitely not being used, think it through, take a backup of your files and talk to others.
The odd unlinked (red) rooms will be common in the early stages of a project, but once the planning has settled down, the 1:200 departmental layouts have been signed off and you enter the Design Development phase you should ideally have a database full of linked (blue) rooms and a Revit model full or rooms with parameter Linked_Status = 'Valid Link'
Unlinked rooms in CodeBook may originate from the schedule of accommodation (space programme), a room may have become accidentally unlinked or even deleted from the model and so a "due dilligence" check needs to be carried out before it is deleted. In order to check this, I would first run a full synchronise for the project so all linked rooms are coloured blue in CodeBook and each linked Revit Room has a Linked_Status parameter value of 'Valid Link'.
There are lots of wonderfully technical ways to review these, but I find a visual "common sense" check is normally the quickest and best method. A quick eyeball check of each department will identify unlinked rooms in CodeBook and through a Revit schedule you can identify any unplaced or unlinked rooms in Revit. Using a combination of the CodeBook display rooms function, find room using BIM hit and the Revit function Show (from within a schedule) will zoom you to any rooms that you need to check.
New and experienced users will generate extra lookup values and room data template duplicates, whilst developing the project. Often this happens by a lookup value simply becoming obsolete, for example, a type of floor finish might be specified early on and subsequently be deleted from the scheme. Also templates may be duplicated in error and then not removed.
You may ask yourself why would someone do this - i.e. create unecessary data? Using any software is difficult before it becomes easy, and it's always easy when you know how.
Before getting rid of these items, you should first check if and where they are being used - i.e. assigned to a room and form part of that rooms data. To do this we generate lookup and room data template usage reports, which list out the rooms that are using the value or template.
From within the Lookups Editor or Room Data Templates window, you can generate these usage reports quite easily. (note, you'll need to do this for each project database)
Equipment can also become redundant and again, like lookups and templates, we first need to assess whether these are in use within the project before removing them. If you suspect an item is no longer in use, then if you browse to the item in the Equipment Library window, you can generate a usage report by selecting File > Usage Report.
You can 'Hide' individual items of FF&E, but if you are confident using Access, or even Excel based formula's you will be able to work out which items exist within your project as required or designed equipment, and compare this against the overall equipment in your library. Once you have identified the equipment that you want to hide, there is a nifty and fairly recent function that will let you do this en masse.
From Librarian > Update Data > Batch Hide Equipment, this will open a window with 2 buttons, select "Create xls file of current library" and CodeBook will generate an excel list of the equipment within your library.
The excel file has a column 'Show or Hide' which you can edit accordingly. Once you've finished editing your excel file, select the Update button, browse to your freshly updated xls file and CodeBook will do the rest.
So many times I've heard people say "Well I didn't create it, so I'm not going to delete it." But these are normally the same people who complain about having too many lookups, or templates they know should be removed.
Everyone should be responsible for keeping the project dataset lean and mean, and whilst it may not be everyones role to remove redundant data you should encourage your team not to suffer in silence. Hope this gives you a few ideas...
In this post I've outlined some of the common "health problems" that CodeBook projects can suffer from and how to resolve them. After reading this post, your very next step should be to implement a database maintenance policy on your projects as soon as possible.
Most AutoCAD files need to be purged once in a while, sometimes even "super purged", Revit models too can get clogged up with redundant data and need to be purged, compacted and central files periodically rebuilt - well CodeBook files also require the odd bit of maintenance.
The technical reason for this is that when you add information to a database, space is allocated for that information and when you delete something the space allotted for the information continues to be held in reserve by the database and it is not released for re-use. Likewise, extra space, created by modifying and shortening records, is not released for reuse.
So there are several ways to tidy up or compact your database, you can simply open the database in Microsoft Access and from the Office button select Manage > Compact and Repair Database. If you don't have Microsoft Access installed, or opening up a database in Access scares you - you can do this in CodeBook through File > Compact Project.
From within CodeBook you can also set the database to Auto-compact once it gets to a certain filesize. From the Project Properties window > Database Settings, there is a box labelled "Auto-compact database at size" in which you can enter a number.
As mentioned in a previous post, you can have a single database which stores all of the buildings, departments and rooms - but you may also choose to split this up into several more manageable databases when working within a team environment with multiple Revit FF&E models and users accessing and contributing to the data. This has it's pros and cons of course, typically I try to keep project database size to under 15mb wherever possible.
In addition there may be redundant data lurking in your database, which should, but has not yet been deleted. What I mean by this are things like, unlinked rooms no longer in use, duplicate rooms, lookups created by mistake, room data templates copied in error and equipment that someone else must have created??
I'm stepping into slightly dangerous turf here... but I'm a firm believer in not carrying around unnecessary baggage within files and blasting away data that is not actively in use. BUT, before doing so take some time to double check the data is definitely not being used, think it through, take a backup of your files and talk to others.
The odd unlinked (red) rooms will be common in the early stages of a project, but once the planning has settled down, the 1:200 departmental layouts have been signed off and you enter the Design Development phase you should ideally have a database full of linked (blue) rooms and a Revit model full or rooms with parameter Linked_Status = 'Valid Link'
Unlinked rooms in CodeBook may originate from the schedule of accommodation (space programme), a room may have become accidentally unlinked or even deleted from the model and so a "due dilligence" check needs to be carried out before it is deleted. In order to check this, I would first run a full synchronise for the project so all linked rooms are coloured blue in CodeBook and each linked Revit Room has a Linked_Status parameter value of 'Valid Link'.
There are lots of wonderfully technical ways to review these, but I find a visual "common sense" check is normally the quickest and best method. A quick eyeball check of each department will identify unlinked rooms in CodeBook and through a Revit schedule you can identify any unplaced or unlinked rooms in Revit. Using a combination of the CodeBook display rooms function, find room using BIM hit and the Revit function Show (from within a schedule) will zoom you to any rooms that you need to check.
New and experienced users will generate extra lookup values and room data template duplicates, whilst developing the project. Often this happens by a lookup value simply becoming obsolete, for example, a type of floor finish might be specified early on and subsequently be deleted from the scheme. Also templates may be duplicated in error and then not removed.
You may ask yourself why would someone do this - i.e. create unecessary data? Using any software is difficult before it becomes easy, and it's always easy when you know how.
Before getting rid of these items, you should first check if and where they are being used - i.e. assigned to a room and form part of that rooms data. To do this we generate lookup and room data template usage reports, which list out the rooms that are using the value or template.
From within the Lookups Editor or Room Data Templates window, you can generate these usage reports quite easily. (note, you'll need to do this for each project database)
Equipment can also become redundant and again, like lookups and templates, we first need to assess whether these are in use within the project before removing them. If you suspect an item is no longer in use, then if you browse to the item in the Equipment Library window, you can generate a usage report by selecting File > Usage Report.
You can 'Hide' individual items of FF&E, but if you are confident using Access, or even Excel based formula's you will be able to work out which items exist within your project as required or designed equipment, and compare this against the overall equipment in your library. Once you have identified the equipment that you want to hide, there is a nifty and fairly recent function that will let you do this en masse.
From Librarian > Update Data > Batch Hide Equipment, this will open a window with 2 buttons, select "Create xls file of current library" and CodeBook will generate an excel list of the equipment within your library.
The excel file has a column 'Show or Hide' which you can edit accordingly. Once you've finished editing your excel file, select the Update button, browse to your freshly updated xls file and CodeBook will do the rest.
So many times I've heard people say "Well I didn't create it, so I'm not going to delete it." But these are normally the same people who complain about having too many lookups, or templates they know should be removed.
Everyone should be responsible for keeping the project dataset lean and mean, and whilst it may not be everyones role to remove redundant data you should encourage your team not to suffer in silence. Hope this gives you a few ideas...
Wednesday, 12 October 2011
Backups, archiving and milestone images
One of the most useful CodeBook functions, is the ability to create a Revision database and compare milestone images against one another. You might be asking yourself "what does all of that mean?" Well don't worry, you're probably not the only person and in this post I'll cover basic backup procedures, images and revision databases.
Backups
In order to make a full backup of your data, you'll need to take a copy of the CodeBook project database(s) and also the library files (equipment + room data). As a general rule of thumb it's a good idea to take a backup of your files on a weekly basis and at each project milestone, but it's worth speaking to your IT department to find out how often they run a full studio backup. Typically this is carried out monthly and a backup tape stored locally as well as off site. Larger practices may do this on a weekly basis, but whatever the frequency this will inform the amount of backup files you should keep on your server at any time. If your practice take monthly backups and you are also taking weekly backups, you should only ever need to keep 1 months worth of live backups on your server at any time. The rest can be retrieved from the backup tapes your IT department have taken.
Over the years, I've rarely reverted to a backup file older than one month, as typically the design has moved on substantially during that time meaning you'd lose more than you'd gain. If you take weekly backups and don't delete any of these till the project is over, you could end up with a large amount of unnecessary data stored on your server. That data will also be backed up monthly in the studio backup and so the issue manifests exponentially. The CodeBook data alone won't cause problems, but having a sensible approach towards backups is critical when working in a team environment - if everyone is taking more backups than they really need and never purging these from the server, it is inevitable that you will run into problems at some point.
For large projects you may have a series of staggered milestones and there may be a timeframe of longer than one month between them. This is where milestone image database should be utilized.
Images of the past...
An image database is a single consolidated database which merges the project, equipment and room data files to provide a snapshot of the data at a specific moment in time. If you create image databases at each project milestone, you're able to generate a revision database, which compares milestone image 1 with milestone image 2. The reports that you can generate from a Revision database highlight the differences between the two milestone images.
This can be a very powerful tool if used correctly and can aid with your in-house QA checking. Often clients want validation that their comments (from a previous meeting) have been taken on board, so providing that all of the clients comments have indeed been made, you're able to create a report which demonstrates this.
Generating an image database is quite a simple process, from the Control Centre select Output>Create Image Database... and you'll then be asked to confirm the location where the file will be saved. (In Project Properties you can specify the default location for this) A window will pop up asking you to add a note, which will act as a future reminder. It's obvious right now why you are creating the image database, but may not be 100% clear in the future, especially if you are working on a large project. Speaking from personal experience, clear notes are valuable and will help ensure you can locate the right image database in future and reduce the chances for error.
One very important thing to consider is precisely when you create the image database. If you create the image before producing reports and schedules, there is the chance that "last minute changes" could be made (having reviewed the reports) and your image does not fully reflect the issued set of documents. Similarly if you leave it till a few days after the issue has been made, again there may be differences between the issued set of information and the image you have generated.
The right time to create the image is straight after your reports have been generated and in conjunction with this, you should also be mindful of what other users may be working on. If another user is editing the project, equipment or room data library this may affect your image database. The key thing is communication and it should be possible to organize the production of reports and image databases to happen when the rest of the team are not editing the CodeBook data - or perhaps vice versa, the team are aware when this is happening and that they should not be editing CodeBook data.
The default CodeBook filename used for images includes the current date and time, it's advisable to keep this but to also include the project, sector and/or department the image relates to. This will be useful later on when you want to create a revision database and need to find the right image file to use.
Revision databases
An image database cannot be opened directly in CodeBook per se, it's purpose is to provide a point of comparison - so the way that you access the image information is to create a revision database. The process for creatng a revisions database is straightforward, from the Output menu simply select Create Revision Database and a pop up window will prompt you to specify the latest image and comparison image database. The latest image database should automatically be filled in with details of the last one you created, the comparison image should be the project/sector/department image database you created at the previous project milestone.
So give it a go, explore the Revision database reports that are available and start getting real value out of your data.
Backups
In order to make a full backup of your data, you'll need to take a copy of the CodeBook project database(s) and also the library files (equipment + room data). As a general rule of thumb it's a good idea to take a backup of your files on a weekly basis and at each project milestone, but it's worth speaking to your IT department to find out how often they run a full studio backup. Typically this is carried out monthly and a backup tape stored locally as well as off site. Larger practices may do this on a weekly basis, but whatever the frequency this will inform the amount of backup files you should keep on your server at any time. If your practice take monthly backups and you are also taking weekly backups, you should only ever need to keep 1 months worth of live backups on your server at any time. The rest can be retrieved from the backup tapes your IT department have taken.
Over the years, I've rarely reverted to a backup file older than one month, as typically the design has moved on substantially during that time meaning you'd lose more than you'd gain. If you take weekly backups and don't delete any of these till the project is over, you could end up with a large amount of unnecessary data stored on your server. That data will also be backed up monthly in the studio backup and so the issue manifests exponentially. The CodeBook data alone won't cause problems, but having a sensible approach towards backups is critical when working in a team environment - if everyone is taking more backups than they really need and never purging these from the server, it is inevitable that you will run into problems at some point.
For large projects you may have a series of staggered milestones and there may be a timeframe of longer than one month between them. This is where milestone image database should be utilized.
Images of the past...
An image database is a single consolidated database which merges the project, equipment and room data files to provide a snapshot of the data at a specific moment in time. If you create image databases at each project milestone, you're able to generate a revision database, which compares milestone image 1 with milestone image 2. The reports that you can generate from a Revision database highlight the differences between the two milestone images.
This can be a very powerful tool if used correctly and can aid with your in-house QA checking. Often clients want validation that their comments (from a previous meeting) have been taken on board, so providing that all of the clients comments have indeed been made, you're able to create a report which demonstrates this.
Generating an image database is quite a simple process, from the Control Centre select Output>Create Image Database... and you'll then be asked to confirm the location where the file will be saved. (In Project Properties you can specify the default location for this) A window will pop up asking you to add a note, which will act as a future reminder. It's obvious right now why you are creating the image database, but may not be 100% clear in the future, especially if you are working on a large project. Speaking from personal experience, clear notes are valuable and will help ensure you can locate the right image database in future and reduce the chances for error.
One very important thing to consider is precisely when you create the image database. If you create the image before producing reports and schedules, there is the chance that "last minute changes" could be made (having reviewed the reports) and your image does not fully reflect the issued set of documents. Similarly if you leave it till a few days after the issue has been made, again there may be differences between the issued set of information and the image you have generated.
The right time to create the image is straight after your reports have been generated and in conjunction with this, you should also be mindful of what other users may be working on. If another user is editing the project, equipment or room data library this may affect your image database. The key thing is communication and it should be possible to organize the production of reports and image databases to happen when the rest of the team are not editing the CodeBook data - or perhaps vice versa, the team are aware when this is happening and that they should not be editing CodeBook data.
The default CodeBook filename used for images includes the current date and time, it's advisable to keep this but to also include the project, sector and/or department the image relates to. This will be useful later on when you want to create a revision database and need to find the right image file to use.
Revision databases
An image database cannot be opened directly in CodeBook per se, it's purpose is to provide a point of comparison - so the way that you access the image information is to create a revision database. The process for creatng a revisions database is straightforward, from the Output menu simply select Create Revision Database and a pop up window will prompt you to specify the latest image and comparison image database. The latest image database should automatically be filled in with details of the last one you created, the comparison image should be the project/sector/department image database you created at the previous project milestone.
So give it a go, explore the Revision database reports that are available and start getting real value out of your data.
Wednesday, 14 September 2011
Libraries - one size fits all???
CodeBook libraries have insighted much opinion and debate over the years, in this post I'll touch on some of the history, what is available now and what makes a good library in my opinion.
Back in my day...
When I first started using CodeBook in 2003, it came with a library database built on the ADB briefing system and an image library of microGDS or AutoCAD blocks. At the time we had 3 major projects running simultaneously in AutoCAD, with each of them using a different briefing system - ADB, Hiltron and Healthcare Environments (HCE). Once we started to develop our exemplar rooms, we soon realised that the 'out-of-the-box' CodeBook library didn't contain everything that we needed and we would need to create project specific content. Also some of the existing blocks, weren't drawn in the way we wanted and so also required some attention.
Naturally each of these projects had their own project database and library, their own set of exemplar room layouts and after drawing equipment and room layouts 3 separate times with only minor differences between them we thought - there has to be a better way! At first the questions were - why doesn't CodeBook provide a decent library? Why are the blocks drawn so badly? I'm sure that I asked Peter these questions quite directly and probably a bit rudely on several occasions.
To his credit and in his usual style Peter explained politely, calmly and succintly that each practice does things differently, each project has different requirements and that he could spend the rest of his life drawing content and still not make everyone happy. Shortly after this he created a new build for me, which added additional fields in the database for different briefing systems (cwfCode2, cwfCode3 and cwfCode4) and enabled us to have an ADB, Hiltron and HCE code neatly sat in parrallel with each other all linked to the same CAD graphic.
The issue of library content had still not gone away though and so myself and a colleague decided to tackle the issue head on and organised a meeting between ADB, Hiltron and HCE. Peter also attended along with a few other architects and service engineers. There was hot debate about industry standards, what wasn't being provided and the lack of content sharing between the various parties. Unfortunately, the differing commercial interests of each party meant that the idea never really gained traction, despite the good intentions.
So whilst being a little disheartened, we decided to consolidate the libraries from these 3 major projects into our very own practice library ready for whatever future project came up, regardless of the briefing system used. This was very powerful and we also picked out the best exemplar rooms from each project and made them into assemblies ready-to-go on the next project. We still felt there was something missing though, as we had lots of individual room data templates (design, finishes, m&e) and assemblies which, on a large project, were very difficult to coordinate and manage. Soon enough, we had another new CodeBook build to try out which introduced Room Types and combined all of these separate templates, plus more.
I learned some valuable lessons back then and working together with Peter, gave us great results. Fast forward to 2011, Revit and Australia and I find that I'm having similar conversations with people albeit several years later on the other side of the world.
So what is available now and what makes a good library?
The standard CodeBook libraries offer both UK and Australian room data sheet templates and provides an AutoCAD library that can be converted into Revit families or A.N.Other platform. There is also now quite a lot of free content available on-line in the form of sketchup models or Revit families. The more astute manufacturers are starting to understand the benefits of modelling their products in Revit and making them available to the industry. Manufacturers producing these aesthetically pleasing accurate families, with O&M manuals and other FM data are already standing themselves apart from their competitors.
There are also companies whose core business is building families and generally speaking these are available for a reasonable price, but you are licensing the right to use the family - not the IP or the exclusive use of it. Not a problem for many practices, but there is yet a further option for the more discerning Revit user - to outsource the creation of your very own custom built library to India or Asia, where you can specify your requirements and have your families built cheaper than you could do in your own studio.
But with all of the above, you need to understand what it is that you are loading into your models and using in your documentation. What is the right level of detail (LOD)? Are the families dimensionally correct? Do they comply with local regulation? The responsibility for this has to remain with the party producing the model or drawings in my opinion and not necessarily the person who produced the family.
Many people think that you can start a project with an "off the shelf library", that will not require any editing throughout the duration of the job. The reality is that you will always have project specific content and each client will want to see greater or lesser detail, descriptions, groupings or coding systems than you currently have. Personally speaking I think investing resources into creating a generic library and then resisting the temptation to make it bespoke for as long as possible is a sound strategy.
At my practice we have made this investment and are now starting to realise the benefits of this work, plus have avoided large volumes of work duplication. In addition, we are generating a series of generic rooms and room data sheets with the goal that each project uses this as a starting point and, through the design development stage, update these to suit specific project / client requirements.
The concept is really quite simple, start from a point of compliance and don't re-invent the wheel each time you start a new project - however - many practices struggle to understand the value of this 'non-project-specific' work, or comprehend sufficiently enough to fund it. This really makes it a strategic matter and if a practice is serious about BIM and Healthcare, they will need to invest money and resources which cost in the short term, but will provide efficiencies in the future.
In addition to creating families and room assemblies, we've also spent considerable time reviewing the data component, in that we have several coding systems sat in parallel, complete with group, class and numerous other properties. These equipment properties are mapped to a corresponding Revit Equipment Parameter, contained within a Shared Parameter file, so that we have continuity and achieve synergies across multiple projects and studios.
Content sharing has been a hot topic of debate and whilst I'm a supporter of the ideal, I'm still uncertain of how it would work in practice. For example, if we were to give our library to another practice, they could not utilize it in the same way that we do in a 'plug-and-play' fashion. Why? Because it is setup to work in our Revit environment and is based on the criteria that we selected. Most practices will have similar requirements, but the naming conventions we use, the coding, description, equipment parameters, revit schedules, views and other 'template' related items will differ and so other than providing a visual representation, using someone else's library has limited value.
To summarize, some of the main elements that make a good library are:
1. Compliance with local standards
2. The correct LOD - i.e. don't model the nuts & bolts, just the general form.
3. Flexibility
4. Equipment data, and last but by no means least
5. Guidance material
You can have the best library in the world, but if no-one knows what it contains or how to use it.....maybe that's why you're reading this blog now!
There are many other parts to this issue, parameter mapping, types & catalog files, reports, legends etc... which I'll cover in separate posts.
Back in my day...
When I first started using CodeBook in 2003, it came with a library database built on the ADB briefing system and an image library of microGDS or AutoCAD blocks. At the time we had 3 major projects running simultaneously in AutoCAD, with each of them using a different briefing system - ADB, Hiltron and Healthcare Environments (HCE). Once we started to develop our exemplar rooms, we soon realised that the 'out-of-the-box' CodeBook library didn't contain everything that we needed and we would need to create project specific content. Also some of the existing blocks, weren't drawn in the way we wanted and so also required some attention.
Naturally each of these projects had their own project database and library, their own set of exemplar room layouts and after drawing equipment and room layouts 3 separate times with only minor differences between them we thought - there has to be a better way! At first the questions were - why doesn't CodeBook provide a decent library? Why are the blocks drawn so badly? I'm sure that I asked Peter these questions quite directly and probably a bit rudely on several occasions.
To his credit and in his usual style Peter explained politely, calmly and succintly that each practice does things differently, each project has different requirements and that he could spend the rest of his life drawing content and still not make everyone happy. Shortly after this he created a new build for me, which added additional fields in the database for different briefing systems (cwfCode2, cwfCode3 and cwfCode4) and enabled us to have an ADB, Hiltron and HCE code neatly sat in parrallel with each other all linked to the same CAD graphic.
The issue of library content had still not gone away though and so myself and a colleague decided to tackle the issue head on and organised a meeting between ADB, Hiltron and HCE. Peter also attended along with a few other architects and service engineers. There was hot debate about industry standards, what wasn't being provided and the lack of content sharing between the various parties. Unfortunately, the differing commercial interests of each party meant that the idea never really gained traction, despite the good intentions.
So whilst being a little disheartened, we decided to consolidate the libraries from these 3 major projects into our very own practice library ready for whatever future project came up, regardless of the briefing system used. This was very powerful and we also picked out the best exemplar rooms from each project and made them into assemblies ready-to-go on the next project. We still felt there was something missing though, as we had lots of individual room data templates (design, finishes, m&e) and assemblies which, on a large project, were very difficult to coordinate and manage. Soon enough, we had another new CodeBook build to try out which introduced Room Types and combined all of these separate templates, plus more.
I learned some valuable lessons back then and working together with Peter, gave us great results. Fast forward to 2011, Revit and Australia and I find that I'm having similar conversations with people albeit several years later on the other side of the world.
So what is available now and what makes a good library?
The standard CodeBook libraries offer both UK and Australian room data sheet templates and provides an AutoCAD library that can be converted into Revit families or A.N.Other platform. There is also now quite a lot of free content available on-line in the form of sketchup models or Revit families. The more astute manufacturers are starting to understand the benefits of modelling their products in Revit and making them available to the industry. Manufacturers producing these aesthetically pleasing accurate families, with O&M manuals and other FM data are already standing themselves apart from their competitors.
There are also companies whose core business is building families and generally speaking these are available for a reasonable price, but you are licensing the right to use the family - not the IP or the exclusive use of it. Not a problem for many practices, but there is yet a further option for the more discerning Revit user - to outsource the creation of your very own custom built library to India or Asia, where you can specify your requirements and have your families built cheaper than you could do in your own studio.
But with all of the above, you need to understand what it is that you are loading into your models and using in your documentation. What is the right level of detail (LOD)? Are the families dimensionally correct? Do they comply with local regulation? The responsibility for this has to remain with the party producing the model or drawings in my opinion and not necessarily the person who produced the family.
Many people think that you can start a project with an "off the shelf library", that will not require any editing throughout the duration of the job. The reality is that you will always have project specific content and each client will want to see greater or lesser detail, descriptions, groupings or coding systems than you currently have. Personally speaking I think investing resources into creating a generic library and then resisting the temptation to make it bespoke for as long as possible is a sound strategy.
At my practice we have made this investment and are now starting to realise the benefits of this work, plus have avoided large volumes of work duplication. In addition, we are generating a series of generic rooms and room data sheets with the goal that each project uses this as a starting point and, through the design development stage, update these to suit specific project / client requirements.
The concept is really quite simple, start from a point of compliance and don't re-invent the wheel each time you start a new project - however - many practices struggle to understand the value of this 'non-project-specific' work, or comprehend sufficiently enough to fund it. This really makes it a strategic matter and if a practice is serious about BIM and Healthcare, they will need to invest money and resources which cost in the short term, but will provide efficiencies in the future.
In addition to creating families and room assemblies, we've also spent considerable time reviewing the data component, in that we have several coding systems sat in parallel, complete with group, class and numerous other properties. These equipment properties are mapped to a corresponding Revit Equipment Parameter, contained within a Shared Parameter file, so that we have continuity and achieve synergies across multiple projects and studios.
Content sharing has been a hot topic of debate and whilst I'm a supporter of the ideal, I'm still uncertain of how it would work in practice. For example, if we were to give our library to another practice, they could not utilize it in the same way that we do in a 'plug-and-play' fashion. Why? Because it is setup to work in our Revit environment and is based on the criteria that we selected. Most practices will have similar requirements, but the naming conventions we use, the coding, description, equipment parameters, revit schedules, views and other 'template' related items will differ and so other than providing a visual representation, using someone else's library has limited value.
To summarize, some of the main elements that make a good library are:
1. Compliance with local standards
2. The correct LOD - i.e. don't model the nuts & bolts, just the general form.
3. Flexibility
4. Equipment data, and last but by no means least
5. Guidance material
You can have the best library in the world, but if no-one knows what it contains or how to use it.....maybe that's why you're reading this blog now!
There are many other parts to this issue, parameter mapping, types & catalog files, reports, legends etc... which I'll cover in separate posts.
Saturday, 10 September 2011
Starting a new project
There are differing lines of thought relating to project setup and configuration, unfortunately there is not a single strategy, but there are some key principles to consider which will guide you though a methodical thought process.
The first relates to project scale. What is the overall square meterage? How many buildings make up the scheme? What is the project build cost? How many departments are there?
Let's take the fictitious example of a 20,000m2 hospital, comprised of a new main hospital building, a new separate clinical services building and a small existing building to be refurbished. The project build cost might be in the region of $100 million, lets say there are 30 departments and lets be nice and give the project a name too - Opera Hospital.
Within CodeBook we have databases, sectors, departments and floors to organize and use to order and group together our rooms. There may also be a Schedule of Accommodation (or Space Programme) to be taken into account when structuring your CodeBook project. We also have the option to assign a room category, which is yet another useful way to group related rooms but we'll come back to this later.
So how many databases will I need? Well, this depends on two other key factors, how will the Revit models be organised and how many CodeBook users will there be?
Based on our example, the Opera Hospital, the project would most likely have three Revit Architectural model files, one for the Main Hospital building, one for the Clinical Services building and one for the existing building that is going to be refurbished. You can of course have a single central model file, containing everything and that every user accesses, but from a practical model management perspective it would probably make sense to split into a series of linked model files. Perhaps you might also have a separate site model, structural model for each of the new buildings and there may also be various consultant models.
The architectural team for Opera Hospital will of course vary depending on the services being offered, resources available and programme, but it would seem reasonable to assume a team size of eight people. This would include a project director, project manager, architects, medical planners and architectural technicians and of this team you might have three staff using CodeBook on a daily basis, the project manager occasionally and perhaps even your client periodically.
One approach would be to have a single CodeBook project database with three sectors, one for the Main Hospital, Clinical Services and Existing building. Each sector would be sub-divided into departments and floors and the departments linked to the appropriate Revit model. The room category is typically used to delineate between clinical, clinical support, general support, administration etc... the beauty of room categories is that they allow you to group rooms across different departments and you can have as many or as few category types as you see fit. If you map these CodeBook fields to a Revit room parameter, you can synchronise the data to your model and build views upon them, which can be a powerful tool and provide a visual representation of your schedule of accommodation (space programme).
This arrangement would provide a good basis to start the Opera Hospital project from and by having a single database, it means that you only need setup the project properties, parameter mapping, reporting formats etc... once, rather than several times had you started off with multiple databases. It is possible to copy settings from one project database to another, but if you can avoid the extra work of coordinating multiple databases and updating them, then why wouldn't you?
Well, one potential reason is the size of the project database and another is the number of users accessing, editing, updating and reporting from it. Technically you can have any number of users working in a single project database at the same time, but from a practical perspective it sometimes makes sense to split files up to avoid the performance of the whole team being adversely affected.
Generally speaking I try to keep project database filesize under 15mb, I've found that project databases larger than this, suffer from at least one of the following:
_as an attachment, the project database is too large for some email systems
_the users may notice performance issues, i.e. how long it takes to perform a task
_users often "bump into each other", i.e. one person is synchronising, whilst another is linking rooms, or updating designed equipment, or running a report...
Databases will allow multiple users to access them simultaneously, but if one user has a room open, whilst another user synchronises the same room, whilst a third user tried to update designed equipment for the room - what do you think might happen? The likelihood is that at least one of these processes would not complete fully, or worse still the program might crash. Databases use record locking, a similar concept to Revit worksets, and this generally applies at the room level of granularity.
Through each project phase, the Opera Hospital will amalgamate more and more information, room data sheets will be completed, detailed construction information added and costing, procurement and FM data may be included towards the end of the architectural teams involvement. The usage and demand of users accessing CodeBook will change during the project lifecycle, so it is quite likely that you may start with a single project database, but this may be sub-divided once you get into the design development stage. It is also quite feasible that your client will want a single consolidated view of the project at key project milestones and upon handover, which will require you to merge back together your project database files.
Reviewing the demands of the project regularly and considering the needs of the team using CodeBook is essential to the health of your project files. In summary the sort of questions you should consider are:
1) What is the scale of the project?
2) How many users will be accessing the CodeBook files?
3) How many Revit models are there containing Revit rooms and families?
4) Will these requirements change in the next few months?
This should help you determine the best way to organise your CodeBook files, but remember files can quite easily be split and merged back together, although I wouldn't advise doing this on a regular basis. Before making a significant change to your structure, speak with other members of the project team, the BIM/model manager and take a backup so that you can revert back if needed.
I'll cover splitting and merging databases in a subsequent post, plus backups and archiving.
The first relates to project scale. What is the overall square meterage? How many buildings make up the scheme? What is the project build cost? How many departments are there?
Let's take the fictitious example of a 20,000m2 hospital, comprised of a new main hospital building, a new separate clinical services building and a small existing building to be refurbished. The project build cost might be in the region of $100 million, lets say there are 30 departments and lets be nice and give the project a name too - Opera Hospital.
Within CodeBook we have databases, sectors, departments and floors to organize and use to order and group together our rooms. There may also be a Schedule of Accommodation (or Space Programme) to be taken into account when structuring your CodeBook project. We also have the option to assign a room category, which is yet another useful way to group related rooms but we'll come back to this later.
So how many databases will I need? Well, this depends on two other key factors, how will the Revit models be organised and how many CodeBook users will there be?
Based on our example, the Opera Hospital, the project would most likely have three Revit Architectural model files, one for the Main Hospital building, one for the Clinical Services building and one for the existing building that is going to be refurbished. You can of course have a single central model file, containing everything and that every user accesses, but from a practical model management perspective it would probably make sense to split into a series of linked model files. Perhaps you might also have a separate site model, structural model for each of the new buildings and there may also be various consultant models.
The architectural team for Opera Hospital will of course vary depending on the services being offered, resources available and programme, but it would seem reasonable to assume a team size of eight people. This would include a project director, project manager, architects, medical planners and architectural technicians and of this team you might have three staff using CodeBook on a daily basis, the project manager occasionally and perhaps even your client periodically.
One approach would be to have a single CodeBook project database with three sectors, one for the Main Hospital, Clinical Services and Existing building. Each sector would be sub-divided into departments and floors and the departments linked to the appropriate Revit model. The room category is typically used to delineate between clinical, clinical support, general support, administration etc... the beauty of room categories is that they allow you to group rooms across different departments and you can have as many or as few category types as you see fit. If you map these CodeBook fields to a Revit room parameter, you can synchronise the data to your model and build views upon them, which can be a powerful tool and provide a visual representation of your schedule of accommodation (space programme).
This arrangement would provide a good basis to start the Opera Hospital project from and by having a single database, it means that you only need setup the project properties, parameter mapping, reporting formats etc... once, rather than several times had you started off with multiple databases. It is possible to copy settings from one project database to another, but if you can avoid the extra work of coordinating multiple databases and updating them, then why wouldn't you?
Well, one potential reason is the size of the project database and another is the number of users accessing, editing, updating and reporting from it. Technically you can have any number of users working in a single project database at the same time, but from a practical perspective it sometimes makes sense to split files up to avoid the performance of the whole team being adversely affected.
Generally speaking I try to keep project database filesize under 15mb, I've found that project databases larger than this, suffer from at least one of the following:
_as an attachment, the project database is too large for some email systems
_the users may notice performance issues, i.e. how long it takes to perform a task
_users often "bump into each other", i.e. one person is synchronising, whilst another is linking rooms, or updating designed equipment, or running a report...
Databases will allow multiple users to access them simultaneously, but if one user has a room open, whilst another user synchronises the same room, whilst a third user tried to update designed equipment for the room - what do you think might happen? The likelihood is that at least one of these processes would not complete fully, or worse still the program might crash. Databases use record locking, a similar concept to Revit worksets, and this generally applies at the room level of granularity.
Through each project phase, the Opera Hospital will amalgamate more and more information, room data sheets will be completed, detailed construction information added and costing, procurement and FM data may be included towards the end of the architectural teams involvement. The usage and demand of users accessing CodeBook will change during the project lifecycle, so it is quite likely that you may start with a single project database, but this may be sub-divided once you get into the design development stage. It is also quite feasible that your client will want a single consolidated view of the project at key project milestones and upon handover, which will require you to merge back together your project database files.
Reviewing the demands of the project regularly and considering the needs of the team using CodeBook is essential to the health of your project files. In summary the sort of questions you should consider are:
1) What is the scale of the project?
2) How many users will be accessing the CodeBook files?
3) How many Revit models are there containing Revit rooms and families?
4) Will these requirements change in the next few months?
This should help you determine the best way to organise your CodeBook files, but remember files can quite easily be split and merged back together, although I wouldn't advise doing this on a regular basis. Before making a significant change to your structure, speak with other members of the project team, the BIM/model manager and take a backup so that you can revert back if needed.
I'll cover splitting and merging databases in a subsequent post, plus backups and archiving.
Wednesday, 7 September 2011
Upgrading a v8.2 dataset to v9
The process to upgrade a v8.2 dataset to v9 is very straightforward, but before doing so, take a moment to think through the pros and cons because once you have upgraded the data you will no longer be able to open it with v8.2
Generally speaking you should find more positives than negatives, but perhaps you're locked into an older CAD format (<2008) for the project by your client and that format is not supported by v9? The project is almost completed and v8.2 is doing everything you require? Other members of the design team are using v8.2? You're providing the CodeBook database files to your client, which they are plugging into their own systems?
None of the above are a showstopper, but think it through first, take a backup of your files and talk to others.
OK, so the process for upgrading your v8.2 data to v9 is simply:
1. Run the file 'CodeBook_v82_data_upgrade.exe'
2. You'll be asked to select the CodeBook project database you want to upgrade
3. Then you'll be asked to select the Codebook library that you want to upgrade
...refer to CIS-56 for more information...
Once you've run through this process, fire up CodeBook v9 and take a look!
One of the main differences between the versions is that in v8.2 all of the lookups, room data templates, equipment and assemblies were stored in a single library database. CodeBook has evolved substantially during the last few years and storing the lookups and room data templates in one database (CDEB_RmDataLib.mdb) and the equipment and assemblies in another (CDEB_EquipLib.mdb) made sense for many reasons. The v9 library files are more portable, arguably there are performance advantages and now there are many more options and possibilities regarding equipment and it's associated data.
So when you run the 'CodeBook_v82_data_upgrade.exe' what is happening in the background is that your equipment library is being split into two databases one containing room data information and one containing equipment.
The CodeBook project database and library are still connected through linked tables and most users won't notice any real difference other than having to select the location of the Equipment library and also having to select the location of the Room Data library upon opening a project for the first time in v9.
Generally speaking you should find more positives than negatives, but perhaps you're locked into an older CAD format (<2008) for the project by your client and that format is not supported by v9? The project is almost completed and v8.2 is doing everything you require? Other members of the design team are using v8.2? You're providing the CodeBook database files to your client, which they are plugging into their own systems?
None of the above are a showstopper, but think it through first, take a backup of your files and talk to others.
OK, so the process for upgrading your v8.2 data to v9 is simply:
1. Run the file 'CodeBook_v82_data_upgrade.exe'
2. You'll be asked to select the CodeBook project database you want to upgrade
3. Then you'll be asked to select the Codebook library that you want to upgrade
...refer to CIS-56 for more information...
Once you've run through this process, fire up CodeBook v9 and take a look!
One of the main differences between the versions is that in v8.2 all of the lookups, room data templates, equipment and assemblies were stored in a single library database. CodeBook has evolved substantially during the last few years and storing the lookups and room data templates in one database (CDEB_RmDataLib.mdb) and the equipment and assemblies in another (CDEB_EquipLib.mdb) made sense for many reasons. The v9 library files are more portable, arguably there are performance advantages and now there are many more options and possibilities regarding equipment and it's associated data.
So when you run the 'CodeBook_v82_data_upgrade.exe' what is happening in the background is that your equipment library is being split into two databases one containing room data information and one containing equipment.
The CodeBook project database and library are still connected through linked tables and most users won't notice any real difference other than having to select the location of the Equipment library and also having to select the location of the Room Data library upon opening a project for the first time in v9.
Tuesday, 6 September 2011
Installing CBv9 for Revit 2011 & Revit 2012
Much of this post is stating the obvious, but for new users, CodeBookers who don't typically install software and IT departments who don't use Revit or CodeBook and normally run a single installation file - it might be useful.
CodeBook Information Sheet #55 (CIS-55) will walk you through the step by step process for installing the software, but there are a few key points worth highlighting that may save you a call to CodeBook support!
1. Before you are ready to install CodeBook, you must first:
a) purchase a license
b) download the installation files
c) download the Sample Project Revit files, ('CdeB_MasterLib_V9_Revit' & 'Sample Project v9 Demo')
d) have administrator rights to the PC you are installing the software onto
...for local resellers, see the links on the right hand navigation...
2. Installation files that need to be run are:
a) CodeBook_v9.msi (installs the software)
b) CodeBook_x64Service.msi (MS Access = 32 bit, Revit = 64 bit so this service enables Access and Revit to communicate)
3. License server, the process to obtain a license is:
a) fire up CodeBook
b) enter your 'company reference' (provided when you purchased the software)
c) register a 'New User'
d) check your email for the confirmation code from Nitromation (Nitromation provide the license manager server)
e) copy and paste your confirmation code into the CodeBook login screen
f) click 'Obtain License'
...keep going, almost there...
4. Start CodeBook v9, assuming you've never used the software before you should:
a) Create a new project
b) When asked to select an existing project to use as a template > path to the location where you saved the Sample Project Revit files
c) You'll be prompted to save your new project, and then
d) Confirm the location of the Equipment and Room Data Libraries > again path to the location where you saved the Sample Project Revit files
...if you have used CodeBook before and want to upgrade from a previous version, see the post Upgrading a v8.2 dataset to v9...
5. Revit to CodeBook command path - final step!
a) Select File > Project Properties...
b) Expand the Administrator > CAD and BIM Settings section and click on Revit
c) In the Codebook to Revit command path check the path and location of the 'CodeBook.Addin' file
For this last part, if you have a standard, out-of-the-box installation of Revit, you may choose to keep the CodeBook default location:
'C:\Users\xxx your username xxx\AppData\Roaming\CodeBook Data'
The chances are you'll have some Revit customisation, so you will need to check that you have the CodeBook.Addin file saved into your Revit Addins folder and that you have entered this location in the 'Codebook to Revit command path'.
For example, we use various Revit Add-ins, such as Worksharing Monitor, Model Review, Bluestreak etc... accessed through the Revit Addins ribbon and these are all saved into:
'C:\ProgramData\Autodesk\REVIT\Addins\2011'
Congratulations - you've now successfully installed and configured CodeBook to work with Revit!
I'll cover Project & Library setup in a subsequent post.
Revit Architecture 2011 or 2012 and the Microsoft Access version of CodeBook will be used by most of the industry, but I'll keep an eye out for requests to explain the install process for other software packages or releases...
CodeBook Information Sheet #55 (CIS-55) will walk you through the step by step process for installing the software, but there are a few key points worth highlighting that may save you a call to CodeBook support!
1. Before you are ready to install CodeBook, you must first:
a) purchase a license
b) download the installation files
c) download the Sample Project Revit files, ('CdeB_MasterLib_V9_Revit' & 'Sample Project v9 Demo')
d) have administrator rights to the PC you are installing the software onto
...for local resellers, see the links on the right hand navigation...
2. Installation files that need to be run are:
a) CodeBook_v9.msi (installs the software)
b) CodeBook_x64Service.msi (MS Access = 32 bit, Revit = 64 bit so this service enables Access and Revit to communicate)
3. License server, the process to obtain a license is:
a) fire up CodeBook
b) enter your 'company reference' (provided when you purchased the software)
c) register a 'New User'
d) check your email for the confirmation code from Nitromation (Nitromation provide the license manager server)
e) copy and paste your confirmation code into the CodeBook login screen
f) click 'Obtain License'
...keep going, almost there...
4. Start CodeBook v9, assuming you've never used the software before you should:
a) Create a new project
b) When asked to select an existing project to use as a template > path to the location where you saved the Sample Project Revit files
c) You'll be prompted to save your new project, and then
d) Confirm the location of the Equipment and Room Data Libraries > again path to the location where you saved the Sample Project Revit files
...if you have used CodeBook before and want to upgrade from a previous version, see the post Upgrading a v8.2 dataset to v9...
5. Revit to CodeBook command path - final step!
a) Select File > Project Properties...
b) Expand the Administrator > CAD and BIM Settings section and click on Revit
c) In the Codebook to Revit command path check the path and location of the 'CodeBook.Addin' file
For this last part, if you have a standard, out-of-the-box installation of Revit, you may choose to keep the CodeBook default location:
'C:\Users\xxx your username xxx\AppData\Roaming\CodeBook Data'
The chances are you'll have some Revit customisation, so you will need to check that you have the CodeBook.Addin file saved into your Revit Addins folder and that you have entered this location in the 'Codebook to Revit command path'.
For example, we use various Revit Add-ins, such as Worksharing Monitor, Model Review, Bluestreak etc... accessed through the Revit Addins ribbon and these are all saved into:
'C:\ProgramData\Autodesk\REVIT\Addins\2011'
Congratulations - you've now successfully installed and configured CodeBook to work with Revit!
I'll cover Project & Library setup in a subsequent post.
Revit Architecture 2011 or 2012 and the Microsoft Access version of CodeBook will be used by most of the industry, but I'll keep an eye out for requests to explain the install process for other software packages or releases...
Thursday, 9 June 2011
All things CodeBook blog now open...
This is the first post of a new blog aimed at teaching, promoting good practice and demystifying the use of CodeBook within Architecture.
I've been a user of the software for around 9 years and have worked on some great projects, where we've been able to add real value and generate time savings through the successful implementation of CodeBook.
I've also worked on projects which have not gone according to plan and that proved... challenging.
But life is a constant learning experience and sometimes it is just as useful knowing where common mistakes are made in order to avoid them and how to fix them if they are unavoidable.
Stay tuned...
I've been a user of the software for around 9 years and have worked on some great projects, where we've been able to add real value and generate time savings through the successful implementation of CodeBook.
I've also worked on projects which have not gone according to plan and that proved... challenging.
But life is a constant learning experience and sometimes it is just as useful knowing where common mistakes are made in order to avoid them and how to fix them if they are unavoidable.
Stay tuned...
Subscribe to:
Posts (Atom)