Лоцман, Спецификация

Автор l2qwe, 29.03.11, 16:25:20

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

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

Дед Мороз

Цитата: YorikER от 19.08.11, 08:08:50
3. Спецификация оформляется полностью в ЛОЦМАНЕ (для этого написан полномасштабный редактор спецификаций в своем собственном клиенте - см. http://www.infnt.ru/ECom/Functions/ECFPage1.html Учетная карта сборочной единицы)...
жжжжжж... это не спроста
жжж... это значит - пчёлы
а пчёлы - это мёд

на практике заметно, что
построитель и редактор спецификаций КОМПАС отличается от построителя спецификаций ЛОЦМАН

есть ощущение, что развитие процедуры "застыло" перед каким-то барьером

я спрошу прямо - по каким правилам формируется спецификация для конфигурированного изделия ?

YorikER

Цитата: Дмитрий22 от 19.08.11, 08:54:15
Вот это интересное решение. Единственное, при таких сложных "вмешательствах" в Лоцман необходимо иметь штат программистов на предприятии, потому как сторонняя фирма, мне кажется, очень долго будет отлаживать программу. В условиях производства некогда ждать пока сторонняя фирма ответит на запрос, исправит, перешлет исправление, местные админы установят и так по кругу.У нашего предприятия свои требования (те же спецификации на листе, уверен всплывет что-то еще). Хотел еще спросить, групповые спецификации Ваша система отрабатывает?
За "штат программистов" спасибо - практически всю разработку вел я один, во внедрении помогала группа аналитиков-энтузиастов. Сейчас работаю над библиотекой компонентов под Delphi 2010. В настоящий момент ведется разработка новой версии библиотеки под Delphi 2010. Основное направление - работа как в локальной Интранет сети, так и в Интернете... Т.е. доступ к серверу приложений (естественно через пароли и контроль подключений) может быть открыт через Интернет клиента с помощью IP адреса и номера порта. Слегка напоминает "полуоблачные технологии", о которых много пишут. В открытом доступе предполагается выставить пример Интернет-клиентского приложения с удаленным доступом к базе данных ЛОЦМАНа. В перспективе есть идея разработки на базе платформы ЛОЦМАН:PLM своеобразного DATA-центра для удаленной работы...
Групповые спецификации естественно поддерживаются. У нас используются только групповые спецификации типа А. Тип Б - фактически нет, поэтому в клиентском приложении они не разрабатывались.

YorikER

Цитата: Дед Мороз от 19.08.11, 10:02:41
жжжжжж... это не спроста
жжж... это значит - пчёлы
а пчёлы - это мёд

на практике заметно, что
построитель и редактор спецификаций КОМПАС отличается от построителя спецификаций ЛОЦМАН

есть ощущение, что развитие процедуры "застыло" перед каким-то барьером

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

Дмитрий22

Цитата: YorikER от 19.08.11, 20:03:52
За "штат программистов" спасибо - практически всю разработку вел я один, во внедрении помогала группа аналитиков-энтузиастов.
Групповые спецификации естественно поддерживаются. У нас используются только групповые спецификации типа А. Тип Б - фактически нет, поэтому в клиентском приложении они не разрабатывались.
Ничего себе, надумаете переезжать в Екатеринбург, приходите на собеседование к нам, устроим).У нас используется и тип Б и тип А. Никаких ограничений на ЕСКД нет. Вообщем, работы предстоит много.

Дед Мороз

23.08.11, 09:13:02 #44 Последнее редактирование: 23.08.11, 11:52:10 от Дед Мороз
шутки-шутками ) это хорошо в меру )

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

видно, что мы держим две спецификации (вторая с "Доработка"), это следуя действиям конструкторов

на самом деле это не "доработка" конструктора,
а условие заказа: сборка должна иметь две различные модификации, с разницей во времени разработки

это не случай версий и не случай исполнений, мы решили, что это конфигурирование

что будет, если попросить ЛОЦМАН 8.5 построить спецификацию?

YorikER

Давайте попробуем разобраться...
Исполнения - разные и похожие изделия, имеющие разную физическую сущность... Например муфта зубчатая на разный диаметр вала, одно изделие нельзя применить вместо другого по физическим ограничениям...
Конфигурации - разные и похожие изделия, имеющие одинаковую физическую сущность... Та же зубчатая муфта, но одна из стали 45, другая из стали 40Х... При определенных передающих моментах одно изделие можно установить вместо другого...
Другой пример автомобиль разной конфигурации (или комплектации): с кожаным салоном или с матерчатым... физическая сущность одна...
У нас конфигурации не используются... Алгоритм не проработан...

nagornick

Не удержался и отвечу.
При внедрении ЛОЦМАН (как и другой PDM) надо вообще запрещать работать в КОМПАС-СПЕЦИФИКАЦИИ.
(Раньше благо это было отдельное приложение, можно было на ключе убрать)

Спецификации и прочие отчеты - печатать только из ЛОЦМАН и точка.
И никогда не будет нормальной интеграции КОМПАС-СПЕЦИФИКАЦИЯ, пока там будут возможности писать, что угодно. Вообще сама по себе КОМПАС-СПЕЦИФИКАЦИЯ - это мини PDM система.
Зачем интегрировать 2 PDM системы.

Сама по себе конструкторская спецификация морально устарела. И вообще, во многом EСКД и нормоконтроль, но это уже другая тема.



Дмитрий22

01.09.11, 20:30:39 #47 Последнее редактирование: 09.09.11, 17:52:09 от Администратор
Прежде чем что-то запрещать, предложите такой же хороший инструмент для расчета массы сборки по деталям в спецификации, автоматической расстановки зон в спецификации.

Дед Мороз

02.09.11, 09:19:56 #48 Последнее редактирование: 02.09.11, 09:30:36 от Дед Мороз
Цитата: nagornick от 01.09.11, 16:23:02
Вообще сама по себе КОМПАС-СПЕЦИФИКАЦИЯ - это мини PDM система.
может, микроскопическая ERP ?
  :shu:

вот, почему Вы думаете, что конструкторская спецификация как класс устарела ?
это интересно, а Ваш ответ и своевременный и внятный
я, как математик, имею привычку спрашивать то, что замечается ))

YorikER  
очень хорошо пояснил, как спецификация может отражать некую физическую сущность

nagornick

Формат этого документа изначально не проектировался для электронной обработки.
Про ERP не знаете - лучше не язвите.

Дед Мороз

02.09.11, 09:40:14 #50 Последнее редактирование: 02.09.11, 09:57:02 от Дед Мороз
отбросим то, что формат куцый
допустим идеальный формат

что изменится ?

я уверен, что спецификация - это начало ERP
или я ошибаюсь ?

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

88))

YorikER

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

Дед Мороз

06.09.11, 09:29:29 #52 Последнее редактирование: 06.09.11, 12:25:24 от Дед Мороз
1. теперь мы не путаем  конструкторскую спецификацию со спецификацией ERP...   :o:
раньше говорили: фортран 77 - это суженное расширение фортрана 4  :%: (имея в виду стандарт языка)

если я скажу, что хочу объединить эти сущности как есть - это будет не совсем верно
если я скажу, что не хочу объединить эти сущности как не есть - так же это будет не совсем верно

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

каверзный вопрос:
может ли готовое изделие передаваться заказчику без конструкторской спецификации?

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

значит, в принципе, конструкторская спецификация может быть заказчику не нужна,
а раз так, то:

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

я пользуюсь тем, что результат электронной формы неотделим от способа изготовления - это единое целое, умозрительно делимое на части. Электронные формы документооборота позволяют не только накапливать, но и технологично, чувствительно обрабатывать (объединять, разединять) данные.

процесс потребления включает процесс производства - не так ли ?

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

nagornick

Конструкторская спецификация есть подмножество НСИ.
Конструкторская спецификация -> Технологический состав (разбиение на подсборки, детали для испытаний, технлогические операции ...) -> Технологический состав с маршрутами/ТП -> Производственный заказ (+ замены)

Смысл в том, что конструктор должен управлять составом в рамках НСИ.
Поэтому, нужно запретить использование КОМПАС-СПЕЦИФИКАЦИИ в рамках комплексных проектов.
Если говорить об решениях АСКОН, то ЛОЦМАН/ГОЛЬФСТРИМ должны выполнять функцию привязки к позициям КОМПАС и соответствующий функционал (в том числе печать документов), а не паразитное  в данном случае звено КОМПАС-СПЕЦИФИКАЦИЯ.

Координально, надо хоронить ЛОЦМАН, ВЕРТИКАЛЬ (в том виде каком она есть, что и происходит), КС.
Оставить КОМПАС->ГФ.





Дед Мороз

06.09.11, 10:07:32 #54 Последнее редактирование: 06.09.11, 16:08:50 от Дед Мороз
А что скажете на утверждение:
Смысл в том, что конструктор должен удовлетворить требования заказчика в рамках НСИ
?

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

nagornick

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

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

У АСКОН этой интеграции очень много и вот мы видим в этой и соседних ветках все эти сложности типа interface not suppoirted, потому что бизнес компании подразумевает развитие взаимоисключающих направлений: комплексные решения vs локальные, продукты vs сервис.

Дед Мороз

06.09.11, 11:17:05 #56 Последнее редактирование: 06.09.11, 16:07:23 от Дед Мороз
Что должен рядовой конструктор более-менее понятно, если не задавать вопрос:

Что на самом деле "должна" спецификация ?
безотносительно этого вопроса другой
спецификация является некой частью механизма управления ??

хорошо, согласен ) на данном этапе она часть КИС
что дальше ?

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

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

Дед Мороз

07.09.11, 09:18:24 #57 Последнее редактирование: 07.09.11, 09:40:15 от Дед Мороз
Цитата: nagornick от 06.09.11, 09:36:05
Конструкторская спецификация -> Технологический состав (разбиение на подсборки, детали для испытаний, технлогические операции ...) -> Технологический состав с маршрутами/ТП -> Производственный заказ (+ замены)
:?:
Производственный заказ (+ замены) ->
Цитировать
Конструкторская спецификация -> Технологический состав (разбиение на подсборки, детали для испытаний, технлогические операции ...) -> Технологический состав с маршрутами/ТП
приоткрыть скрытое  :shu: ( путём голосования ржу как лошадь)

Дмитрий22

Цитата: nagornick от 06.09.11, 10:55:33
Конструктор должен
1. Спроектировать изделие с требуемыми ТТХ
2. Обеспечить производство и технологов информацией, достаточной для изготовления изделий и в виде, позволяющем обработку данных в КИС с минимальными трудозатратами.

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

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

Maxxx

Значит у них так внедрили.... что у конструкторов время уходит на ввод данных...