Александр недавно писал что и как, постов 10 выше в этой ветке. Не знаю, что еще нужно.


Да, поначалу были проблемы с тем, что если поле "Тип" не заполнить, то каждый раз будет автозаполнение. А я по первости их удалял, а ГОСТ-tools их снова автоматом заполнял. Но после того, как заполнил по рекомендациям Александра, то автозаполнения прекратились. Это было особенно актуально для микросхем, т.к. я не знал куда писать наименование в "Тип" или "Значение". Если в значение, тогда проблемы с автозаполнением. Если пробелом Тип везде задать, то его видно в перечне.

На данный момент полет нормальный. Единственно, что режет глаз, это то, что для резисторов и конденсаторов разные наименования получаются. Вместо пустого поля подтип, где у конденсаторов тип диэлектрика, ГОСТ-tools пихает пробел, что в результатет вынуждает делать разное обозначение конденсаторов и резисторов. Хотя тоже пофигу. То что есть, лучше чем ничего нет. Все настройки ГОСТ-tools сохраняются в файле схемы. Как делать грамотно библиотеки, тоже понятно.

Чип 0805-X7R-25 В- 1 мкФ ±10 %
Чип 0805 1 кОм ±5 %

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

Вы все ждете у моря погоды, что КД сгенерируется на основе произвольной сырой схемы полностью без Вашего участия
Мы можем идти в этом направлении автоматизации заполнения атрибутов на основе каких-то предопределений. Но пока этого нет в требуемом объеме. Чтобы это было, это нужно сделать. А прежде, нужно сначала понять что и как делать.

Одно из Ваших предложений было - добавить обработку префиксов полей Chip Name из библиотеки mixture.lib.
Так можно сделать. Прикручиваем кнопку, по нажатию на которую выполняется сканирование префиксов у поля Chip Name, выполняется сопоставление префиксов с ГОСТ наименованиями на основе таблицы. В результате атрибуты Title (Наименование в менеджере компонентов) заполнятся ГОСТ наименованиями. Заполненные атрибуты Title сохранятся обратно в схему. Если какие-то будут исключения, через менеджер компонентов пользователь поправит для определенных компонентов поле Title руками.

Однако у меня нет убеждения, что данный механизм нужно делать средствами программирования и средствами ведения таблицы сопоставления. По моему мнению это лишнее звено с точки зрения затрат на разработку, а также с точки зрения надежности.
Мое предложение было - добавить поле Title прямо в библиотеку mixture, где и прописать ГОСТ наименования. Библиотечный компонент для того и служит, чтобы его атрибуты хранить не разрозненно, а вместе, внутри одной сущности.

Теперь о "c_cap".
Менеджер компонентов читает атрибуты компонентов схемы и делает следующее:
Если у компонента в схеме нет атрибута Type (в сырой схеме его обычно не должно быть) , то в поле "Тип" менеджера компонентов отобразится значение обязательного атрибута Chip Name этого компонента. Иначе, если атрибут Type у компонента есть, то в поле "Тип" менеджера компонентов отобразится значение атрибута Type этого компонента.
Если атрибут Type отсутствовал у компонента, то после ввода в поле "Тип" в менеджере компонентов какого-то другого значения отличного от значения атрибута Chip Name, создастся атрибут Type, и с этого момента в поле "Тип" менеджера компонентов будет отображаться введенное пользователем значение (сохраняется в схему в виде атрибута Type).
Данный алгоритм используется только для поля "Тип" менеджера компонентов.

То, что попадает в ПЭ3 и спецификацию, грубо говоря, складывается из полей, которые можно видеть в менеджере компонентов.
Упрощенно в ПЭ3 столбец "Наименование" формируется конкатенацией значений полей из менеджера компонентов:
поле "Наименование" + поле "Тип" + поле "Подтип" + поле "Номинал" + поле "Допуск" + поле "Обозначение".

Теперь наверно вопрос, зачем такой алгоритм для поля "Тип"?
В основном это дает преимущество генерации КД на основе схем, выполненных в P-Cad, и скорее всего в большинстве других CAD.
У P-Cad есть обязательный атрибут Type, который обозначает имя компонента (не имя УГО). Проще всего объяснить для микросхем логики серии 74xx.
К примеру существует реальная микросхема SN74HC04D. Так вот нормальная ситуация, когда есть пикадовский компонент SN74HC04D (его атрибут Type="SN74HC04D"). Компонент у пикада - это агрегатор УГО, посадочного места и еще некоторой агрегирующей информации.

В KiCad поле Chip Name несет в себе другой смысл. Chip Name в KiCad - это имя УГО компонента. В случае KiCad значение Chip Name для микросхемы SN74HC04D будет = 7404.

В результате имеем:
1) для схем импортированных из P-Cad в KiCad в менеджере компонентов поле "Тип" будет иметь для вышеприведенного примера значение "SN74HC04D". В результате именно это значение и попадет в КД. Останется только задать поля "Наименование" = "Микросхема" и "Производитель" = "NXP" (и/или возможно ТУ еще).
2) для сырой схемы KiCad в менеджере компонентов поле "Тип" будет иметь для вышеприведенного примера значение "7404", что ни о чем не говорит, и в КД такое отправлять нельзя. Поэтому в менеджере компонентов для этого компонента в поле "Тип" нужно руками вбить "SN74HC04D". После чего в КД попадет то, что нужно.

Я совсем не продвинутый пользователь KiCad. Возможно не знаю откуда можно автоматом получить значение "SN74HC04D".
Однако при задании полей через менеджер компонентов, а это делается один раз при разработке схемы, вся проделанная работа по заполнению сохраняется в схему в виде атрибутов. То есть ничего не разрозненно, все внутри проекта, и введенная информация дополняет проект (многие из вводимых атрибутов на столько важны, что в некоторых ситуациях без них проект устройства не может считаться проектом). Нужно понять что за микросхема DD5 на схеме? Смотрим чему равен атрибут Type у компонента в схеме, либо открываем менеджер компонентов и смотрим в нем, ну и конечно же смотрим КД.

Может. Я, к сожалению, еще не вникал как сделано в скрипте. Нужно будет посмотреть.

Да, постараюсь заняться в ближайшее время. Русский перевод уже есть и как раз уже отсоединил логику генерации для русского и английского языков. Так что теперь есть на что ссылаться (GUI на русском) при написании документации.


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

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

С другой стороны, если говорить непосредственно о позиционных обозначениях (поле Reference), то такая обработка (даже и с таблицей сопоставления) скорее всего будет иметь смысл. Поскольку позиционные обозначения регулируются ГОСТом, и в данном случае хочется надеяться, что это не будет частным случаем. То есть мысль такая, если мы сможем написать список всех типов позиционных обозначений, которые соответствуют ГОСТ и при этом не будет неоднозначности в их трактовании, то такой список (таблицу) есть смысл программировать и обрабатывать (обрабатывать не chip name компонента, а его Reference, который также устанавливается на этапе создания библиотечного компонента).
Я поэтому и спрашивал ранее, почему префикс позиционного обозначения находится в поле chip name в библиотеке mixture.lib вместо того, чтобы находиться в самом позиционном обозначении (я пытался на тот момент вникнуть в логику mixture.lib). Вы, Aldan, тогда сказали, что эти префиксы находятся в поле chip name, чтобы было удобно выбирать библиотечный компонент из списка. Хорошо. Также понятно, что в том виде, в каком эти префиксы сейчас прописаны в поле chip name в библиотеке mixture.lib не получится прописать прямо в позиционные обозначения этих библиотечных компонентов. Например, префикс VD_DAO (точно сейчас не помню обсуждаемый пример) никак не ложится в формат позиционного обозначения.

А вот другой пример, позиционное обозначение DR - резисторная сборка.
ГОСТ явно не указывает, что DR - это резисторная сборка, однако ГОСТ указывает, что D - это микросборка, а R - это резистор.
То есть мы можем договориться, что все-таки DR - резисторная сборка - соответствует ГОСТу, и создавать библиотечные компоненты резисторных сборок строго с позиционным обозначением DR.
Как быть с диодной сборкой и другими не простыми наименованиями пока не знаю. Диодные сборки я обычно обозначал VD, из чего не возможно принять решение диод это или диодная сборка.


Не совсем понимаю, что значит используется информация прямо из файла схемы? И какая именно информация?
В GOST-doc-gen тоже используется информация прямо из файла схемы, а именно она вычитывается из атрибутов компонентов схемы. Мало того, используется информация текущего состояния схемы после того как файл схемы был открыт, и возможно, в добавок отредактирован без сохранения и повторного открытия (текущая сессия).

А DD - это сборка сборок, а DA - сборка устройств
Тяжело приследовать здесь какую-либо логику. Вот здесь товарищи резисторные сборки вообще обозначают как E, а микросхемы все как D. В студенчестве мне было очень сложно отнести микросхему к цифровой или аналоговой. Хоть тот же микроконтроллер. Философия Гейзенберга )).

Нет, согласно ГОСТ (номер ГОСТа на прошлой неделе указывал, сейчас нет под рукой) имеет значение позиция символа. В случае двухбуквенных обозначений для каждой буквы своя таблица по интерпретации в ГОСТе.
У ведущей буквы D, на сколько помню, варианты интерпретации: микросхема, микросборка и еще что-то.
У следующей буквы, видимо, детализация:
DD - цифровая микросхема
DA - аналоговая микросхема
DR - резисторная сборка
? - диодная сборка
по аналогии если рассуждать DC - конденсаторная сборка - я никогда не встречал.

Я поэтому и говорю, что надо договориться потому что наш ГОСТ (и не только) - это что-то с чем-то

В идеале, раз стандарт, так и дали бы однозначные таблицы обозначений на все радиодетали. Сколько лет этому ГОСТу, а ничего не меняется.

2.710


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

Резисторные сборки обозначаем как RA (resistor array) или RN (network - если связи есть между резисторами). Внутри УГО ставили *R.
Набор конденсаторов - по аналогии CA или CN (внутри УГО *C).
В перечне - отдельным разделом "Резисторные/конденсаторные сборки".
Нормоконтроль пропускает без вопросов.
Диодные сборки - как набор из диодов VD1.1, VD1.2 и т.д.

Открыл ГОСТ 2.710-81. Эти товарищи по ссылке в принципе ГОСТ не противоречат
Согласно ГОСТ элементы могут обозначаться однобуквенным или двухбуквенным кодом.
Вот примеры из однобуквенной таблицы:
D - Схемы интегральные, микросборки
E - Элементы разные (ну а чем резисторные сборки не "разные", раз отдельной категории для них нет )
Однако у товарищей по ссылке обозначение предприятия внизу написано "ГНБК", а вверху "НИЦС"

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


А вот в ГОСТе не смог найти ничего похожего на RA / RN.

Да, но и мы успешно проходили сертификацию и последующие проверки, при этом у нас префикс DR для резисторных сборок

Это на схеме? А в ПЭ3 и спецификации что?


Посмотрел реализацию скрипта Константина. Так в GOST-doc-gen и так одинаково сделано в плане чтения из схемы. Различие в том, что в скрипте Константина читается атрибут "Группа", а в GOST-doc-gen читается атрибут "Title".

И у меня поначалу были проблемы и у кого-то еще они будут.., зачем это все? Если Александр напишет руководство объемом (20...30)% от того, что пишет за день на этом форуме, то таких проблем больше ни у кого не будет.

Да, поначалу я предлагал такое решение, но потом перестал настаивать на нем именно по той причине, что другие библиотеки, которые тоже могут использоваться, скорее всего будут оформлены иначе и все перестанет работать. Мне подумалось, раз уж компоненты на схеме имеют вполне конкретные пары обозначение-значение, причем, согласно ГОСТ, то пользоваться нужно именно этой информацией, которая от оформления библиотек и компонентов в них никак не зависит. Позже, когда я испытал скрипт Константина Барановского и увидел, что при его работе не выводится косяков типа с_сар и проч., я совершенно укрепился в этом мнении т. к. получил практическое подтверждение правильности и реальности такого решения.
Я оставил префиксам их изначальное назначение — функциональная группировка компонентов и облегчение их выбора.
Теперь немного о том «откуда ноги растут» у моего пожелания возможно полнее реализовать автозаполнение полей. Здесь дело не только в том, что автоматизация способствует экономии времени, а еще и в психологии пользователя. Пользователь привык по нажатию кнопки получать готовый ВОМ, однако, при запуске менеджера и нажатии кнопки мы получим практически пустой перечень т. к. поля «наименование» не были определены.
Помню, когда я проделал это в первый раз и получил пыстышку, то подумал, что либо я что-то напортачил, либо программа еще сырая, а почитать что-то вразумительное в отсутствующем руководстве пользователя, естественно, не удалось. Все это послужило для меня неким психологическим ударом, актом недружественности со стороны GOST doc gen. Вот по этой причине я и предлагал ранее усугубить автозаполнение, чтобы обычные пользователи по нажатию кнопки все же получали хоть и требующий доработки, но документ.
В данный момент я уже не настаиваю на этом, т. к. выделять группы полей и определять их довольно просто и требует меньше времени и сил, чем переписка на форуме. Однако, я все равно остаюсь при своем мнении, что автозаполнение поля «наименование» является более цивилизованным решением. При этом уточняю: нужно сделать автозаполнение полей только тех компонентов, которые могут быть определены однозначно — C, R, L и т. д., если же однозначность невозможна, то такое поле не автозаполняется, а выделяется цветом до завершения ручного заполнения.

Если брать пару «обозначение-значение» на каждый компонент из схемы, то никакие поля дополнять и их заполнять не придется. Напрягать пользователя объемной и не нужной работой — ложный путь. Успешная работа скрипта Константина Барановского показала, что ничего этого не нужно.

В который уже раз, когда речь заходит об организации библиотек у меня складывается впечатление, что между нами какая-то стена недопонимания. Вы все время игнорируете мои слова насчет того, что некое обобщенное название компонента в библиотеке становится совершенно конкретным (и совершенно другим) в конкретной схеме. Постараюсь проиллюстрировать это еще одним примером и заодно покажу, что все это касается не только mixture.lib.
Зайдем в библиотеку analog_IC.lib. Просматривая компоненты мы будем видеть их реальные названия без всяких префиксов, т. к. каждое название относится только к одному конкретному компоненту а принадлежность к группе аналоговых микросхем содержится в самом названии библиотеки.
Однако, дойдя до буквы «о» мы увидим «OPAMP1_8» и еще пять других «OPAMP». В данном случае это уже не конкретное название компонента, а условное название группы «OPAMP» - операционные усилители. Сделано это для того, чтобы этими шестью условными компонентами описать несколько тысяч реально существующих операционных усилителей различных фирм.
«OPAMP1_8» означает, что это УГО одного операционного усилителя в корпусе с 8-ю выводами. «OPAMP2_8» означает, что это УГО двух операционных усилителей в корпусе с 8-ю выводами и т. д.
Если конкретные названия микросхем перекочуют в схему без изменения, то условные названия операционных усилителей будут заменены на конкретные названия компонентов в схеме. Таким образом, совершенно не важно как назывался компонент в библиотеке, важно как он в конце-концов называется в схеме. И если черпать информацию именно из схемы, то перечень будет содержать лишь то, что нужно и все косяки типа «с_сар» пропадут.

Как я написал выше: нужно сделать автозаполнение полей только тех компонентов, которые могут быть определены однозначно — C, R, L и т. д., если же однозначность невозможна, то такое поле не автозаполняется, а выделяется цветом до завершения ручного заполнения.

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

Видимо, теперь все будет в полном порядке. Если что, Константин обещал, что поможет.

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

Я скриптом Константина конечно не пользовался, но групповое выделение всех конденсаторов в GOST-tools и назначение им "Наименования" - конденсаторы представляет собой трехсекундное дело.

По поводу того, надо ли автоопределять что-то. Думаю что это плюшка-дополнение. Сейчас можно работать и так. Есть ли время у Александра, другой вопрос. Кроме того, когда я предлагал делать библиотеки с предопределенными номиналами, что из этого получилось? В большинстве своем люди против. Да, полезно было-бы это делать, но это опция. Чем mixture.lib лучше других? У меня все библиотеки собственного изготовления, и я готов их адаптировать под GOST-Tools. И считаю, что без этого нельзя. Волосы нужно не только причесывать, но и мыть иногда.

PS: Честно, мне очень нужны были автогенераторы ПЭ и Спецификации. На создание подобных документов у моей коллеги уходило несколько дней, ввиду большого количества компонентов. То что есть сейчас снимает вопросы нескольких дней до половины дня, за что выражаю еще раз Большое Спасибо авторам GOST-Tools, и Александру в частности. В перспективе хотелось бы автогенерацию без настроек. Но этот вопрос упирается в библиотеки и у каждого они свои, похоже.

Вернулась старая проблема "RPC_DOC_IFACE: Unable to put cell"

Шрифт в форматках страшный. Надо его копировать, как я щас вспоминаю.

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

Да, шрифт нужно установить пока руками.

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

Если бы Вы были внимательны к моим сообщениям, то давно бы поняли — я тот самый конечный пользователь:

Улыбнуло: «Солженицина не читал, но осуждаю»

Вы забываете, что AVL сознательно не заполняет поля «наименование» для того, чтобы видеть что еще не было обработано и опять невнимательны к тому, что я пишу т. к. и я считаю, что выделение вручную не затруднительно. Вот, например, то, что я написал в сообщении на которое Вы мне ответили:

Я писал ранее и об опциональности автоопределений. И вот Вы опять мне пишете:

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

Кто же спорит. Речь идет о поиске путей по усовершенствованию программы, а не о том, может ли она уже работать. Чувствуете разницу? Мне кажется, Вы пытаетесь защитить AVL от моих «нападок». Не стоит это делать, т. к. AVL может и сам послать меня куда-подальше, если пожелает.

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

Я считаю AVL умным собеседником, который получил подтверждение, что убрать косяки можно без того, чтобы напрягать пользователя дополнительными доделками-переделками. Это очень важно, т. к. вольность в оформлении библиотек «не переделанных под менеджер» будущими пользователями может привести к косякам в будущем. Нужно радоваться, что нескладухи проявились именно сейчас — на старте.

Так, по-спокойнее Любое общение по делу важно.
Единственное, Aldan, я не всегда понимаю смысл того, что вы пишите, извините:

Вот пока ничего не понял.


Да, так реально сделать (кроме L, что такое L? дроссель, катушка индуктивности, еще варианты? ).

Aldan
Только одних резисторов с учетом высокоточных рядов получилось бы несколько тысяч вместо одного единственного компонента. А там еще конденсаторы, индуктивности... Бррр... Все же здоровое у нас сообщество на форуме, раз отвергает такие предложения.
А у Mentor Graphics это основной принцип. Да ещё всё не собрано в библиотеки, а валяется отдельными файлами.