ихние Plm и нашенские стандарты

[Странник 6]

Пока стандарт помогает повысить эффективность бизнеса, он нужен и полезен. Когда он начинает мешать - в топку стандарт и деятелей типа "ЕСКД никто не отменял".

<{POST_SNAPBACK}>

Кстати, а что будут делать этот мега-гига-терра и иже с ним ежели вдруг будет объявлена мобилизация?

Ну, например, родится у... монголов новый Чингис-Хан, или западные варвары опять поедут крышей по поводу расы господ?

Скажет тогда власть имущий сокраментальную фразу из серии: "Срочно развёртываем на базе КЗК, с его супер PLM производство, допустим, БТР! Соответствующее КБ вместе с его кадрами, КД и заделом срочно перебросить в Красноярск!", а на КЗК уже и ЕСКД в топку отправили, и людей с ним знакомых типа тоже.

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

Вероятно, лавры описанных здесь <Время новостей N°207, 08 ноября 2005>, предприятий таки покоя не дают. Очень жаль, что не в состоянии люди смотреть хоть на пол шага далее собственного носа.

Наткнулся на этот примерчик вот тут: <noindex>http://forums.airbase.ru/viewtopic.php?id=35307</noindex>

сообщение №14.

[Елена 116]

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

[Фокс Малдер 0]

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

<{POST_SNAPBACK}>

Таким пониманием мы сразу загоняем себя в рамки и правила чисто-бумажного документооборота. Поясняю. Если есть, бумажный чертеж, то очевидно, мы можем нарисовать его в автокаде. Если есть бумажная спецификация, то мы можем набрать ее в ворде или в экселе. То есть пользуемся понятием, что электронный документ - просто файл. Однако, очевидно, что перенос тех-же процессов с бумаги в файлы как раз не дает существенной экономии времени. Это тупиковый подход. На самом деле, уже сейчас, эта примитивная теория не работает. Введем понятие "представления". Представление - это то, что отображается на экране пользователя или печатается на бумаге. Файл - поименованная область данных на носителе. Между этими понятиями существует фундаментальная разница. Возьмем пример с этим форумом. Можно сделать принт-скрин и получить представление в виде растрового файла BMP. Его можно напечатать. Допустим, кто-то этот форум создает, а другой его утверждает, третий использует. Очевидно, что все они должны иметь одинаковое понимание того, что они видят. Как раз с растровым файлом все просто. Его можно подписать, утвердить, даже напечатать, а потом положить в архив. Однако внесение изменений в растровый файл - извращение. Зайдем с другой стороны. Страницу форума можно сохранить в набор файлов. И в системе хранить именно этот набор файлов. Внесение изменений существенно упрощается. Однако, пользователю, особенно утверждающему, потоки байтов в файлах не интересны. Ему нужно именно "представление". Попытаемся подписать и утвердить файл HTML. Его менять уже нельзя. Но кто-то изменил картинки или скрипты, также используемые для отображения страницы. Очевидно, что "представление" в этом случае уже меняется. Мы сразу понимаем, что утверждать и подписывать файлы по отдельности нет смысла. Надо подписывать все файлы, которые влияют на конечный результат "отображения".

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

Как только мы касаемся вопросов подписи и утверждения, становится очевидно, что в инженерном деле электронный документ - совсем не то-же самое, что файл. В итоге понятие электронного документа становится весьма нетривиальным. И более-менее внятного определения я так и не слышал. Все старательно обходят этот вопрос, легко жонглируя терминами. Очевидно, что сразу же рядом встает вопрос разграничения доступа. Допустим, есть файл "А" с некой моделью. Один эскиз с этой модели используется для построения другой модели, хранящейся в файле "Б". А другой эскиз с модели "A" используется для построения модели "В". Пользователь Вася не должен менять модель "Б", но он должен иметь право менять модель "В". Что он может делать с исходной моделью "А"? Понятно, он может вносить в нее только такие изменения, которые не повлияют на модель "Б". А этого не добиться, просто устанавливая права доступа к файлам средствами операционной системы.

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

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

Есть тут желающие задуматься над этими вопросами?

[Елена 116]

Я не сказала, что утверждающий лист в чертеже. Если все на одной базе данных, то он (точнее таблица), идет как пристройка к ЭСИ. Хоть ко всей сборке, хоть к отдельным деталям, хоть к СТО, хоть к технологии ( у кого как заведено) . Программисты знают как это сделать.. На экране - как лист. Должностному лицу даже писать ничего не надо для утверждения. Просто нажать на кнопку СОГЛАСОВАТЬ. Тут же заносится текущая дата и отметка о согласовании. Следующим (возможно и многим сразу) в таблицу назначений записываются поручения о документах (номерах), которые нужно согласовать. Замечания могут передаваться разработчику любым способом. А Вы этот процесс представляете как-то иначе (вопрос)

Изменения - Как в новых стандартах - заменой документа, но с обязательным приложением характера отраженных изменений в отдельном документе. Все это тоже на ЭСИ. Конечно, если разработка ЭСИ своя у предприятия, то разработать эти алгоритмы проще. Хотя на все нужно время...

[Странник 6]

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

<{POST_SNAPBACK}>

Вопрос, а зачем вообще ЕСКД выкидывать?

Не лучше ли таки реанимировать (если угодно, возродить из пепла) было начавшуюся в последние предперестроечные годы государственную программу по автоматизации + кое что в самих ЕСКД и ЕСТД таки поставить с головы на ноги?

Например, вносить в ТТ чертежей технологические требования и так запрещено, а реально что?

Уберите же "Т.контр" и "Гл.мет" из штампа, тем паче визы на полях просто запретить.

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

А то и подпись "Провер.", ведь двух начальничков сажают на голову ведущего спеца, один из них зачастую просто 0 без палочки, а второму опускаться до деталей просто некогда, вот и начинают они вводные подсовывать одна другой смешнее. Одной подписи "Утв." хватило бы за глаза, только надо чётко обязанности разделить. Начальнику стало быть РАБОТАТЬ бы пришлось, а не купоны стричь.

Допустим, есть файл "А" с некой моделью. Один эскиз с этой модели используется для построения другой модели, хранящейся в файле "Б". А другой эскиз с модели "A" используется для построения модели "В". Пользователь Вася не должен менять модель "Б", но он должен иметь право менять модель "В". Что он может делать с исходной моделью "А"? Понятно, он может вносить в нее только такие изменения, которые не повлияют на модель "Б". А этого не добиться, просто устанавливая права доступа к файлам средствами операционной системы.

<{POST_SNAPBACK}>

Это легко делает PDM, а вот понятие ДЕЙСТВУЮЩЕЙ итерации - однозначно слабовато, это как на бумажке документ АБВГД.NN.NN.NNN изменение №7, допустим, и пока не пройдёт вся процедура ИИ все будут официально пользовать имеено этот документ, хотя бы автор у себя на рабочем столе понаделал уже сотни три новых вариантов с тем же индексом.

Изменения - Как в новых стандартах - заменой документа, но с обязательным приложением характера отраженных изменений в отдельном документе. Все это тоже на ЭСИ. Конечно, если разработка ЭСИ своя у предприятия, то разработать эти алгоритмы проще. Хотя на все нужно время...

<{POST_SNAPBACK}>

Именно, только не забывайте и про то, что то самое ИИ может иметь адресовку и на несколько предприятий, например если по вашей КД работают несколько независимых предприятий.

[Фокс Малдер 0]

Я не сказала, что утверждающий лист в чертеже.

<{POST_SNAPBACK}>

А утверждающий лист и не может быть в чертеже. Это всегда отдельный документ. Однако, этот глюк уже зафиксировали в новых ГОСТах, когда сказали, что электронная цифровая подпись является атрибутом документа и хранится внутри файла. В результате сама операция подписания документа является операцией внесения изменений. Для подписи, получается, нужно право доступа на изменение и оформление ИИ. Бред очевидный. Тем не менее, этот бред зафиксирован в новом ГОСте и передается от книжки к книжке и от статьи к статье как раз людьми, далекими от программирования и от строгой математической логики. И вообще, в новых ГОСТах столько ошибок и откровенного бреда, что уж лучше бы оставили все по старому. Как обычно в нашей стране, их сначала приняли, потом стали обсуждать со специалистами <noindex>http://cals.fastbb.ru/index.pl</noindex>

Программисты знают как это сделать..

<{POST_SNAPBACK}>

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

Просто нажать на кнопку СОГЛАСОВАТЬ.

<{POST_SNAPBACK}>

Согласовать что именно и с какой целью? Я ведь только-что разжевывал. Чертеж согласовали, подписали, через пять минут загружаем его - упс, а он уже поменялся. Кто именно, с какой целью и в каком месте поменял - неизвестно. Единственный способ избежать этого эффекта - разорвать ассоциативность. Сохранить чертеж, например, в формате PDF. С моделью и спецификацией - сложнее.

А Вы этот процесс представляете как-то иначе (вопрос)

<{POST_SNAPBACK}>

Да. Совсем иначе. В современных системах изменение одного размера, одно движение мышкой, легко приводит к изменению гигабайтов цифровых данных, сотен чертежей, спецификаций, не только на изделие, но и на оснастку. Так что все поменять за пять минут - не проблема. Проблема - понять, на что это повлияет, пересогласовать, подписать и утвердить. Раньше месяцами всем КБ вносили изменения на бумагу, стараясь ничего не забыть и не перепутать. Теперь легко меняет один человек за считанные секунды. Однако проблема "согласовать, проверить и утвердить" никуда не делась. Это все чисто ручная работа. Получилась фигня. Раньше 100 изменений вносилось за месяц. Теперь они вносятся за час. Количество конструкторов можно сократить, количество согласующих, подписывающих и проверяющих надо увеличить. Кто такой "нормоконтроль", я так и не понял. Какие функции он выполняет? Проверяет, что толщина линий на чертеже соответствует ГОСТу?

но с обязательным приложением характера отраженных изменений в отдельном документе.

<{POST_SNAPBACK}>

Зачем? Есть две версии документа. Их можно сравнить и увидеть разницу. Зачем эту разницу хранить отдельно в отдельном документе? Такое понятие, как "Извещение" надо просто отменить совсем. Оно не нужно.

[Странник 6]

Кто такой "нормоконтроль", я так и не понял. Какие функции он выполняет?

<{POST_SNAPBACK}>

А чего тут не понять?

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

Зачем? Есть две версии документа. Их можно сравнить и увидеть разницу. Зачем эту разницу хранить отдельно в отдельном документе? Такое понятие, как "Извещение" надо просто отменить совсем. Оно не нужно.

<{POST_SNAPBACK}>

А вот это, пардон, совершенно не верное заявление.

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

Смотрите:

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

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

Как это сделать?

Пересоздать габаритную модель заново? Конечно нет, а взять и создать новую итерацию, либо даже версию.

Что при этом будет с окружающими?

Одним словом можно сказать так - труба им будет, если механизм ИИ исключить. А вот если он есть, то всё обойдётся. Доколе процедура введения ИИ не прошла все их модели ссылаются на действующий вариант (именно с номером измененя N).

Тож самое и при пути снизу вверх.

Тогда и жалоб таких не будет:

Согласовать что именно и с какой целью? Я ведь только-что разжевывал. Чертеж согласовали, подписали, через пять минут загружаем его - упс, а он уже поменялся. Кто именно, с какой целью и в каком месте поменял - неизвестно.

<{POST_SNAPBACK}>

и ассоциативность рвать будет совсем ни к чему.

[Фокс Малдер 0]

Не лучше ли таки реанимировать (если угодно, возродить из пепла) было начавшуюся в последние предперестроечные годы государственную программу по автоматизации

<{POST_SNAPBACK}>

Спасибо, государственную не надо. Хватит уже 70 лет государственных программ. Пусть коммерческие фирмы этим занимаются и конкурируют друг с другом.

кое что в самих ЕСКД и ЕСТД таки поставить с головы на ноги

<{POST_SNAPBACK}>

Этим должны заниматься коммерческие организации, которые и будут создавать свои стандарты, потом объединяться в крупные ассоцации и создавать некие "стандарты альянса". Именно "единой" системы не нужно. Если заказчик - оборонка, то у нее и стандарт свой и требования. У другого заказчика вполне может быть свой стандарт.

Например, вносить в ТТ чертежей технологические требования и так запрещено, а реально что?

<{POST_SNAPBACK}>

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

А то и подпись "Провер.", ведь двух начальничков

<{POST_SNAPBACK}>

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

Одной подписи "Утв." хватило бы за глаза, только надо чётко обязанности разделить.

<{POST_SNAPBACK}>

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

понятие ДЕЙСТВУЮЩЕЙ итерации

<{POST_SNAPBACK}>

Понятия ДЕЙСТВУЮЩЕЙ итерации не существует. Для одного действующей является одно, для другого - другое. По одной версии документа проектируется, по другой изготавливается, по третьей - в эксплуатации. Если что-то, изготовленное 10 лет назад поломалось и нужен чертеж, то какой будет действующим для данного случая?

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

<{POST_SNAPBACK}>

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

[Елена 116]

Помните, в детских журналах печатали задачки "Сравнить 2 картинки и найти 10 различий". Не всем удавалось с первого раза. А различия нужно бы знать. Особенно технологам. Вдруг данные различия не внесут никаких изменений в технологию (за исключений размеров, по которым только УП пересчитать ), или наоборот - очень существенны

[Странник 6]

Спасибо, государственную не надо. Хватит уже 70 лет государственных программ.

<{POST_SNAPBACK}>

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

Будете элементарно даже типы резьбы в крепёжных отверстиях глубоко каждый раз согласовывать или таки пусть будет ЕСКД?

Если все в одной системе и в одной организации, как это обычно есть в России, то такой запрет выглядит весьма странным и бессмысленным.

<{POST_SNAPBACK}>

Т о если проектировщик знает что его детище будут клепать где-то за воротами то никакой технологии в ТТ, а если у себя то технологи могут расслабиться ибо он всё будет делать заних?

Нет уж, конструкторский чертёж - это чётко сформулированное задание технологу, а не полуготовый (если не совсем готовый) техпроцесс, даже если имеем дело с фирмочкой где и технолог и конструктор - одно и тоже лицо.

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

<{POST_SNAPBACK}>

Однако на лицо непонимание...

Здесь работает принцип единоначалия, именно "Утв." даёт приказ и именно ему докладывают о выполнении. А всякие там прочие "т.контр" должны обезпечивать "разрабу" условия для выполнения, а не мнения свои выпячивать.

Это как в авиации, комполка сказал "ко времени Ч в таком то квадрате разбомбить то и это" дело же инженеров и тыловиков - обезпечить вылет, а не говорить лётному составу: "то, другое, третье... идите типа пёхом и подальше", а если и в самом деле то, другое, третье и задание невыполнимо то он уж это комполка сообщает, лично.

Понятия ДЕЙСТВУЮЩЕЙ итерации не существует. Для одного действующей является одно, для другого - другое. По одной версии документа проектируется, по другой изготавливается, по третьей - в эксплуатации.

<{POST_SNAPBACK}>

Либо нестыковка в терминах, либо "доброе утро".

Типа у проектировщика одна геометрия, на станке другая, а в издели поставят вообще неизвестно что? Это знаете ли и есть бардак.

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

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

<{POST_SNAPBACK}>

Опять 25.

КД введена и это есть изменение N-1, до тех пор пока не появится новое изменение №N, то технологи работают по N-1 и в ус не дуют. Когда же приходит N, то в нём имеются указания о внедрении, заделе, применении и ещё дополнительные, отлично всё получается.

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

Красивая тут просматривается работа программисту, однако.

[SVS 1]

Для того, что бы человек мог что то такое смастерить он должен это УВИДЕТЬ так или иначе. Данное свойство человеческого естества не денешь никуда.

Когда сам разработчик перекладывает собственную мысль в язык моделей CAD системы, то чётко определённые масштабы ему особо не нужны, но то разработчик. Совсем иначе дело обстоит когда другой человек должен переложить собственно мысль разработчика с языка CAD, допустим, на станок ЧПУ. Здесь тоже имеет место быть вполне творческий процесс, а значит надо всёже увидеть конечный результат и вид заданного масштаба тут уже просто необходим.

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

Итак, потребны чётко отмаштабированные виды с явно заданными особыми требованиями, а это всё и есть чертёж.

Кстати, у китайцев тоже есть так называемое ПЗ, при чём ни сколь не менее "весёлое" чем у нас.

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

<{POST_SNAPBACK}>

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

А для заказчиков я вообще не помню чтобы оформляли чертеж.

Заказчики то разные, начиная с Америки и заканчивая Китаем.

[Странник 6]

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

<{POST_SNAPBACK}>

Так, начинаются давно ожидавшиеся от пользователей ProE приколы. Ну что же... только техника и ничего личного.

1. А вы собственно кто есть то? В смысле - директор, главный инженер, начальник отдела или таки будете непосредственно техническую задачку решать?

2. Что у вас за предприятие такое? В смысле НИИ, головное КБ, крупный завод, мелкий завод или ещё какой вариант?

3. Выпускаете ли сами КД, али таки приходят к вам уже оформленные по всем канонам документы?

4. Знакомы ли вы с понятием контекста и его +, а более всего с тем во что применение сей возможности выливается в модель?

5. Можете ли вы требовать от каждого сотрудника такого же уровня владения IT, как у себя самого?

6. Знакома ли вам ситуация с работой в нескольких CAD системах, например: у вас ProE, а смежник сидит на CATIA (кстати, смежник тот имеет собственное юридическое лицо, а с вами у него договор 50 на 50).

7. Является ли отсутствие определённого опыта у какой либо личности гарантией отсутствием такового опыта и в природе?

[SVS 1]

Уже как то обсуждалось подобное, ни хотелось бы повторяться, но если в кратце:

1. Предприятие иностранное, проектирование, изготовление и частично изготовление на стороне (где используются другие CAD системы)

2. Вся информация храниться в базе данных. При поступлении заказа, распечатываются чертежи, после выполнения заказа чертежи уничтожаются. Так как большинство деталей (90%) изготавливаются на ЧПУ, то чертеж наиболее необходим только ОТК, для выборочной проверки. (На сложных моделях даже допускалось не проставлять все размеры, а только наиболее ответственные, чтобы ОТК могло проверить)

3. Все конструктора, технологи, мастера сборочного участка на необходимом уровне владеют 3D пакетом. При устройстве на работу все проходят обучение, а потом в течении полугода втягиваются в работу. (По началу маленькие узлы, потом побольше, и т.д.)

На своем опыте хочу сказать, что если человек хочет, то поймет и ЕСКД и ISO и DIN и JIS и т.д.

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

Так, начинаются давно ожидавшиеся от пользователей ProE приколы. Ну что же... только техника и ничего личного.

<{POST_SNAPBACK}>

Не в ProE дело, а в организации и подходе к проектированию.

Я работал (не пробовал а работал) и в Unigraphics, и в CATIA, и в Pro/E. Не знаю как вам а мне есть с чем сравнивать.Работать можно в чем угодно, только организуйте и подгатовте пакет инструкций. Хотя не скрою что больше всех мне нравиться ProE. Причем намного больше.

[SVS 1]

Как только мы касаемся вопросов подписи и утверждения, становится очевидно, что в инженерном деле электронный документ - совсем не то-же самое, что файл. В итоге понятие электронного документа становится весьма нетривиальным. И более-менее внятного определения я так и не слышал. Все старательно обходят этот вопрос, легко жонглируя терминами. Очевидно, что сразу же рядом встает вопрос разграничения доступа. Допустим, есть файл "А" с некой моделью. Один эскиз с этой модели используется для построения другой модели, хранящейся в файле "Б". А другой эскиз с модели "A" используется для построения модели "В". Пользователь Вася не должен менять модель "Б", но он должен иметь право менять модель "В". Что он может делать с исходной моделью "А"? Понятно, он может вносить в нее только такие изменения, которые не повлияют на модель "Б". А этого не добиться, просто устанавливая права доступа к файлам средствами операционной системы.

<{POST_SNAPBACK}>

1. В PDM системе легко и просто можно выявить что от чего зависит, а вот что с этим делать должно четко регламентироваться инструкциями на предприятии.

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

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

P.S. При всех изменениях в PDM отражается кто изменил и когда, сотрудники об этом знают и от этого вырабатывается высокое самосознание. - Всегда можно найти кто же отнесся халатно.

[Странник 6]

А вообще у нас существовало инструкция о том что модели не должны зависит друг от друга (намного упрощает управление изделием).

<{POST_SNAPBACK}>

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

Представьте себе, например, заливку клеем (или ещё чем) полости, образуемой стыком 2 и более деталей сложного профиля, как будете без контекстов обходиться?

Или ещё чище, таж самая полость но не в статике, т е образующие её детали как то там двигаются друг относительно друга, а объёмчик важен как один из параметров проектирования, тоже без контекста обойдётесь?

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

При поступлении заказа, распечатываются чертежи, после выполнения заказа чертежи уничтожаются. Так как большинство деталей (90%) изготавливаются на ЧПУ, то чертеж наиболее необходим только ОТК, для выборочной проверки. (На сложных моделях даже допускалось не проставлять все размеры, а только наиболее ответственные, чтобы ОТК могло проверить)

<{POST_SNAPBACK}>

Ну вот, без чертежей и у вас не обходится. О чём тогда, собственно, говорим? Кстати, кто их таки выпускает то, вы или извне они к вам попадают?

Тут же возникает вопрос и о жёсткости приёмки, как последствия предъявляемых требований.

Все конструктора, технологи, мастера сборочного участка на необходимом уровне владеют 3D пакетом. При устройстве на работу все проходят обучение, а потом в течении полугода втягиваются в работу. (По началу маленькие узлы, потом побольше, и т.д.)

<{POST_SNAPBACK}>

У нас тож самое, мало того, сертификаты есть у подавляющего большинства. А вот требовать такого же уровня работы как у себя самого не имею права всё равно.

Спросите почему?

Потому, что каждому - своё.

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

<{POST_SNAPBACK}>

А вот это не верно в корне.

У каждого изделия есть свои, не присущии никакому другому особенности, даже если все изделия проектируются под подобные условия и функции. Так же, как нет 2 одинаковых человек нет и 2 одинаковых методов преложения мысли в модель. Можно выпустить СТП в коем оговорить правила названия документов, шаблоны, потребные атрибуты, слои, форматы и много что ещё, но никак не стиль построения.

Заставлять новичка работать на чемпионском уровне ни чуть не менее безумно чем чемпиону приказывать применять только новичковские приёмы.

К тому же, реальное проектирование всегда требует именно чемпионов многоборцев (и в собственно специальности, и в IT, да ещё и сверх того кое что).

[SVS 1]

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

Представьте себе, например, заливку клеем (или ещё чем) полости, образуемой стыком 2 и более деталей сложного профиля, как будете без контекстов обходиться?

Или ещё чище, таж самая полость но не в статике, т е образующие её детали как то там двигаются друг относительно друга, а объёмчик важен как один из параметров проектирования, тоже без контекста обойдётесь?

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

<{POST_SNAPBACK}>

Вопрос 1: Сколько работает у вас сотрудников в вашем 3D пакете?

Ну вот, без чертежей и у вас не обходится. О чём тогда, собственно, говорим? Кстати, кто их таки выпускает то, вы или извне они к вам попадают?

Тут же возникает вопрос и о жёсткости приёмки, как последствия предъявляемых требований.

<{POST_SNAPBACK}>

Ни один чертеж не подписан ручкой, проверку осушествляет только ведущий изделия и утверждает документ в PDM системе, далее берутся за дело ЧПУ-шники. А чертеж распечатывается как отчет о модели на бумаге. Все геометрические, и линейные допуска, базы шероховатости стоят в модели. И как я уже писал нужны чертежи в основном ОТК.

Но ни один сотрудник не будет брать информацию из чертежа. Если необходимо что-то узнать - только из базы, т.к. последняя ерсия только в базе. Чертеж не является главным документом.

Распечатывает их подготовка производства, и на каждом чертеже, в установленном поле, при распечатке наноситься номер заказа. В периуд изготовления некоторые службы (ОТК, производство ...) пользуються этими чертежами, но так же, если что-то не понятно, могут зайти в базу и посмотреть более детально. Потом чертежи уничтожаються, пока не появиться следующий заказ.

У нас тож самое, мало того, сертификаты есть у подавляющего большинства. А вот требовать такого же уровня работы как у себя самого не имею права всё равно.

Спросите почему?

Потому, что каждому - своё.

А вот это не верно в корне.

У каждого изделия есть свои, не присущии никакому другому особенности, даже если все изделия проектируются под подобные условия и функции. Так же, как нет 2 одинаковых человек нет и 2 одинаковых методов преложения мысли в модель. Можно выпустить СТП в коем оговорить правила названия документов, шаблоны, потребные атрибуты, слои, форматы и много что ещё, но никак не стиль построения.

Заставлять новичка работать на чемпионском уровне ни чуть не менее безумно чем чемпиону приказывать применять только новичковские приёмы.

К тому же, реальное проектирование всегда требует именно чемпионов многоборцев (и в собственно специальности, и в IT, да ещё и сверх того кое что).

<{POST_SNAPBACK}>

Ну что же лепите тогда кто как умеет, Вам виднее. Потом сами будете разбираться как это сделано.

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

А Вот это правильно:

Можно выпустить СТП в коем оговорить правила названия документов, шаблоны, потребные атрибуты, слои, форматы ...

Только не можно а нужно.

[Странник 6]

Вопрос 1: Сколько работает у вас сотрудников в вашем 3D пакете?

<{POST_SNAPBACK}>

Что бы мне только не сильно ошибиться, человек 800...1000, однако, как сами понимаете, всё это постоянно обновляется. Тех, что "не слезая", конечно поменьше но не уж очень на много.

Ну что же лепите тогда кто как умеет, Вам виднее. Потом сами будете разбираться как это сделано.

<{POST_SNAPBACK}>

Ой нет, не будет такого провала.

Как это сделано народ разберётся, другое дело что сумеют ли сами так работать. А в крайнем случае есть IT подразделение, как экстренный вариант сработают, ну а уж если совсем что - напишут в Москву. ;)

Вообще же говоря, вот тут качественное преимущество солидовского интерфейса, работать удобно, это очень много.

Ни один чертеж не подписан ручкой, проверку осушествляет только ведущий изделия и утверждает документ в PDM системе, далее берутся за дело ЧПУ-шники. А чертеж распечатывается как отчет о модели на бумаге. Все геометрические, и линейные допуска, базы шероховатости стоят в модели. И как я уже писал нужны чертежи в основном ОТК.

<{POST_SNAPBACK}>

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

С ЧПУ-шниками же разборки бывают непременно и объективно, ибо мы КД разрабатываем и отрабатываем.

Только не можно а нужно.

<{POST_SNAPBACK}>

А это у нас и сделано, давным - давно, многим в пример к подражанию.

[SVS 1]

Вообще же говоря, вот тут качественное преимущество солидовского интерфейса, работать удобно, это очень много.

<{POST_SNAPBACK}>

У меня приятель очень долго работал в Солиде, когда он попал к нам на работу и я его переучивал на Pro/E, по началу он был очень недоволен, потом втянулся в работу, а через пол года, сказал что ProE и солид это как Windows95 и WindowsXP.

(Таким образом у меня есть один реальный человек, который долго,около 3 лет, работал в Солиде, перешел на Pro/E и назад к Солиду уже не вернулся. А вот чтобы наоборот - то таких я не видел. Но если у вас работает столько людей в Солиде, то может у вас есть такие)

Если не брать функциональные возможности программы, то как организовать совместную работу с единой конфигурацией всех сотрудников в Солиде?

Где у вас храняться настройки Солида на сервере или у клиента?

Где у вас храняться данные?

то бы мне только не сильно ошибиться, человек 800...1000, однако, как сами понимаете, всё это постоянно обновляется. Тех, что "не слезая", конечно поменьше но не уж очень на много.

<{POST_SNAPBACK}>

Поделитесь тогда опытом: какую вы используете PDM систему для 1000 человек работающих в Солиде.

а вот ОТК у вас более чем странное.

<{POST_SNAPBACK}>

?

[Странник 6]

Поделитесь тогда опытом: какую вы используете PDM систему для 1000 человек работающих в Солиде.

<{POST_SNAPBACK}>

PDM у нас пока несколько, всё никак окончательно не выберем.

Опыт же работы неумолимо показывает, что нужно нам нЕчто горазда большее чем просто PDM, не знаю даже потянут ли потребное и те, что называются PLM.

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

Так же как известную притчу о том, что скупой платит дважды.

Если не брать функциональные возможности программы, то как организовать совместную работу с единой конфигурацией всех сотрудников в Солиде?

Где у вас храняться настройки Солида на сервере или у клиента?

Где у вас храняться данные?

<{POST_SNAPBACK}>

Наши сотрудники IT с этим легко справляются. Есть СТП, есть центральный сервер, есть шаблоны, а главное - есть несколько чемпионов которых теперь внимательно слушают. Жаль только эта практика началась позже чем надо было бы. Сидели бы быть может сейчас на UG. Хотя повторюсь, SolidWorks очень не плох, а мог бы быть и ещё лучше.

Цитата(Странник @ Aug 22 2006, 17:28)

а вот ОТК у вас более чем странное.

?

<{POST_SNAPBACK}>

С такими подходами в чертежах могут быть хоть ссылки на сайты интернета.

[vitch 0]

Что бы мне только не сильно ошибиться, человек 800...1000, однако, как сами понимаете, всё это постоянно обновляется. Тех, что "не слезая", конечно поменьше но не уж очень на много.

<{POST_SNAPBACK}>

Означает ли сие, что Вы приобрели 800...1000 лицензий SW