For discussion: library part driven scheduling

[Anonymous]

Hello everyone!

We use ArchiCAD library parts as a representation of real word's objects. When we create a schedule we visualize this correlations and make some calculations. And interactive schedules take most of information from instances of library parts. What strategy should we use for filling placed library parts with information of their real-word prototypes? I am going to introduce one-to-one library part to real-word object mapping approach below.

Usually, real-word object is a base product with some varied properties (base type of door with different sizes or materials, for example). "Intelligent" library parts have a lot of parameters which represent most of this variable properties. So, when I say "one-to-one" correlation I mean relation between base real-world object and a library part.

So, go step by step. In the beginning we have a project with standard library (or office library) and an empty project library folder.

1.1. We want to use some real-word object in our project which haven't placed yet. Ok, locate some good object in standard library, open and resave it in the project library with meaningful name. If the library part object already resaved in our project library, but we need more differences then simple properties variations, when we save the same library part object in our project library again with other name. And the difference in names should reflect the differences in their real-world prototypes (names should be meaningful).

1.2. Set parameters according to real-word object properties which you already know and place the project library's object.

1.3. Proceed with this object placement method.

Ok, now we want to create a schedule.

2.1. Place library part name and all parameters, representing real-word objects properties, in Schema. Include ALL parameters including empty one as manufacturer etc. Also include ID. Generate interactive schedule with "Show uniform items as a single entry" option.

2.2. Export the schedule to Excel. Fill empty fields with appropriate information. It's much easily to do in Excel then in ArchiCAD . If you don't use some kind of variation in your project, but can use it in the future (for example, you place only right-handed instatcies of some door, but can use left-handed in the future), just duplicate the row and change one of main parameters (door orientation in our example). And not forget to fill in ID field - it totally depends on other parameters!

2.3. Save CSV file in your project library folder with ProjectObjects.CSV name.

2.4. Now our objects should change their parameters automatically. Thanks to parameter script our objects can be self-modifiable. If we have a macro which can read the ProjectObjects.CSV file and modify parameters in the library part which call it than we only need to include the macro call in parameter script of every library part. It is a long boring work, but don't mind the problem now, please. It can be solved.

2.5. Ok, now our objects contain all information about manufacturer, costs, etc. And they have appropriate IDs. We can create interactive schedules easily.

2.6. If you need modify some information or include new data, just use Excel and resave the ProjectObjects.CSV file.

So, we can implement some kind of self-made "database" about library part to real-word object correlations.

What do you think about this idea? Can it be used in your practice? I guess the most problematic points is: can you use the library part resaving approach?

I can implement the self-modification macro, if you find this idea useful.

[Erika Epstein]

Leo,
This sounds great. I would love to try it.
One of my wishes has been the ability to integrate data back in to archicad. The ability to export to excel and then bring back the data with the changes. This arises often because not all team-members are archicad users or should be. And/or as you point out some types of data is entered far more efficiently in spreadsheet format.

Can a similar approach be done with zones? I'm thinking through the life of a project, or projection/control of life-cycle costs. Preliminary work where developer/owner/end-user info is being analyzed and interpreted as design. During design, construction and then post construction maintenance of a building(s). etc. etc. etc.

Very exciting!

[Rob]

Leo,
I agree in principal but I do not believe that attaching cutomised information should be done via GDL script and variables (and I appreciate that your proposed workflow is based on utilising existing resources).
Edited: in fact we do have this implemented for lib parts (only) based on subtype templates (see Parameters for Listing in the parameter list of any standard GS lib). This is just 'hangover stuff' originated in a long dead GS's Property Management Software (I have forgotten its name already).

All of this should be done by independent 'tags' sandboxed from the lib part GDL code itself. This way any changes to a lib part's code (eg. upgrades, debugging, version migrating) or actual replacement of the lib part itself (replacing eg Chair1 by Chair2 would not necessarily delete all information already attached to Chair1) would not have any impact to attached customised information. Also, tags would allow attaching customised information for non-GDL elements too.
And surprise, surprise it is already there however it is not 'wired' properly. If you went to Scheme Settings/Available Parameters/General you would find 'Custom Text #' variables (AC11 has 3 only but AC12 has already 10 of them). These are in fact customisable tags attached internally to each particular AC element.

Flaws:
1. they are not visible in the Default Settings dialog (the best place for them should be the Listing and Labeling tab).
2. they are not visible in Element Information palette
3. they are not visible to associative labels
4. They can not be renamed so we could see what is what in eg Default Settings dialog.
5. Point no.4 leads inevitably into another shortcoming and that is - each individual AC element type (slab, window, door, beam, column... etc) has to have its own set of tags (and to be fair may be 10 per each set would be enough). To explain what I mean here is the example: if we renamed let's say 'Custom Text 1' to 'Type of glazing' (Windows/Doors) with current system it would be shown as 'Type of Glazing' tag for all AC elements (eg a wall) which is not desirable. Therefore we need to have different sets of tags per each element type (note!: I do not mean an element instance here.)
6. and of cause tags should be connected (import/export-wise) to some common database types (Access or FileMaker). However I do not believe that Excel is a proper tool for it as it does not handle 'records' as such. eg each individual database item has to have its unique 'key' (or ID as you already suggested) and that is not possible to maintain automatically in Excel (imagine a big list of items - if somebody moved a field it would be a mess and definitely a dangerous practice too).

Anyway, GS has provided yet another alternative (which is obsolete as hell) - property objects but that is another cup of tea I do not wish to go to... I just simply do not want to spoil my day cursing this 'piece of work'

[Erika Epstein]

Sigh.

[Anonymous]

Hi Erika!

Ok, I am going to implement this tools. I guess the development process takes about a week. My experience in supporting Russian architects talks me that this solution needs strict workflow and can't be implemented because of chaotic nature of work at Russian design studios. But I know that western practice gives us examples of very, very strict workflow. So, I'll be glad if this solution works for your company.

This technology can work for Zone Stamps too.

I am going to publish a post here with the macro and it's manual when they are ready.

Cheers,
Leo

[Anonymous]

Rob,

from my point of view, the most serious problem with interactive scheduling is instance-based nature. When we talk about element scheduling, most of information about scheduled items come from real-world prototypes. Usually we have a lot of instances, but only a few prototypes. Why should we fill every instance with identical information? And we have to be careful for avoiding inconsistency.
ArchiCAD Property Object does this work - links library object with some special object, which provides information about real-world prototype. Unfortunately, Graphisoft don't let us to use Property Object's information in interactive schedules.
So, the strange GDL-base solution helps us to fill all instances of library part with information about related real-world object. All information come from one source, so we have more reliable schedules.

You are right - I plan to fill "Parameters for Listening" fields.

Cheers,
Leo

[Anonymous]

This all sounds very interesting Leo. Please keep me posted on your progress. The problem of instancing is a major one that must be solved to realize the full potential of virtual building.

[Rob]

I have tried to implement a similar system couple years ago. Part of this was revision/issue/sheet numbering hooked on Excel transmittal record spreadsheet done by my colleague. The system was simple (as we thought) - Excel file writes/reads a text file by pressing a button (handled by VisualBasic macro in Excel), then particular GDL lib part reads/writes the same text file and handles the AC part. We have abandoned this kind of approach for one reason and that is: maintenance-to-benefits ratio is huge especially in a longer run of a project life.
I have learnt my lesson there that creating a convoluted system dependent on GDL proves to be counterproductive. Simply GDL is not robust enough for this kind of functionality.... and there are technical obstacles too... like linking external file from/to GDL is a real headache in terms of different platforms and rigid folder/drive structure path location, GDL backward incompatibility (if you update AC10 macro with AC11 it won't work with all AC10 lib parts), migrating and updating (macros are not picked up), working in Teamwork with drafts (someone working at home - GDL macro will point to non-existent path) and so on.

Flexibility is the main looser here and inevitably it will bring whole system down sooner or later.

[Anonymous]

Rob wrote:
Flexibility is the main looser here and inevitably it will bring whole system down sooner or later.

Absolutely agree. I have mentioned similar things here http://archicad-talk.graphisoft.com/viewtopic.php?p=137692#137692.

But in this case we have to implement one middle-sized GDL macro only. If the macro is simple and well-structured then it'll be like an idea - adaptable to needs of particular user and new software modification. We don't need to maintain it as a SOFTWARE SOLUTION - we are not so proud .

I don't think that Graphisoft can throw away such important features as opportunity to change parameters or read text/XML files in library part scripts.

Cheers,
Leo.

[Rob]

I do not wish to discourage anyone here.
What I am trying to say is - I have been there and it did not work. I know that GDL capabilities sound very tempting but again GDL stands for Geometric Description Language so I feel you are 'knocking' on a wrong door.

As a good example is current property lib parts status based on GDL - an utter failure in terms of usability.