Перейти к публикации

Рекомендованные сообщения

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

ДЭ (Документ Электронный), по ГОСТ 2.051 - это "Документ, выполненный как структурированный набор данных, создаваемых программно-техническим средством."

По ГОСТам конструкторских документов, каждый документ должен быть завизирован кучей подписей, например, обязательны - разработчик и н.контр.

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

Может, кто-нибудь использовал ЭСИ, как ДОКУМЕНТ, а не как 'удобную' базу данных? Или, хотя бы имеет представление о том, как это сделать?

Лично у меня постоянно возникают какие-то сложности. Убился ГОСТы читать, не нахожу ответов на многие вопросы. Вот, например:

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

2. Как сохраняется конкретная версия документа? Всю БД слить на диск (скопировать в другое место)? Либо ГОСТ позволяет, чтобы используемая компьютерная система динамически строила ЭСИ, каждый раз, в зависимости от запроса "версии"?

Изменено пользователем AnTe
Ссылка на сообщение
Поделиться на других сайтах


Попытаюсь отчасти сам ответить на свои же поставленные вопросы. Вот, что нашёл в ГОСТ 2.051, про Документы Электронные (ИЕ = "Информационные Единицы"):

4.5 ДЭ подразделяют на простые, составные и агрегированные в зависимости от состава и способа

организации содержательной части:

- в простом ДЭ содержательная часть реализована в виде одной ИЕ;

- в составном ДЭ содержательная часть реализована в виде нескольких ИЕ, связанных друг с дру-

гом ссылками, как правило, определяемыми применяемым форматом данных;

- в агрегированном ДЭ содержательная часть реализована в виде нескольких ИЕ, информационно

связанных друг с другом;

4.6 ИЕ в ДЭ могут образовывать сложные иерархические структуры, имеющие совмещенные рекви-

зитные части и общие описания составляющих компонентов. При многократном использовании компонен-

тов допускается применение ссылок*.

Да, в комментарии к пункту сказано, что "активные ссылки" зачем-то должны быть организованы по какому-то ИСО 8879, похоже это SGML, в общем, что-то вроде более известного XML. Зачем - непонятно. Ну да ладно, похоже, что это частности.

В следующем пункте запрещают, и одновременно разрешают применение ссылок в утверждённом документе:

4.7 Если в документе используются ссылки, то при выпуске документа все ссылки должны быть

заменены на соответствующее им содержание. В составном и агрегированном документах, если его фор-

мат требует наличия ссылок, допускается оставлять ссылки при условии, что целостность таких ДЭ обес-

печивают программно-технические средства*.

Пытаемся переложить на практику.

Положим, у нас есть файлы, т.е. ИЕ, лежащие в одной папке :) каждый файл-ИЕ содержит полный состав этой ИЕ, == ссылки на другие файлы-ИЕ, а так же необходимую дополнительную информацию для ИЕ.

таким образом, получаем, что за ЭСИ, скажем, "автомобиля" можно взять весь этот набор файлов, указав "стартовую" ИЕ, которая в базе под номером 0000. За ЭСИ "моста" - ИЕ моста, и все файлы, участвующие при построении дерева программными средствами....

Вот и ответ на первый вопрос.

Ответ на второй вопрос - сохранив где-нибудь эту кучу файлов, определив доступ к ним, - автоматически сохраняем все участвующие в процессе документы-ЭСИ.

Единственное сомнение пока вызывает переход к базе данных. База данных обычно основана не на файловой системе, т.о., можно сказать, что вся куча файлов-ИЕ находятся в одном файле. Но в том же ГОСТ 2.051 прописано, что

3.1.8 информационная единица: Файл или набор файлов, рассматриваемый как единое целое.

То есть, если понять под словом "файл" привычные нам файлы в привычных:) операционных системах, то вроде как ИС формально не может быть частью файла базы данных.

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

То же сомнение про запросы к БД: может ли результат запроса к БД быть документом? Опять же, по упомянутому выше п 4.7, если БД обеспечивает целостность, что является необходимым условием разработки БД, - то может!

поправьте меня, если я где-то ошибся в рассуждениях

очень интересует вопрос, кто-нибудь использует ЭСИ как действующий конструкторский документ?

или всё остаётся на уровне "удобная база данных, для всех"?

буду признателен за любые ответы по этой теме!

Изменено пользователем AnTe
Ссылка на сообщение
Поделиться на других сайтах

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

Мне кажется, что нужно идти от назначения и понятий: что такое документ и что такое ГОСТ?

Документ - информация, оформленная по неким правилам, обязательно содержащая реквизитную часть. Так как отчет из БД не содержит в себе реквизитов - то сам по себе документом не является.

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

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

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

Насколько же ГОСТ удобен - это совсем другой вопрос. Просто сейчас так, другого нету.

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

Ссылка на сообщение
Поделиться на других сайтах

очень интересует вопрос, кто-нибудь использует ЭСИ как действующий конструкторский документ?

Да мы ЭСИ создаем, как конструкторский документ, с момента внедрения PLM Windchill. Однако создавать и использовать это две разные вещи, особенно имея в виду понятие - база данных.

Создавая ЭСИ надо хорошо понимать для чего и как Вы сможете ее использовать.

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

Внедрение АСУпр позволило автоматизированно осуществлять подготовку производства изделий.

В настоящее время, проводятся работы по переводу этой базы данных под Windchill. Т.е АСУпр и Windchill становятся компанентами единой информационной сиситемы предприятия.

Ссылка на сообщение
Поделиться на других сайтах

очень интересует вопрос, кто-нибудь использует ЭСИ как действующий конструкторский документ?

или всё остаётся на уровне "удобная база данных, для всех"?

буду признателен за любые ответы по этой теме!

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

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

Ссылка на сообщение
Поделиться на других сайтах

ЭСИ строится на основе САПРовской модели изделия в PDM-системе.

С этим можно отчасти поспорить.

Прежде всего ЭСИ должна строиться, не только на основе сапровской модели, но и сугубо самостоятельно. Я полагаю, далеко не все САПРы позволяют по своим данным строить ЭСИ (например AUTOCAD). Во вторых т.к. ЭСИ должна создаваться для каждой СП, в том числе для комплектов всех мастей (комплекты аппаратуры, подборных частей, запасных частей и т.п.), а также для СП на программные изделия (не будем забывать, что роль программных изделий в общей массе железа сейчас резко возрастает).

СБ получается независимо от PDM.

Если уж ЭСИ строится на основе сапровской модели, то и СБ строят на основе тойже модели, а электронная модель в этом случае должна быть зависима от PDM.

А вот если СБ строится сам по себе (без модели), то ЭСИ придется набивать ручками, опираясь на данные базы данных компонентов и PDM.

Ссылка на сообщение
Поделиться на других сайтах

ЭСИ должна строиться, не только на основе сапровской модели, но и сугубо самостоятельно.

Совершенно согласен, что не только по модели. Более того, у нас структуры изделий (намеренно избегаю сочетания ЭСИ, поскольку это уже считаем документом) строятся совершенно независимо. Хотя есть SW, PDM-W. А структура строится "ручками", дублируется, естественно с ошибками :sad: . Это совершенно недопустимо, но пока так :wallbash: . Пэтому я сделал акцент на последовательности САПР-модель, PDM, ЭСИ.
Ссылка на сообщение
Поделиться на других сайтах

Документ - информация, оформленная по неким правилам, обязательно содержащая реквизитную часть. Так как отчет из БД не содержит в себе реквизитов - то сам по себе документом не является.

Кто ж сказал, что не содержит? Просто, акцентируя внимание на содержательную часть, про реквизитную, как вроде мелочь на фоне проблем с содержательной, я умолчал:)

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

Что такое ГОСТ - стандарт, то есть правила.

..

Кстати, спасибо за рассуждения о сути ГОСТов, в голове что-то подобное было, в виде каши, а тут всё уложено, по полочкам:)

Наше предприятие интенсивно работает с различными заказчиками, смежниками, поэтому, вероятно, разумнее подойти к ГОСТам как можно ближе сразу, чем "дорабатывать напильником" потом.

С использованием ЭСИ не как документа дело тоже труба. Найдутся такие, которые не будут заполнять, или, что хуже, будут заполнять её не верно, т.к. "зарплату я получаю за выпущенный документ"

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

Тут дело ещё круче! Как следует из определения, ЭСИ непременно должна содержать "иерархические отношения (связи) между его составными частями", т.е. если вложенность ограничить, то, скажем, где в ЭСИ на автомобиль связь между колесом и гайкой? В ЭСИ должно содержаться ВСЁ!

Появляются всё те же проблемы с изменениями, обозначенными Странником в соответствующем треде: если гайку заменили - изменены не только ЭСИ колеса, но и ЭСИ моста, ЭСИ самого автомобиля! Всё заново переутверждать. :wallbash:

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

Да, на счёт "простоты" впорос ещё тот. Позиции придётся добавлять вручную. А ведь сейчас множество средств, вроде автокадовского Mechanics, или в компасе, спецификации с позициями получаются автоматом. Вот блин предложи такую полуатоматизированную систему получения спецификций с ЭСИ.. столько воплей будет, что "работать мешаете":) Изменено пользователем AnTe
Ссылка на сообщение
Поделиться на других сайтах

Не пойму, а что мешает получать (не вручную) ЭСИ на основе спецификации, которую конструктор все равно делает (хоть почти и автоматом)?

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

Ссылка на сообщение
Поделиться на других сайтах

Не пойму, а что мешает получать (не вручную) ЭСИ на основе спецификации, которую конструктор все равно делает (хоть почти и автоматом)?

О! это подход с другой стороны :) вообще говоря, с этой стороны я и подходил изначально. Проблема заключается в том, что спецификации получают в разных средах, в разных форматах (вплоть до того, что кто-то вбивает буквы в шаблонах word или excel), для того, чтобы получать информацию со спецификации, необходимо, чтобы вид был един. Сейчас в pdm если и кладут спецификации, то строго в pdf

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

Или хотя бы с учетом ее (если кому нужны позиции).

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

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

Ну если систем несколько, то не родной для ПДМ системы действительно. Можно принять единый стандарт, конвертировать спецификации в тот же Exsel, откуда можно уже поднять.

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

Не понял? Ведь специя получается автоматом, за исключением моментов оформительного характера. А Наименование - Обозначение вводится (должно) только один раз при создании модели.

В концев концов спецификация, это всего лишь урезанный вариант ЭСИ. И ПДМ на основе данных спецификации (Состав изделия) подымает из моделей дополнительные данные.

Ссылка на сообщение
Поделиться на других сайтах

Ну если систем несколько, то не родной для ПДМ системы действительно. Можно принять единый стандарт, конвертировать спецификации в тот же Exsel, откуда можно уже поднять.

Из Excel? Сложновато будет. У нас сейчас примерно такая схема и работает. Сидит целая комната девочек, которые ВРУЧНУЮ забивают данные из спецификаций, к-ые к ним приносят в бумажном виде, чтобы заполнить базу в отделе планирования....

Не понял? Ведь специя получается автоматом, за исключением моментов оформительного характера. А Наименование - Обозначение вводится (должно) только один раз при создании модели.

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

В конце концов спецификация, это всего лишь урезанный вариант ЭСИ. И ПДМ на основе данных спецификации (Состав изделия) подымает из моделей дополнительные данные.

Да, получается, если не принять за основу ЭСИ - нужно создать: 1. редактор спецификации 2.конвертер спецификация-ЭСИ, с контролем возможных ошибок, и пр.

А если принять ЭСИ за основу - то нужно только программу для получения отчётов в форме СП.

Вообще, как понимаю, переформулировать вопрос можно следующим образом: откуда получать спецификацию, из ЭСИ или ЭМИ (Электронная Модель Изделия). По смыслу мне кажется, что СП получать однозначно из ЭСИ. т.е. из ЭМИ получить ЭСИ, а из ЭСИ уже СП :rule::flush:

ps мда, по идее, это для темы "спецификация", но, с другой стороны, по всей видимости, "спецификация" и "ЭСИ" можно хоть объединять :doh:

Ссылка на сообщение
Поделиться на других сайтах

Кто ж сказал, что не содержит? Просто, акцентируя внимание на содержательную часть, про реквизитную, как вроде мелочь на фоне проблем с содержательной, я умолчал:)

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

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

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

Наше предприятие интенсивно работает с различными заказчиками, смежниками, поэтому, вероятно, разумнее подойти к ГОСТам как можно ближе сразу, чем "дорабатывать напильником" потом.

Если "напильником" - то наверное да, лучше сразу по ГОСТам. А вот если "не напильником", а по удобной отработанной технологии с малой трудоемкостью, то вряд ли сразу по ГОСТ - разумно.

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

С использованием ЭСИ не как документа дело тоже труба. Найдутся такие, которые не будут заполнять, или, что хуже, будут заполнять её не верно, т.к. "зарплату я получаю за выпущенный документ"

Тут дело ещё круче! Как следует из определения, ЭСИ непременно должна содержать "иерархические отношения (связи) между его составными частями", т.е. если вложенность ограничить, то, скажем, где в ЭСИ на автомобиль связь между колесом и гайкой? В ЭСИ должно содержаться ВСЁ!

По моему в определении нет ни слова о необходимости включения в конкретную ЭСИ всех уровней иерархии..

Но если ЭСИ выполнять когда необходимо (при передаче на сторону) по "удобной отработанной технологии" - то какие проблемы? Даже легче все уровни иерархии воткнуть (настройка отбора меньше).

Появляются всё те же проблемы с изменениями, обозначенными Странником в соответствующем треде: если гайку заменили - изменены не только ЭСИ колеса, но и ЭСИ моста, ЭСИ самого автомобиля! Всё заново переутверждать. :wallbash:

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

А если глубже копнуть - так и спецификация, как документ, может и не нужна вовсе?

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

А вот нужно ли это в каждом конкретном случае - см. договор с заказчиком. Если в договоре ни слова - то на усмотрение исполнителя (опять цитата из ГОСТ).

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

Ссылка на сообщение
Поделиться на других сайтах

Из Excel? Сложновато будет. У нас сейчас примерно такая схема и работает. Сидит целая комната девочек, которые ВРУЧНУЮ забивают данные из спецификаций, к-ые к ним приносят в бумажном виде, чтобы заполнить базу в отделе планирования....

А сохранить электрнную спецификацию в промежуточный формат, который понимает ПДМ, уже трудно?

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

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

Второе вообще не понял. обозначение-наименование вводится только один раз.

1. редактор спецификации 2.конвертер спецификация-ЭСИ, с контролем возможных ошибок, и пр.

Все это уже есть в системе CAD, да и конвентер нужен только в случае если ПДМ система не может поднять нужные данный из не родной для нее системы.

Ссылка на сообщение
Поделиться на других сайтах
  • 3 недели спустя...

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

По поводу электроных моделей согласен - см. примечаниях к таблице 4 ГОСТ 2.102-68 изм. 8. , а вот насчтет необязательности спецификации при наличии ЭСИ помоему Вы погорячились. В ГОСТ 2.102 в примечаниях к таблице 3 указано, что Спецификацию, ВС, ВД, ВП, ВИ, ДП, ПТ, ЭП, ТП, ВДЭ, ЗИ, ВЭ и др. при выполненнии автоматизированным способом следует получать, при возможности, в форме отчета из электронной модели. И никаких указаний о необязательности спецификации.

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

- автоматизация оформления КД;

- автоматизация подготовки производства.

Таким образом мы получаем три обязательных конструкторских документа: чертеж детали, СП и ЭСИ :g:

Остается решить ряд вопросов:

1 Согласно ГОСТ 2.102 ЭСИ есть конструкторский документ, а коли так эначит должен иметь свой КОД документа, однако согласно таблицы 3 его нет (значит обозначение ЭСИ такое же как у СП), но согласно табицы 4 ЭСИ имеет дополнительный код "ЭС", который должен быть указан в реквизитной части документа (т.е. согласно ГОСТ 2.051-2006 присваивая обозначеие ЭСИ в системе PDM я должен вместо УЖАС.123456.789 указать УЖАС.123456.789ЭС ??).

2 Должен ли конструктор, оформляя СП на изделие, с момента разработки ЭСИ, вводить ее обозначение и наименование в СП в раздел Документация? (непонятно как работает "дополнителный код")

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

3 Как корретировать ЭСИ (через извещение? - абонет который использует данные ЭСИ ведь должен получить информацию о ее замене), ведь не всякая корректировка СП может быть связана с корректировкой ЭСИ или это неотвратимо?

4 Должна ли версия СП совпадать с версией ЭСИ?

Решение этих вопросов возможно лежит на пути принятия следующего решения. Через СТП должно быть доведено следующее - ЭСИ есть не самостоятельный конструкторский документ, а часть СП, предствленная в виде совокупности данных, с последующим наложением соответствующего шаблона СП.

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

Изменено пользователем DGroot
Ссылка на сообщение
Поделиться на других сайтах

Конструктор работает с моделями, пусть и далее с ними работает, а все чертежи, ЭСИ, СП должны легко либо даже автоматически строиться с модели. Собственно для этого ЭЦМ и нужны.

Просматривается как бы отражение события через фильтры тех или иных задач.

Ссылка на сообщение
Поделиться на других сайтах

..По поводу электроных моделей согласен - см. примечаниях к таблице 4 ГОСТ 2.102-68 изм. 8. , а вот насчтет необязательности спецификации при наличии ЭСИ помоему Вы погорячились...

Если смотреть определения ЭСИ и спецификации, а также п. 2.2 указанного стандарта, кажется, написано однозначно.

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

Это, по моему, и есть ключевой вопрос.

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

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

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

Но тенденции и темпы развития, как мне кажется, все очень скоро изменят.

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

Ссылка на сообщение
Поделиться на других сайтах

В другой ветке

<noindex>http://fsapr2000.ru/index.php?showtopic=2...mp;#entry209794</noindex>

пользователь Ruslan сделал интересное заявление, близкое к тематике этого топика.

Повторю еще раз, для состава изделия, грузить геометрию нет ни какой необходимости.

Когда ЭСИ уже есть, то каждый раз загружать всю модель может и не надо, но как эту структуру изначально получить?

Итак, мне известно 3 способа построения ЭСИ:

1. Автоматически по полноценному ЭЦМ;

2. Частично по модели с дополнением вручную;

3. Полностью вручную.

Каким же образом можно получить ЭСИ без геометрии и не прибегая к обезьяноподобной работе операторов?

Как ни крути, а хотя бы пустые элементы (подсборки, детали и т.п.) в CAD дереве проекта расставлены быть должны.

Набить вручную спецификацию, например, посредством WORD и через какой ни будь транслятор получить ЭСИ в PDM?

Всё одно на лицо обезьянья работа и очень широкое поле для последующих неприятностей.

Ссылка на сообщение
Поделиться на других сайтах

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

Все проблемы начинаются тогда, когда Вы имеете большой задел деталей на бумажном носителе или в электронном виде, но в каком-нибудь AUTOCADe, а проектирование ЭЦМ надо осуществлять в ProE. Или того хуже Вы 10 лет проектировали в ProE, сдавая в архив только "фотографии" чертежей в формате PDF, а ЭЦМ хранили локально, не имея возможности (не организовав) их хранить в файловом архиве. При этом 90% всех новых разработок базируются на ранее созданном заделе деталей (и денег на перепроектирование никто давать не торопится - попробуй объясни заказчику, что для того чтобы "жить красиво и счастливо" в PDM, тебе надо полностью перепроектировать в ProE сборку из 1000и деталей).

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

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

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • lem_on
      По моему вполне логично если станок вывалится в ошибку если рука не доехала до места. У меня так же если кулачки или деталь на пути, просто пихаеш ее до места и станок опять активен. Но нынешние пановья даже не могут написать модель станка.
    • Viktor2004
      Я согласен что скорее всего проблема механическая Но если логика прописана криво и возможно не предусмотрела остановку в промежуточном состоянии, разве не логично будет попробовать принудительно подав напряжение дернуть эту руку вверх-вниз? Возможно то что туда попало выпадет  
    • Guhl
      Если оставить за скобками вопрото том, что до м19 работает нормально, а после нет, то вы не считали сколько у него реально импульсов на оборот? с помощью стороннего плк, например  А если ориентацию м5 снимать, а не м20?
    • lem_on
      Что это за станок такой в котором сразу ладер ковырять надо, даже не смотря на возможность механической проблемы? Или профдеформация?
    • Viktor2004
      не сразу я понял в чем вопрос. Долго соображал что такое режим управления скоростью. При завершении ориентации PMC снимает сигнал G70.6 ? И если он после снятия сигнала продолжает удерживать шпиндель, при каких условиях эта ориентация все же снимается? После нажатия аварийного грибка или еще как?
    • Viktor2004
      Ладдер пришлите. Будем принудительно пробовать поднимать и опускать
    • streamdown
      Коллеги приветствую! IPS 8. Подскажите пожалуйста, кто какое серверное железо использует? Интересуют параметры при одновременной работе, ну например, 400 пользователей онлайн
    • gudstartup
      так он так и позиционируется по m19 pmc выдает g70.6 а чпу отвечает f45.7 но ориентацию и смещение в 4077 он отрабатывает нормально шпиндель встает ровно и смена происходит хорошо. вопрос почему после ввода команды управления скоростью он все еще продолжает контролировать число импульсов между нуль метками хотя в принципе уже должен отменить позиционный контроль и просто считать обороты по 0 метке как он это делает без М19? это все понятно но почему оно продолжает проверять это после завершения ориентации мне непонятно
    • Александр1979
      SP9047 SSPA:47 ILLEGAL SIGNAL OF POSITION CODER "The relationship between the A/B phase and 1-rotation signal is incorrect (Pulse interval mismatch)." "Неправильное значение счетчика импульсов сигнала на энкодере ALPHAi. На фазах A и B энкодера за один оборот шпинделя насчитывается 4096 импульсов обратной связи. Программное обеспечение по управлению шпинделем проверяет количество импульсов на фазах A и B, соответствующее энкодеру, при каждой генерации сигнала одного оборота. Данный аварийный сигнал срабатывает, если регистрируется число импульсов, нарушающее заданный диапазон."
    • vs3dpro
      Добрый день! У нас на есть SLA принтер 600х600х400мм. Можно напечатать мастер- модели, и можно приехать посмотреть. mail@iges.space
×
×
  • Создать...