Jump to content

    
Sign in to follow this  
oleg_dyakov

Использование Altium на малом предприятии или фирме с БД компонент.

Recommended Posts

Вопрос, собственно, стоит скорее как получить хороший совет от тех инженеров, которые используют библиотеки Altium на основе БД.
В частности я планирую завязать всё на MySQL. Уже пробовал как-то организовать так свои БД. Получилось. Понравилось.
Но в пределах предприятия никогда таким не пользовался. Вот и возникают много вопросов.
В частности есть неуверенность: а нужно ли самому что-то городить или может быть воспользоваться готовыми решениями на основе Volt или Nexus.

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

Share this post


Link to post
Share on other sites
Цитата

быть воспользоваться готовыми решениями 

Это лучше. Хот готовыми их назвать нельзя. Там готовый только инструмент.

Систематизация и порядок -- за вами

Share this post


Link to post
Share on other sites
1 час назад, Uladzimir сказал:

Систематизация и порядок -- за вами

Нет, ну это понятно. Разумеется.
Вопрос только в инструментарии разумеется.
Просто на базе MySQL придётся либо городить какой-то интерфейс к БД, либо прописывать параметры компонент, используя какой-нибудь WorkBench ( что не есть хорошо ).
С другой стороны тот же Altium Concord потребует вникать в новый для себя продукт со всеми вытекающими.
Конечно же, на  первый взгляд склоняюсь к Concord.
Но тут тоже дополнительных вопросов куча.
1. Не стучит ли вылеченная версия?
2. Можно ли поднять сервер Concord где-нибудь, скажем, на Гугл-пуле или Amazon VPS ?  и не будет ли это эдаким "насрать у соседа под дверью, позвонить в дверь и попросить бумажку" ?
В общем, есть некоторые сомнения.
3. Купить - скорее всего будет очень дорого.
 

Share this post


Link to post
Share on other sites

1. стучит все, просто не всегда это слышно.

2. Если официально -- то вроде можно, но не пробовал
3. Используйте A365 там  встроенный для библиотек, правда облако. Concord не нужен

Share this post


Link to post
Share on other sites

Извините если не в тему и этот вопрос уже проработан:

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

Share this post


Link to post
Share on other sites
4 часа назад, Ruslan1 сказал:

А нужно ли на "малом предприятии или фирме" это?

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

Share this post


Link to post
Share on other sites
12 hours ago, musa said:

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

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

Share this post


Link to post
Share on other sites
1 час назад, Ruslan1 сказал:

там не вводили централизованные базы.

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

Share this post


Link to post
Share on other sites
23 hours ago, oleg_dyakov said:

В частности я планирую завязать всё на MySQL.

а чем обоснован выбор MySQL ? Почему не Excel/Access ? 

Quote

 Уже пробовал как-то организовать так свои БД. Получилось.

если у вас уже получилось, то в чем проблема распространить вашу БД на все предприятие. 

Скорее сложность тут в админ.ресурсе - заставить всех пользоваться вашей базой? 

Quote

 Натолкните на правильные "рельсы"

а есть ли у вас на предприятии ERP или PLM или PDM? Нужно ли вам чтобы абсолютно все пользовались единой базой элементов. 

Чтоб например транзистор был единый для всех: для схемотехников это был компонент альтиума, для 3д конструкторов - это была 3д моделька, для технологов этот транзистор имел привязанный к нему тех.процесс, для отдела закупа этот же транзистор имел список поставщиков, остатки на складе и цены, и т.д.

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

А как правило делаются разрозненные огороды, у плат одна база на экселе, у технологов бумажки вообще, у ОКМ своя отдельная база в 1С и ниче друг другу не соответствует, и все всё делают вручную, генерируют накладные, расходные и т.д. 

 

Зарубежный опыт показывает, что в идеале должна быть полная связка PDM - PLM - ERP. Чтобы на любом из этапов можно было выделить плату и точно определить какие компоненты взяты, кто и когда их делал, пойти назад к проектированию и найти проект альтиума и открыть схему/плату, или пойти вперед к накладным и заказам комплектующих. Вот к такой системе нужно стремиться. В идеале сделанный проект альтиума при сдаче в PDM систему уже должен автоматически создавать электронный состав, из которого можно сгенерить и спецификации, и тех.маршруты (потому что ко всем элементам они уже разработаны и привязаны), и накладные для заказов у поставщиков можно сгенерить просто отчётами. 

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

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites
38 минут назад, popms сказал:

эта база будет жить только внутри себя

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

Share this post


Link to post
Share on other sites
26 minutes ago, musa said:

дальше что будет с ней мне уже не важно

это очень плохо,

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

 

Share this post


Link to post
Share on other sites
3 минуты назад, popms сказал:

ваш проект должен быть исходными данными

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

Share this post


Link to post
Share on other sites
3 hours ago, musa said:

Но мне совершенно не важно в первом приближении когда и сколько будут производить этих устройств

это печальный и крайне недальновидный подход. 

4 hours ago, popms said:

а чем обоснован выбор MySQL ? Почему не Excel/Access ? 

Задачу TC я примерно понимаю, сам сейчас стою на распутье.

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

В идеале я считаю должно быть так: в альтиуме только УГО и футпринт, все остальные параметры подтягиваются из базы предприятия.

У нас сейчас база предприятия как раз на акцесс и я хочу все параметры из альтиума отдать в эту базу и потом оттуда их получать (и другие получат) + данные поставок/остатков/движения, видеть статусы EOL, nRND и т.п., а то сейчас как раз как вы описали выше: у каждого своя бумажка.

Но т.к. у нас все планируют с акцесса соскочить не хочу пока лезти.

 

 

Если я правильно понял, как раз конкорд может такую задачу решить?

Share this post


Link to post
Share on other sites
2 minutes ago, peshkoff said:

Если я правильно понял, как раз конкорд может такую задачу решить?

конкорд через костыли можно подсоединить к базе предприятия, опыта нет примерно ни у кого, спросить не у кого, поддерживается только ограниченный набор СУБД типа Firebird.

К Access конкорд точно подключить невозможно.

Единственные плюшки конкорда - это красивая админка базы и проектов, управляемые параметры проектов и красивый поиск по всей библиотеке.

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

 

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

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

 

При таком построении мы не зависим почти ни от чего, ни от того, что альтиум придумает в конкорде, потому что база выглядит как обычный DbLib файл со строкой подключения к базе Oracle.

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this