Информационный портал для профессионалов в области САПР
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Форумы CADUser → Autodesk → AutoCAD → Совместная работа над проектом
И впрямь, никто на производстве не работает?
Только пальцами по клавишам?..
Кто и как, по его мнению, правильно, построил на своем предприятии ПРОЦЕСС проектирования?
Есть Добрые Люди, которые могут поделиться опытом?
> Бестолковый
При такой конкретной постановке нет ни чего проще.
> Valery Brelovsky
Благодарю!
Более развернутого и подробного ответа я и не ожидал увидеть!
Главное так все доходчиво объяснено!
((
))
> Бестолковый
Отвечаю конкретно: "AutoCAD не предоставляет возможности совместной работы над проектом".
Ищи другие программы.
Не знаю, мы веники не вяжем, честно сознаюсь. Стыдно мне:-( Неужели бывают такие веники?
Показать свой результат никто не может, т.к. его, просто-напросто НЕЕЕТ!
Спасибо всем!
Извините, не туда зашел.
> эйбиси
Кстати, а ПОДШИВКА для чего?
Ну, да ладно...
> Бестолковый
ПОДШИВКА не проходит.
Ребята, мы же хотим найти решение в до боли знакомом всем Автокаде!
Кто может поделиться опытом (можно и отрицательным) организации выпуска/создания проекта с применением внешних ссылок.
Пряники, бананы и т.д. не предлагать.
> Бестолковый
Взаимоувязку отделов можно организовать Диспетчеризацией. Смотрел прогу Spider http://www.spiderproject.com.ua/ Честно скажу, понравилось.
> Alan
Нет решения. AutoCAD- это векторный редактор в основном для того что бы чертежи чертежить. А не для того что бы организовывать совместную работу с кем- то или над чем- то. Не более того.
> эйбиси
Нет решения какого? Векторный редактор AutoCAD это одно из средств проектирования. Я не обольщаюсь ПОДШИВКАми, я думаю всё-таки о Системе Документооборота, для обращения документов.
Но! Для проектирования "что бы чертежи чертежить", не ОДНОВРЕМЕННО, но ВМЕСТЕ! чтоб не примененить чё-нибудь, например, внешние ссылки?
> Alan
Были какие- то решения у "Autodesk". И программы сторонних разработчиков были. Я все это периодически ставил до 2000 года. Потом все это хозяйство умирало само собой. И оставался Windows - Total Commander. Производственная жизнь несется вперед. 80% проектов вообще не добиралось изготовления. Такие дела :(
Можно организовать так - этот сборный коллектив, который не может всем работу найти - разогнать.
Сделать из каждого отдела ( а почему ВК просто, а электрик "главный"?)независимые небольшие фирмы во главе с "толковыми" специалистами по данному направлению. Работу организовать на субподряде.
Должность человека ,задавшего этот непонятный вопрос - ликвидировать.
> PL
Примите мою искренюю поддержку :)
<PL (2006-02-10 17:03:37)
Да Вы правы. Если до этого времени не дошло то уже вряд ли дойдёт.
неловко попытаюсь
у меня все архитекторы
попытки приучить работать с ксрефами провалилась
удобство всеми признано - бархтаешься в собственных слоях время от времени поглядываешь на то, что натворили коллеги, что б соотнести с ними свои дальнейшие действия.
но реальность существенно расходится с действительностью.
на практике каждый втащил себе в файл файлы коллег блоками и барахтался с копией давно неактуальной информации. дурацких копий понаделали ошеломляющее количество.
небольшое расследование привело к наблюдению, что открытый ксреф неудобен в работе поскольку он всё время собака меняется. только привыкнешь к какому-то одному его состоянию, как там уже фсё по-другому. только настроешь себе набор отображаемых слоев с информацией, которая лично тебя интересует (не копаться же тебе в слоях с кучей чьих-то глубоко личных сомнений), как там уже с полсотни новых слоев с новым барахлом которое тебя совсем не интересует. и всё это лезет к тебе на монтажный стол, заслоняет собой твою личную работу.
удобством было бы включать только те слои которые тебя интересуют. я имею ввиду так же и вновь образуемые слои в ксрефленном файле.
думаю для совместной работы нужна совсем другая структура рабочей информации. имеется ввиду параллельное наблюдение - необходимость предоставление рабочей группе возможность ознакомиться с тем что делаешь ты. предлагаемая структура с оверлейнутыми и приаттаченными файлами образует из структуры проекта несносную бредятину. постоянная борьба с закольцовыванием ксрефных ссылок, бесконечные расследования у кого открыт тот или иной файл, чтобы иметь возможность внести в него изменения. в конечном итоге структура файлов проекта находится не в компьютере и не в программе, а в голове у проектировщиков. а она должна быть занята не структурой ссылок на файлы, а структурой проекта. поэтому её в голову никто и не берет - легче скопировать себе полпроекта, и с ним работать.
может быть надо позаимствовать принцып у гис-систем. новый слой - новый файл. хочешь - ксрефь, хочешь - нет.
то есть оболочка проекта = оболочка программы, а слои информации = набор файлов, но изнутри программы(проекта) это не чувствительно - имеешь дело только со "слоями информации".
либо оболочка проекта = файл, а слои информации = слои в файле. но тогда уже всех нужно пускать в этот файл одновременно и там копаться в слоях да еще так, что б для каждого они отображались по-своему.
в любом случае практика показывает, что с набором слоев люди с трудом, но работают, а когда человека ситуация вынуждает держать в голове и структуру слоев и структуру файлов, он начинает на всё чихать и примитивными и доступными средствами избавляет себя от лишних заморочек.
и здесь я полностью на их стороне. через более чем тридцать лет после старта идеи автоматизирования проектирования, проектировщики кроме того чтобы быть частью проекта (не знаю как в остальных отраслях, а в архитектуре внутридисциплинарных заморочек более чем достаточно) вынуждены быть частью компьютера, частью операционной системы, частью программы, частью файловой структуры - не слишком ли?
про бритву оккама слыхали? так вот в сапрах ситуация, когда сложность (структурная) решения превосходит (иной раз и многократно) сложность самой задачи - обычное дело.
так вот если в индивудуальной борьбе с эти как-то вынужденно, но свыклись, то попытка выстроить машинку для коллективной борьбы с проектной ситуацией (вроде бы все возможности и все предпосылки наличествуют) приводит к усложнению структуры решения на несколько порядков. вот поэтому работники этого всего и избегают. ни кнут ни пряник им не указ.
> menhir
Огромное спасибо за опубликованную информацию!
Наконец-то появилось сообщение с какой-то информационной начинкой, а не пессимистические заявления. Отрицательный результат - тоже результат.
Хотелось бы только спросить, menhir :
1.Вы пробовали обуздать вакханалию архитекторов (свободных художников!) с создание новых слоёв и примитивов каким-то соглашением (типа СТП) или учебой их одинаковым приёмам работы?
2.Пробовали ли работу не с динамически изменяемой (т.е. находящейся в работе) внешней ссылкой, а с заменой её по сигналу (заданию) ГИП-ГАПа?
А мы (проектная строительная фирма 50 чел.) работаем с разными архитекторами. И , естественно, указывать им какие слои применять не можем, у них у всех свои системы, и они разные.Но какое отношение к применению хрефоф ето имеет?
Хрефы мы постоянно применяем, все арх. планы сидят как хреф. Ну конечно не в "динамическом" режиме. Это ни к чему.
Обновление происходит в зависимости от расписания работы над проектом. Например мне известно что 22 февраля надо выдать чертежи на стадии 80%DD (design development). Мне известно что на мою работу на этой стадии мне нужно 2 дня (плюс-минус). Архитектурнуе планы и т.д. я возьму с ftp site архитектора утром 20 февраля, и ни часом раньше.
22 февраля вечером архитектор получает мои чертежи, а моя работа над этим проектом прекращается. Следующая стадия
100%DD по расписанию 6 марта, мне нужно 3 дня, т.е. я зайду за новыми арх. планами утром 3 марта. и т.д.
1.начали с целого пакета соглашений.
- слой 0 держать чистым. то есть он используется как монтажный слой в котором происходит текущая работа, но в какой-то момент все, что натворил, перемещается в специально созданый поименованный слой, и там происходит окончательная доводка. никаких ошметков в 0 в итоговом файле!
- новые блоки, группы, стили текста и размеров создаются в слое 0, затем переносятся в специально созданые слои.
- все ксрефы создаются в специальном слое $XR, допускается создание группы слоев с префиксом $XR*для набора ксрефов (удобно оперативно включать/отключать при работе)
- то же касается подгруженных картинок - $IMG
- введен специальный слой $UTIL
- ну и дальше сложноструктурированное соглашение об именовании слоев со всякими суффиксами, префиксами и развитой системой синтаксиса
- за именование слоев типа "Катя" "маша 1" "красный" и т.п. кара страшная - обнародование и всеобщее осмеяние
тут же столкнулись с печальным опытом применения всей этой системы.
на начальных этапах проектирования удобно именовать слои по одним признакам (пытаешься ухватить проект "вцелом" (стены, полы, потолки и т.д.), тут поначалу всё происходит в 2д, но итог стадии - 3д модель (то есть появляется другой тип данных), затем идет стадия когда разбираешь проект по крупным кускам (гостиная, столовая, кабинет) где опять чередуется 2д информация с 3д моделями, и, наконец, заканчивается всё сплошняковым 2д, детально разобраным по типам данных. то есть в начале в префиксах удобно держать части проекта, а в конце - тип данных. на всё это накладывается надсистема из вариантов решений и вспомогательной информации. в результате от стадии к стадии суффиксы и префиксы меняются местами, но с этим удалось справится с помощью менеджера слоев адт, который позволяет формировать перекрестную группировку слоев да еще и в полуавтоматическом режиме. всё было бы чудесно, но как выясняется, народ готов вполне упорно осваивать суффиксы и префиксы, но что касается еще одного уровня (перекрестные группы) или хотябы полууровня (синтаксис в именовании слоев) - тут полный крах, в головах проектировщиков такое не удерживается. к этому еще добавляется еще один уровень разделения - разделение на файлы! обычно новые файлы появляются либо с новым вариантом решения, либо со сменой стадии проектирования.
во всяком случае проетировщики предпочитают иметь дело с одноуровневой структурой слоев, и всячески избегают разноуровневой (ситема перекрестной группировки)
"я хочу думать про узел, а не про то в каких слоях должны находится разные части его чертежа". я почти сразу отказался от предоставления рабочей группе готового шаблона - пытался заместить шаблон универсальным правилом, поскольку задачи всякий раз разные, и подразумевают разные структуры и принцыпы именования слоев. имелось ввиду, что если проектировщик сам формирует структуру слоев, то он будет иметь больше представления о том, как она устроена.
в идеале структура слоев должна соответствовать структуре проектного решения.
Вот чем больше я думаю, тем все чаще мне кажется, что идея определения слоя, как свойства объекта - идея ущербная, создающая глобальный конфликт в использовании AutoCAD'а. Если слой - свойство объекта, то как он может существовать при отсутствии объектов в рисунке? Еще одна проблема, еще один конфликт, состоит в том, IMHO, что при вставке блока или внешней ссылки за ними тянутся не только слои, принадлежащие вставляемому объекту, но и все слои, даже не задействованные (не вычещенные). Я хочу вставить в текущий рисунок нужный объект, но зачем мне всякая дрянь, которая тянется за этим объектом? Или взять ADT. Стена - "самостоятельный" объект со своими специфичискими свойствами, но зачем к нему прикреплен слой? В кавычках я написал потому, что стена - не примитив, это составной элемент из обычных примитивов AutoCAD'а. Пора бы уже изменить концепцию AutoCAD'а и, соответственно, "вертикальных" решений на основе AutoCAD'а. Почему, например, Revit обходится без всяких слоев, или же я их там просто не заметил? Но, возможно, такое определение слоев в AutoCAD'е - необходимое условие для программирования в этом продукте и так просто все не изменишь.
в определенном смысле эта проблема решена в параметрических кадах. всякое двухмерное там "зарыто" в 3д объекты, которые в результате из этого двухмерного получаются, 3д объекты собираются в детали "частей", а части - в сборки. на каждом из уровней объекты являются носителями свойств, соответствующих типу объектов - никаких тебе слоев. если нужно из трехмерного экстрагировать серию двухмерных чертежей - пожалте в отдельный программный модуль (мне нравится эта концепция - чертеж как элемент постобработки объемной модели).
но...параметрические кады обычно, что называется, "не гибридные", а это неудобно во многих случаях проектирования. то есть, если не задаешь точные параметры описывающие геометрию примитива, то модель его игнорирует и блокируется - просто так линию висящую в воздухе не нарисуешь. а архитектурное дело, к примеру, едва ли не сплошняком состоит из чего-то не-на-столько-конкретного. тут мне возможно возразят что вон к примеру мдт гибридный. по моему крайнему разумению мдт это свалка из неудобств автокада, неудобств параметрического модуля и неудобств модуля работы с поверхностями - три программных модуля в одной программной оболочке и совокупляйте их как вам заблагорассудится.
еще один вариант реализован в кореле в виде менеджера объектов. есть объекты со своими свойствами, огромное количество (как и в акаде) анонимных объектов, поименованных по типам объектов, но есть возможность задавать им имена собственные, объединять в группы и подгруппы, задавать имена группам, локировать как пообъектно так и группами, и, наконец, фасовать всё это по слоям, и гасить целыми слоями.
вся эта тирада была бы полным оффтопиком, если бы не одно кардинальное наблюдение - чтобы эффективно организовывать работу в группе нужна кардинально другая структура информации. во как.
> menhir
Вот и я так думаю - другая структура информации. AutoCAD не был задуман как программный продукт для групповой работы над рисунком, IMHO. Это инструмент для индивидуальной работы. И это уже пользователи приспособили отдельные инструменты AutoCAD'а для псевдоколлективной работы. Поскольку сами инструменты несовершенны, то приходится сочинять кучу правил, включая СТП, для более или менее приемлимой групповой работы. Но ведь это тупик. Правила эти не имеют отношения к информационным технологиям, это диктаторские правила и поэтому ненадежные и исключающие творчество.
menhir писал:
"просто так линию висящую в воздухе не нарисуешь.
это ещё почему?
Я сейчас немного занимаюсь Autodesk Inventor :)
(До этого работал а Акадом, но скорее по машиностроительному профилю). AI легко делает то, что Вы считаете не возможным :) Для прикола: я тут из любви в искусству свой дом рисовам в AI. Это может быть и не правильно, но мне понравилось :) И совместная работа там решена... Вообще удивляюсь я безмерно. Почему АДТ до сих пор находится на платформе Акада? ИМХО платформа АИ - вот будущее :)
а архитектурное дело, к примеру, едва ли не сплошняком состоит из чего-то не-на-столько-конкретного. тут мне возможно возразят что вон к примеру мдт гибридный. по моему крайнему разумению мдт это свалка из неудобств автокада,
Он совокупляет не только неудобстово акада, но и его удобства, потому как по существу это и есть акад :)
неудобств параметрического модуля и неудобств модуля работы с поверхностями — три программных модуля в одной программной оболочке и совокупляйте их как вам заблагорассудится.
А СЭР знает, что это продукт не для строителей :), пусть они и судят, те для кого он создан.
Форумы CADUser → Autodesk → AutoCAD → Совместная работа над проектом
Форум работает на PunBB, при поддержке Informer Technologies, Inc
