ответ я нашел, но ето непросто. вот он:
http://electronix.ru/forum/index.php?act=A...st&id=40320

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

Я предупреждал, что с TDD быстрее будет?
Это потому что в компасе все немного через одно место. Конвертер там запускается не каким-то файлом, а изнутри компаса, причем искать его надо ЕМНИП не в меню, а в окошке "библиотеки"...


Зато Вы в Москве.
Нет, это все мишура и преходящее, истинные ценности - это лень и "надо вчера". Спасибо, что напомнили, пора уже и заканчивать работу и двигать в сторону коньяка, пьятниццо кагбэ...

какую всю схему? Зачем вам схема в компасе?
вы компас вообще запустили?
БОМ - сделали?
в компас БОМ втянули?
Какие из 10 пунтов описаных выше были вам непонятны?

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


Та, как -то одинаково. В свое время перепробовал все "ТДД" до которых руки добрались. Время обработки документа, после того как все настроено и все опробовано от 15 минут, до пол дня - на исправление номиналов компонентов - где нужно.

А еще, выходные таблицы будут - тоже только в компасе открываться, или их придется кудато перегонять (pdf?)

Я это делаю в MS Access. Довольно элементарно.

Следующие шаги:
1. В Altium Designer создается для проекта Job - файл

Назовем его BOM.job.
2. В категории Report Outputs создаем Bill of Matereals так чтобы туда попали все интересующие поля и экспортируем в таблицу Excel.
3. Этот же Job файл содержащий только задание на Bill of Matereals вставляем во все остальные проекты плат и также формируем там аналогичные BOM-ы в формате Excel
4. Создаем Access базу данных и вставляем туда все Excel BOM-ы через связывание.
5. Создаем UNION запрос и на базе всех BOM-ов создаем единую сводную таблицу.
6. На основе сводной таблицы создаем PIVOT запрос и и проводим агрегацию по одинаковым компонентам.
7. Получаем таблицу где одинаковые компоненты собраны в одну позицию, но при этом можно видеть информацию сколько компонентов входит в каждую плату.

Способ в принципе работает с любым пакетом умеющим экспортировать BOM-ы в Excel или даже CSV.

pivot не помню, но номиналы Access понять не сможет. Или у Вас номинал - текстовое поле ?
тогда не получится нормальной сортировки по номиналу.
а если цифровое, тогда получите 10 мкф = 10 пф
а если приведете в экспоненциальный вид, тогда нечитаемо будет

http://advantex.ru/joom/content/section/6/69/
Не работал, подробности не знаю.

В Access есть с несколько десятков inline функций парсинга и конвертирования строк и чисел в обе стороны, а в запросы SQL от начала времен можно было вводить вычисляемые поля.
Так что номиналы не проблема.

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

А что мешает просто записывать в виде 0,0001, 0,000001 и т.д, т.е просто в Фарадах?

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



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

Если выбирать из этого списка то однозначно Access- тут и удобство использования и документация и поддержка и обновления-не представляю благодарю чему можно еще подразумевать TDD как альтернативу.

О май гад! Ну что мешает рядом еще одну колонку сделать, в которую либо тупо руками либо процедурой заносить значение с префиксом? Это если без него жить нельзя. У меня, например, вообще такой колонки нет, а есть только код заказа компонента и все в порядке, никто не мучится. Кроме того, если у Вас ментор (Вы же его еще не снесли по причине кривизны?), то именно этот формат он корректно использует в dxdatabook, там стоит только настроить эти самые множители в свойствах библиотек.


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

код заказа компонента лежит у меня в колонке comments и является необязательным атрибутом компонента, и вот почему: если Вы посмотрите в етот запрос(http://smd-component.ru/webcatalog/section.php?act=search&s_id=66&p_name=&c370l[]=12&c556l[]=19&c373num1=0.01&c373f1=6&c373num2=0.01&c373f2=6&on_pages=20), то увидите 11 одинаковых конденсаторов 0.01 мкф, от 5 производителей. У них 11 разных part number. В случае, если
Ваш part number временно out of stock, Вам придется делать следующее: расшифровывать Ваш part number, выписывать строку параметров, идти куда-то, и выбирать по этой строке другой компонент. Не проще ли сразу сделать строку основным параметром, а partnum- вспомогательным, и сделать так, чтобы строки было удобно просматривать.


да хочу


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

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


Серьезно? Ок, я завтра сделаю, но учтите, что она для наших реалий, а не для Ваших.


Поздно пить боржоми, когда почки отказали.

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


Вы почти правильно все обрисовали, за исключением того, что ключевым полем в таблицах компонентов должны быть все-таки параметры компонента. Указывая готовый парт, вы таким образом расширяете зону имеющих существенное для схемы значение параметров, и, например, при передаче базы в ведение Ваших подчиненных, увеличиваете возможность не купить что надо, или сделать ошибку. Делать partnum основой неправильно хотя бы потому, что иногда парт снимается с производства.
К тому же, я например, во всех изделиях стараюсь проводить унификацию узлов - если у нас есть, например, узел 1 Гбит ethernet трансивера, зачем делать его заново в другом изделии. Так вот, в разных изделиях может быть разный перечень разрешенных - у меня например есть такой прецедент. В этой ситуации опора на partnum 100% приведет к удвоению работы по формированию перечня.


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


почки пока не отказали. в ожидании Вашей инструкции ковыряю Access

Ок, речь о макетах. Запомним это.


Указывая готовый парт, я таким образом гарантирую, что парметры, не указанные в перечне (а при такой постановке вопроса я могу вообще ни одниго параметра не указывать,верно?) не повлияют на работу изделия, ибо я (разработчик) в явном виде указываю, что я рассчитал схему для данного конкретного партнамбера.
Если же я настолько крут (у Вас там, я слыхал, лучшие из лучших работают?), что могу позволить себе выставить на схему абстракуную деталь, заданную только парочкой параметров, то это не значит, что я это буду делать всегда. Довольно часто мне надо будет выставлять на схему именно конкретный партнабмер, говоря тем самым, что замены тут недопустимы.
При этом база у меня должна быть одна, и она должна позволять работать в двух стилях сразу. Кроме того, как Вы сами заметилии, для разных проектов могут быть разные перечни разрешенных, а также нужен склад, закупки и т.д. Как это все сделать? Только имея в качестве ключа партнабер реальной детали. Тогда это будет база деталей, а не база абстракций. Вот и всё.


Как Вы понимаете, это описывается в базе спец. полем, например "дата снятия с производства".


Че-то не уловил, почему? Потому что год назад сняли с производста деталь, которая там забита? Так следить надо и списки допустимых замен формировать.