BOM

Sat Jan 22 2005 10:31, Vitaly Polikarpov wrote to Alex Kouznetsov:

VP> Тема в общем-то для rus.pcad..

Я думал, что rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.

AK>> Кто чем пользуется для составления bill of materials (BOM)? AK>> Или, в терминах ГОСТ - перечня элементов и спецификации?

VP> Большинство пакетов его генерит само в том или ином виде, не претендующем VP> на полноту - минимум для составления ПЭ3, но не ведомости покупных, VP> используемых конструкционных, оперативного расчета себестоимости по VP> комплектации и тп.

VP> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они VP> версиезависимы - с P2001, к примеру, не живут, да и не решают VP> вышеозначенных задач.

Правильно ли я понял, что эти тулзы:

-- Привязаны к конкретному пакету (ПКАД), даже еще хуже - к версии пакета

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

VP> Можно использовать Orcad CIS, внутренние возможности которой весьма VP> убоги. Hо, если думать о внешних, то никто не мешает SQL-запросом VP> связать уже сгенеренный BOM c полями произвольной БД, как и использовать VP> средства генерации отчетов DBMS или сторонние, например, тот-же Crystal VP> Report, что и Orcad.

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

Я пока больше склонен копать в сторону Context Management System. Что-нибудь на основе PHP+MySQL, типа eGroupWare. Если бы к этому добавить PHP скрипты, заточенные на обслуживание специфических баз данных (т.е. ведение стока, библиотека компонентов, и т.п), и на генерацию доки (включая BOM), то могла бы получиться икебана.

Пока, Алексей

AK> Правильно ли я понял, что эти тулзы: [...]

AK> -- Делают не все, что хотелось бы, так что после них все равно приходится AK> править ручками "Так отож". У меня больше половины схем в итоге имеют несколько вариантов исполнения, это забито в табличке на полях схемы. Может и можно как-то хитро сделать табличку и через DBX и это вытащить в соответствующий документ, но...

Проще оказывается AK> в основном все делают доку врукопашную. причём руками "более младшего конструктора" ;-)

wbr,

Mon Jan 24 2005 08:43, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> Проще оказывается

AK>> в основном все делают доку врукопашную.

OR> причём руками "более младшего конструктора" ;-)

В принципе монотонную нетворческую работу комп сделает лучше и дешевле. А так-то, конечно, и Беломорканал лопатами копали...

Пока, Алексей

OR>> Проще оказывается

AK>>> в основном все делают доку врукопашную.

OR>> причём руками "более младшего конструктора" ;-)

AK> В принципе монотонную нетворческую работу комп сделает лучше и дешевле. Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта вот схема имеет 3 варианта исполнения, в двух из которых вон_то не паяется, а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот, паяется вон_то, а вот_эти резисторы не паяются. Я просто не знаю, как такое объяснить пикаду, чтобы он и до BOM-а это довёл :-) А "более младешму" я это за пару минут излагаю и он сначала рисует нужную табличку на полях схемы (пикад сам это всё равно не сделает), а потом делает ПЭ3 с вариантами исполнения и нужное количество вариантов Э7. При этом самую монотонную работу - подсчёт сколько чего есть - делает всё равно компьютер, а выдаст он это в виде стандартного пикадовского report-а или сразу в виде вордовского, к примеру, файла - разница невелика на фоне остальной работы "младшего".

wbr,

Tue Jan 25 2005 01:12, Oleksandr Redchuk wrote to "Alex Kouznetsov":

AK>>>> в основном все делают доку врукопашную.

OR>>> причём руками "более младшего конструктора" ;-)

AK>> В принципе монотонную нетворческую работу комп сделает лучше и дешевле.

OR> Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта OR> вот схема имеет 3 варианта исполнения, в двух из которых вон_то не OR> паяется,

Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута "исполнение".

OR> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот, OR> паяется вон_то, а вот_эти резисторы не паяются.

Это можно описать в виде внешней таблицы. Например, xls

OR> Я просто не знаю, как такое объяснить пикаду, чтобы он и до BOM-а это OR> довёл :-)

Импорт в BOM наверняка ведь есть, в том или ином виде. Задача состоит в том, чтобы взять импорт, скрестить его с xls табличкой, с результатом пошарить по базе данных, и сгенерировать сам BОM. Выглядить это как весьма посильная работа для php скрипта.

OR> А "более младешму" я это за пару минут излагаю и он сначала OR> рисует нужную табличку на полях схемы (пикад сам это всё равно не OR> сделает), а потом делает ПЭ3 с вариантами исполнения и нужное количество OR> вариантов Э7. OR> При этом самую монотонную работу - подсчёт сколько чего есть - делает OR> всё равно компьютер, а выдаст он это в виде стандартного пикадовского OR> report-а OR> или сразу в виде вордовского, к примеру, файла - разница невелика OR> на фоне остальной работы "младшего".

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

Пока, Алексей

AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:

AT>> А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....

AM> Хотя бы этy веткy не загаживай, энypезник.

Зря ты, ведь только хуже будет :-(

Wbr,

OR>> Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта OR>> вот схема имеет 3 варианта исполнения, в двух из которых вон_то не OR>> паяется,

AK> Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута AK> "исполнение". Для BOM-а да, можно что-то придумать.Какие-то value01 value02 и т.д. (у непаяющегося в данном исполнении элемента можно дать соответствующий аттрибут). После этого выброшенный из пикада BOM уже поддаётся осмысленной обработке. Но что-то не припомню, чтобы пикад мог включать/выключать элемент при печати в зависимости от того, есть ли у него определённые аттрибуты и от их значения.

OR>> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот, OR>> паяется вон_то, а вот_эти резисторы не паяются.

AK> Это можно описать в виде внешней таблицы. Например, xls На схеме табличка всё равно нужна, её хоть так, хоть так рисовать.

OR>> А "более младешму" я это за пару минут излагаю и он сначала OR>> рисует нужную табличку на полях схемы (пикад сам это всё равно не OR>> сделает), а потом делает ПЭ3 с вариантами исполнения и нужное количество OR>> вариантов Э7. OR>> При этом самую монотонную работу - подсчёт сколько чего есть - делает OR>> всё равно компьютер, а выдаст он это в виде стандартного пикадовского OR>> report-а OR>> или сразу в виде вордовского, к примеру, файла - разница невелика OR>> на фоне остальной работы "младшего".

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

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

Дык я не спорю, что всё, что *имеет смысл* автоматизировать - надо автоматизировать. В моём случае *эта* автоматизация (которой буду заниматься я) как своего рода "процесс разработки" нескоро окупится за счёт сэкномленного времени "младшего конструктора" (при нынешнем потоке схем). Хотя я уже сам иногда из любопытства поглядываю в эту сторону, выходным форматом скрипта, пожалуй, должен быть TeX :-)

wbr,

Tue Jan 25 2005 23:39, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> Hо что-то не припомню, чтобы пикад мог включать/выключать элемент при OR> печати в зависимости от того, есть ли у него определённые аттрибуты OR> и от их значения.

А оно надо? Имхо, схема может быть одной, все исполнения могут описываться в ВОМ-е. Но если уж _очень_ хочется, можно было бы зафигачить макросы, которые размножат варианты исполнения схемы из одной базовой.

OR>>> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот, OR>>> паяется вон_то, а вот_эти резисторы не паяются.

AK>> Это можно описать в виде внешней таблицы. Hапример, xls

OR> Hа схеме табличка всё равно нужна, её хоть так, хоть так рисовать.

В принципе скрипт мог бы на основе xls таблички сгенерить макрос, который прорисовал бы такую же табличку в схеме

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

OR> Дык я не спорю, что всё, что *имеет смысл* автоматизировать - надо OR> автоматизировать. В моём случае *эта* автоматизация (которой буду OR> заниматься я) как своего рода "процесс разработки" нескоро окупится OR> за счёт сэкномленного времени "младшего конструктора" (при нынешнем OR> потоке схем). OR> Хотя я уже сам иногда из любопытства поглядываю в эту сторону, OR> выходным форматом скрипта, пожалуй, должен быть TeX :-)

Я как-то не могу проникнуться прелестю ТеХ-а. Ну, если формулы писать, то понятно, а так-то зачем? Универсальным форматом данных может быть XML, а уж из него легко преобразовать во что угодно, в том числе и в ТеХ.

Пока, Алексей

OR>> Hо что-то не припомню, чтобы пикад мог включать/выключать элемент при OR>> печати в зависимости от того, есть ли у него определённые аттрибуты OR>> и от их значения.

AK> А оно надо? Имхо, схема может быть одной, все исполнения могут описываться AK> в ВОМ-е. Я не про схему, я про печатку, "сборочный".

AK> В принципе скрипт мог бы на основе xls таблички сгенерить макрос, AK> который прорисовал бы такую же табличку в схеме Только этот скрипт писать мне, а это

OR>> нескоро окупится OR>> за счёт сэкномленного времени "младшего конструктора" (при нынешнем OR>> потоке схем).

OR>> Хотя я уже сам иногда из любопытства поглядываю в эту сторону, OR>> выходным форматом скрипта, пожалуй, должен быть TeX :-)

AK> Я как-то не могу проникнуться прелестю ТеХ-а. Ну, если формулы писать, AK> то AK> понятно, а так-то зачем? Универсальным форматом данных может быть XML, а AK> уж из него легко преобразовать во что угодно, в том числе и в ТеХ. От BOM-а мне надо одно единственное - напечатать в нужном виде со всеми рамочками/полями для подписей и т.п. Зачем мне он в XML-е? Если автоматизировать насквозь всё, через суммирование комплектации по разным изделиям и разделение этого по отдельным спискам для каждого поставщика (см. выше про окупаемость этого у нас на фирме сейчас), то тогда логичнее вбросить в нормальную базу, а не в XML. Я понимаю, что и в XML можно нарисовать все нужные рамки, но чем он для данной задачи лучше TeX?

wbr,

AK>> Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута AK>> "исполнение". OR> Для BOM-а да, можно что-то придумать.Какие-то value01 value02 и т.д. OR> (у непаяющегося в данном исполнении элемента можно дать соответствующий OR> аттрибут).

Можно проще: $(путь_к_каду)/utils/variants.{exe|wri}.

BP> Можно проще: $(путь_к_каду)/utils/variants.{exe|wri}. Спасибо, не знал. Рылся по тому каталогу, но не всё перерыл значит (в работу только refdesud.exe пошло).

wbr,

Wed Jan 26 2005 23:26, Vitaly Polikarpov wrote to Alex Kouznetsov:

VP>>> Тема в общем-то для rus.pcad.. AK>> Я думал, что rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.

VP> не только - другие EDA/eCAD/eCAM тоже. Каким?

EasyPC

VP>>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они VP>>> версиезависимы - с P2001, к примеру, не живут, да и не решают VP>>> вышеозначенных задач. AK>> Правильно ли я понял, что эти тулзы: AK>> -- Привязаны к конкретному пакету (ПКАД), AK>> даже еще хуже - к версии пакета

VP> И мне так кажется (детально не проверял, но работает лишь с открытым VP> проектом), VP> с использованием OLE, а не DBX, спецификация на который не менялась VP> (afaik) VP> со времен Аccel v14. Hо, все еще хуже :) включая глюкавую проверку VP> его лицензионности (при идентичных инсталляшках на одной машине идет, VP> на другой - нет), введенную, по всей видимости, согласно пожеланиям VP> местных дристрибьюторов k$ глюкодромов.

VP> Вообще, ставя с содроганием очередной пакет с тупым менеджером лицензий VP> под мастдай, у которого в свою очередь глючит version control management VP> user interface (одни только MSVCRT, MSVCIRT чего стоят), гадаешь, что из VP> ранее установленного прижмурится на сей раз...

VP> В, общем, не IDE, а конструктор "Собери сам", который (PDM/TDM/CRM/..), VP> если-уж создавать, то на несколько иной, более стабильной и "прозрачной" VP> (в плане интерфейсирования) основе, как вариант, ODBC/DBMS.

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

VP> ПЭ3 в траурной рамке, дабы унасекомить нормоконтроль, оно (если захочет VP> :) в Ёксель передаст, а иного никто и не обещал :)

AK>>>> Соответствие ГОСТ меня не интересует,зато интересует привязка к AK>>>> базам данных. VP>>> Можно использовать Orcad CIS, внутренние возможности которой весьма VP>>> убоги. Hо, если думать о внешних, то никто не мешает SQL-запросом VP>>> связать уже сгенеренный BOM c полями произвольной БД, как и VP>>> использовать средства генерации отчетов DBMS или сторонние, например, VP>>> тот-же Crystal Report, что и Orcad. AK>> Спасибо за отклик. Поскольку ты единственный, кто ответил, можно AK>> предположить,что в основном все делают доку врукопашную.

VP> Я - не исключение, хотя с БД и работаю с 93го. VP> Если для конструктора, автоматизация этого потока может и стоит на первом VP> месте, то для схемотехника, важнее параметический подбор компонентов, VP> на который тратиться значительно больше времени, чем на его VP> квинтэссенцию.

Хотелось бы решать все в комплексе. Для подбора элементов по минимуму нужны три вещи:

-- БД элементов, имеющихся в стоке

-- Интернет для поиска новых

-- Е-мэйл для общения с поставщиками Меня напрягает разнородность этих инструментов. Слишком много приходится держать в голове. Сейчас я _частично_ решаю эту проблему при помощи dokuWiki, но это решение явно промежуточное.

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

AK>> Я пока больше склонен копать в сторону Content Management System. AK>> Что-нибудь на основе PHP+MySQL, типа eGroupWare. Если бы к этому AK>> добавить PHP скрипты, заточенные на обслуживание специфических баз AK>> данных (т.е. ведение стока, библиотека компонентов, и т.п), и на AK>> генерацию доки (включая BOM), то могла бы получиться икебана.

VP> Для принятия решений о месте web-технологий мне хватило копирования VP> одного CD (кажется, OnSemi) c ~20000 .htm в одной директрии DN-ном VP> (который ее перечитывает, перед копированием очередного) :)

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

Пока, Алексей