Опыт использования BIM, Тут предлагаю делиться своим опытом Опции

[glam]

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

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

на что тогда сказали - да чё там, поменять свойства семейств под конкретный шаблон не сложно. видимо все же есть нюансы

Не сложно поменять свойства семейств под конкретный шаблон в единичных разовых эпизодических случаях когда какой-то корпоративный настроенный шаблон внутри одной компании остается без изменений, но если переезжать на рельсы глобализации, когда твои семейства должны будут стать совместимыми с шаблонами остальных участников отрасли хотя бы в параметрах описания (расчетные не беру, т.к. они, как правило, могут быть не общими параметрами, а конкретно локальными параметрами самого семейства), тогда для достижения этой благой цели надо будет пройти какой-то путь. Если перелопатить надо сразу какую-то глобальную библиотеку семейств, то выполнять перенос по одному элементу нерационально как с точки зрения трудозатрат, так и контроля выходного результата. Я где-то на просторах рунета скачал утилиту для пакетного добавления параметров семействам. Схема работы там очень простая: указываем входную папку для обработки, указываем выходную папку, указываем файл общих параметров, из которого будут добавляться новые параметры в обрабатываемые семейства, и из этого файла общих параметров выбираем те параметры, которые мы хотим добавить в обрабатываемые семейства, выбирая к каким категориям будут относиться выбранные параметры. Вроде бы всё замечательно, но если вдруг в обрабатываемых семействах уже есть параметры с таким же наименование (пусть и с другим GUID), то мастер обработки просто пропустит такие семейства, т.к. видимо в нём не настроена элементарная логика что в случае наличия в семействе параметра таким же наименованием, на которое происходит замена, старый параметр из семейства должен быть удалён.
На самом деле и это не является большой сложностью. Думаю тот кто написал эту утилиту, вполне сможет доработать её логику, добавив в нее новые опции как стоит вести себя мастеру пакетной обработки при совпадении наименований параметров. И опять же даже это не есть какая-то мегасложность. Основной задачей при переезде на какую-то общенациональную систему описания элементов проблему будет составлять не технический способ такого переезда, а человеческий фактор и четко прописанные регламенты процедуры переезда. Потому что как бы это странно не звучало может оказаться не такой то простой задачей донести до всех участников проектного процесса, что вот из той папочки со старой библиотекой семейств для новых проектов теперь брать элементы нельзя, а надо брать из новой, но при редактировании старых проектов или при продолжении работы над еще актуальными проектами надо брать элементы всё-таки из старой структуры, а не из новой. Ну и непременно чтобы не было бардака в организации обязательно должен быть какой-то ответственный библиотекарь (BIM-специалист), который будет отслеживать чтобы на период переезда обе структуры сосуществования элементов находились в актуальном состоянии, при этом не взаимопересекались, чтобы не возникало ненужных вопросов и эксцессов.

Сообщение отредактировал glam - 8.10.2016, 14:02

[glam]

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

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

на что тогда сказали - да чё там, поменять свойства семейств под конкретный шаблон не сложно. видимо все же есть нюансы

Не сложно поменять свойства семейств под конкретный шаблон в единичных разовых эпизодических случаях когда какой-то корпоративный настроенный шаблон внутри одной компании остается без изменений, но если переезжать на рельсы глобализации, когда твои семейства должны будут стать совместимыми с шаблонами остальных участников отрасли хотя бы в параметрах описания (расчетные не беру, т.к. они, как правило, могут быть не общими параметрами, а конкретно локальными параметрами самого семейства), тогда для достижения этой благой цели надо будет пройти какой-то путь. Если перелопатить надо сразу какую-то глобальную библиотеку семейств, то выполнять перенос по одному элементу нерационально как с точки зрения трудозатрат, так и контроля выходного результата. Я где-то на просторах рунета скачал утилиту для пакетного добавления параметров семействам. Схема работы там очень простая: указываем входную папку для обработки, указываем выходную папку, указываем файл общих параметров, из которого будут добавляться новые параметры в обрабатываемые семейства, и из этого файла общих параметров выбираем те параметры, которые мы хотим добавить в обрабатываемые семейства, выбирая к каким категориям будут относиться выбранные параметры. Вроде бы всё замечательно, но если вдруг в обрабатываемых семействах уже есть параметры с таким же наименование (пусть и с другим GUID), то мастер обработки просто пропустит такие семейства, т.к. видимо в нём не настроена элементарная логика что в случае наличия в семействе параметра таким же наименованием, на которое происходит замена, старый параметр из семейства должен быть удалён.
На самом деле и это не является большой сложностью. Думаю тот кто написал эту утилиту, вполне сможет доработать её логику, добавив в нее новые опции как стоит вести себя мастеру пакетной обработки при совпадении наименований параметров. И опять же даже это не есть какая-то мегасложность. Основной задачей при переезде на какую-то общенациональную систему описания элементов проблему будет составлять не технический способ такого переезда, а человеческий фактор и четко прописанные регламенты процедуры переезда. Потому что как бы это странно не звучало может оказаться не такой то простой задачей донести до всех участников проектного процесса, что вот из той папочки со старой библиотекой семейств для новых проектов теперь брать элементы нельзя, а надо брать из новой, но при редактировании старых проектов или при продолжении работы над еще актуальными проектами надо брать элементы всё-таки из старой структуры, а не из новой. Ну и непременно чтобы не было бардака в организации обязательно должен быть какой-то ответственный библиотекарь (BIM-специалист), который будет отслеживать чтобы на период переезда обе структуры сосуществования элементов находились в актуальном состоянии, при этом не взаимопересекались, чтобы не возникало ненужных вопросов и эксцессов.

Сообщение отредактировал glam - 8.10.2016, 14:02

[ssn]

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

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

[PWW]

Согласен на 100%. Новые обсуждаемые СПшки, как раз и развивают тему по наполнению модели от проектировщиков силами ПТО информацией о составляющим объекта для строительства.
.... Наверное, некорректно высказался

Подумаю, напишу.

[PWW]

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

Беда одна. а оно ему надо? Он же не сможет "угадать мелодию из..", которую слышал конкретный разработчик семейства под себя любимого.
Вижу так.
Есть глобальный параметр, который просто заполнен по умолчанию, но может брать значение ои параметра вложенного семейства или невложенного, от конкретного разработчика экземпляра.
Тогда и языковой барьер преодолим и глобальный параметр будет соответствовать шаблону.
В итоге - имеем семейство , мягко говоря наполовину пустое, или имеющее ограниченное количество параметров со значениями по умолчанию. Типа куб 1х1х1, с ets-ами , штук по 10.
Далее вкладываем семейство от производителя или "левши". Глобальные параметры берут сведения из вложенного по экземпляру. И тогда фиолетово, как "левша" обзовет свой параметр, если он не идентичен по наименованию с глобальным.
Если не прав, поправьте!
Забыл добавить. У нас новое семейство получится под конкретный проект, из семейства по типу, с глобальными параметрами, которое нам фиолетово как его в шаблоне обзывать будут, и наше, с неправильно обозванными параметрами. П по шаблонам, пусть разрабы СП голову ломают, как согласовывать.


Сообщение отредактировал PWW - 8.10.2016, 15:49

[Vano]

Коллеги, а как вообще сам Ревит без этих свистелок в виде супер пупер семейств?
Мы ж в строительстве работаем - часто бывает достаточно черный квадрат куб поставить, но вовремя сдать работоспособный проект.
Упрощают задачу черные квадраты - т.е Ревит рисовалка?

[ssn]

с черными квадратами там сложно ))) придётся создавать семейство черных квадратов. там все по честному. если есть квадрат - то круг из него на чертеже сделать не выйдет.

[Vano]

Ну может так и надо.
Вот сейчас в проекте у меня оборудование американское технологическое - судя по всему еще и производитель не знает его габариты до конца и куда надо подвести среды, знает только, какие среды и в каком объеме (потери напора тоже не знает).

[ssn]

концептуальное проектирование квадратиками это все же не про ревит ))))

[glam]

Упрощают задачу черные квадраты - т.е Ревит рисовалка?

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

[PWW]

Ну может так и надо.
Вот сейчас в проекте у меня оборудование американское технологическое - судя по всему еще и производитель не знает его габариты до конца и куда надо подвести среды, знает только, какие среды и в каком объеме (потери напора тоже не знает).

Потери напора не больше нормативных))), Это и америкос знает! Но можно все и квадратом, только метров по 3 запасу дать, во все стороны, или по 6, чтоб уж наверняка.

[silent]

Ну может так и надо.
Вот сейчас в проекте у меня оборудование американское технологическое - судя по всему еще и производитель не знает его габариты до конца и куда надо подвести среды, знает только, какие среды и в каком объеме (потери напора тоже не знает).

Можно на начальной стадии использовать квадрат, а затем по мере получения информации детализировать семейство в рамках текущего проекта и добавлять в него недостающую информацию (как информационную так и графическую), и если правильно все организовать, то даже не будет никаких проблем с присоединением коннекторов и принадлежностью к системам

[PWW]

Можно на начальной стадии использовать квадрат, а затем по мере получения информации детализировать семейство в рамках текущего проекта и добавлять в него недостающую информацию (как информационную так и графическую), и если правильно все организовать, то даже не будет никаких проблем с присоединением коннекторов и принадлежностью к системам

Все правильно. Вот только размеры первого квадрата какие брать? Сколько граммов вешать? И еще, чтоб сразу знать где что присоединяться будет, где зоны обслуживания и ремонта, проходы....
В технологическом, к сожалению, много чего требуется, что не сразу дается.

[Vano]

Ну в данном примере меня интересовали среды.
Остальное боль технологов.

[denik]

Коллеги, а как вообще сам Ревит без этих свистелок в виде супер пупер семейств?

Если в данную секунду нужен квадрат, то можно нарисовать обычными линиями, такой инструмент тоже есть, хотя техника работы от Автокада отличается. Если нужен куб, то можно создать объемный элемент прямо в проекте не переходя ни в какой редактор семейств. Но оптимальным все таки является создание семейств, пусть даже на начальном этапе это будет параллелепипед с тремя размерами и названием.

[PWW]

Если в данную секунду нужен квадрат, то можно нарисовать обычными линиями, такой инструмент тоже есть, хотя техника работы от Автокада отличается. Если нужен куб, то можно создать объемный элемент прямо в проекте не переходя ни в какой редактор семейств. Но оптимальным все таки является создание семейств, пусть даже на начальном этапе это будет параллелепипед с тремя размерами и названием.

Лучше тремя параллелепипедами с видимость. в разных проекциях. Так замороченней будет))) Правда куда ets-ы клеить???

[Шпилька]

Я тут выгляну из Зазеркалья по поводу опыта использования БИМ.

На прошлогоднем Аутодеске мне больше всего понравились выступления Айбима и Проектного Портала. У Айбима все хорошо, а вот с Проектным Порталом - не очень... Там и большая задержка по зарплате, да и говорят, бимлидеры покинули их стены. Насчет Романа Митина - не знаю, но, говорят, многие ушли...
Лично по моему мониторингу, фирмы, которые занимаются только проектированием на платформе БИМа долго не выдерживают...

Сообщение отредактировал Шпилька - 13.10.2016, 22:59

[Vano]

Вот вот и меня терзали смутные сомнения.
Слышал, что лидеры перешли в другое место............
Но думаю этот процесс вечен.
Типа Маск со своей ракетой.

[PWW]

Я тут выгляну из Зазеркалья по поводу опыта использования БИМ.и...
Лично по моему мониторингу, фирмы, которые занимаются только проектированием на платформе БИМа долго не выдерживают...

Есть такая тенденция. Будучи директором проектного бюро, длительно пытался объяснить персоналу, что их высокие зарплаты, только за счет того, что фирма занимается и строительством, а руководителю всегда было удобней напрячь проектировщиков своих, в части оперативного внесения корректировок в РД, чем это же осуществлять со сторонними организациями.
С учетом того, что ВIM не увеличивает скорость проектирования, но позволяет значительно увеличить качество, малым фирмам его не осилить. И так будет до тех пор, кока не наступит понимание, что за качество надо платить.
Деньги для этого уже в стоимость заложены. Это те 2% непредвиденных от стоимости всего!!!. Качество уменьшит сроки строительства, переделки, устранение коллизий и пр., что снизит построечные затраты. И если в ценниках сейчас уже заложен коэфф. 1,7 на увеличение стоимости при построении 3D модели, то это еще не значит, что он учитываются при ценообразовании за проект.
Пока будет демпинг цен на проектные и выбор будет зависеть от минимальной цены, Максы с ракетами будут вынуждены бегать.
Как не крути, но принцип проектирования быстро, качественно, недорого осуществим только при соблюдении 2-х из указанных условий.

[Виталик]

Согласен с директором проектного бюро. Все решают цены и сроки. В данный момент мы занимаемся преимущественно небольшими объектами (да что там говорить, даже большими!) и делаем их на платформе AutoCAD+MagiCAD. ("Мы"-группа проектировщиков-смежников под руководством проектировщика-ГИПа). При коротких сроках удается делать работу качественно. Когда все специалисты работают в MagiCAD, очень хорошо удается избежать коллизий. По сути, тот же BIM, но лишенный автоматизма. А переход на полноценный BIM нужен, как и нужно понимание Заказчика про цену и качество.

[PWW]

Тема умерла? Всё так плохо, что не хочется об этом вспоминать,или так хорошо, что не хочется спугнуть?

[экспорт]

? может быть всё засекретили ?

Прикрепленные файлы

 BIM_TS.jpg ( 45,07 килобайт ) Кол-во скачиваний: 6

 

[cpt]

Всё хорошо, кому нужен бим те делают в биме кто не хочет учить новое работают по старому.

[Vano]

А кому он нужен?
Ну сферы применения?
Интересно же.
Можете пояснить.

[экспорт]

сообщение 502 в микроскоп:

с БИМ "делают"
без БИМ "работают"

предполагаю: в БИМ переделывают
что другие наработали без БИМ

[Composter]

Тема умерла? Всё так плохо, что не хочется об этом вспоминать,или так хорошо, что не хочется спугнуть?

ну все кто сталкивался уже высказались, нужно по второму кругу?

[cpt]

Vano, заказчикам, они почему-то платят деньги за этот BIM, а за чертежи от руки на ватмане не платят, странные люди.

[MC2007]

Действительно, законодательная инициатива, по моему, заглохла. Сначала первую редакцию стандарта завернули, затем и про вторую говорить перестали...
Но, по моим наблюдениям, основная проблема заключается именно в непонимании зачем вообще нужен этот BIM. Да и те, кто внедряет, далеко не всегда представляет где потом использовать данные из модели. По сути, кроме поиска коллизий ничего особенного у нас предложить не могут.
Нужно понимать, что данные заложенные в BIM модель в первую очередь могут быть нужны при строительстве и эксплуатации. Если, например, 1 год проектируют, 3 года строят, 80 лет используют - где нужно искать эффект? Пока не все готовы признать, что проектирование с созданием BIM-модели дороже, чем "традиционное", а окупаемость наступает на других этапах.

[ssn]

Vano, заказчикам, они почему-то платят деньги за этот BIM, а за чертежи от руки на ватмане не платят, странные люди.

я вас уверяю, Vano, как раз таки, как ГИП вполне себе понимает... что платят не за модель, а за чертежи на бумаге
в чем выполнены эти чертежи и как вообще не интересно никому. лишь бы ошибок не было и пересечений. а как это достигнуто - вообще пофиг.
модель модель... а кому конкретно из заказчиков она нужна и что он дальше с ней будет делать?
на мой взгляд, единственно зачем это надо на данный момент - это визуально удостовериться, что конструкции не встретятся на площадке друг с другом, т.е. просто проверить проектировщика на ошибки. это основной функционал, который накладывает заказчик на модель. меня часто спрашивает заказчик - давай делать чертежи без модели, мне модель не нужна, и соответственно просит дешевле... типа меньше трудозатрат. т.е. он не понимает, что изначально модель, а уже с неё автоматом чертежи и спецификации. и это я думаю не единичный случай.

[Composter]

MC2007, ну у нас основная проблема что строят одни а экплуатируют другие, застройщику главное сдать объект ,а дальше хоть трава не расти...

а на счет заказчиков и BIM, уже несколько раз было что нам нужен проект в BIM, а потом сделайте нам пдф нафиг нам ваша BIM-модель.

[PWW]

... Если, например, 1 год проектируют, 3 года строят, 80 лет используют - где нужно искать эффект? Пока не все готовы признать, что проектирование с созданием BIM-модели дороже, чем "традиционное", а окупаемость наступает на других этапах.

Срок службы инженерных систем колеблется в пределах 25-30 лет. А за 80 столько реноваций придумают, что от задуманного давно усопшим коллективом инженеров, мало что останется.
Может к такому времени и электроэнергию начнут передавать воздушно-капельным путем ;-)

... а на счет заказчиков и BIM, уже несколько раз было что нам нужен проект в BIM, а потом сделайте нам пдф нафиг нам ваша BIM-модель.

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

Сообщение отредактировал PWW - 11.5.2017, 12:51