Do you have a question? Post it now! No Registration Necessary

BOM
Привет Alex!
13 Jan 05 12:05, Alex Kouznetsov -> All:
Тема в общем-то для rus.pcad..
Также послано в RUS.PCAD
AK> Кто чем пользуется для составления bill of materials (BOM)?
AK> Или, в терминах ГОСТ - перечня элементов и спецификации?
Большинство пакетов его генерит само в том или ином виде, не претендующем
на полноту - минимум для составления ПЭ3, но не ведомости покупных,
используемых конструкционных, оперативного расчета себестоимости по
комплектации и тп.
Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
версиезависимы - с P2001, к примеру, не живут, да и не решают
вышеозначенных задач.
AK> Соответствие ГОСТ меня не интересует,зато интересует привязка к
AK> базам данных.
Можно использовать Orcad CIS, внутренние возможности которой весьма убоги.
Hо, если думать о внешних, то никто не мешает SQL-запросом связать уже
сгенеренный BOM c полями произвольной БД, как и использовать средства
генерации отчетов DBMS или сторонние, например, тот-же Crystal Report,
что и Orcad.
Vitaly Polikarpov, vitvp[эt]mail.ru
13 Jan 05 12:05, Alex Kouznetsov -> All:
Тема в общем-то для rus.pcad..
Также послано в RUS.PCAD
AK> Кто чем пользуется для составления bill of materials (BOM)?
AK> Или, в терминах ГОСТ - перечня элементов и спецификации?
Большинство пакетов его генерит само в том или ином виде, не претендующем
на полноту - минимум для составления ПЭ3, но не ведомости покупных,
используемых конструкционных, оперативного расчета себестоимости по
комплектации и тп.
Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
версиезависимы - с P2001, к примеру, не живут, да и не решают
вышеозначенных задач.
AK> Соответствие ГОСТ меня не интересует,зато интересует привязка к
AK> базам данных.
Можно использовать Orcad CIS, внутренние возможности которой весьма убоги.
Hо, если думать о внешних, то никто не мешает SQL-запросом связать уже
сгенеренный BOM c полями произвольной БД, как и использовать средства
генерации отчетов DBMS или сторонние, например, тот-же Crystal Report,
что и Orcad.
Vitaly Polikarpov, vitvp[эt]mail.ru

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), то могла бы
получиться икебана.
Пока, Алексей
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), то могла бы
получиться икебана.
Пока, Алексей

Re: BOM
Hi Oleksandr!
25 янваpя 2005 01:12, Oleksandr Redchuk писал "Alex Kouznetsov":
AK>> В пpинципе монотоннyю нетвоpческyю pаботy комп сделает лyчше и
AK>> дешевле.
OR> А "более младешмy" я это за паpy минyт излагаю и он сначала
OR> pисyет нyжнyю табличкy на полях схемы (пикад сам это всё pавно не
OR> сделает),
Есть отечественный схемный pедактоp (Schematism ?), yмеет делать BOM в виде
классической ГОСТовской спецификации и pазмещать ее, пpи необходимости, на
одном листе со схемой. По фоpматy тайла совместим с пикадом. Есть на
www.gaw.ru.
P.S. С yдивлением обнаpyжил там пpогpаммy теpмического анализа электpонных
плат, pазpаботаннyю в pодном инститyте (КГТУ) 8-( ).
Best regard, Roman Gubaev! [Team Beer - rulez forever!]
e-mail: rgubaev[собака]yandex.ru
... РАО "ЕЭС России", Хакасэнеpго, Энеpгосбыт, гpyппа АСКУЭ
25 янваpя 2005 01:12, Oleksandr Redchuk писал "Alex Kouznetsov":
AK>> В пpинципе монотоннyю нетвоpческyю pаботy комп сделает лyчше и
AK>> дешевле.
OR> А "более младешмy" я это за паpy минyт излагаю и он сначала
OR> pисyет нyжнyю табличкy на полях схемы (пикад сам это всё pавно не
OR> сделает),
Есть отечественный схемный pедактоp (Schematism ?), yмеет делать BOM в виде
классической ГОСТовской спецификации и pазмещать ее, пpи необходимости, на
одном листе со схемой. По фоpматy тайла совместим с пикадом. Есть на
www.gaw.ru.
P.S. С yдивлением обнаpyжил там пpогpаммy теpмического анализа электpонных
плат, pазpаботаннyю в pодном инститyте (КГТУ) 8-( ).
Best regard, Roman Gubaev! [Team Beer - rulez forever!]
e-mail: rgubaev[собака]yandex.ru
... РАО "ЕЭС России", Хакасэнеpго, Энеpгосбыт, гpyппа АСКУЭ

Re: BOM
Привет Alex!
24 Jan 05 00:23, Alex Kouznetsov -> Vitaly Polikarpov:
VP>> Тема в общем-то для rus.pcad..
AK> Я думал, что rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.
не только - другие EDA/eCAD/eCAM тоже. Каким?
VP>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
VP>> версиезависимы - с P2001, к примеру, не живут, да и не решают
VP>> вышеозначенных задач.
AK> Правильно ли я понял, что эти тулзы:
AK> -- Привязаны к конкретному пакету (ПКАД),
AK> даже еще хуже - к версии пакета
И мне так кажется (детально не проверял, но работает лишь с открытым
проектом),
с использованием OLE, а не DBX, спецификация на который не менялась (afaik)
со времен Аccel v14. Hо, все еще хуже :) включая глюкавую проверку
его лицензионности (при идентичных инсталляшках на одной машине идет,
на другой - нет), введенную, по всей видимости, согласно пожеланиям местных
дристрибьюторов k$ глюкодромов.
Вообще, ставя с содроганием очередной пакет с тупым менеджером лицензий
под мастдай, у которого в свою очередь глючит version control management
user interface (одни только MSVCRT, MSVCIRT чего стоят), гадаешь, что из
ранее установленного прижмурится на сей раз...
В, общем, не IDE, а конструктор "Собери сам", который (PDM/TDM/CRM/..),
если-уж создавать, то на несколько иной, более стабильной и "прозрачной"
(в плане интерфейсирования) основе, как вариант, ODBC/DBMS.
AK> -- Делают не все, что хотелось бы, так что после них все равно
AK> приходится править ручками
ПЭ3 в траурной рамке, дабы унасекомить нормоконтроль, оно (если захочет :)
в Ёксель передаст, а иного никто и не обещал :)
AK>>> Соответствие ГОСТ меня не интересует,зато интересует привязка к
AK>>> базам данных.
VP>> Можно использовать Orcad CIS, внутренние возможности которой весьма
VP>> убоги. Hо, если думать о внешних, то никто не мешает SQL-запросом
VP>> связать уже сгенеренный BOM c полями произвольной БД, как и использовать
VP>> средства генерации отчетов DBMS или сторонние, например, тот-же Crystal
VP>> Report, что и Orcad.
AK> Спасибо за отклик. Поскольку ты единственный, кто ответил, можно
AK> предположить,что в основном все делают доку врукопашную.
Я - не исключение, хотя с БД и работаю с 93го.
Если для конструктора, автоматизация этого потока может и стоит на первом
месте, то для схемотехника, важнее параметический подбор компонентов,
на который тратиться значительно больше времени, чем на его квинтэссенцию.
AK> Я пока больше склонен копать в сторону Context Management System.
AK> Что-нибудь на основе PHP+MySQL, типа eGroupWare. Если бы к этому
AK> добавить PHP скрипты, заточенные на обслуживание специфических баз
AK> данных (т.е. ведение стока, библиотека компонентов, и т.п), и на
AK> генерацию доки (включая BOM), то могла быполучиться икебана.
Для принятия решений о месте web-технологий мне хватило копирования
одного CD (кажется, OnSemi) c ~20000 .htm в одной директрии DN-ном
(который ее перечитывает, перед копированием очередного) :)
Vitaly Polikarpov, vitvp[эt]mail.ru
24 Jan 05 00:23, Alex Kouznetsov -> Vitaly Polikarpov:
VP>> Тема в общем-то для rus.pcad..
AK> Я думал, что rus.pcad обсуждает ПКАД. А я пользуюсь другим пакетом.
не только - другие EDA/eCAD/eCAM тоже. Каким?
VP>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
VP>> версиезависимы - с P2001, к примеру, не живут, да и не решают
VP>> вышеозначенных задач.
AK> Правильно ли я понял, что эти тулзы:
AK> -- Привязаны к конкретному пакету (ПКАД),
AK> даже еще хуже - к версии пакета
И мне так кажется (детально не проверял, но работает лишь с открытым
проектом),
с использованием OLE, а не DBX, спецификация на который не менялась (afaik)
со времен Аccel v14. Hо, все еще хуже :) включая глюкавую проверку
его лицензионности (при идентичных инсталляшках на одной машине идет,
на другой - нет), введенную, по всей видимости, согласно пожеланиям местных
дристрибьюторов k$ глюкодромов.
Вообще, ставя с содроганием очередной пакет с тупым менеджером лицензий
под мастдай, у которого в свою очередь глючит version control management
user interface (одни только MSVCRT, MSVCIRT чего стоят), гадаешь, что из
ранее установленного прижмурится на сей раз...
В, общем, не IDE, а конструктор "Собери сам", который (PDM/TDM/CRM/..),
если-уж создавать, то на несколько иной, более стабильной и "прозрачной"
(в плане интерфейсирования) основе, как вариант, ODBC/DBMS.
AK> -- Делают не все, что хотелось бы, так что после них все равно
AK> приходится править ручками
ПЭ3 в траурной рамке, дабы унасекомить нормоконтроль, оно (если захочет :)
в Ёксель передаст, а иного никто и не обещал :)
AK>>> Соответствие ГОСТ меня не интересует,зато интересует привязка к
AK>>> базам данных.
VP>> Можно использовать Orcad CIS, внутренние возможности которой весьма
VP>> убоги. Hо, если думать о внешних, то никто не мешает SQL-запросом
VP>> связать уже сгенеренный BOM c полями произвольной БД, как и использовать
VP>> средства генерации отчетов DBMS или сторонние, например, тот-же Crystal
VP>> Report, что и Orcad.
AK> Спасибо за отклик. Поскольку ты единственный, кто ответил, можно
AK> предположить,что в основном все делают доку врукопашную.
Я - не исключение, хотя с БД и работаю с 93го.
Если для конструктора, автоматизация этого потока может и стоит на первом
месте, то для схемотехника, важнее параметический подбор компонентов,
на который тратиться значительно больше времени, чем на его квинтэссенцию.
AK> Я пока больше склонен копать в сторону Context Management System.
AK> Что-нибудь на основе PHP+MySQL, типа eGroupWare. Если бы к этому
AK> добавить PHP скрипты, заточенные на обслуживание специфических баз
AK> данных (т.е. ведение стока, библиотека компонентов, и т.п), и на
AK> генерацию доки (включая BOM), то могла быполучиться икебана.
Для принятия решений о месте web-технологий мне хватило копирования
одного CD (кажется, OnSemi) c ~20000 .htm в одной директрии DN-ном
(который ее перечитывает, перед копированием очередного) :)
Vitaly Polikarpov, vitvp[эt]mail.ru

BOM
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 я не вижу.
Пока, Алексей
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 я не вижу.
Пока, Алексей

Re: BOM
23-Jan-05 21:23 Alex Kouznetsov wrote to Vitaly Polikarpov:
AK> Правильно ли я понял, что эти тулзы:
[...]
AK> -- Делают не все, что хотелось бы, так что после них все равно приходится
AK> править ручками
"Так отож".
У меня больше половины схем в итоге имеют несколько вариантов исполнения,
это забито в табличке на полях схемы.
Может и можно как-то хитро сделать табличку и через DBX и это вытащить в
соответствующий документ, но...
Проще оказывается
AK> в основном все делают доку врукопашную.
причём руками "более младшего конструктора" ;-)
wbr,
AK> Правильно ли я понял, что эти тулзы:
[...]
AK> -- Делают не все, что хотелось бы, так что после них все равно приходится
AK> править ручками
"Так отож".
У меня больше половины схем в итоге имеют несколько вариантов исполнения,
это забито в табличке на полях схемы.
Может и можно как-то хитро сделать табличку и через DBX и это вытащить в
соответствующий документ, но...
Проще оказывается
AK> в основном все делают доку врукопашную.
причём руками "более младшего конструктора" ;-)
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */

Re: BOM
Mon Jan 24 2005 08:43, Oleksandr Redchuk wrote to "Alex Kouznetsov":
OR> Проще оказывается
AK>> в основном все делают доку врукопашную.
OR> причём руками "более младшего конструктора" ;-)
В принципе монотонную нетворческую работу комп сделает лучше и дешевле. А
так-то, конечно, и Беломорканал лопатами копали...
Пока, Алексей
OR> Проще оказывается
AK>> в основном все делают доку врукопашную.
OR> причём руками "более младшего конструктора" ;-)
В принципе монотонную нетворческую работу комп сделает лучше и дешевле. А
так-то, конечно, и Беломорканал лопатами копали...
Пока, Алексей

Re: BOM
24-Jan-05 08:58 Alex Kouznetsov wrote to Oleksandr Redchuk:
OR>> Проще оказывается
AK>>> в основном все делают доку врукопашную.
OR>> причём руками "более младшего конструктора" ;-)
AK> В принципе монотонную нетворческую работу комп сделает лучше и дешевле.
Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта вот
схема имеет 3 варианта исполнения, в двух из которых вон_то не паяется,
а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
паяется вон_то, а вот_эти резисторы не паяются.
Я просто не знаю, как такое объяснить пикаду, чтобы он и до BOM-а это
довёл :-)
А "более младешму" я это за пару минут излагаю и он сначала
рисует нужную табличку на полях схемы (пикад сам это всё равно не сделает),
а потом делает ПЭ3 с вариантами исполнения и нужное количество вариантов Э7.
При этом самую монотонную работу - подсчёт сколько чего есть - делает всё
равно компьютер, а выдаст он это в виде стандартного пикадовского report-а
или сразу в виде вордовского, к примеру, файла - разница невелика
на фоне остальной работы "младшего".
wbr,
OR>> Проще оказывается
AK>>> в основном все делают доку врукопашную.
OR>> причём руками "более младшего конструктора" ;-)
AK> В принципе монотонную нетворческую работу комп сделает лучше и дешевле.
Сначала надо компьютеру (в моём случае - пикаду) объяснить, что вот эта вот
схема имеет 3 варианта исполнения, в двух из которых вон_то не паяется,
а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
паяется вон_то, а вот_эти резисторы не паяются.
Я просто не знаю, как такое объяснить пикаду, чтобы он и до BOM-а это
довёл :-)
А "более младешму" я это за пару минут излагаю и он сначала
рисует нужную табличку на полях схемы (пикад сам это всё равно не сделает),
а потом делает ПЭ3 с вариантами исполнения и нужное количество вариантов Э7.
При этом самую монотонную работу - подсчёт сколько чего есть - делает всё
равно компьютер, а выдаст он это в виде стандартного пикадовского report-а
или сразу в виде вордовского, к примеру, файла - разница невелика
на фоне остальной работы "младшего".
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */

Re: BOM
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> на фоне остальной работы "младшего".
А при внесении изменеий в схему - все по новой?
Идеально-теретицки все это должно бы делаться одним нажатием кнопки. Регулярно
и рутинно, как "ежедневный билд софт проекта". Потому что, в сущности, какая
разница, описывается в проекте железо или прога...
Пока, Алексей
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> на фоне остальной работы "младшего".
А при внесении изменеий в схему - все по новой?
Идеально-теретицки все это должно бы делаться одним нажатием кнопки. Регулярно
и рутинно, как "ежедневный билд софт проекта". Потому что, в сущности, какая
разница, описывается в проекте железо или прога...
Пока, Алексей

Re: BOM
25-Jan-05 09:24 Alex Kouznetsov wrote to Oleksandr Redchuk:
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,
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,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */

Re: BOM
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> и от их значения.
А оно надо? Имхо, схема может быть одной, все исполнения могут описываться в
ВОМ-е.
Но если уж _очень_ хочется, можно было бы зафигачить макросы, которые
размножат варианты исполнения схемы из одной базовой.
OR>>> а вот_эти резисторы имеют разные номиналы, а в третьем - наоборот,
OR>>> паяется вон_то, а вот_эти резисторы не паяются.
AK>> Это можно описать в виде внешней таблицы. Hапример, xls
OR> Hа схеме табличка всё равно нужна, её хоть так, хоть так рисовать.
В принципе скрипт мог бы на основе xls таблички сгенерить макрос, который
прорисовал бы такую же табличку в схеме
AK>> Идеально-теретицки все это должно бы делаться одним нажатием кнопки.
AK>> Регулярно
AK>> и рутинно, как "ежедневный билд софт проекта". Потому что, в сущности,
AK>> какая разница, описывается в проекте железо или прога...
OR> Дык я не спорю, что всё, что *имеет смысл* автоматизировать - надо
OR> автоматизировать. В моём случае *эта* автоматизация (которой буду
OR> заниматься я) как своего рода "процесс разработки" нескоро окупится
OR> за счёт сэкномленного времени "младшего конструктора" (при нынешнем
OR> потоке схем).
OR> Хотя я уже сам иногда из любопытства поглядываю в эту сторону,
OR> выходным форматом скрипта, пожалуй, должен быть TeX :-)
Я как-то не могу проникнуться прелестю ТеХ-а. Ну, если формулы писать, то
понятно, а так-то зачем? Универсальным форматом данных может быть XML, а уж из
него легко преобразовать во что угодно, в том числе и в ТеХ.
Пока, Алексей

Re: BOM
25-Jan-05 21:39 Alex Kouznetsov wrote to Oleksandr Redchuk:
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,
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,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */

Re: BOM
AK>> Это несложно сделать при помощи какого-нибудь атрибута. Скажем, атрибута
AK>> "исполнение".
OR> Для BOM-а да, можно что-то придумать.Какие-то value01 value02 и т.д.
OR> (у непаяющегося в данном исполнении элемента можно дать соответствующий
OR> аттрибут).
Можно проще: $(путь_к_каду)/utils/variants..
--
Boris Popov
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Boris Popov
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: BOM
26-Jan-05 12:37 Boris Popov wrote to Oleksandr Redchuk:
BP> Можно проще: $(путь_к_каду)/utils/variants..
Спасибо, не знал.
Рылся по тому каталогу, но не всё перерыл значит (в работу только
refdesud.exe пошло).
wbr,
BP> Можно проще: $(путь_к_каду)/utils/variants..
Спасибо, не знал.
Рылся по тому каталогу, но не всё перерыл значит (в работу только
refdesud.exe пошло).
wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */

Re: BOM
Alex, ты ещё здесь сидишь?
Понедельник Январь 24 2005 00:23, Alex Kouznetsov wrote to Vitaly Polikarpov:
VP>> Для PCAD есть внешние DBX Tool, оформляющие ПЭ3 по ГОСТ, но они
VP>> версиезависимы - с P2001, к примеру, не живут, да и не решают
VP>> вышеозначенных задач.
AK> Правильно ли я понял, что эти тулзы:
AK> -- Привязаны к конкретному пакету (ПКАД), даже еще хуже - к версии
AK> пакета
А что поделать, если версии пакета несовместимы между собой? :-\
AK> -- Делают не все, что хотелось бы, так что после них все равно
AK> приходится править ручками
Се ля ви. Всё, что хотелось бы, оч-чень редко бывает ;)
Георгий

Re: BOM
Привет Oleksandr!
Monday January 24 2005 08:43, Oleksandr Redchuk wrote to "Alex Kouznetsov":
AK>> в основном все делают доку врукопашную.
OR>
OR> причём руками "более младшего конструктора" ;-)
А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....
Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
aka snipped-for-privacy@yahoo.com
http://altor.sytes.net , ftp://altor.sytes.net
Monday January 24 2005 08:43, Oleksandr Redchuk wrote to "Alex Kouznetsov":
AK>> в основном все делают доку врукопашную.
OR>
OR> причём руками "более младшего конструктора" ;-)
А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....
Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
aka snipped-for-privacy@yahoo.com
http://altor.sytes.net , ftp://altor.sytes.net

BOM
Привет Alexey!
Tuesday January 25 2005 09:52, Alexey Musin wrote to Alexander Torres:
AM> Hello Alexander.
AM>
AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:
AM>
AT>> А Жора Шепелев потом спросит - почему доки и платы "девочки"
AT>> делают.....
AM>
AM> Хотя бы этy веткy не загаживай, энypезник.
Дак и не загаживай, вонючка.
Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
aka snipped-for-privacy@yahoo.com
http://altor.sytes.net , ftp://altor.sytes.net
Tuesday January 25 2005 09:52, Alexey Musin wrote to Alexander Torres:
AM> Hello Alexander.
AM>
AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:
AM>
AT>> А Жора Шепелев потом спросит - почему доки и платы "девочки"
AT>> делают.....
AM>
AM> Хотя бы этy веткy не загаживай, энypезник.
Дак и не загаживай, вонючка.
Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
aka snipped-for-privacy@yahoo.com
http://altor.sytes.net , ftp://altor.sytes.net

Re: BOM
25-Jan-05 09:52 Alexey Musin wrote to Alexander Torres:
AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:
AT>> А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....
AM> Хотя бы этy веткy не загаживай, энypезник.
Зря ты, ведь только хуже будет :-(
Wbr,
AM> 24 Jan 05 22:06, Alexander Torres wrote to Oleksandr Redchuk:
AT>> А Жора Шепелев потом спросит - почему доки и платы "девочки" делают.....
AM> Хотя бы этy веткy не загаживай, энypезник.
Зря ты, ведь только хуже будет :-(
Wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua */
Site Timeline
- » ECP порт
- — Next thread in » Microcontrollers (Russian)
-
- » avreal and Intel HEX file
- — Previous thread in » Microcontrollers (Russian)
-
- » По моему это гениально
- — Newest thread in » Microcontrollers (Russian)
-
- » kostenlos abzugeben
- — The site's Newest Thread. Posted in » Electronics (German)
-
- » Wide frequency range, arbitrary waveform DDS
- — The site's Last Updated Thread. Posted in » Embedded Programming
-