Да уж...
Дефицитка (или ведомость дефицита материалов) - это такой документ, который отражает потребности в пополнении склада комплектующих с целью обеспечения производства заданного количества изделий готовой продукции. У нас пока используется построение сего документа на базе 1С:Производство, но там это реализовано несколько убого, из-за чего полноценного развития не получило. Причины такие:
1. Дефицитка от 1С не учитывает такого понятия как аналоги компонента. В результате склад может ломиться от деталей, а попадет в дефицит.
2. Насколько я помню, аналоги в 1С указываются в справочнике материалов, что вообще-то в отношении электроники неверно. Аналоги должны указываться в спецификации конкретного исполнения изделия, хотя и могут быть указаны в справочнике материалов, если действительно полные аналоги. Например, возьмем конденсатор по питанию X7R 0.1мкФ 25В 10%. Если он у меня стоит в цифровой схеме с напряжением 5В, то я могу считать его аналогом и конденсатор с напряжением и 10В, и 50В. А если он стоит в цепях источника питания на 24В, то мне вообще нужен только на 50В конденсатор. Или, другой вариант: можно ли считать аналогами свинцовую и бессвинцовую версию одной и той же микросхемы? По функциональности и собираемости на современных линиях - безусловно да, а по выполнению директивы ROHS - безусловно нет.
3. Дефицитка в простом виде не отслеживает динамику поступлений комплектующих. Если мы вчера сформировали дефицитку по деталям изделия А исполнения 1, после чего заказали их кратно катушкам, упаковкам, блистерам и т.п., а сегодня мы получили заказ на исполнение 2, в котором львиная доля деталей совпадает с исполнением 1, то сколько надо докупить? Реально можно заново начать строить дефицитку, указав в ней уже два вида изделий, и потом вычтя из общей суммы то, что уже заказано. Но это довольно быстро ведет к путанице, а бронирования деталей нет.
4. У нас со временем сложилась ситуация, когда бухгалтерия стала отказываться вставлять в нормативы изделия всякие дешевые детали вроде резисторов и конденсаторов, мотивируя это тем, что они в сумме не тянут и на 3% в себестоимости комплектующих, но при этом очень сильно затруднен учет их остатков, ну и вообще возни с ними много, а толку мало. Ну и в итоге из нормативов они стали исчезать, а при приходе катушки сразу списываются ввиду небольших цен. И вроде если для бух.учета такое упрощение вполне катит, то для обеспечения производства - совершенно не катит!

В общем, надо искать иные способы точного учета компонентов.



Ну поле Value носит чисто OrCAD-овскую семантику, и я не хочу ничего в нем менять. Если мне будут нужны другие функции от базы, то я создам другие поля по мене необходимости. Здесь важно именно то, что Capture понимает, что Value - размерная величина и даже умеет понимать размерность. Если сделать value типа float, то размерность пропадет, а номинал станет неудобоваримым. Придется всегда помнить, по какому эталону размерности создана каждая база. Вопрос, как то же самое распространить на Voltage, Tolerance, Power, Current, и прочие физические параметры.



Я пока не заметил, что простому схемотехнику запрещено менять конфигурацию CIS. Вот ровно вчера этим занимался из-под пользовательского аккаунта. Вот источник данных ODBC и его пользователей может администратор настроить, а редактировать конфигурацию CIS может кто-угодно.




Так CIS выстраивает дерево в соответствии с полем Part_Type. Но первый уровень иерархии он называет по имени таблицы в базе. Поэтому если таблица называется IC_LOGIC_BUFFERS, она и будет так смотреться в иерархии. Вот если таблица будет называться Misc, а внутри будет раздел компонентов с Pаrt_Type = IC\Logic\Buffers, то тогда да, в СIS Explorer увидим иерархию \\Misc\IC\Logic\Buffers

А что, обязательно покупать именно столько, сколько указано в этой дефицитке? Обязательно после производства иметь пустой склад? Если нет, то непонятно, зачем эта дефицитка нужна.... Есть же ВП!



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


Тут мне трудно сказать, не увидев своими глазами, но опять попахивает кривизной софта. Будем знать (я подумываю о возвращении к CIS).


Ну, здесь никаких проблем. У меня все единицы измерения с системе СИ. Конкретно по Вашему списку: В, х100%, Вт, А. Ну и т.д, в том числе и Фарады (без дольных префиксов). Дольные и кратные расставляются в схематике (ментор позволяет, слава Богу), ну и когда надо при экспорте из БД другими средствами. Зато полная совместимость и определенность.



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



Это детали, лично мне не составит труда сделать именно IC\Logic\Buffers. Я просто для начала Вам хотел показать простую систему (линейную), а потом более сложную. Ну вы и сами уже все поняли.

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

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




Value при закупках?! Если честно, ни разу об этом не слыхал. Для закупок мы имеем либо пару Manufacturer:Part Number, либо на худой конец Description, точнее специальное поле для заполнения спецификации по ЕСКД, которая отражает общие свойства компонента, по которым его можно запрашивать у поставщиков, например "конденсатор керамический 0603 X7R 0.1uF 25V 10%". В некоторых случаях общение с поставщиками затрудняется, если вместо обобщенного наименования им выдать, скажем, Part Number от MURATA.


Меня семантика Value устраивает на 100%. Скорее интересно, как это обобщить на произвольные размерные величины.
Кривизна софта совсем в другом. Я как-то назвал таблицу по-русски "Конденсаторы". И она даже появилась в списке таблиц, я все настроил для нее, сохранил конфигурацию, и началось. При попытке снова запустить CIS Configuration Cаpture вылетает. Не переваривает русские буквы в имени таблицы. Не знаю, может в новых версиях что-то изменилось, но в 16.2 так.


Так с явным указанием единицы измерения еще большая определенность Система СИ, конечно, хорошо, но я в Фарадах записывать номиналы не хочу. Например, в машиностроении приняты миллиметры и ставятся без указания "мм". И ничего. По мне так лучше 0.1uF, а не 1e-7 какие-нибудь.



Я почитывал ту переписку в соседнем форуме в 2010 году про затею сделать некую общественную базу через текстовый data source, распространяемый по http, но идея, боюсь, утопична. если уж делать базу, то не только для целей рисования схем. И это расходится с концепцией read-only свойств. Я уже не говорю, что это все заживет при довольно сильной унификации библиотек УГО, футринтов, моделей MCAD, и т.п., чего на самом деле и в помине нет.



Да вот я тут думаю, что если уж пошла технология наследования свойств через view, то, может можно вообще все таблицы сверстать в несколько View (вообще один), в которых через Part Type развести иерархию.

А как Вы наполняете базу, если не секрет? Каковы основные принципы? Компонентов же много. Будешь прописывать в базу вообще все, что в природе есть, так жизни не хватит ее наполнить. Будешь наполнять только тем, что на складе есть, так тогда непонятно, что делать, когда хочется в схему ставить новые номиналы. С другой стороны, если вносить про все детали, то можно какой-нибудь скрипт написать, который сразу для всех компонентов создает нужные записи, например, прописывает все резисторы 0603 5% от конкретного производителя в базу, заполняя все поля автоматически. Но скрипт нужно с умом писать уметь, и на него плохо ложатся микросхемы. Но в любом случае, если работать через CIS, то нужен инструмент доступа к базе, который всегда под рукой и простой как молоток. Я даже не представляю пока, на основе чего он должен быть.

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


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



Ну дык сами же пишете: 0.1uF. Это разве не value? И разве оно не участвует в закупках?
А... Понял, у Вас это забито еще и в некий доп. дескрипшен. Такие методы хранения информации мы не используем. Это как минимум дублирование, да еще и формируемое вручную наверняка. Плюс отдельно хочу заметить, что эта параметрическая форма записи не дает гарантии покупки правильного конденсатора (это мы недавно обсуждали уже).


А что, с другими не работает, что ли (Вы сразу просто как-то не очень ясно написали)?... Это тоже интересно тогда. Еще кривизна.


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


Ну да, я же говорю, в схематике задается. И при экспорте задается. Но никак не в базе, и ни в коем случае не в виде текста типа "156Ом"!



Да, я там чуть ли не в первом посте сказал, что все заглохнет. Но зато там были полезные идеи и для меня тоже. И неважно, что я же их сам и высказывал, в основном. Без обсуждения они бы не возникли просто.
А что за концепция read-only свойств?


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


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

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


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


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


Ну вот есть мысли накалякать морду на php, кое-какой опыт работы с другими базами на SQL через тонкий клиент есть, и в целом это довольно быстрый способ развития сервисов базы, не только для CIS.

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

Кстати, в CIS с помощью View в SQL можно запросто сделать классификатор с множественным вхождением одного компонента в несколько веток классификатора, сохранив при этом единственный источник исходных данных, избежав ручного дублирования. Не знаю, как насчет CSV, но думаю, что со статическими таблицами такое будет невозможно. Но это так, вспомнилось по мотивам того обсуждения в 2010 году.

Получается, что это внутренний документ у закупщиков? Тогда имхо CIS может помочь только в извлечении параметров компонентов при необходимости. Но составлять этот документ надо имхо, все-таки в той же 1С или в другой складской программе.
Естественно, должна быть связь между ними. Но тут дело осложняется в случае мелкого пассива, который обычно заказывают в параметрической форме. Чтобы это работало нормально, надо, чтобы CIS поддерживал формирование строки параметров.


Вот его-то я и называю строкой параметров. Пока не реализовано, к сожалению...


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


Я бы пошел дальше, и не стал ничего писать. В свое время написали, теперь не знаем, что с ним делать. Возьмите лучше сразу менторовский DMS, или, еще лучше, делайте все через Ваш Лоцман. Будет единый интерфейс и стиль работы со всеми объектами проектирования, с компонентами, винтиками, комплексами и т.п.

Если Вы посмотрите даже на примеры у Cadence, то в простейших базах CIS у них имеется такая справочная информация, как cost и availability, которые по сути влияют на выбор компонента конструктором. Идея в том, что база компонентов должна быть единой, а уже CIS - это одно из ее применений. Когда баз становится несколько, неизбежно возникает задача их однозначного соответствия, то есть опять возвращаемся к вопросу о том, как объединить таблицы, а это уже и так делаем при помощи view для CIS.

Что касается пассива, то обычно мы в запросе указываем Manufacturer, Part Number, Description. Тогда поставщик либо ищет конкретный компонент, либо просто подбирает по описанию аналог от другого производителя и выставляет коммерческое предложение. Вопрос только в том, как это в базу должно попасть. Ну и еще бывает так, что в накладной поставщик пишет не исходный part number, а некоторый свой учетный. В этом случае тоже есть проблема у 1C, поскольку по по определению бухгалтерия ведет учет по первичным документам, то есть в данном случае приход комплектующих оформляется по накладным. А вот расход оформляется по данным из справочника нормативов, в который информация попадает из BOM, а в BOM, конечно, стоит настоящий part number от производителя. И в итоге постоянно приходится что-то где-то подправлять. Это еще одна причина отделить производственный учет от бухгалтерского.



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



Насчет Лоцман пока не уверен. Да и потом, проблема то упрется опять в то, кто и как будет заполнять кучу разнотипных таблиц в базе?
Так что на первом этапе нужна какая-то самопальная система работы с базой, а на втором - интеграция самой базы с сервисами других систем. Все же Лоцман:PLM - система для машиностроения по ЕСКД, и кто его знает, насколько ее гибкости хватит для освоения всех особенностей нынешнего приборостроения.

Ну вот, к примеру, обычная стандартная спецификация по ГОСТ 2.106 придумана для машиностроения, где сроду не было никаких маркировок позиционных обозначений (массово). Позиционные обозначения предлагается в ней писать в графе примечания, которая очень узкая. В итоге мы имеем огромную простыню пустых клеток в основных графах документа: Обозначение и Наименование. Зато в примечании перечисляются все 250 конденсаторов по питанию, хоть на несколько страниц. Это же очевидный косяк ГОСТа для приборостроения, и ничего другого пока нет. И вот из таких мелочей в целом складывается весь процесс...

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


А что, так много вариантов? Имхо всего парочка: либо сами схемотехники, либо (если есть) выделенный библиотекарь. Как - средствами лоцмана, так же, как и при внесении в базу других деталей (винтиков, элементов конструкции и прочего).



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

Вот еще какие вопросы по работе с CIS средствами SQL:
1. Правильно ли я понимаю, что столбец БД, указанный конфигуратору как Part_Number (см. рисунок) - это уникальный номер компонента в базе CIS. То есть это не Part Number производителя, потому что теоретически два разных производителя могут выдать одинаковый артикул, в особенности те, кто нумерацию ведет только строками чисел. Смысл этого номера в том, чтобы CIS однозначно мог найти компонент в базе при операциях обновления свойств и т.п. Я поначалу сделал его обычным номером производителя, но сейчас вот думаю перевести его на UUID, который SQL сервер умеет генерировать.
2. Почему перестал работать preview футпринта в CIS Explorer? Вроде бы раньше работал для smdres. Сейчас не работает. Причем пути к библиотекам прописаны, если навести курсор на это поле, то пишет правильный путь к .dra, но символ не показывает.
3. Можно ли убрать из списка таблиц все системные таблицы SQL? Ну или более точно, можно ли явно показать вполне конкретные таблицы CIS? У меня сейчас для простоты всего две (View) созданы, а при этом оно из базы высасывает конфиг от 357 таблиц, в итоге этот сонфиг в XML кушает 2.4 МБ и долго обрабатывается.
4. Наряду с системными таблицами в списке также болтаются имена view, которые были раньше, но которые я уже удалил. Откуда он их берет и как удалить?
5. Можно ли как-то перенастроить связь префиксов с пиктограммами компонентов в part manager? Например по ГОСТ микросхемы принято называть с буквы D (device), а оно при этом показывает диод. А диод по ГОСТ следует маркировать VD, но такой префикс ему вообще неведом.

Почему-то можно явно настраивать только те поля базы, которые имеют тип char, varchar, int. Всякие типы вроде datetime, UUID он не импортирует. Но это удалось сделать через конвертацию данных

Сообщение отредактировал Hoodwin - Feb 29 2012, 14:01

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


Это везде почти так. Во многих программах, работающих с базами или около них это так. Наверно, для совместимости. Меня тоже бесит, но ничего не поделаешь. Я тоже конвертирую в текст частенько.

ну вот я тоже всегда работал по связке MANUFACTURER:PART_NUMBER, но как я понимаю, CIS не понимает, что уникальность может задаваться двумя свойствами. В других местах вроде BOM это настраивается через combined property string, но с CIS видимо оно хочет, чтобы пользователь сам следил за уникальностью.

Вообще я тоже не встречал одинаковых кодов. Но вот у немцев частенько все коды состоят из цифр, побитых на группы дефисами, но дефисы там вещь вспомогательная, как в номере телефона. Всякие там, Harting, WAGO, Phoenix Contact, Molex, Schroff - у всех код из цифр и все. Так что теоретически может быть одинаковый номер.

Используйте т.н. corporate partnumber - код, уникальный внутри Вашей фирмы. Я так и делаю, в него просто обычно копирую код заказа производителя. Если случится этот мифический случай, когда цифры совпадут, то припишу префикс производителя и все.

В Capture.ini путь изменили?

Ну да, пути в capture.ini прописал в раздел Allegro Footprints. Так я ж говорю, оно путь до самого .dra находит, но не кажет ничего...

В папке ...\SPB_16.Х\tools\capture\vendor\ лежат bmp-пиктограммы, с именами в виде префиксов, переименуйте как нравится...