Schedules, door ID and repetitive modules

[Ignacio Azpiazu]

How are people handling door IDs in projects with non-residential repetitive modules (labs, hotels, hospitals, office buildings, schools)?
1) My usual way of doing that was to use hotlinked modules for the repetitive stuff and get the door tag to identify the door type, which works OK. But I am now discovering that
2) many US practices use the tag to identify the door *unit*, so that each individual door in the building gets a unique ID, which I think there is no way of doing with repetitive hotlinked modules.
Given the choice of modeling everything 20 or 200 times each time a change is made to the repetitive design or putting the door tag ID manually at the end of the process I guess I would go for the manually tacked-on door tag object --but that will not show in the door schedule. I am trying to understand the reason for the unique ID for each door, and I am thinking that maybe it is a practice coming from residential and that should be done away with in this type of buildings (where each door is less unique anyway), but since this is the first time I come across this method I am not sure if there is any hidden logic to it that I am not seeing.
3) Another option would be to break the hotlinks at the end of the process and manually give an ID to each door object, which would then show in the schedule. But since nobody can ever be right about when 'the end of the process' is, in practical terms this would end up working exactly the same as '2)'.
So what is everybody doing?

[Anonymous]

Ignacio -

Interesting question. I tend to favour the 'unique number' for every door (and window, for that matter) for 3 reasons: a) if you're using a scheduling method other than ACad's own, it allows a check that you've covered every door, b) you can make modifications in the schedule without having to amend the drawing (e.g. Change 'Door No. GF10' to a 'Type 3'), and c) it simplifies referencing a particular door ('Make good damage to door no. GF10)

If I were using modules, I would use text to label the doors (and yearn for an incremental numbering tool for that purpose).

However, I assume this would preclude you from using Acad's door scheduling tool - don't know the answer to that one.

[Anonymous]

Ignacio -

The first thing that came to mind when I read your situation was, why do your door tags have to be connected to your doors? When using modules I would still use zone stamps, and you can utilize custom parameters within zone stamps to represent your doors, which would solve scheduling problem. But you would have to modify a leader GDL to be able to pull the correct parameter out of your zone stamp. I haven't tried this but I'm sure with a little experimentation it could be pulled off. Let me know if this works.

[Ignacio Azpiazu]

I found the solution, way simpler and more obvious than I ever imagined (I was positively sure that this one wouldn't work, but fortunately I didn't trust myself, tried it and it does work):
- make modules with all the walls etc. and assign each door a User ID in the module (like 1, 2, 3, for the first, second, third door in a room);
- get the door tag to show 'Room and Door ID' (this is an option in the new Special Edition US Library, as is, without any scripting);
- bring in the modules and multiply etc. the modules in the building file, and then create the zones in the building file (this was always a given, in order to get unique room names and numbers using the Zone Name and Zone No.).

The doors will then get their unique door tag showing the Room Number (Zone No.) followed by the Door ID --such as 101 1 (Room No and Door ID show in different lines in the 'Door Marker_NCS SE 9', which is not too bad, but with a bit of scripting could show in a single line, even a single string without spaces).

I had thought the doors built into the module would not read the zones in the building files, but they do. Which is actually the only sensible behavior and the Graphisoft guys obviously figured that one out 20 years ago, but I only realised today. It works beautifully, and I am feeling like kissing these Hungarians. Ahhhh, so much less work, so many less coordination headaches.

[Chazz]

Ignacio wrote:
get the door tag to show 'Room and Door ID' (this is an option in the new Special Edition US Library, as is, without any scripting)

Excellent topic, thanks for the discussion and for sharing your solution.

One question though. The option in the new Special Edition US Library that you write of is the label, not the door itself, right? Presumably this label could be used with other doors (I use DoorBuilder). Is this your situation too? any info appreciated.

[Ignacio Azpiazu]

Chazz wrote:
The option in the new Special Edition US Library that you write of is the label, not the door itself, right? Presumably this label could be used with other doors (I use DoorBuilder). Is this your situation too? any info appreciated.

I am not familiar with Door Builder (not even sure if it is an object or an API). I am not sure about how loading the NCS SE 9 label from Door Builder would work in terms of getting the pop-up parameter for 'Room and Door ID' to display in the label, etc.

If the NCS SE 9 label can do it I would think the potential is there for every door in any library, with the NCS SE 9 if it works and with some custom scripting if it doesn't.

Graphisoft warns severely and repeatedly against the potentially catastrophic consequences of loading the SE Library on a project using the non-SE Library --I would guess some parameters kept their name but changed details of how they work, some things look the same but have differing underlying parameters, etc. So if there is any problem with Door Builder and the new label it can also be related to that.

[Chazz]

Ignacio wrote:
Graphisoft warns severely and repeatedly against the potentially catastrophic consequences of loading the SE Library on a project using the non-SE Library

My thought was to unpack the SE Library PLA and just harvest out the label ID tag. Then rename it and use it within my existing library structure. Seems that ought to work. I will adopt the SE Lib in time but can't swallow the whole thing now. Thanks again for your help here.

[Karl Ottenstein]

Chazz wrote:
[My thought was to unpack the SE Library PLA and just harvest out the label ID tag. Then rename it and use it within my existing library structure. Seems that ought to work. I will adopt the SE Lib in time but can't swallow the whole thing now. Thanks again for your help here.

The revised SE9 library posted today can be loaded alongside other libraries. So, the dire warning associated with the prior release do not apply.

Karl

[Chazz]

Karl wrote:
The revised SE9 library posted today can be loaded alongside other libraries. So, the dire warning associated with the prior release do not apply

GS wrote:
We have significantly changed the parameters and the user interface of many objects (e.g. doors and windows). Therefore, this library can not be used together with the AC 9 US library on the same project. In order to avoid any conflicts between new and old objects, please don't load this library into an existing project and do not load the two libraries together! Please also read the detailed AC 9 Special Edition Library Manual before starting to use it.

Thanks for the heads up on the new version of the SE library. However, it appears to still not play well with the standard AC 9.0 Lib according to the website. I think what they mean is that you can use the revised SE library in conjunction with the old SE library. Or do you have a different read on it? For everyone else, the download can be found here

[Karl Ottenstein]

Chazz,

Sigh. Whoever created that web page on the tr.graphisoftus web site did not update it for the new release. I'm writing the powers that be to let them know of this oversight. The 'test' page (which is gone now) contained the appropriate content - which is that this new SE9 library (posted this week) can be loaded alongside any other library EXCEPT the prior release of SE 9. For people who started using the first release of SE9, you should just remove that library from your project and reference this one instead. Even though the names of the parts have changed, the references will be correct because of matching internal GUID.

The correct announcement text is here:

http://archicad-talk.graphisoft.com/viewtopic.php?p=46767#46767

Tibor wrote:
Special Edition Library Update is Available


The updated version includes the correction of inconsistencies found in the first release and it's fully compatible with the original SE library. The most important changes are the following:

· SE9 version suffix added to each object's name so that it can be loaded together with the ArchiCAD 9 library
· Textures , background pictures and list templates have been removed from the library archive (pla) and moved to separate folders so that you can freely unload or modify them
· Parameter transfer between different types of doors and windows fixed
· Different materials can be assigned to the inside and outside of the doors and windows
· Window size can be entered correctly in the editable hotspot's pet palette
· Sash setback parameter added to windows
· Brick arch and sill functions corrected in case of ganged windows and doors
· No hotspot editing of window size allowed in case of typical sizes
· Correct 2D and 3D if the brick sill is turned off for metal windows
· Simple brick sill position fixed

Please visit the following website for downloading:

http://www.graphisoft.com/support/archicad/downloads/library_updates/usa.html

Regards,
Karl