Спецификации

[sceptic 0]

По п.3 - это новая тема для обсуждения ??? Потытка ответа на него в ГОСТ 2.051-2006.

sceptic, уточните, что Вы имели в виду. Задайте вектор обсуждения.

Вектор уже задан и не мной. Я только высказал опасение, что если не установить единые правила использования PDM-PLM систем (номенклатуру разрешенных или, если хотите, рекомендованных систем, правила использования соответствующих электронных документов и т.д.), это же касается и CAD-CAM систем, бардак будет только нарастать. Кто этим займется, я не знаю. Обычно бывает два пути - авторитарный и демократический. Авторитарный, в данном случае, это разработка и навязывание правил органами стандартизации (Ростехрегулирования). Демократический подразумевает развитие снизу, т.е. метод проб и ошибок, набитые шишки и сломанные шеи и т.д. и т.п. Пока мы идем вторым путем. Может он и вернее, но длиннее. А первый метод часто эффективней, но по аналогии с диктатурой, только если диктатор "хороший".

[DGroot 8]

sceptic, почитайте, возможно несовсем в тему. Но однако.

<noindex>http://authorit.ru/?c=9</noindex>

«юзабилити» (usability), что в словарях приблизительно переводится, как «удобство и простота использования, практичность» программного обеспечения. Самих специалистов называют «юзабилистами»».

Изменено 10 июля 2008 пользователем DGroot

[sceptic 0]

sceptic, почитайте, возможно несовсем в тему. Но однако.

<noindex>http://authorit.ru/?c=9</noindex>

Не совсем понятно, что вы имели в виду, отсылая к этой статье. При разработке чего бы то ни было, как в поварском деле, всегда много пены. Блюдо варится не ради пены, но она неизбежна. Разрабатывать правила надо, в противном меня никто не убедит!

[AnTe 1]

AnTe

Хотелось бы услышать коментарий на мои замечания. О том я написал или не о том?

О том!

Большое спасибо за замечания. Сначала по ним пробегусь, это важно для меня :)

1 Содержание - от балды (извините, сами просили не стесняться). Так не бывает.

Да, но "редактор" позволяет писать любые текстовые значения в известные семь полей спецификации, и всё! Все "объекты" имеют одно окно для редактирования.

2 Заголовки разделов не выделены пустыми строками. Это ухудшает читабельность.

Да, нужно подумать. Пустых строк не было по определению, т.к. "объекты" в том списке, что приведён скриншот, можно сортировать вручную вверх-вниз, в т.ч., перемещая из раздела в раздел.

3 Весь текст набран в верхнем регистре. Ухудшает читабельность.

Наименования содраны с используемой БД-ОБДИ, т.е. при вводе обозначения, при попытке набора наименования, программа выдаёт наиболее подходящие варианты. В базе все наименования, почему-то, в верхнем регистре.

4 Не понятно назначение красного цвета.

Тоже с потолка.. Реализовал сразу в программе возможность выделения цветом, пока не придумал, чего именно, поэтому, "подкрасил" объекты, имеющие одинаковое обозначение. Скорее всего, в реальной практике такое не понадобится.

А теперь ещё по теме нашего обсуждения.

Замечаний по интерфейсу нет. Так как он очень простой.

Я бы сказал, простой донельзя. Предназначен для заполнения полей таблицы документа СП.

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

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

В любом случае, надеюсь, такое 'отображение' бланка СП не слишком смутит конструктора?

Приведенная спецификация получается (или будет получаться) из какого-то САПРа или из записей в БД?. Если не секрет, какая решается задача?

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

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

[DGroot 8]

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

Или это еще один пример того, почему СП нельзя исключать из обращения и заменить электронной структурой изделия.

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

Изменено 13 июля 2008 пользователем DGroot

[brigval 722]

Как такой способ оформления увязать с автоматизацией обработки информации в СП.

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

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

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

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

Я лично не сторонник деталей БЧ:

1 Работая в 3D Модель детали БЧ делать все-равно придется.

2 Сделать с прямоугольного параллелепипеда чертеж займет времени 10 минут.

3 Если выпущен документ, деталь можно заимствовать и в других сборочных единицах.

4 При внесении изменений в деталь-с-документом не надо править спецификацию, которая иногда согласовывается в верхних инстанциях.

5 Технологический контроль не распространяется на спецификации. В них нет подписи Т. контр. А значит могут быть ошибки.

6 Не уверен точно, но думаю, что и технологам удобнее работать с "бумажкой", нежели с записю в спецификации.

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

8 И т. д. и т. п.

Выпуск документа, в этом случае, снимает много проблем по обработке информации.

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

[VOleg 228]

Не вижу никаких проблем с БЧ деталями в СП, оформляемой в базе данных.

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

[brigval 722]

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

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

[VOleg 228]

В данном примере отразились наши шатания по поводу обозначений бесчертежных труб. Децимальный номер состоит из размеров профиля и длинны. Это было навеяно стандартом ISO (когда создаешь трубу из ToolBox - ISO - она по умолчанию имеет подобный номер). Так что сейчас живут оба варианта децимальных номеров.

[brigval 722]

Децимальный номер состоит

То, о чем Вы пишите, не является децимальным номером. Одим из параметров децимального номера (точне, обозначения, по ГОСТ 2.201) является наличие порядкового регистрационного номера. А значит запись трубы не является записью детали БЧ. Это просто удобная для Вашего предприятия запись под "деталь БЧ", и больше ничего. Спасибо за скриншот и... извините за буквоедство.

[brigval 722]

AnTe

Попробую сформулировать свои замечания.

"редактор" позволяет писать любые текстовые значения в известные семь полей спецификации

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

Например в графу "Формат" могут быть введены только

А5

А4

А3

А2

А1

А0

БЧ

*)

-

И то не во всех разделах.

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

Есть ли смысл позволять пользователю в эту графу вводить все что угодно?

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

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

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

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

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

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

Может понадобиться. Выделением цветом можно сообщать об ошибочных данных. О слишком длинных записях...

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

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

[brigval 722]

AnTe

Я попробовал сделать сравнительную таблицу SWR-Спецификации и Таип-спецификации.

Если интересно, взгляните.

<noindex>http://dwg.ru/f/showthread.php?t=23520</noindex>

[VOleg 228]

Если интересно, взгляните.

Интересно, взглянули.

"Вставка и обновление таблицы исполнений на сборочном чертеже" - это свойство Солида - "да"

"Основная надпись

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

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

[brigval 722]

VOleg, спасибо за ответ!

"Вставка и обновление таблицы исполнений на сборочном чертеже" - это свойство Солида - "да"

В описании SWR-спецификации это не отражено. Исправлю при обновлении таблицы, если обновление будет.

"Основная надпись

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

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

А во-вторых, на разных предприятиях работают по разному.

А в модель Вы вводите данные вручную?

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

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

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

[VOleg 228]

А в модель Вы вводите данные вручную?

Да. Пока еще компьютер не умеет читать мои мысли. (Шутка).

Модель - это то, что является основой - чертеж - это отображение модели.

"Проверка обозначения на зарегистрированность" - это свойство модели, а не основной надписи или спецификации или чертежа.

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

[brigval 722]

Модель - это то, что является основой - чертеж - это отображение модели.

Я полагаю с точностью до наоборот.

Скорее всего, чертеж - это "отображение" готового изделия.

Ни одна компьютерная 3D-модель не может включать все данные которые могут содержаться в чертеже. Например, запись "*Размеры для справок", таблицу исполнений и т.д.

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

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

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

Все сказаное про чертеж можно распространить и на спецификацию.

"Проверка обозначения на зарегистрированность" - это свойство модели, а не основной надписи или спецификации или чертежа.

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

У меня в Таипе обозначение + наименование тоже заносятся в свойства модели (в Part Number), но уже автоматом при заполнении основной надписи чертежа. И вставляются в модель именно из основной надписи чертежа. В основную надпись обозначение + наименование попадают из выпадающего списка, формируемого на основе реестра зарегистрированных обозначений. Ручного ввода нет и проверка, по идее, не нужна. Но практика показала, что и из выпадающего списка могут быть взяты не те обозначения. Да и на начальном этапе конструирования не всегда есть зарегистрированное обозначение. Есть и другие причины.

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

А вот выпадающие списки в модели Солида практически отсутствуют. Вот это плохо

Я это тоже заметил.

[Ruslan 945]

Ни одна компьютерная 3D-модель не может включать все данные которые могут содержаться в чертеже. Например, запись "*Размеры для справок", таблицу исполнений и т.д.

В том то и дело, что может.

Да и насколько я знаю VOleg именно так и делает.

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

[VOleg 228]

Например, запись "*Размеры для справок", таблицу исполнений и т.д.

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

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

И вставляются в модель именно из основной надписи чертежа.

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

Для справки, я в SolidWorks работаю - там все хорошо "заточено". И очень удобно.

А наименование файла = децимальному номеру. Так что при повторении просто и не сохранишь.

Да и на начальном этапе конструирования не всегда есть зарегистрированное обозначение

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

да и как быть с безчертежными деталями

Бесчертежные детали имеют полностью оформленные модели по всем правилам. При изготовлении их на нашем производстве - мы чертежи не оформляем - по ГОСТ в СП соотв. запись.

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

Так что сегодня БЧ, завтра Ч - модель д.б. идеальная...

[brigval 722]

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

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

В том то и дело, что может.

Да и насколько я знаю VOleg именно так и делает.

Да я не против. Я знаю примеры организации работы на предприятиях. Вы мне сообщили еще об одном. Только и всего.

Я вижу первую задачу - автоматизировать рутинную работу конструктора, котора может занимать до 90% рабоченго времени. Все остальное - потом. Ручное заполнение свойств модели (как и ручное наполнение ЭСИ) мне не подходит.

Так что сегодня БЧ, завтра Ч - модель д.б. идеальная...

Я тоже не стронник применения деталей БЧ. Сделать чертеж на такую деталь не проблема. Зато много откидывается проблем, связанных с делями БЧ.

[Ruslan 945]

Ручное заполнение свойств модели (как и ручное наполнение ЭСИ) мне не подходит.

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

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

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