Solo AutoCAD. Статья пятая

Дмитрий Тищенко

Постановка задачи на комплект общих видов конструкций

Схемы расположения конструкций — всё ли так просто?

Структура внешних ссылок файла КЖ. 1.1

Слои файла КЖ 1.1

Дополнительные блоки оформления

Подсчет конструкций на отметке

Постановка задачи на комплект общих видов конструкций

Прежде чем приступить к изложению конкретных шагов и указаний, полезно осветить историю вопроса и саму постановку задачи, приведшую к разработке методов работы, о которых пойдет речь. При этом придется частично повторить то, что уже было сказано в первой и второй статьях. Но лучше немного повториться, чем оказаться в положении человека, разъясняющего подробности решения задачи, даже не осознанной аудиторией. Разумеется, автор не претендует на оригинальность и авторство проблем, которые будут описаны. Так или иначе, все эти проблемы возникали перед коллективами, ведущими разработку рабочей документации на монолитные конструкции больших зданий.

В свое время, а именно в 2003 году, коллективу, в состав которого входил автор, предстояло запроектировать одно из крупнейших зданий на территории СНГ. Общая площадь этого здания многофункционального назначения приближалась к 200 тыс. м2. Значительная площадь, сжатые сроки, большое количество конструктивных схем отдельных блоков зданий, насыщенность инженерными системами и смелые архитектурные решения — вот основные проблемы, с которыми столкнулись разработчики.

Быстро выяснилось, что никаких цельных сред для проектирования железобетонных конструкций, которые помогли бы нам решить эти задачи, не существует. Все рассматриваемые продукты в процессе решения давали проблемы, масштаб которых не уступал решаемым задачам. Системные решения вообще были немногочисленными. Каждый производитель ПО норовил рассмотреть свою отдельную проб­лемку, безжалостно вырвав ее из контекста.

Так мы очутились в положении строителей египетских пирамид — задачи обширны, а с механизацией не сложилось.

Поэтому мы взяли AutoCAD и поволокли камни в гору. Через некоторое время выяснилось, что при правильной постановке задач уникальные адаптационные способности и здравая архитектура среды способны сотворить чудо. То, что виделось нам «медным долотом», оказалось идеальным набором инструментов для оптимальной механизации разработки. Впоследствии оказалось, что применение разработанных методик целесообразно не только на больших объектах.

Итак, назовем проблемы, которые нам пришлось решать:

• организация параллельного труда проектировщиков для интенсификации работ. Для этого требовалось разбить задачи на мелкие участки, которые можно было бы разрабатывать параллельно. Тут нам неоценимую помощь оказали внешние ссылки. Об этом мы говорили в четвертой статье;
• поддержка целостности и верности документации на протяжении всего проектирования сложного комплекса. Объем изменений при таком проектировании сложно прогнозировался и достигал значительных объемов;
• поэтапная выдача документации требовала хорошо продуманной системы разбивки проектной документации комплекса на блоки и комплекты;
• максимально возможная автоматизация подсчета расходов материалов. Особенно серьезной проблемой оказался сбор материалов по всему блоку, по всему зданию. Вручную такие задачи не решались вследствие большой скорости работы и постоянных изменений.

Так родилось содружество Excel, AutoCAD и те среда и стиль работы, о которых повествуется в данном цикле статей. Справедливости ради надо отметить, что часть поставленных задач решилась только в AutoCAD 2006, когда процесс проектирования этого здания был давно окончен.

Сердцем разработанной нами среды стал комплект общих видов и схем расположения конструкций — КЖ 1.1 (общая структура описана во второй статье). В него входят специ­фикации к схемам расположений, разрезы и виды, а также таблицы сводных ведомостей расходов материалов — по группам конструкций и на все здание или блок здания. И ни одного рабочего чертежа собственно конструкций.

Зачем нужны такие комплекты? К списку аргументов, важных для проектировщика, в пользу такого решения можно отнести следующие:

• в этом комплекте собиралась вся информация об объекте — конструкторская и смежников. В этот комплект подкладывались внешними ссылками подосновы: как DWG, так и растровые, в нем считались марки, отслеживались изменения в плитах, колоннах, балках. Собранные таким образом в КЖ 1.1 данные можно легко проверить на наличие ошибок. Кроме того, если в проекте есть несколько мест хранения информации, вероятнее всего, к концу проекта они начнут конфликтовать. Например, даже отслеживание изменений в осях, особенно на стыках блоков здания, представляло проблему, когда здание размером с квартал и фактически представляет собой более десятка зданий, стоящих вплотную друг к другу;
• Фредерик Брукс, о котором мы много раз упоминали, рекомендует организовывать коллективы по образу операционной бригады, то есть когда много людей в ходе операции работают на хирурга, который освобождается от рутинных проблем и может сосредоточиться на сути происходящего. Это реализуется путем назначения руководителя группы, ответственного за разработку КЖ 1.1, — он становится на объекте компетентным замом главного конструктора. Через этого человека проходят все задания и все изменения — он держит в голове весь проект, так же как главный конструктор. Наличие такого специалиста позволяет поддерживать высокую целостность всей рабочей документации, не перегружая при этом главного конструктора. Обвинения в излишнем аристократизме образовавшейся «белой кости» хирурга и его первого зама Брукс парирует очень легко — в каждом труде и на каждом уровне достаточно творческой работы. Было бы желание;
• здание легко обозреть, понять его структуру, не вдаваясь в ненужные на этом этапе подробности;
• девиз: «одни и те же данные должны вноситься или корректироваться в проекте один раз» — представляется плохо реализуемым без выделения ведущего, главного комплекта. Например, оси всего проекта можно собрать в отдельный файл и вставить в КЖ 1.1 внешней ссылкой. Таким образом, любой чертеж, изготавливаемый на основе КЖ 1.1, будет иметь верные оси на любом этапе жизни проекта;
• нарезка проекта на небольшие комплекты, как судна — на водонепроницаемые переборки, повышает живучесть и надежность проекта. Руководителю проекта легче увидеть и оценить проблемные места проекта и сманеврировать ресурсами.

Из менее крупных задач КЖ 1.1 можно назвать:

• определенная часть строителей, например руководители производства, производители работ, могут ограничиться изучением одного этого комплекта и, всегда имея его под рукой, будут лучше ориентироваться в здании;
• для выполнения конкретной конструкции не придется носить с собой весь комплект. Достаточно комплекта КЖ 1.1 и комплекта чертежей конкретных рабочих марок. Разработанная таким образом рабочая документация будет не так быстро «раздергиваться» на строительстве.

Схемы расположения конструкций — всё ли так просто?

Столь значительные плюсы, по мнению автора, должны помочь выполнить работу по первоначальной стандартизации и обучению персонала.

Однако следует упомянуть о нескольких вопросах, которые могли бы возникнуть на данном этапе у читателя.

Первый из них — на каждом ли объекте стоит выстраивать иерар­хию комплектов, о которой мы говорим? Ответ очевиден: после освоения нормальной технологии даже самые мелкие объекты хочется делать правильно. Тем не менее само освоение — тоже труд, а потому желательно, чтобы он достаточно быстро принес плоды. Для этого, конечно, желателен крупный объект.

Второй вопрос — стоит ли в пределах чисто двумерного AutoCAD разворачивать такие технологии и конвейеры? Не будет ли это изобретением велосипеда? Ведь в настоящий момент есть некоторое количество достаточно мощных трехмерных систем, в которых заявлен такой же или подобный функционал — это и Autocad Architecture, и Revit. Есть и среды, произведенные не Autodesk.

Для ответа на этот вопрос следует вспомнить, какую цель преследует рабочее проектирование. Цель проста: получение в установленные сроки и при заданных ресурсах рабочей документации с минимальным числом ошибок. Остальное — средства, к которым относится и трехмерное проектирование. К сожалению, для многих проектировщиков это средство подменило собою цель (к слову, как и для меня в начале разработки описываемого большого здания). Сейчас трехмерное проектирование иногда рассматривают как самодостаточное средство и очередную «серебряную пулю». Автор убежден в наивности такого подхода и считает, что в настоящее время возможно построить на основе плоского проектирования среду, эффективную для рабочего проектирования монолитных конструкций. Более того, программа­убийца плоской разработки рабочей документации на монолитный железобетон еще не создана. Хотя желающим увидеть такого убийцу, пока он маленький, я бы рекомендовал присмотреться к Revit Structure.

Еще один вопрос, часто задаваемый автору, условно можно сформулировать так: «А как же хомуты?» Среди части проектировщиков и большинства разработчиков ПО утвердилось мнение, что главное при проектировании железобетона — уметь красиво и просто рисовать хомуты и прочую гнутую арматуру. Не имея ничего против специализированных инструментов, автор берет на себя смелость утверждать, что создание, поддержание целостной и актуальной информационной среды, а также совместной работы на уровне всего здания гораздо важнее отдельных мелких удобств и инструментов. Бессмысленно в не построенном еще доме вешать занавески на несуществующие окна.

А хомуты как раз рисуются прос­то. Автор долго мучался с этой проблемой. Пока однажды не обнаружил, что проблема давно решена его подчиненными. Они просто дергали из проекта в проект хомуты и модифицировали их командой _stretch, а рассчитывали их количество и длину все равно в спецификации в Excel по несложной формуле.

Структура внешних ссылок файла КЖ. 1.1

Исходя из поставленных для комплекта КЖ 1.1 задач, поговорим о структуре ссылок для сборки «типовой» схемы расположения здания (в скобках указан тип ссылки):

• оси проекта (вставленная внешняя ссылка);
• отверстия смежников (вставленная внешняя ссылка);
• архитектурное задание (наложенная внешняя ссылка);
• задания смежников (наложенная внешняя ссылка);
• генплан (наложенная внешняя ссылка);
• файл штампов (наложенная внешняя ссылка). Применяется, если вы делаете штампы внешней ссылкой, а не через поля подшивки.

Почему все вспомогательные внешние ссылки наложенные, думаю, пояснять не надо. Дальше файла КЖ 1.1 они идти не должны, чтобы не нагружать машины.

Файл осей мы обычно располагаем в папке «Компоненты» проекта. Причиной его появления стало то, что поддержание осей в большом проекте на протяжении всего его жизненного цикла — непростая задача. Проще иметь все возможные виды осей в одном файле. Там же можно и типовые высотные цепочки набрать. В каждом конкретном файле вставленный файл просто подрезается. Таким образом, все разрезы, фасады и схемы расположения проекта будут обеспечены актуальными осями. Выглядеть этот файл может так, как показано на рис. 1.

Рис. 1

С файлом отверстий смежников не всё так просто. Автор сам сравнительно недавно пришел к этой идее. Отверстия смежников редко бывают уникальными на каждом этаже высотного здания. Чаще всего отверстия смежников оказываются одинаковыми на каких­то этажах. Например, у высотного здания могут быть уникальные отверстия на нижних и верхних этажах, потом, по мере увеличения высоты, этажи будут собраны в две­три типовые группы вследствие изменения сечений воздуховодов.

Однако такое членение будет подчиняться собственной логике и вряд ли будет совпадать с логикой объединения одинаковых схем расположения конструкций на разных отметках. Кроме того, отверстия часто появляются или меняются по ходу проектирования. На одном из более поздних наших проектов это поставило под вопрос получение надежных схем расположения — сколько раз группа проверки проверяла, столько обнаруживались мелкие ошибки на разных этажах зданий в связи с большим количеством ручного труда по обработке отверстий на каждой отметке.

Тогда типовые схемы расположения отверстий всего высотного здания были собраны в один файл. Получилось не то четыре, не то пять групп. Выглядело это примерно так, как показано на рис. 2.

Рис. 2

Затем эти файлы были наложены внешней ссылкой на соответствующие схемы расположения по отметкам. Ошибки прекратились. На всех опалубках плит появились правильные отверстия. В дальнейшем, благодаря удобству и надежности работы, был сделан вывод, что решение получилось универсальным и заслуживает того, чтобы войти в технологические карты изготовления рабочей документации предприятия.

Слои файла КЖ 1.1

О слоях стандарта предприятия мы говорили во второй статье. Здесь же упомянем, что структура слоев должна быть разработана так, чтобы позволять отфильтровывать друг от друга объекты на чертежах, которые будут изготовлены на основе схем расположения, например на опалубке плит и схемах расположения балок.

Однако злоупотреблять количеством слоев также не стоит — будет труднее ориентироваться в чертеже.

Не следует забывать, что в процессе разработки для удобства можно придавать разным слоям, в том числе слоям внешних ссылок, различные цвета. Возможность сохранения и загрузки состояния слоев делает такие действия простыми и удобными. На рис. 3 приведен собранный типичный файл схемы расположения.

Рис. 3

Видно, что оси и отверстия являются внешними ссылками.

Дополнительные блоки оформления

На рис. 4 изображен блок наложенного сечения балки. Сейчас уже мало кто помнит этот элемент оформления чертежа, позволяющий на порядок повысить читаемость схемы расположения монолитных конструкций. Например, отличать стены от балок, читать на плане сечения балок. На рис. 5 показано, что умеет делать этот блок.

Рис. 4

Рис. 5

Рекомендую потратить немного времени и изготовить такой динамический блок.

Подсчет конструкций на отметке

Для подсчета конструкций заранее поставим разумное ограничение. Наша цель — правильность чертежа и спецификации, а не просто абстрактная верность модели. Для этого надо, чтобы были подписаны все конструкции — иначе на строительной площадке чертеж не будет прочитан. Вот подписи мы и будем считать. Для этого разработаем динамический блок подписи конструкции с атрибутами, как показано на рис. 6.

Рис. 6

Сам блок со своими ручками управления изображен на рис. 7.

Рис. 7

По сути это обычный объект «Выноска», заключенный вместе со своими ручками в динамический блок с прикрепленным атрибутом. Сейчас, после выхода AutoCAD 2010, для решения этой же задачи можно предложить иной способ — мультивыноску типа «Блок» с требуемым блоком. Однако такой способ реализации потребует модификации команды attout. Поэтому, если у вас нет штатного программиста, такой путь рекомендовать нельзя.

Подпишем все конструкции на чертеже. Теперь отработанным приемом с помощью команды attout выведем атрибуты в текстовый файл и откроем его в Excel (рис. 8).

Рис. 8

Для анализа полученных данных применим механизм сводных таб­лиц. На рис. 9 изображено окно с параметрами сводной таблицы.

Рис. 9

Результат работы сводной таблицы представлен на рис. 10.

Рис. 10

Полученные количества марок можно вставить в XLS­файл спецификации, а затем передать в AutoCAD через связь с таблицей Excel. Итог — спецификация к схеме расположения монолитных конструкции, изображенная на рис. 11. Также данная технология подходит для подсчета единиц сборных конструкций и узлов на плане или разрезе. Чертим, размещаем подписи в виде динамических блоков с атрибутами — и считаем.

Рис. 11

Итак, мы научились делать чертежи комплектов КЖ 1.1, то есть комплектов общих видов — сердца системы проектирования монолитных конструкций. В следующей статье мы будем учиться делать рабочую документацию на монолитные плиты: опалубку, армирование, считать арматурные стержни и делать специ­фикации. Разумеется — на основе файлов КЖ 1.1.

К слову, все статьи можно найти на ресурсах Сообщества пользователей Autodesk в России: http://communities.autodesk.com/. А на форумах сообщества мы сможем обсудить все статьи и ваши идеи, которые возникли при прочтении статей.

САПР и графика 11`2009