Solo AutoCAD. Статья первая

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

Sola Scriptura*.
Мартин Лютер

Серебряной пули нет!
Фредерик Брукс

Мнение, что обычный пользователь использует AutoCAD на 5% его возможностей, давно стало прописной истиной, и многие проектировщики с ним смирились. Следствием этого является то, что проектировщики теряют много времени на лишние действия, переделки, не могут добиться от своего инструмента полного повиновения. А самое главное — не могут справиться с рядом задач, которые могли бы решить при должном владении инструментом. Чтобы изменить это, надо изучать AutoCAD. А учиться легче, когда понимаешь — зачем? Вот и попробуем в этом цикле статей продемонстрировать задачи, которые мы сможем решить, если изучим AutoCAD хорошо.

Поставим цель: разработать благодаря знанию AutoCAD и методологии проектирования самодостаточную рабочую среду проектирования железобетонных конструкций на основании исключительно AutoCAD с привлечением минимума дополнительных средств. И как школьники называют неизвестную переменную x, так и мы заранее назовем ее, скажем, Solo (от лозунга «Solo Auto cad», хотя ориентируем мы эту среду в первую очередь на коллективную работу). По моему субъективному мнению, вопросы проектирования ЖБК в AutoCAD не освещены достаточно полно. Надеюсь, что публикации этой серии заполнят имеющиеся пробелы. Впрочем, первые три-четыре статьи будут интересны не только специалистам по проектированию ЖБК.

Давно известно, что форма освобождает. Иными словами, для того чтобы что-то создать, необходимо иметь четко очерченные границы. Попробуем поставить себе те ограничения, которые помогут нам создать среду Solo.

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

Следующие архитектурные принципы возьмем из книги «Мифический человеко-месяц, или Как создаются программные системы» Фредерика Брукса (это одна из тех немногих книг, которые я обыкновенно рекомендую прочитать). Первый из них — принцип классификации задач. Все задачи, согласно Бруксу, следует делить на две категории: сущностные и второстепенные (в терминах Брукса — акциденциальные). Сущностные задачи — это задачи, изначально свойственные данной отрасли человеческой деятельности. Например, разработка конструктивной схемы здания, выбор пролета, расположение опор — типичные сущностные задачи. Независимо от века и инструмента решать их придется инженеру. Второстепенные задачи — это задачи, не присущие данному виду человеческой деятельности, но происходящие от инструментов, с помощью которых решаются сущностные задачи. Например, отправка на печать готовых листов — второстепенная задача, поскольку не требует инженерного труда. Перед решением задач важно грамотно и безошибочно разделить их на эти две группы.

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

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

Если вам пытаются что-то продать под таким соусом — внимательно присмотритесь. Вдруг панацею продают?

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

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

Итерационный он потому, что за одну проходку по производственной цепочке мало что удастся. По цепи придется пройти не один раз взад и вперед, каждый раз выявляя проблемы, ставшие узким местом после предыдущих оптимизаций. Попробовали внедрить подшивки или работу с внешними ссылками — выяснилось, что без единого сервера это невозможно. Поставили единый сервер и научили всех туда сохраняться — сеть не выдержала. Модернизировали сеть — выяснилось, что надо договориться о стандартах именования файлов. Договорились — стало понятно, что теперь бы и структуру проекта стандартизировать надо… Многие из проблем, которые проявятся спустя год-два такой работы, могут сильно удивить вас. Но именно такой постепенный эволюционный процесс, а не попытки найти философский камень приводит к успеху.

Применим приведенные нами принципы для оптимизации процесса проектирования. Начнем с конца. Первое, что попадается на глаза в конце, — это печать и оформление листов. Типичная второстепенная проблема. Тем не менее часто именно печать становится проблемой в последние дни проекта, когда и так времени нет ни на что. К сожалению, несмотря на всё, что Autodesk сделал для решения данной проблемы, многие пользователи так и остались на уровне 10-го AutoCAD и черчения в плоскости модели. Что тут сказать? В задачи автора не входит обучение AutoCAD и критика устаревших способов решения задач. Зато я попробую продемонстрировать, что теряют пользователи, делающие чертежи столь отсталым образом.

Использование «Листов» (Layouts) и «Видовых экранов» (Viewports) сегодня, конечно, уже не предел упрощения. Начиная с 2005-й версии появились подшивки, каждая из которых представляет собой файл, в котором расположены ссылки на листы проекта. На рис. 1 приведена подшивка одного из наших проектов.

Рис. 1

В разных разделах этой подшивки находятся сотни листов. Преимущества подшивок для сколько-нибудь большого проекта очевидны:

• возможна автоматическая печать всего проекта, раздела проекта, просто нескольких произвольно выбранных листов из разных файлов;
• с помощью полей подшивки можно наладить эффективную и надежную работу с номерами, именами, ссылками на листы разрезов, узлов, сечений проекта. При любых изменениях номеров листов и имен комплектов верность нумераций и ссылок будет поддерживать AutoCAD;
• гарантируется получение полного проекта по корректно сделанной подшивке;
• открытие любого листа (Layout) по клику в подшивке позволяет не думать о расположении конкретного файла;
• при печати всего проекта не нужно открывать/закрывать файлы;
• возможность архивации, передачи всего проекта (либо его любой части) прямо из подшивки с сохранением всех необходимых файлов, в том числе внешних ссылок.

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

Продолжим оптимизацию процесса печати. Теперь рассмотрим печатные устройства. Конечно, в случае использования подшивок есть смысл купить быстрые печатные устройства, поскольку теперь именно процесс печати будет критичным. Но и тут есть подводный камень. Принтер — это устройство, а значит, оно ломается, переезжает внутри интрасети. Брукс учит нас, что изменения — это не досадное недоразумение, а часть жизненного цикла. Значит, к ним надо быть готовым. Как можно быть готовым к поломке принтера, и как застраховать себя от перенастройки 500 листов проекта на новый принтер? Ответ очевиден — применение виртуальных принтеров, например DWF- или PDF-принтеров. Технология проста: «листы» шаблона настраиваем на виртуальный принтер (например, входящий в состав AutoCAD DWF6 ePlot или любой из имеющихся на рынке PDF-принтеров), готовые листы проекта печатаем вначале в PDF, а затем из Acrobat Reader — на бумагу.

Преимущества виртуальных принтеров:

• главное — независимость проекта от конкретных принтеров;
• в процессе работы над проектом облегчается манипулирование форматами. Например, лист А2 можно распечатать из Acrobat на А3 для внутреннего использования или на выдачу, если сохраняется читаемость. Практика показывает, что от уменьшения на один формат читаемость грамотно выполненного чертежа не ухудшается;
• PDF-версию проекта можно давать заказчику. С PDF может работать и прораб, и секретарь руководителя — в отличие от DWG. Также очень полезно, что у заказчика при этом нет полноценных чертежей. Ушлому заказчику не удастся «за тарелку супа» откорректировать ваши чертежи в подсобном хозяйстве;
• можно легко печатать старые проекты — так же быстро, как и новые проекты.

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

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

Начать надо с создания блока штампа. Сделать его нетрудно. Это должен быть блок с атрибутами. Выглядеть он может приблизительно так, как показано на рис. 2.

Рис. 2

Все данные штампа делаем в виде атрибутов этого блока (к сожалению, объем статьи не позволяет подробно рассказать о процессе создания такого блока; рис. 3).

Рис. 3

Теперь в файле с названием, к примеру, «Штампы.dwg» размещаем все файлы раздела или проекта. Получается примерно так, как на рис. 4.

Рис. 4

Далее — привлекаем две команды из Express Tools: attout и attin. Первая из них выводит содержимое атрибутов в текстовый файл, а другая считывает.

Применяем attout на созданные нами блоки и открываем получившийся текстовый файл в Excel. Сортируем, вписываем текст в ячейки, растягиваем, копируем. Одним словом, работаем в Excel (рис. 5).

Рис. 5

Сохраняем TXT-файл и импортируем его обратно командой attin. Эти две команды можно найти и на ленте (Ribbon) в группе Express tools (рис. 6).

Рис. 6

После импорта TXT-файла блоки штампов заполняются введенными данными (рис. 7).

Рис. 7

Теперь вставляем штамп внешней ссылкой на «Лист» чертежа и подрезаем (рис. 8).

Рис. 8

Вставленный нами штамп, как и любая внешняя ссылка (External References), сам обновится при обновлении файла штампов. Поэтому массовое обновление, корректировка отдельных штампов чертежа, изготовление ведомости листов — теперь не проблема. Благодаря малым затратам времени это теперь может делать один ответственный специалист.

Тут надобно сказать, что с развитием подшивок данный способ работы со штампами перестал быть единственным оптимальным решением. Довольно удобно можно делать штампы с помощью связывания блока штампа и полей подшивки через объекты «Поле» (Field). Мы так не делаем потому, что уже привыкли, и потому, что оба эти метода не имеют каких-либо качественных преимуществ друг перед другом. А читателям я предлагаю попрактиковаться в этой методике, потому что мы к ней еще вернемся. С ее помощью мы будем решать довольно интересные задачи, например автоматически обсчитывать арматурные стержни плит, количество марок на отметках. Но всему свое время.

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

В следующей статье мы поговорим о единых стандартах бюро.

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

Главный конструктор ООО «ДАКК» (г.Днепропетровск, Украина). Активист Сообщества пользователей Autodesk (community.autodesk.ru).

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