My last post on Architechtural Desktop

Well, it's official! Architectural Desktop is no more. I've heard a number of rumors in the past year with people saying ADT is going away, it's being replaced with Revit, Autodesk is abandoning one of it's largest installed user base for it's products, etc... I hope your happy. Introducing AutoCAD Architecture 2008. Well, alright, I may have over done it slightly.

ADT is really still here - it's just sporting a new name and a new look. I know many have mixed feelings on the name change - as do I. I was introduced to ADT with the release of 2004. I immediately embraced the step up from vanilla AutoCAD and jumped right in with both feet learning the platform in and out. For those that remember the splash screen from ADT 2004 and 2005, it was a picture (tinted blue) of the Tokyo International Glass Forum Building (picuture included at end of post). In 2005, I had the opportunity to give the building a visit while on vacation in Japan. I have to say it's a wonderful building, but then again, I'm also a big fan of all things Japanese - so I'm a little biased. That being said, ADT has been all I've known the product as. Others who go back further recall it as softdesk (prior to Autodesk buyout). So I suppose one more name change isn't that big of a deal in the grand scheme of things, right?

Perhaps. Change is part of our life. Yet for some reason, when it comes to technology, many people don't like change (I'd say 50%-60% - this might change as the years go on, but currently that is my opinion). So for some, this name change is world shattering - life ending. For others, it's just another day at the office. At first, I was more than a little bothered by this name change, however I quickly snapped out of it and realized a couple of things. One is that change is, as I said, part of our world. The other was that I had no ability to change the mind of a multi-billion dollar company and their marketing departments' choice to change a few product names. So I quickly moved on and accepted the fact that ADT was gone and replaced by AutoCAD Architecture or ACA for short. This change affects more than just Autodesk - many other companies will have to adapt to this name change. Blog names will need updating. Websites need updating. Speaking of updating websites, the ADT/ABS Community on AUGI is being updated in anticipation of the new products shipping. I suppose I should get busy editing those web pages!

CAD Standards Content - Local or Network?

Beth Powell made a good point on her blog about CAD Standards content being kept on a local drive versus a network drive (link). It may be more work, but not by much. The part that's takes the most work is building the script file to begin with. Once it's built, it's done. Everyone still has to update the content files, organize them, etc. - whether that's done on a local or network drive it will still take the same amount of time. Using it for updated versions or new software deployments takes next to no time since you can simply make a copy of the script file and continue on from there. Did I mention I made a deployment image, applied a service pack to it and had the new release of tools ready to go in one day for ADT 2007?

While I agree, this is not for everyone, it will work in many situations. Beth also mentioned she was curious about performance seen from keeping content locally vs in a network location. What the end user will see varies greatly on a number of things. Size of the company, locations of the office or offices, network policies, number of people trying to access the network and so on. I guess what I'm saying is that it would be very hard to put an average number to any perceived performance boost due to varying network conditions. I think it would be safe to say that a small office of 50 people or less would probably not notice a difference between content stored locally or on the network. Medium size offices (50-100) would see some difference and a large office environment (100 and above) would see something much more noticeable. I've have seen companies spread out over a WAN that had some really complex network systems in place to keep everyone connected. Hopefully you are not building the content so it has to pull across the WAN - that would make things painfully slow.

Either way, as Beth mentioned, consistency will help tremendously. I've seen that more now than ever before as I have seen things become much easier in deploying the next version of the software. Whether you go with content locally or on the network, it's your call. If given the choice for myself, content will always be local if feasible.

Tool Palette Order and Grouping

I consistantly see users asking how to make tool palettes display the same way on multiple computers to match a standard layout. This seems to be a recurrent topic in many companies. I made a brief comment on the Profile.aws file in a previous post, last paragraph - however, I don't feel I gave it enough attention as to why you need this file that is buried deep within Documents and Settings. The Tool Palettes are extremely flexible, yet trying to share them with others that follow a standard format can be frustrating. Hopefully this will help demistify it and help you understand better an easy way to share a standard layout of tool palettes.

The Profile.aws contains a number of things about how palettes - specifically tool palettes - are displayed. The aws file extension stands for AutoCAD Work Space and is a fitting name since it remembers changes you make to the environment of AutoCAD. If you were to open the aws file with Microsoft word or Internet Explorer you will find that it is based on XML code. While I do not write or fully understand XML code, the structure of it allows you to start to understand it if you look long enough (kinda Matrix esq, huh?). One thing you can try if you open it with MS Word is to use the find command on the Edit menu to search for a name of a tool palette you know is available in the program. Once it finds the palette name, look at the surrounding text to see what is around it and it should give you an idea of what data is stored in the file.

In vanilla AutoCAD, tool palettes allow you export the tool palette groups to an xtp file which can then be imported to another users computer. While this is dandy, for those using ADT (even if you run a profile to use ADT as AutoCAD), this option is disabled to prevent exporting tools on palettes that only run in ADT to users of AutoCAD. While I find this response from Autodesk somewhat lame, it is what it is. While I would know better than to load ADT palettes onto a system running only vanilla AutoCAD, appearently Autodesk thinks there are some that wouldn't know any better. I suppose they are right but this leaves us advanced users trying to figure out how to make ADT have standard tool palette groupings. One could use Catalogs and have them mimick tool palettes, but I find this to be somewhat of a long winded process that novice users have a difficult time with. This means the advanced user is stuck going around dropping palettes from catalogs onto everyones system and we all know the advanced users time is better spent elsewhere.

Enter the Profile.aws - this file contains all the info of the tool palettes on a system - order of palettes, which palettes belong in which group and the location/size of the palette on the computer screen. This file exists for both vanilla AutoCAD and ADT, so it does not matter which platform you run on. So if you as the advanced user builds and organizes 50 palettes into multiple groups and sub groups with specific ordering to them, this file is the key to duplicating that orginazation to everyone else on your team or in the company. Where can you find it? There will be a profile.aws in a folder that corresponds to the profile name in AutoCAD. This is the *.aws file you want - the FixedProfile.aws file will do you no good. If you installed AutoCAD (or ADT) via the application defaults for support files then you can find the profile.aws in a location similar to this: C:\Documents and Settings\USERNAME\Application Data\Autodesk\ADT 2006\enu\Support\Profiles. Once inside the last folder in that list, Profiles, you will see folders for each profile available in AutoCAD. Go into the one for the profile we are working with and you will find the file Profile.aws. Export your profile from options and import it to a test system. Close ADT and then copy the aws file and drop it onto the test system in the mirror location for it. Reopen ADT and you should have the palettes grouped in the same order as the source system!

How to deal with 300 users that all want it their way - Part 5

Well, it looks like I'm not done writing about this subject. I had a colleague write me asking more about what I would do with certain content for AutoCAD and/or ADT. There are several different areas that I look at content covering. There is out of the box (ootb) content, company specific content and support content - I will go more into depth on each of these in a moment. I have my own opinions on where these should be placed, however location of the content depends on several factors.

Here's some questions you can ask to help determine where the content needs to be store.

• Who will be maintaining the content if it needs revising or additional content added? Advanced, technically savvy users should have no problem placing the content anywhere they choose and maintaining it in addition to that.
• If no such user exists in the office, who will be doing the revisions? If it will be an outside consultant that has limited time in office, you may defer to their preference.
• What content needs to be accessed and used with AutoCAD/ADT? Depending on what the content is, you may choose to have a mixed environment where some content is stored locally and other content stored on the server.
• Who interfaces with the company and how flexible do you need the standards to be? If the company has strict policies on the use of their content outside the workplace and have tight controls on what data enters/leaves the workplace, then storage of all content on a server is unavoidable due to the need to restrict user access. This also means you most likely will never have to worry about project consultants trying to use the same tools as the rest of the internal company staff. However, more firms are beginning to realize the benefits of having their own employees be able to use the same tools at home as they do at work in the event they need to work overtime on the weekend and wish to do so from home. In addition, many firms have outside consultants helping to generate plans as well and they realize if the consultants have access to the same tools then they get more consistent plans that match what they would do in the office.
• Is the content something that will be re-usable for future releases of software or will it need to be rebuilt? Certain parts of the software are not backwards compatible. For example, tool palettes have been getting little tweaks as the releases of the software move forward. If you use those new features in a more current version, will you need to think about keeping a legacy set of palettes stored in that case? Hopefully not, but something to keep in the back of your mind...

OOTB Content

For AutoCAD, I would consider things like templates (dwt, dst and dws), fonts, CUI (menu) files, plot styles, profiles, dynamic blocks, tool palettes, etc. that ship with the product to be ootb content. For ADT, I would consider things like AEC styles (architectural, documentation and miscellaneous), ADT tool palettes, Detail Component and Keynote libraries, PN template projects and Content Browser Catalogs that ship with the product to be ootb content. Usually most firms have their own version of these items. Due to that, I will typically let all ootb content be installed to the local machine. The main reason being is that if for some reason a problem happens on a system, I have a fall back to check and see if the same problem occurs under ootb settings. Some might say that now the users have access to non-standard content. Well, if the average is able to somehow find it, then they are no longer an average user since the content's default location is buried in Documents and Settings and most never venture that deep into the system. In addition, the office deployment will most likely replace the majority of the ootb tools with their own version of it. You can also stress to users that it is not their job to customize AutoCAD - that's my job. They should instead focus on getting those drawings out the door. If they want to play with the software, they are in the wrong position.

Company Specific Content

When I refer to company specific content, I'm referring to blocks, AEC styles, things the are actually drawn in the drawing. The amount of this content will depend on a number of things. How much legacy content have you been bringing forward, how much new content will be generated by future releases and how much content will be built as time goes forward and people find new parts of the software they want to take advantage of. For new users of ADT, the content typically will start small and expand overtime as they begin to use more and more of the software. Where will you place this content?

Well, the location of the content is something that you do not want to change, especially if the content is placed on tool palettes. The reason being is that the content on tool palettes are hard pathed to the source files the drive the content on the palettes. For this reason, I try real hard to pick a location that will never change, otherwise you have a lot of tools to fix. Many like to place tool palettes on a network drive. That's great until one of several things happen. What if IT decides the location of the content needs to move to another server drive and the drive letter previously mapped was S and now it is place on a drive mapped with letter T. All tool palettes that referenced the previous drive are broke and need to be fixed. What happens if the network goes down? No content. What happens if you want to use the tools and the palettes outside the office? You get to go thru an extensive process to package up the tool palettes into a catalog and hope the user can set them up on their own at home. These are the main reasons I prefer to place the content and the tool palettes for company specific content on a users local drive and in a location that can be consistent everywhere they go. Hence in my second post why I outline placing everything in a folder on the root of their local C drive. Every computer I've worked with has a C drive.

Other options I've seen used if you must keep content on the network is to burn it to a CD or DVD and remap the optical drive to match the server drive. You could also place the content on a flash drive and remap the flash drive to the server letter. You would want to do that after disconnecting from the network and prior to launching AutoCAD. The advantage to using a flash drive is if your content and project files are stored on the same drive letter you do not need to repath xref'd files when working at home. Simply drop the project files on the flash drive as well and you are set to go. As a side point, you can use a flash drive at home mapped to the server drive letter your project files are stored on to avoid repathing xref files when working from home. Another option is to use something like Robocopy to copy files from the server down to a local folder each time a user logs into the network to ensure they have the latest version of files on their local drive.

Ultimately, this is something you want to think about long and hard for each situation you come across. Believe me, I know from experience, it is not fun to get all your content built and placed on palettes only to find out they should have been mapped to a different location.

Support Content

I consider things like fonts, plot styles, pc3 files, CUI files, lisp files (or any custom apps), templates - basically anything set for use in Options, appload or the CUI - to be support content. Tool Palettes are the one exception to this. Again, where you place these files will reflect the office environment you are in. Most of these items get placed in their own respective folders for the particular team or office. In the situation that I gave at the beginning of this series, there are variants of each of these items. For the standard office content it goes something like this.

• C:\Company CAD\Custom - This contains any general apps, files or other misc content that is the same for everyone (i.e. - acad.pgp, master lisp file, arx, vba, etc.). Let me stress that if you have a company that is bringing forward legacy custom commands from previous releases (like back to R14) take the time to sit down, document all commands, make sure they work as intended and look for any duplicates. It's not a fun task, but highly worth it in the end especially if they have a lot of them since you will then have a base on which to develop additional commands if needed and not wonder why it is calling up some other command you didn't know existed.
• C:\Company CAD\AutoCAD - This contains the CUI files used for this variant of the install.
• C:\Company CAD\ADT - Again, contains CUI files used for this variant of the install. If they using the Acad.cui loaded as a nested CUI inside the adt.cui, then there is a unique acad.cui I place in this folder. Do not reference the one inside the folder C:\Company CAD\AutoCAD - I have found issues trying to do that.
• C:\Company CAD\Team A - Once again, contains CUI files used for this specific team. Do not reference the CUI files in the other Company CAD folders - I have found issues trying to do that.

If you are wondering what issues I have found, when I first started playing with this situation, I had the bright idea to make my life simpler by having an enterprise CUI loaded with every team CUI loaded as a partial. The problem I quickly ran into was running the menus and toolbars and commands via workspaces and profiles did not work they way I expected them to. This is what led me to the above break down of CUI files. Just trust me on this one if you are using the same approach I am.

For the other support files, here is a little more break down on them.

• C:\Company CAD\fonts - Everyone in the company uses and has access to the same fonts so they go here.
• C:\Company CAD\Lisp - An extensive library of custom LISP routines has been collected over time and compiled in this folder. They are loaded with a master lisp routine located in the folder C:\Company CAD\Custom.
• C:\Company CAD\Plotters - This folder is empty, minus one shortcut folder inside it. The shortcut folder points to a location on the server that holds all office plotter files. This allows the user to add plotter config on the local machine outside the office if needed.
• S:\Company CAD\PMP Files - This is the one exception where I have a folder pointing to the network. Everyone gets the same PMP files for the office. If the network goes down, you can't print anyway.
• C:\Company CAD\Plot Styles - This folder follows the same principle as the Plotters folder. Individual users can drop project specific plot styles for projects from subs on the project into this folder to print their drawings if needed.

What about Autosave, temp and log folders? For ease of users looking for such files in a panic, I place them in a seperate folder under the root of C called C:\AutoCADresourceFiles. Remember to empty these on your local machine prior to compiling the exe for the team content or the compiler will add your autosaves, temp and log files in the exe, thereby adding unnessecary size to the exe file and increasing compilation/installation time.

• C:\AutoCADresourceFiles\Autosave - Pretty self explanatory.
• C:\AutoCADresourceFiles\Log Files - Any log files that are generated from things such as exports, etransmits or plotting/publishing.
• C:\AutoCADresourceFiles\Temp - Any temp files generated by AutoCAD during operations such as refediting xref's, opening host files that contain xrefs, etc.

For AEC content such as Tool Catalogs, Detail Component and Keynote Databases, I leave them pointing to their default locations. For Tool Catalogs, if these are used they typically per team or project and would be placed in the teams folders and then added to each individuals Content Browser. I find that they are rather unnecessary in this particular case since tool palette setup and management are controlled by the exe. In my opinion, Detail Component and Keynote Databases (if used) should be on a project by project basis, copied from a master set on the server and set current via PN. Same goes for project based tool palettes if used. At the end of the project, you should evaluate if any changes or additions made to the project specific content should be added to the teams standard or master set of tools.

I apologize for the length of these posts, but this turned out to be a bigger project than I had originally anticipated. On the flip side, I've finally written down what I've been lugging around in my brain for the last year and a half and it feels like a great weight has been lifted. This has been something I've been wanting to do for some time and I'm glad I finaly did. Hopefully this will help you determine what to do with the variety of content and situations you might run across. If you have something else that you feel I didn't cover in this subject, please drop me a line!

Project Scenarios

I was asked the other day about how I would go about setting up projects in Project Navigator for Phased work or for Modernization work. Phased work and modernization are similar in the aspect that they are both dealing with stepped processes dealing with existing drawings and coordinating your work between them. They are vastly different in what is done for work, both in the office and in the field. Provided you are using Project Navigator (PN), this will help alleviate some of the headache of trying to keep files organized.

For phased work, I personally would start the project with a defined set of classifications to help in separating objects that do not need to be scheduled. Outline the main phases and base your classifications on the phases. As for PN, you could use divisions for each phase, but I find that gets a bit tedious. I would be perfectly comfortable keeping all phases under one division. The exception to this would be if different phases overlapped into parts of the building already built - I.e.: Phase 1 is the exterior shell and phases 2 is the interior finishing - or something like that. Then I might consider using divisions, but even then I would be hesitant. Another approach would simply be to use folders in each part of PN (elements, constructs, views and sheets) to identify the drawings of each phase. Either way you approach it, the drawing file names should all be unique to the phase they are associated with (I.e.: phs1, phs2, etc. should be included in the file names) for archival purposes down the road.

For modernization work, what you do may depend on what needs to be done with the legacy drawings. In the typical scenario where the old drawings must remain un-touched for archival purposes, simply make a copy of the original project. If it was previously done in ADT using PN, see if you can re-use the existing PN project as a base for your files or simply import the old drawings you need into element files. If working with the copy of the old files, you can either edit them directly to reflect the changes, or xref them into new drawings and use them as backgrounds (which you might want to do if you need to show part of the old building as screened that is being untouched by the modernization). Here you will begin to see the similarities between Phased and Modernization work. You can again use classifications to help in separating objects that do not need to be scheduled. Whether you are using old drawings as a background or editing them directly, you need to make a distinction between the old files and the new ones so they do not have the same names (leaving the old files named the same, but appending mod1, mod2, etc to the new file names). Again, use of divisions are optional in my opinion, I would prefer to use folders in each part of PN as it is a bit more visual for me.

Ellipse walls in ADT

Here's a way to create ellipse walls in ADT.

• Type PELLIPSE and set the value to 1.
• Draw an ellipse with the values needed.
• Right click any wall tool on a tool palette and choose Apply tool properties too... -> Linework.
• Select the ellipse and you will have a wall that is segmented, but in the shape of an ellipse.

The reason this works is it generates the ellipse as an approximation (a rather good one) and generates it as a segmented polyine.

How to deal with 300 users that all want it their way - Part 4

I have a little bonus for you. Here is an example of a script file I use with a few extra little tweaks that took me some time to figure out. I've also included a screen shot of it inside Inno Setup so I can disect it and tell you what I did after i used the Script Wizard to generate the initial script (click the image for a larger version).



Area #1
The majority of the stuff in this area is generated by the first screen in the script wizard. Make sure to save your script files in the event you need to update the office content or are facing a new version of AutoCAD that you are rolling out. Then all you have to do is change the version of the exe and they can run the updated version. If it detects a previous verion on the system it will overwrite it and bring the user up to speed. Keep in mind if you have removed files from the folder containing your content, those files will not be removed unless you use add/remove programs to remove the previous version before installing the new one.

Area #2
This is the line that will place the desktop icon on the desktop to run the company profile for AutoCAD.

Area #3
***Warning!!!*** Registry values are extremely picky. They make programs work the way they should and if the wrong one is deleted the program (or a bunch of programs - maybe even the OS) most likely will stop working. If you've never worked with the registry or don't even know what I'm talking about, proceed at your own risk. Everytime you make a profile in AutoCAD and modify it or move toolbars around in your workspace, that data is written to the windows registry. Each version of Autodesk products have their own location and values in the registry. As I've worked with AutoCAD and ADT over the years I have tried to take some of the mystery out of what exactly happens when you tell options to set Autosave to 10 minutes instead of 30 minutes or tell options to give you a white background in paper space instead of black. Previously if I had someone import a profile for use in AutoCAD, it was in there for good. The only way to force them to update to the changes I made in Options was to delete the profile in AutoCAD and reimport the new one. This gets very tedious if you have 300 users and you forgot to change something in options that everyone needs (i.e.: support paths or the like).

Well, when I discovered that the changes we make in options are stored in the registry (and the specific location), I was jumping up and down like a kid given a pot of coffee. Usually they can be found in HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R16.2\ACAD-4004:409\Profiles. Inside the Profiles folder there will be a folder for each profile in AutoCAD along with keys for each profile.

***Important!!!*** Ensure all Autodesk applications are closed! When you delete the folder with the profile name, it is removed from options the next time you go into it. Why is this a big deal? Because in area 3 of the script file I have a line that will delete the registry key associated with the profile being used by the cad standards when the exe is run by the user. This ensures that every time a new version of tools is issued to the user, they see the really important changes. No more manual deletion of the old profile.

To edit the registry, go to your Windows Start Menu -> Run, type REGEDIT and hit enter. Use the following screen shot as a guide to where you can find the settings. Keep in mind that even if you are running ADT, you will not find an entry for it in the registry - it is listed as AutoCAD.


Area #4
This is where the compiler looks for all files needed for installation. Important things are the desktop shortcut icon (AutoCAD 2006.lnk in the first line of area #4), Company CAD folder and contents, Profile.aws and the AutocadResourceFiles folders. You'll notice that profile.aws is listed twice. Normally you should just be able to drop it into the current users directory for that machine, but sometimes it needs to be copied to the administrators folder as well.

Area #5
This tells the exe what to do with the desktop shortcut you packaged up with the program. You'll notice the icon is only placed on the current users desktop. This is because this exe we built needs to be run for each user. If I log onto someone elses computer I need to run the exe to ensure I get the profile.aws dropped under my username so I see everything the way it needs to be in AutoCAD.

Hopefully I haven't lost you along the way here, but I've basically just documented a process I've been fine tunning for over a year now. Right now I have this working like a charm. I started using this when a company was on ADT 2005, used it for the rollout of ADT 2006 and it worked even smoother since we had ironed out alot of details. This week I built a network deployment, script file and generated the exe for the tools for ADT 2007 in one day. Very powerful stuff! Cheers!