Collaboration with other software
About model and data exchange with 3rd party solutions: Revit, Solibri, dRofus, Bluebeam, structural analysis solutions, and IFC, BCF and DXF/DWG-based exchange, etc.

Opening orientation of double-sided doors

Anonymous
Not applicable
I am sorry, but can anyone recommend me a way for creating door schedule with quantity of Left/Right oriented doors? I want to count the quantities for doors which really have orientation, but double-sided doors are divided by this criteria too ! Can I get overall number only for such non-oriented doors from standard ArchiCAD library (AC 12) without changing GDL code for them?
21 REPLIES 21
Anonymous
Not applicable
Leo wrote:
I am sorry, Wrathchild, but we are talking about quantities, aren't we? Empty ID field can't solve the problem with countable fields
There's a separate field for the quantities in your scheme settings. Go to scheme settings. One of your fields will be Quantity and one will be ID.
The quantity field will count and the ID field will filter.
Anonymous
Not applicable
Looking back at your post, this might not work for you exactly as you want. You would have to have separate rows for RH and LH doors. Not sure if you can live with that or not.
Anonymous
Not applicable
You would have to have separate rows for RH and LH doors. Not sure if you can live with that or not.
Unfortunately, I can't go with it. I have to put quantities of left/right opened doors and overall quantity of this particular type of doors on one row.
Karl Ottenstein
Moderator
Leo wrote:
At first, ArchiCAD already does a lot of work for us when it let us to set door's swing visually. Why should we ignore this information?
I agree. It is a bit embarrassing for GS that doors store so much parametric information, and yet one cannot retrieve the swing orientation. The LHS/RHS info could be easily computed by the door objects - which have to take into account their own 'mirror' and 'flip' status - yet it is not. Scheduling the swing is a pretty basic concept, and I agree with you Leo that it should be computed from the model, not retrieve from manually entered data fields which can easily become incorrect.

I disagree with Wraithchild on the use of the ID field in this case, which IMHO should be reserved for the marker. All doors and windows have plenty of user defined text fields to store other data, such as RHS/LHS, etc. The ID field, combined with Element ID Manager, is designed for and more appropriate for window/door labeling.
There are three cells in each row for quantity: quantity of left-swinged, quantity of right-swinged, and overall quantity.
ArchiCAD will let you create a group header for each of the three types of door quantities, but each total would appear in its own row (three rows). I don't know of a way to get ArchiCAD to directly generate a single row with the totals in three columns - other than publishing the schedule as CSV and letting an Excel pivot table (or database query/report) reformat the data.

Sorry nothing positive to suggest,
Karl
One of the forum moderators
AC 28 USA and earlier   •   macOS Sequoia 15.2, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
Karl makes a lot of sense. The RH or LH should go into one of the User Defined parameters instead. I've been using custom ID in my door marker settings but I'll be rethinking that now.

Wrathchild<-------bows to the master
Anonymous
Not applicable
Karl Ottenstein wrote
The LHS/RHS info could be easily computed by the door objects - which have to take into account their own 'mirror' and 'flip' status - yet it is not.
Thank you, Karl, for your answer. But I thought that "W/D opening orientation" field in List Schemas worked well for oriented doors. According to my experiments, the field changes status after flipping, mirroring e.t.c. Why did you say that this functionality haven't implemented yet?
Karl Ottenstein
Moderator
Sorry, Leo, you are correct that 'Orientation' gives the hinge side. I remembered that there was a problem, and forgot what it was!

The problem relates to at least the US libraries, which have an 'outside' and an 'inside' attribute for the door panel as well as the casing etc. In the US at least, we often have different materials on one side of a door or window than the other - most often metal cladding on the exterior.

You had wanted to get an inventory of door panels based on how the hinges would mount. But, with the US library, this is slightly problematic due to a library bug. When you place a door, the eyeball is clicked towards what is to be treated as the 'outside', and towards the hinge side. If the door is then supposed to swing inside, it is flipped as the next step.

But, in the US lib, if you have assigned materials to 'outside' and place a left hinge door and flip the door to swing 'in' (giving you a right hinge door), the casing still has the outside material, but the bug is that the door materials are reversed - with what is supposed to be the exterior material now on the inside. You have to manually edit the door and assign the interior material to 'outside' and the exterior material to 'inside'.

If you place the same door and have it swing out, right hinge, without editing to fix the bug, the schedule would show both door panels to be the same, even if you were to include the material parameters to further group the panels without editing the door. So, without manual editing to work around the bug, any time a door is flipped, it might show up in the schedule as being the same type of slab as another door when it in fact has different materials or cladding.

I don't know about the INT library - if it has this inside/outside concept.

But, yes, you are right - Orientation is adequate if materials are uniform!

Thanks,
Karl
One of the forum moderators
AC 28 USA and earlier   •   macOS Sequoia 15.2, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Karl Ottenstein
Moderator
This thread listed another problems with swing scheduling, but with list schema rather than (interactive) element schedules:

http://archicad-talk.graphisoft.com/viewtopic.php?t=24379&postdays=0&postorder=desc&&start=0
One of the forum moderators
AC 28 USA and earlier   •   macOS Sequoia 15.2, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
Thank you, Karl, for you so informative answer. it's really very interesting for me.

I have international and russian versions of ArchiCAD Library. As I understand from testing, they haven't the bug with materials of internal/external sides of doors. Fortunately, the bug with 3D symbol doesn't important for me.

It seems to me, that I have achieved my goal. I have created custom graphic template, which does all work for me. List Schema let us to get several totals at one row. But I am afraid, that Graphisoft can get rid of List Schemas in the future .

Anyway, one remark about door schedules. Why do you prefer to save door type information with each instance of library part? I think that it would be much better to choose some library door as a base for a real door and sort instances according to their parameters. We can use a very simple Property Object for that. For example:
1. Create new database for door types. Create several keys in this database - one per subtype of the base real door. Name the keys according to real names of that subtype.
2. Create simple property object, which would analyze main library door parameters (name of the library part, orientation, flipping, width, height, e.t.c.) and select one component for the door from our database, according to results. We can create a template for this object and slightly change it for each "real" door.
3. Link this property object by criteria with selected library door.
4. Create Interactive schedule with component name as a field and enjoy.

In this way we can always check ourself about all door instances in our project - just schedule doors without components. If you save door identifiers inside each instancy, you can relay on your accuracy only.

Sorry, I am not sure that I describe the approach clearly .
Anonymous
Not applicable
Sorry, I went wrong in my previous post. Graphisoft don't give us any chance to use library part's components and descriptors in interactive schedules.

But still, I believe that "library part to real element" approach is better than "ID to real element" approach.
In this way we can use parameter script for analysing current state of the library part and redefining some of it's "Listing" parameters accordingly. So, it seems to be a kind of solution for a task, which Erika told about here http://archicad-talk.graphisoft.com/viewtopic.php?p=136434#136434. We can write a macro for analysing XML (or CSV) and call it from parameter script of each library part, which we use in our project. The macro will change parameters of all placed instances accordingly to the XML file. So, out interactive schedules will be changed like after import.