Первое в мире ПЕЧНОЕ и СТРОИТЕЛЬНОЕ мобильное |
Генетический код строительного объекта
Сметный суперотдел, Эйнштейн и веяние времени
В начале восьмидесятых я был старшеклассником в Белгородской школе. Моя мама, Валентина Михайловна Захарченко, руководила сметно-договорным отделом в конструкторском бюро. Маму ценили как работника, потому что она лучше всех ориентировалась в многочисленных томах СНиПов, допусков, уточнений, рекомендаций, постановлений, приложений, нормативных актах и в прочих толстых фолиантах из которых она могла взять искомую цифру и поставить ее в составляемый документ. Кажется, что это была адская работа. Такая рутина, на мой взгляд, убивает творчество и самостоятельное мышление. Мне было немного жалко этот суперотдел, который рассчитывал сметы для разных строительных объектов, я говорил, мол, всех вас может заменить один программист, если вы ему ваши тома оцифруете в базу.
Странно, но даже в те давние дни возможности компьютерных технологий не ставились под сомнение. Это казалось очевидным, пусть компьютеризация и представлялась делом если не фантастическим, то зачаточным и туманным, пусть еще не было ноутбуков, планшетов и сотовых телефонов, не было интернета и социальных сетей. Однажды нас, школьников, водили экскурсией показывать Электронно-Вычислительную Машину. То был, по старым меркам, кажется, небольшой компьютер, портативный вариант, так сказать. Занимал он пространство актового зала на 2-3 этажа. Мы стояли внизу у основания этой машины, благоговейно соприкасаясь с большой Наукой, одетой в лампочки и обмотанной проводами, а откуда-то сверху по винтовой железной лестнице спускался счастливый оператор ЭВМ, размахивая свитком. Чтобы впечатлить нас школьников, он уговорил этот агрегат нарисовать для нас портрет Эйнштейна на широкой рулонной бумаге, продырявленной с боков. Работа была выполнена одинаковыми блекло серыми крестиками в полсантиметра размером, и издалека, при некоторых допущениях, шедевр действительно напоминал лицо известного физика. Малютка постаралась! Возможно, это еще и не все, что она умела делать, но я того достоверно не знаю. Мне показалось, что, оператор был впечатлен больше экскурсантов. Смешно...Но не в тот момент.
Однако, и тогда время было неудержимо как сегодня, а воздух наполнен запахами будущих технологий. Прагматичная лень, помноженная расчетливостью, раскручивает маховик автоматизации – колесо желаний потратить меньше, получить больше и лучше. Уже нет моей мамы и ее «суперотдела», наверняка нет той ЭВМ и прошитого крестиками портрета Эйнштейна, но есть воспоминания и образы прошлого как отправная точка настоящего
Автоматизация
То, что я сделал в своей программной разработке, о которой хочу здесь рассказать – это продукт времени, и эту простую работу все равно кто-нибудь бы сделал. Идея автоматизации процесса проектирования появилась после того, как я к тому времени десяток лет провел, занимаясь печной кладкой и проектированием печей. Разные заказы на проектирование поступали мне и зачастую проекты были очень схожими. Это наводило меня на мысль о том, что я повторяюсь и делаю работу конвейера-, обидно.
Тогда мне захотелось упростить процесс проектирования и уйти от рутины, мое образование это позволяло. Приступил. Вначале я научил программу создавать виртуальные кирпичи и укладывать их в простую кладку по контуру и со сплошным заполнением.
При этом кирпич может быть любого размера и любой из шести возможных ориентаций с любым размером шва.
.jpg)
Другими словами, это может быть и совсем не кирпич, а блок, брус, панель и т.д. что угодно. Для достижения этого результата понадобилась совсем немногое. Создается один кирпич как объект в пространстве с переменными координатами и далее в программном цикле перебираются вычисленные координаты для данного контура, на которые кирпич тиражируется.
Далее мне показалось самым разумным задавать программе такие параметры, какие интересуют в первую очередь проектировщика, если б им был я, то есть: задать программе внешние контуры, по которым вести кладку, слои, которые бы определяли высоту того или иного контура и научить вырезать проемы под дверки в нужном слое. Воплощение этих идей выросло в небольшой и простой пользовательский интерфейс.
Оставалось приложить к программе расчет размера печи и топливника, выбор симметрии топки и конвективной системы, способы подачи воздуха, конструкции пода и некоторые другие кнопочки, чтобы первая программа увидела свет. Она тогда называлась «Печепостроитель».
Программа была выполнена модулями, которые предполагалось дописывать отдельно. Каждый модуль заключал с себе сотни и тысячи разных проектов, объединённых одной концепцией. Вначале появился модуль для проектирования отопительных печей, прямоугольной формы. Пользователь закладывал в программу свои данные по утепленности помещения, ориентации печи, желательной форме и симметрии, размерам кирпича и шва, конструкции топки (вихревые топки тоже были представлены), конструкции пода, наличию колосника, бака для воды и т.д. и получал соответствующий этим заложенным данным, проект.
Особой проработки потребовала идея расчета теплообмена слету в пользовательском режиме. Дело в том, что готовых физических формул здесь не было и инженеры для расчетов теплопотерь пользовались таблицами. Для каждого отдельного случая утепленности есть свои табличные значения теплопотерь, зависимые от размеров помещения. Это все дискретные (не непрерывные) величины. Кроме того, таблицы к калькулятору не пришьешь, нужна формула. Итак, есть в наличии дискретные величины утепленности для которых существуют дискретные зависимости теплопотерь от площади помещения. Требуется связать непрерывной функцией теплопотери помещения, его площадь и утепленность. Задачу эту решил, использовав аппроксимацию и разложение в ряды Тейлора. Готовая, работающая формула в приближении до 6 степени включительно такова:
Данную формулу удобнее использовать для прямых расчетов теплопотерь, чем таблицы, так как она достаточно точна и дает непрерывный спектр значений, а для автоматизированных расчетов это и совсем единственный способ. Она связывает теплопотери помещения, его площадь и утепленность в единую зависимость. Сегодня можно воспользоваться данной формулой напрямую в разделе «калькулятор печника» обсуждаемого сервиса stoveweb.com
Итоговые результаты работы первой версии данной программы можно было получить в виде нескольких форматов: рисунка с порядовкой и расходом материалов или книги, слайд-фильма, текстового файла комплектации или книги pdf с нарезкой кирпича.
По одному из замыслов, создавался файл комплектации с привязкой по ценам к конкретному магазину – пользователь сам мог решить к какому. Но для этого требовалось иметь авто обновляемые каталоги из заинтересованных магазинов, написанных по одному образцу. Это оказалось не так просто, потому что каталоги мало, что постоянно обновляются, но и составлены не для автоматической обработки. Да, может и не было в том большой заинтересованности магазинов. Потенциал здесь имеется, а констатация факта такова: на данный момент идея с комплектацией провалилась. Однако, главная цель совсем другая.
Следующий модуль появился для проектирования отопительно-варочных плит с щитками, где был заложен все тот же функционал, что и в прежнем модуле. В этом модуле прорабатывались всевозможные размеры и положения плиты, щитка, дверок, духовок и трубы.
В этом виде программа была опубликована к моменту, когда ее возможности я демонстрировал на Колеватовских чтениях в 2011 году, куда меня пригласили с докладом уважаемые коллеги печники из Санкт-Петербурга.
3d-графика
Для универсальности программы не хватало еще одного: нужно было сделать выход на трехмерную графику, чтоб выходной формат предполагал прорисовку проекта в какой-нибудь программе трехмерного моделирования с целью вписывания объекта в интерьер, проработки дизайна, визуализации и выполнения прочих современных фокусов. Выбор пал на программу SketchUp, которая интенсивно развивалась и является, на мой взгляд, самой простой и функциональной в этой сфере сегодня. Я дописал к программе SketchUp расширение, которое бы распознавало файлы, подготовленные обсуждаемым сервисом, и отстраивала бы трехмерную модель. Это небольшое расширение на 3КБ сейчас доступно всем желающим на официальном сайте SketchUp, оно так и называется «объекты от (Objects from) stoveweb.com».
Связка эта действует следующим образом: серверная программа ДНКП отстраивает виртуально модель, соответственно заданным контурам, слоям и пр., одновременно записывая координаты углов каждого кладочного элемента и его цвет в отдельный текстовый файл. В этом текстовом файле в итоге присутствует столько объектов, сколько их есть в данном проекте, пусть даже не одна тысяча. Далее этот текстовый файл открываем описываемым расширением Objects from stoveweb.com программы SketchUp, которое и воссоздает трехмерный образ каждого объекта (кирпича, термоизолятора, задвижки, варочного настила) как отдельную группу со своим идентификатором ряда, что впоследствии позволяет работать с полученной моделью по рядам, если это необходимо
Потолок развития Печепостроителя
Дальнейшее развитие программы предполагало постепенное добавление все новых и новых модулей разных объектов из кирпича и не только (!) от общераспространенных до самых экзотических. То есть к уже созданному модулю отопительных печей, модулю отопительно-варочных печей, предполагалось добавление бесконечного ряда других отопительных, варочных, садовых печей, каминов, барбекю, комбинированных печей, даже беседок или домов в разных концепциях и видениях, в разных сочетаниях и последовательностях форм и объемов.
И это неплохо, с одной стороны. А с другой стороны, даже если все эти бесконечные модули разместить в одной программе, останется ограничение для пользователя: меняется только размер, симметрия, расположение дверок и немногое другое, но все же пользователь ограничен моим видением объекта (как разработчика модуля), которое не изменить пользователю, а оно может отличаться. И еще одно меня останавливало: я опять попадаю в бесконечный конвейер новых модулей, по сути, в чем-то похожих друг на друга и обрекаю себя в пожизненное рабство своей программы (а кто бы еще кроме меня писал эти модули?). Я пытался уйти от одной рутины, а пришел к другой.
Кроме того, я увидел, что несмотря на весь этот обширный потенциал, которым обладала программа, большинство печных комплексов, что мне заказывали для проектирования, приходилось прорабатывать вручную. Простых комплексов, которые уже могла бы собрать программа, мне попросту не заказывали, что и понятно. А писать для каждого нового случая программный модуль просто смешно, быстрее сделать по-старинке, тем более что в следующий раз проект с такой же концепцией редко повторялся в моей практике. Вот и выходило, что я создавал программу автоматического проектирования печей, но на практике, чаще всего, делал проекты вручную. Тогда зачем нужна такая программа? Мне нужен был этот инструмент, в первую очередь, как помощник. А тут одна обуза. Требовался другой путь. Нужно чтобы пользователь мог сам легко и быстро создавать любой модуль самостоятельно слету или мог воспользоваться уже готовым и корректировать его.
Я оставил поддержку «Печепостроителя», как программы готовых модулей в пользу новой идеи, реализованной в полном объеме в ДНКП, где модули шаблоны создаются слету самим пользователем.
Ген строительного объекта - ДНКП
В живых организмах носителями наследственной информации являются молекулы ДНК. ДНК имеет в себе базы данных и программы развития организма на всех стадиях жизни, так называемый, генетический код. Небольшие отличия в ДНК определяют отличия в многочисленных видах и подвидах живых существ и обеспечивают разнообразием черт каждого отдельного индивида. Но и велика в этом случае цена ошибки в ДНК – клетка с нарушенным ДНК мутирует и может оказаться нежизнеспособной.
Как программный код ДНК отвечает за развитие живой клетки, таким же образом, можно задать программный код, содержащий всю информацию о строительном неживом объекте. Программный код математически точно может определить расположение и форму каждого строительного элемента внутри этого объекта.
В «Печепостроителе» эта идея уже была воплощена, но с небольшими «но»: непростой код был спрятан внутри программы, и пользователь не имел к нему доступа. Я стал оптимизировать этот код, упрощать его. В итоге, код готового строительного модуля стал довольно компактным и занимал всего несколько строк текстового файла 1-2 КБ. Я стал называть его ДНКП – Динамично Направляемый Код Печи или шаблон. Небольшие изменения кода вызывают значительные изменения всего объекта. Один добавленный или убавленный штрих кода превращает объект в другую форму, других размеров, другого сочетания объемов. Однако, ошибка в коде приводит к катастрофическим последствиям. Очень похоже на код ДНК в этом, не так ли? Как возможно написать такой код?
Вот простой пример программной команды, понятной человеку:
Начиная от заданной точки в выделенном направлении на расстоянии 10 мм друг от друга выложить 1000 кирпичей размером 120х250х65 в прямую линию на заданной отметке высот и ориентации плашмя-ложкой.
Это задание - программа действий, которую должен однозначно понять любой каменщик, если все слова стоят на своем месте. Но стоит убрать что-нибудь в задании, результат может быть обескураживающим. Попробуйте убрать фразу «в выделенном направлении» или «плашмя-ложкой», можно ведь налепить кладку и на север, и на запад, и поставить тычком на ребро или на «попа» волнистой прерывистой линией, влево-вправо, вверх-вниз. Хотя в программе не говорится конкретно, где должен оказаться в итоге, скажем, 238-ой кирпич, но положение и его все же точно известно, как и положение всех остальных кирпичей. Это положение заранее определено заданием с точностью кладки и точностью геометрии кладочного материала. Другими словами, хотя в задании не упоминается непосредственно каждый кирпич, это не мешает правильно уложить его в кладку.
Есть небольшая проблема. Человек эту программу поймет если, конечно, знает русский язык и знаком с печными понятиями. А для машины нужно говорить на ее языке, без разночтений и неопределенности. Нужно быть совершенно уверенным, что программа поймет задание однозначно, то есть нужен компактный интерпретатор-посредник. Этот интерпретатор должен с одной стороны легко читаться-писаться человеком и, с другой стороны, его слету должна понимать машина. Созданием такого интерпретатора, который был бы интуитивно понятен любому пользователю и следовало заняться.
Интерпретатор
Он здесьВо-первых, нужно создать объект, который будет использоваться программой. То есть должен быть отдельный параграф для описания материала, с которым работать. Назовем его «кирпичи».
В этом параграфе пользователь сам решает каким будет этот материал. Каждый новый вид материала следует описать в новой строке. Если один материал идет на строительство разных непересекающихся корпусов, то лучше создать отдельный материал с отдельным корпусом.
Далее определяем контуры объекта, которые будут использоваться при проектировании. Следующий параграф «контуры» это и делает. Он привязывает контур с конкретным именем к конкретной точке и соответствующему размеру.
Обычно таких контуров не один, а много и их всех следует определить. Но опять есть «но». Лучше, если все последующие контуры будут привязаны к первому, «базовому» и по размеру, и по начальной точке. Это нужно для того, чтобы виртуальный объект легко можно было сместить в любую точку, перемещая только один контур, а также изменить размер всего объекта, поменяв лишь размер одного базового контура.
В случае, если потребуется сместить объект или изменить его размер, достаточно поработать только со строчкой параграфа, где описывается базовый контур, а остальные строки не меняются, если не меняется концепция.
Можно задавать контуры и другим способом, используя гомотетию путем сжимания разжимания любого из уже заданных контуров, при этом достаточно указать сжимаемый контур и указать через запятую размеры, на которые следует его растянуть. Данный способ универсален для любых преобразований контуров: гомотетией можно получить любой прямоугольный контур в любом месте из любого уже существующего. Например, запись 25,25,25,25 будет означать, что контур будет выступать от базового контура на 25 мм во все стороны
Следующий параграф, «слои», отвечает у нас за высоту того или иного контура и способ заполнения этого контура. Способ заполнения контура определит, каким образом данный контур используется в кладке: сплошным заполнением, заполнением по периметру или заполнением каких-то сторон отдельно, а возможно это будет угловой контур или круговой, или полу арочный, вписанный в изначально заданный прямоугольный контур. Возможно, это будет несколько контуров, сложенных вместе, прорез в сплошном слое, вихревой канал, выпускное хайло и т.д. – все эти и другие особенности кладки данного слоя описываются здесь, так же, как и способ использования материала кладки (ориентация кирпича)
Последний параграф интерпретатора определяет положение вырезов и дверок в слое
Интерпретатор не сложно дополнять новыми элементами, удобными пользователю. Дальше требуется данные из интерпретатора расшифровать программой и, произведя алгоритмы, заложенные пользователем в данном коде выполнить виртуальную кладку слой за слоем.
Виртуальная кладка
Виртуальная кладка обычного прямоугольного контура была уже оцифрована в «Печепостроителе», и эта часть программы просто перекочевала в ДНКП. Интересны случаи посложнее с необычной, малораспространенной или нестандартной кладкой. Например, возьмем случай многокорпусной кладки, когда несколько контуров требуется объединить в один с учетом перевязок по углам. Кажется, это просто объяснить строителю, обрисовав внешний контур и проинструктировав о том, какой должна быть перевязка с учетом всех углов и четности ряда. Но как это объяснить программе, чтоб это было выражено математически точно, ведь количество поворотов, а с ними и количество контуров может быть сколь угодно большим?
Расскажу способ, который был применен мной. Во-первых, рассматривается два произвольных контура и рассчитываются возможные случаи пересечения в общем виде для слоя кладочных элементов. Создается функция, которая объединяет произвольные два контура в один непрерывный контур с заданным кладочным элементом и «хорошей» перевязкой углов. После этого применяя рекурсивное повторение этой функции в цикле для всех заданных контуров, получим требуемый результат.
Случаи с угловыми контурами требовали определения дополнительных параметров, например, размер плеча для регулировки длины угловой стороны. Кроме этого, для реализации этого случая был создан угловой кладочный элемент, который позволяет осуществлять кладку с наилучшей перевязкой на угле в 135 градусов.
Аналогично для кругового или арочного контура рассчитываются свои оптимальные размеры кладочного элемента и пространственные координаты
Подведем черту
Перед разговором о перспективах программы, нужно подвести черту под итогами работы на данный момент. Что сегодня делает программа Вебконструктор ДНКП?
1. ДНКП виртуально воспроизводит все распространенные элементы кладки с прямоугольной перевязкой, угловыми, круговыми и арочными контурами, производит сложение контуров и их вычитание, применяет разнообразные нестандартные способы заполнения контуров и легко позволяет задавать новые способы заполнения контура кладкой при необходимости
2. Программа позволяет создавать не просто готовые проекты строительных объектов, но целые их семейства, которые легко модифицируются базовыми параметрами модуля-шаблона. Результатом этого является мгновенное создание высокотехнологичных проектов из готовых модулей, в которых учтены все мельчайшие детали. А если такого модуля не существует, то программа позволяет спроектировать такой модуль и легко редактировать его на любом этапе работы. Однажды спроектированный модульным образом строительный объект больше никогда не придется проектировать повторно: для аналогичных случаев достаточно внести корректировки в базовые параметры шаблона. Как следствие, процесс проектирования в ДНКП значительно упрощается для новых объектов, а для схожих с готовыми модулями объектов и вовсе сводится к простым изменениям базовых параметров.
3. ДНКП полностью оцифровывает строительный объект: программа каждому элементу кладки соотносит свои пространственные координаты углов. Эту информацию легко применить в виртуальной кладке программами трехмерного моделирования или использовать в реальной кладке при помощи 3d-укладчиков или 3d-принтеров. Можно сказать так: если завтра появится некий автомат-робот, который может уложить заданный элемент кладки в нужную точку пространства, то этот робот сможет построить и весь объект, следуя программе ДНКП
4. ДНКП создает «генетический код» семейства строительных объектов в виде очень компактного файла в 2КБ, что значительно упрощает классификацию этих объектов и последующий доступ к технической документации любого «оцифрованного» объекта – программа по короткому коду воссоздает сложный объект «слету». ДНКП является готовым емким хранилищем-базой для сохранения в электронном виде проектов строительных объектов.
Мне много приходится проектировать печных комплексов каждый год, и самому производить кладку разных печных комплексов ежегодно и по сей день. Для меня программа ДНКП незаменима и всегда является отправной точкой моделирования, даже если я и не собираюсь создавать шаблон объекта со всеми подробностями. Созданный в ДНКП объект я далее открываю в программе трехмерного моделирования SketchUp для визуализации и, при необходимости вношу послойные (по рядам) корректировки, хотя для тщательно сделанных шаблонов, корректировки не требуются. ДНКП мне экономит значительно время и упрощает на порядок работу, которая, к тому же, оказывается выполнена максимально точно. Для любого профессионала проектировщика это должно быть таким же хорошим подспорьем в работе, как и для меня. Объективно предполагаю, что будущее за этой программой, так как уверен, что любой человек, освоивший азы ДНКП, не захочет возвращаться к «ручному» проектированию.
Мое видение дальнейшего развития ДНКП:
Конкретное дальнейшее развитие программы ДНКП и приближение ее к массовому потребителю прежде всего зависит от отклика самих пользователей. Они могут помочь сформировать видение того, каким этот сервис должен быть завтра, чтоб он был максимально понятен и максимально полезен. Я со своей стороны готов внимательно изучать любые предложения и воплощать их в жизнь для общей пользы.
Программа ДНКП очень проста в использовании, но начальный момент обучения проектированию в ДНКП требует небольших усилий. Особенно это касается тех, кто привык работать старыми методами. Тем не менее, есть пользователи разных возрастных категорий, которые тщательно исследуют возможности программы, задают вопросы и находятся со мной в контакте – спасибо этим пользователям, благодаря такому отклику программа живет сегодня. Для молодежи процесс обучения проще и быстрее. Предполагаю, что вскоре должно вырасти поколение проектировщиков и печников, которые будут пользоваться исключительно программой ДНКП и подобными. Хорошо бы проводить тренинги для таких желающих. Также предполагаю, что развитие робототехники приведет к еще большей востребованности ДНКП. Ну и к вопросу о классификации и единой проектной базе по строительным объектам – ДНКП уже сегодня является готовым емким хранилищем, которое легко можно сориентировать для подобных нужд.
Назад
все материалы сайта являются авторскими, при перепечатке ссылка
на первоисточник http://stoveweb.com/ обязательна . С ув. Андрей Захарченко
+79210187073 ,
berejki@gmail.com
навигация поиском
+79210187073 , berejki@gmail.com