• Добро пожаловать на Форум пользователей ПО АСКОН. Пожалуйста, авторизуйтесь.
 

Уважаемые пользователи,

Хотим проинформировать вас о режиме работы регистрации на нашем сайте.

Зарегистрироваться возможно в рабочие дни, с 8:00 до 20:00 (мск).

Если у вас возникнут вопросы или потребуется дополнительная информация, не стесняйтесь обращаться к нашей службе поддержки. Вы можете связаться с нами по указанным контактным данным на нашем сайте.

Благодарим вас за понимание и сотрудничество. Мы ценим ваше терпение и стремимся предоставить вам лучший опыт использования нашего сервиса.

С уважением,
Команда Ascon

Кто как в Лоцмане проводит извещения?

Автор Система, 24.10.08, 13:41:55

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

Система

В связи с тем, что на нашем предприятии до сих пор "висит" вопрос как правильно проводить извещения об изменениях, и в частности одна из проблем описана http://forum.ascon.ru/index.php/topic,12354.0.html. Интересно, вообще кто-нибудь пользуется асконовским модулем ИИ под Лоцман или может быть написали для этой цели свои плагины?

YorikER

Тема огромная по разнообразию мнений и подходов...
Для начала необходимо понять, о каком извещении идет речь... Извещение об изменении в конструкторском (проектном) составе изделия или же речь идет уже о производственном извещении, когда изделие уже в производстве, обросло заготовками, затратами, нарядами и т.д. В ЛОЦМАНе нет еще производственного блока (по крайней мере я еще не видел реализацию), думаю, что речь идет о проектном составе изделия...
Здесь у АСКОНа (да и у многих других IT компаний) есть засада в подходе... Информация формируется от CAD к PLM... Интеграция построена также - от CAD к PLM... Скажу честно, наупражнялись с таким подходом от души... В определенный момент отказались от него и сделали все наоборот... Информация у нас формируется от PLM к CAD... Первичным является база данных, а уж потом CAD... Спецификация (состав изделия) формируется конструктором сразу же в в базе данных ЛОЦМАНа с помощью своего клиентского приложения... И только потом грузится CAD (КОМПАС) для формирования необходимых документов на каждой ветке состава (3D-модели деталей, сборок, чертежи, спецификации). Спецификация в КОМПАСе используется как табличный редактор, который заполняется из базы данных. Очень много вопросов упростилось, в том числе и проведение изменений. Непосредственно в базе данных создаете новую версию сборки (предположим принято решение заменить у нее подсборку на другую). Удаляете из состава необходимую подсборку, формируете другую... Создаете копию файла 3D-сборки с отражением номера новой версией в имени файла. Грузите 3D сборку из базы данных, КОМПАС выдает ошибку, что отсутствует подсборка на рабочем диске, удаляете ее из дерева файла, вставляете новую подсборку и все... У вас новая 3D модель изделия зарегистрированнная в базе данных. Параллельно с этим в базе данных регистрируется извещение, как сопроводительный документ... Никакой интеграции от CAD к PLM не надо, т.к. вы сразу же в базе данных сформировали новый состав изделия... Но для этого пришлось изменить АСКОНовскую идеологию ЛОЦМАНа...

Дмитрий

2YorikER
Хотелось бы уточнить один вопрос по извещениям.
Допустим, у нас есть 3D сборка №1.00.00, в нее входит подсборка №1.01.00, в которую в свою очередь входит деталь №1.01.01.
На деталь необходимо выпустить конструкторское извещение об изменении. Т.е. создаем новую версию детали №1.01.01, а так же создаем копию файла 3D-детали с отражением номера новой версией в имени файла. Изменяем 3D-модель детали. После этого конструкторское извещение проходит, согласование, утверждение и попадает в архив.
Однако в подсборке №1.01.00 осталась ссылка на файл детали №1.01.01 первой версии. Вот тут проблема. Возможно мы, что-то не правильно делаем? Подскажите, пожалуйста, как нам быть.

YorikER

Похоже Вы используете обычную спецификацию по ЕСКД, где есть только номер позиции, обозначение, наименование, количество и примечание. Изменение материала и массы детали никак не сказывается на спецификацию подсборки, изменение массы детали повлечет только изменение массы сборочного чертежа и всей цепочки сборочных чертежей вверх. У нас спецификация расширенная: в нее добавлены колонки Материал, Масса 1 шт и Масса общая. Поэтому любое изменение в детали с изменением массы и материала влечет за собой изменение верхних спецификаций. Т.е. извещение затрагивает всю цепочку информации наверх, а не только деталь... Теперь по поводу ссылок: в составе подсборки в базе данных создаете новую версию объекта типа Деталь (!), затем в объекте по связи "Документы", создаете новую версию документа, затем создаете новый файл для нового документа с новым именем с новой версией в названии. В составе подсборки удаляете из состава старую версию объекта типа Деталь (!) (Внимание!!! Удалить именно из состава а не из базы данных), не забудьте перед этим поменять состояние старой версии на "Аннулирован", т.к. данная деталь может входить в другие составы (другие сборки) и вообще-то это надо выловить... Мы даже писали функцию проверки, куда входит измененная деталь, чтобы изменить версию и там, однако потом от этого отказались... При запуске в производство других сборок со старой версией детали, если у нее изменено состояние на "аннулирован", это сразу же видно... Конструктору дается команда разобраться в чем дело... После чего грузите свою подсборку как обычно на рабочий диск, КОМПАС не находит старый файл, выдает ошибку, Вы меняете файл и все...

Дмитрий

29.10.08, 11:45:42 #4 Последнее редактирование: 29.10.08, 12:41:23 от Дмитрий
2YorikER
Что-то я пока не могу осознать весь процесс проведения изменения.
Интересно как у вас построена система безопасности.

У нас "ДСЕ" и конструкторские документы  имеют четыре состояния "Проектирование", "Утвержден", "Архив" и "Аннулирован".
В изменении участвуют два пользователя конструктор и работник архива.
Конструктор имеет доступ "Чтение / Запись" к состоянию "Проектирование", а к остальным состоянием доступ "Только чтение".
Работник архива имеет доступ "Чтение / Запись" ко всем состояниям.

Теперь проведение самого извещения об изменении.
Например, есть сборка №1.00.00, в нее входит подсборка №1.01.00, в которую в свою очередь входит деталь №1.01.01. Все объекты находятся в состоянии "Архив".
По извещению изменяется только деталь №1.01.01.
Конструктор создает новые версии детали №1.01.01 и ее документов, у документов создаются файлы в именах файлов, которых учитывается номера новых версий документов.
Деталь и ее документы создаются в состоянии "Проектирование", соответственно конструктор к ним имеет доступ и может изменять файлы.
После утверждения извещения конструктор переводит новые версии детали и документов в состояние "Утвержден".
Работник архива переводит старую версию детали и ее документов в состояние "Аннулирован", а новую версию детали и ее документов в состояние "Архив".

Проблема в том, что конструктор при проведении извещения не имеет доступа к подсборке №1.01.00 и он не может изменить в ней ссылку на новую версию детали №1.01.01. Если же создать новую версию подсборки №1.01.01, то проблема возникнет со ссылкой на нее из сборки №1.00.00. Т.о. придется менять всю цепочку.

И как вы проводите извещения с учетом безопасности?

YorikER

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

chelcar

Цитата: Дмитрий от 27.10.08, 14:43:33
2YorikER
Однако в подсборке №1.01.00 осталась ссылка на файл детали №1.01.01 первой версии. Вот тут проблема. Возможно мы, что-то не правильно делаем? Подскажите, пожалуйста, как нам быть.
Ох не просто тут разобраться. Делаем так. Пока работаем с изменением, новое имя файла у новой версии, хорошо, никто не увидит что кто-то вносит изменение и если модель заимствуется много раз, на другие сборки новая модель не повлияет. Это хорошо.
Но когда изменение готово, то новое имя файла повлечет изменение всех сборок до самой верхней. Это плохо.
Придумали себе компромис. Когда изменение файла модели утверждено, имя файла новой версии менятеся на "старое", без номера версии, и все сборки не трогаются.
Хорошо бы ЛОЦМАН сам это делал. А пока ручками...