Александр недавно писал что и как, постов 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 это основной принцип. Да ещё всё не собрано в библиотеки, а валяется отдельными файлами.

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

Здесь я отвечаю на Ваше предложение о том, что если в свойствах компонента ввести доп. поле и заполнить его у каждого компонента, то это может помочь решить проблемы появления «косяков». В прошлом сообщении я объяснил Вам, что не важно как назывался компонент в библиотеке, главное, как он называется на схеме. Каждый компонент на схеме имеет пару «обозначение-значение», например, обозначение — R1, значение — 1кОм.
Если Вы будете брать только эту информацию, то именно она и уйдет в перечень, а вот если Вы начнете ее еще смешивать с информацией из библиотеки, то в перечне вместо «1кОм» появится «R_RES 1кОм», где «R_RES» - не нужный нам «косяк». Информация отраженная в схеме самодостаточна и нет нужды к ней примешивать еще что-то. В каких полях брать эту информацию из схемы Вам виднее, как специалисту.
Далее я пишу о том, что раз схема все уже содержит, то нет необходимости вводить дополнительные поля и заставлять заполнять их пользователями. Уверенность в правильности такого решения опирается на то, что скрипт Константина Барановского работает без «косяков».
Таким образом, главная мысль — поскольку мы составляем перечень (спецификацию) схемы, то и брать информацию нужно со схемы, а не откуда-то еще.

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

Здесь я пишу о том, что раз скрипт Константина Барановского выводит перечень без «косяков», то это означает, что он выводит только то, что есть на схеме, а не подмешивает еще и информацию из библиотек.

Здесь я пишу о том, что раз уж Вы ознакомились с кодом скрипта Константина Барановского, выводящего перечень без «косяков», то теперь то уж и в Gost doc gen все будет в порядке.

Если заглянуть в ГОСТ 2.710-81, то там мы увидим: L — катушки индуктивности, дроссели. Больше никаких вариантов не предусмотрено. Правильными будут оба варианта, но наиболее употребимый вариант, на мой взгляд, - дроссели. Но не надо особо заморачиваться над окончательным вариантом по двум причинам: во-первых, если не удается добиться однозначности, то, как предлагалось мною, не автозаполняем такое поле, а выделяем его цветом; во-вторых, если будет сделан редактируемый список вариантов соответствия, то время его отшлифует и каждый сможет его «заточить» под себя.

Ужааасссс!

Может кто подскажет по обозначению сопротивлений? На сколько мне было известно, сопротивление ниже 1 кОм в КД вроде как должно обозначаться просто числом без слова "Ом". Например 220 Ом должно обозначаться просто числом 220. Пробежался по ГОСТ 8.417-2002, однако нигде не могу найти такого требования, что указывать Ом не нужно.
Как правильно должно быть, кто знает?


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

Выводить в КД только позиционное обозначение и номинал? А как же тип компонента? Как без него? А допуск? А производитель? А еще остальные поля?
Также не могу понять разницу с Ваших слов между атрибутами компонента библиотеки и атрибутами этого компонента сразу после инстанциации в схеме. Атрибуты же идентичны. Они могут начать отличаться только после того как разработчик схемы принудительно их изменил в схеме.

Вы пишите:

Я не могу понять как они будут заменены на конкретные названия компонентов в схеме, кем / чем?
Возможно, я что-то упускаю?

Смотрите мой ответ выше.

Вот не вижу связи

Нет, я не обижаюсь, просто рождается иногда такое чувство, что Вы скажете «ничего не понял», а потом сидите и посмеиваетесь, как я там пытаюсь разжевать молекулы на атомы

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

Именно! Я ведь не единожды Вам писал, что обобщенное условное обозначение, например, «OPAMP2_8» из моего предыдущего сообщения, разработчиком принудительно заменяется, к примеру, на TLV2452. При этом скрипт Константина Барановского выведет в перечень именно TLV2452, а Ваша программа выведет OPAMP2_8 TLV2452. Но ведь никакого «OPAMP2_8» на схеме нет!
Вот я и пишу, что не важно как назывался компонент в библиотеке, а важно как он стал называться в схеме и брать информацию нужно только из схемы + те доп. поля, что генерит Ваш менеджер.
Если теперь Вы перечитаете несколько моих последних сообщений на эту тему, то теперь все должно быть понятно.

См. ответ в моем предыдущем абзаце.

Как же нет связи? Если Вы ознакомились с кодом скрипта Константина Барановского и Вам стало ясно как он выводит информацию в перечень без «косяков», то что мешает применить новое знание на практике? Вот я и пишу, что теперь-то все будет в порядке, разве не так?

Я разработчик, и я от этого ушел! Жалко времени. У нас на предприятии широко используется два типа усилителей: AD820 и OP2177. Все! И спрашивается, зачем мне каждый раз писать AD820 или OP2177? И в таком случае при использовании даже того-же OPAMP2_8 создайте к нему псевдонимы и они автоматом встанут в поле "Тип", и Вы получите сразу нормальное обозначение в перечне. Но, похоже, Вам лень добавить Alias к тому же OPAMP2_8, которого в схеме нет и быть не может. Добавте к OPAMP2_8 поля Title и Type и не будет у Вас проблем, что вдруг случайно какое-то мясо попало в перечень.

Вот если даже невольно вдуматься в исходную логику разработчиков KiCAD и поле "ссылка на документацию" в компоненте. Вы на какой абстракт ссылаться собираетесь? OPAMP2_8.pdf? А эти ссылки заполняются до того, как компонент попадет на схему.

Aldan
Информация отраженная в схеме самодостаточна и нет нужды к ней примешивать еще что-то.
Недостаточна. На схеме, как правило, не указывается мощность (хотя и можно в УГО, но не все, а только до 5 Вт), точность, и уж точно не указывается тип резистора. Про конденсаторы и говорить нечего, там это ещё важнее. Я практически постоянно использую разные типоразмеры резисторов и конденсаторов. А у конденсаторов и разные напряжения (соответственно и диэлектрики).

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

брать информацию нужно со схемы, а не откуда-то еще.
Это правильно. На схеме в дополнительные поля элемента можно внести необходимую информацию. Эти поля можно сделать невидимыми (или как-то ещё, чтобы видно было, но не печаталось), и вставлять эти поля в перечень/спецификацию. Может к каждому полю завести кроме атрибута "Показать", атрибут "Печатать"?

Второе — прошу, например, break в качестве стороннего наблюдателя сообщить нам на самом ли деле я так путано выражаюсь или все же что-то можно понять из моих объяснений.
Откровенно говоря, я не вчитывался в этот спор, только просмотрел "по-диагонали" - "слишком много букв", а времени не хватает вникать. (Мне тут ещё столько схем надо проверить... включился защитный клапан

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

AVL
Может кто подскажет по обозначению сопротивлений? На сколько мне было известно, сопротивление ниже 1 кОм в КД вроде как должно обозначаться просто числом без слова "Ом". Например 220 Ом должно обозначаться просто числом 220. Пробежался по ГОСТ 8.417-2002, однако нигде не могу найти такого требования, что указывать Ом не нужно.
Как правильно должно быть, кто знает?
Не тот ГОСТ.
ГОСТ 2.702-75 Правила выполнения электрических схем

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

tema-electri
И спрашивается, зачем мне каждый раз писать AD820 или OP2177?
С точки зрения трудозатрат, никакой разницы нет - писать в каждом элементе прямо на схеме, или добавить Alias.

1) Псевдоним делается 1 раз, по первой необходимости. Делается за 10-30 секунд.
2) Нет разницы, что искать в библиотеке OPAMP2_8 или AD820
3) В настоящий момент применение псевдонимов позволяте автоматически заполнить поле "Тип" у микросхем.
Спорить нет особого желания об этом. Каждый работает в своем стиле, и экономит время по-своему. Писать о важности суффиксов в конце обозначения микросхем тоже не хочу.

Здесь необходимо "разжевать молекулы на атомы" чтобы я понял.
Как можно изменить поле Chip Name у компонента, после его вставки в схему на новое имя X при этом не имея в наличии другого библиотечного компонента либо его псевдонима с именем X?

Так GOST-doc-gen и так берет все поля компонентов из схемы, напрямую из библиотек ничего не берется. Библиотечные атрибуты используются только в момент разработки схемы (вставки библиотечных компонентов в схему). После того как разработчик вставил компонент в схему, он либо оставляет значение атрибутов компонентов как есть, либо редактирует по необходимости.

Я отвечал Вам ранее:

Какое новое знание мне нужно применить на практике?
А в сообщении я подробно объяснил как формируется поле "Тип".
Здесь добавлю резюме:
1) в скрипте Константина читается атрибут "Марка"
2) а в GOST-doc-gen читается атрибут "Type" при условии, что атрибут "Type" был задан у компонента тем или иным способом (руками в схеме, либо через менеджер компонентов). Если же атрибут "Type" отсутствует (сырая схема), то читается поле Chip Name этого компонента.

И в случае скрипта Константина и в случае GOST-doc-gen нужно задать необходимые атрибуты, чтобы значения этих атрибутов в конечном итоге появились в КД.
Эти атрибуты, если их нет в библиотечном компоненте изначально, ни откуда не возьмутся, пока разработчик схемы сам их не добавит каким-либо из способов.

Я поэтому не понимаю к чему Вы клоните


Отлично, спасибо.

Что-то у меня ничего не получается с kicadbom2spes. Делаю всё по инструкции (кроме пути - не "Program Files (x86)", а "Program Files"), но:
1. Pyton не устанавливается. Приходится вручную устанавливать отдельно.
2. Не знаю как и куда устанавливается odfpy (причём тоже вручную отдельно), но в консоли пишет только:

3. При нажатии "Создать спецификацию", ничего не происходит.

Похоже CSV файл не нравится.

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

Наверное Вы являетесь начальником, так как не замечаете как переходите на менторские нотки: «создайте», «вам лень добавить», «добавьте».., но разве я просил Вас поучать меня, или Вы считаете себя умнее всех?
Поскольку Вы не считаете возможным для себя читать мои сообщения внимательно, то повторяю, что «OPAMP2_8» является прототипом тысяч, Вы слишите, ТЫСЯЧ различных операционников с такой структурой, так что, мне заполнить на них всех алиасы? Если так сделать, то вместо нескольких прототипов «OPAMP» появятся несколько ТЫСЯЧ названий алиасов и библиотека превратится в помойку. Конечно же, конечный пользователь, да еще такой как Вы с двумя операционниками может заполнить парочку алиасов и радоваться, но зачем же говорить за всех?

И об этом я Вам уже писал в конце своего прошлом сообщения: «Это очень важно, т. к. вольность в оформлении библиотек «не переделанных под менеджер» будущими пользователями может привести к косякам в будущем. Нужно радоваться, что нескладухи проявились именно сейчас — на старте.» Разве не понятна простая мысль, что различные разработчики библиотек могут просто не знать о каких-то дополнительных правилах и ограничениях, навязанных Gost doc gen, поэтому разумно постараться не заставлять пользователя что-то дооформлять или переделывать, а пойти таким путем, который позволит обойтись без этого. Только тогда можно будет быть уверенным, что у пользователей «некалиброванных» библиотек не появятся проблемы в виде каких-то «косяков». Скрипт Константина Барановского показал, что такой путь возможен, все остальное — отговорки и нежелание быть честным перед собой.

Если скачать полную сборку Кикада, т. е. с документацией, с фтп Жан Пьера и посмотреть в поле "ссылка на документацию", то мы увидим, что там находится именно ссылка на документацию — pdf-даташит на данный компонент. Я этим не пользуюсь, т. к. не считаю нужным захламлять свой компьютер ненужной документацией. Все, что мне нужно для работы есть в моей удобной библиотеке даташитов, причем, я постоянно отслеживаю их «свежесть». При желании, я мог бы дать ссылки на эти даташиты в используемых мною компонентах, но не нахожу в этом необходимости.
Для такого пользователя, как Вы, работающего с малым количеством комплектации, можно и нужно заполнить все поля компонента при его создании и радоваться, ну а тем, кто работает с разнообразной комплектацией придется пользоваться услугами менеджера Gost doc gen. Все поля у моих компонентов чисты, т. к. их содержание будет изменятся в зависимости от того, какой КОНКРЕТНО компонент в данной схеме они представляют.
-----
tema-electric, наше с Вами общение не несет содержательного характера, но отнимает много времени на ответы Вам. Прошу Вас впредь писать мне только то, что очень важно или не писать вовсе иначе мне просто придется уклоняться от ответов Вам.

Да, действительно Вы не вчитывались в данную дискуссию, иначе бы заметили, что только что я ответил AVL по данному поводу:

Ваше отношение к «злобным буратино» тоже не разделяю

И на это я уже отвечал, считая, что лучше избегать такого подхода, чтобы у любого пользователя не возникало косяков. Раз есть возможность обойтись без дополнительных доделок-переделок, то почему бы это в Gost doc gen не сделать? Вот скрипт Константина Барановского, например, без доделок-переделок выводит все правильно.

AVL, я ведь простой пользователь и не обязан знать «кухню» внутреннего устройства Кикада. Все эти «поля», «атрибуты» и их конкретные названия предлагаю отодвинуть в сторону и услышать меня чистым непредвзятым разумом. Я предлагаю Вам потратить несколько минут на проведение небольшой практической работы по установке компонента из библиотеки в схему и понаблюдать за тем, что происходит. Т.е. акцент будет смещен не на то, что я объясняю, а на то, что Вы сами увидите. Думаю, такой подход должен полностью исключить всякое недопонимание.
Итак, запускаем kicad_gost_commiters, подключаем мою библиотеку analog_IC.lib и открываем какую-нибудь из Ваших небольших схем, которую не жалко будет испортить.
Далее открываем библиотеку analog_IC.lib и выбираем для схемы парочку компонентов, например, - LM2664 и OPAMP1_8. Далее, двойным щелчком кликаем по полю «OPAMP1_8», правим это поле на TLV2450 и тем самым условное обобщенное название одиночного операционника в 8-ногом корпусе - «OPAMP1_8» принудительно приобретает конкретное название «TLV2450». После этой процедуры «OPAMP1_8» остался в библиотеке, на на схеме фигурирует уже только «TLV2450».
Далее, для достоверности эксперимента, присоедините эти микросхемы куда-нибудь в своей схеме и, завершив работу со схемой, создайте перечень с помощью Gost doc gen. Рассматривая полученный перечень, Вы заметите, что микросхема LM2664 в нем отразилась чисто, без «косяков», а вот TLV2450 отразилась как OPAMP1_8 TLV2450. В схеме OPAMP1_8 нет, а в перечне — есть. Непорядок
Все мои усилия были направлены только на то, чтобы избавиться от этого «косяка» и выводить название компонента так же чисто, как это делает скрипт Константина Барановского. Все.
AVL, теперь у Вас нет права говорить, что Вы что-то не поняли, по крайней мере, если не хотите, чтобы я застрелился Кикад, библиотека и косяки — все перед Вами и в Вашей власти, так что все вопросы к ним

Aldan
Да, действительно Вы не вчитывались в данную дискуссию, иначе бы заметили, что только что я ответил AVL по данному поводу:
Это как раз прочитал. Мне казалось, что я тоже имею право высказывать своё мнение, а не просто поддакивать.

Вот скрипт Константина Барановского, например, без доделок-переделок выводит все правильно.
У кого как. У меня вообще ничего не выводит.

Это зря. Дьявол в деталях.

Отлично, тоже хотел предложить.

У меня чувство, что Вы знаете то, чего я не знаю.
Из Вашего описания я не могу понять что, где и как открыть, чтобы получилось как у Вас. Я даже открыл eeschema и не могу понять что я должен где нажать.
Есть ли где-то инструкция по данной функциональности, может в документации на EEschema? Можете указать страницу где про это написано, чтобы я изучил? Документацию на eeschema я однажды читал мельком, времени досконально перечитывать документацию у меня пока нет.
Либо сами сможете четко по пунктам изложить, что куда нажать? Вплоть видеоролик сделать этих действий, я уж не знаю.

По крайней мере, пока не пойму Ваши действия по добавлению компонента в схему, нет смысла ссылаться на скрипт Константина. На текущий момент, имея мое представление, я не вижу разницы в работоспособности между GOST-doc-gen и скриптом по данному вопросу.
Сейчас первым делом мне нужно понять как Вы добавляете компонент.
Я добавляю компонент иным образом, поэтому у меня, наверно из-за этого, другое представление о проблеме.
Единственное, прямо сейчас нет под рукой библиотеки analog_IC.lib. Я открывал стандартную библиотеку 74xx. Надеюсь это не играет роли?

Нет здесь таинства. Таково поведение программы. Если взять стандартный компонент с определенными полями: Позиционка (F0), Значение (F1), Посадочное (F2), Документация (F4), то GOST-tools менеджер отобразит в поле "Тип" библиотечное название компонента. В спецификацию попадет склейка "Type" + "Значение"(F1). Об этом и пишет Aldan. В данном случае "Type" автоматом определился как OPAMP1_8, а значение (F1) забито ручками как " TLV2450".

Об аномалиях я уже писал Вам. Если GOST-Tools не находит поле "Type" в компоненте, он его определяет автоматом по библиотечному наименованию, при этом это поле не прописывается в компонент до тех пор, пока пользователь руками не введет некое значение (не пустое). Я по первости мучился. Очищал поле "Тип" в менеджере бэкспейсом, генерировал перечень, но если переоткрыть GOST-Tools то снова сработает автозаполнение, потому что удаление значений из поля "Тип" в менеджере не приводит к сохранению пустого поля "Type" в компоненте. Вот если пробел записать или полное название, тогда все будет супер.

Аномалия, которую я обнаружил, это то что в GOST-Tools для двух разных компонентов "Тип" компонента в менеждере в одном случае автоопределился по библиотечному названию, а в другом по полю "Значение"(F1). Т.е. что-то где-то не так работает. Чтобы увидеть эту аномалию, посмотрите схему, которую я Вам выслал и комментарии к ней в первом письме.

Здесь я разграничил для понимания.

"Тип" в менеджере - это то что менеджер показывает.
Type - это поле, хранящееся в компоненте.

PS: Сейчас подумал о тильде. Может с ней какие-то фокусы. Поле не может быть пустым, там должна быть она ~.

Ваше объяснение понял. Неужели Aldan это и имел в виду?
Вроде с ним вели речь об имени компонента (chip name). Не мог подумать, что имелось в виду поле "Номинал" ("Value") компонента в eeschema.
Aldan, все правильно? Это и имели Вы в виду?

Насчет поля "Номинал" у компонента мы уже ведь обсуждали. С моей точки зрения (и, как выяснилось, не только моей) автозаполнение поля "Номинал" значением из "Chip Name" в момент добавления компонента в схему - это баг дизайна eeschema.
Было предложено простое решение - при чтении схемы, если значения полей Chip Name и Value совпадают, то поле Value интерпретировать как пустое. Такую доработку я и внес в GOST-doc-gen. Мне казалось, что на этом вопрос исчерпан.

Соответственно возникает вопрос, а зачем идти на поводу кривости дизайна eeschema по указанной проблеме и вбивать в поле "Номинал" тип (марку) реального компонента?
Ну допустим вы идете этим путем:
1) добавляете в схему библиотечный компонент 7400 (поле "Chip Name" = "7400", поле "Value" = "7400")
2) меняете поле "Value" с "7400" на "SN74HC00D"
а что вы будете делать в случае с конденсаторами, резисторами и т.д.?
1) добавляете в схему библиотечный компонент С (поле "Chip Name" = "С", поле "Value" = "С")
2) меняете поле "Value" c "C" на "К73-17"
3) и дальше что? куда вводить номинал "0,1 мкФ"?

В GOST-doc-gen для вбивания типа (марки) используется дополнительный атрибут "Type". И нет проблем.

Пример схемы пока не смотрел. Поздно вечером смогу посмотреть. Но я так понимаю я правильно понял все?

Не совсем понял о какой проблеме идет речь.
Если что, GOST-doc-gen интерпретирует поле "Value" как пустое, если поле "Value" == полю "Chip Name", либо поле "Value" == "~".

Это первое, с чем я столкнулся. У меня также были записульки в стиле CAP_0805_BOX Чип 0805 X7R 1 мкФ 25 В ))).


Видимо это я и принял за аномалию, а он оказывается сравнивает и выкидывает. 2 = 2; 2 + 2 = 2. В этом был вопрос. Теперь ясно. Но механизм не прозрачен. Лучше бы он автоматом очистил Value (при совпадении с ChipName) и создал Type для однозначности.


Это я понимаю, и этим пользуюсь.
_____________________________________________________________________________

Ммм, не прошло и часа. Александр, я понял, зачем Вы привели пример с микросхемой и конденсатором.

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

В зависимости от типа компонента ГОСТ-tools производит разную обработку.

Для старых: добавляется поле Type = ChipName; Value = "~" в случае, если ChipName==Value; Иначе просто добавляется поле Type="~"; Value остается без изменений. Старый компонент становится "Новыми". Первый случай подходит для микросхем. Второй случай подходит для чего угодно, например резисторов и конденсаторов.

Для новых: Value="~", если ChipName==Value. Иначе ничего не трогается. Структура уже заполнена как надо.

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

Сейчас осознал, что они пишут в этом ГОСТе об указании номиналов около УГО (на схеме).
А вот интересно, есть ли какой-то ГОСТ по этому поводу для ПЭ3 и спецификации? Я на сколько понял ГОСТ 8.417-2002 это регулирует (засомневался, что ГОСТ 2.702-75 это определяет). Если все-таки ГОСТ 8.417-2002 для ПЭ3 и спецификации, то насчет использовать "Ом" или без "Ом" там не могу найти.

P.S.: так для информации, в поисковике нашел ГОСТ 2.702-2011, который взамен ГОСТ 2.702-75.

А я и не просил поддакивать.

Руководство по пользованию скриптом kicadbom2spes, написанное Константином Барановским просто до дотошности подробно. Главное, нужен питон2, а не питон3. И еще, у меня питон установился в корень диска С, а Вы пихаете его "Program Files", что может быть и не критично, но уже является самодеятельностью.
На мой взгляд, если хотите получить гарантированный результат, следуйте требованиям руководства пользователя без самодеятельности и все должно получиться.
Самое лучшее, конечно, это получить консультацию от самого Константина, но он, видимо, пока очень занят т. к. не ответил на Ваше сообщение, да и на мое http://electronix.ru/forum/index.php?showt...t&p=1170196 тоже не ответил.

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

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

А что, скачать с фтп слабо или мощности интернета хватает только на форум? Прилагаю эту библиотеку в аттаче.

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

Не совсем правильно меня поняли. Владею кикадом в том объеме, какой мне потребовался для разработки пока одного устройства, о котором я писал в этой теме. А также в том объеме, чтобы интегрировать/разрабатывать pcad2kicad, а также менеджер компонентов + GOST-doc-gen.
Но уверен, что не владею кикадом в 100% функциональности.
Я просто написал Вам, что я усомнился в том, что знаю все способы добавления компонента в схему, поскольку Вы объясняете столь уверенно, а я не понимаю, что Вы имеете в виду.

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

Предлагаю не отклоняться от темы.

Ну почему слабо. На той машине, с которой писал сообщение и запускал кикад, закрыт доступ по 21 порту и еще куче других портов.

Хорошо, вот дома у меня есть Ваша библиотека analog_IC.lib.
1) Я вставил в схему компонент OPAMP1_8. Сверху УГО написано DA?. Снизу УГО написано OPAMP1_8.
И тут я наконец-то нашел место о котором Вы говорили где нужно щелкнуть 2 раза.
2) щелкнул 2 раза, появилось диалоговое окно "Edit Value Field". Исправил OPAMP1_8 на TLV2450. Нажал ОК. Снизу УГО теперь написано TLV2450.
3) щелкаю 2 раза на УГО. Открывается окно "Component properties". И что я вижу? Поле "Chip Name" = "OPAMP1_8". Поле "Value" = "TLV2450".
Вывод. Имя компонента как было "OPAMP1_8", так и осталось, о чем я Вам и писал. А изменилось поле "Value" - это номинал компонента, который имеет смысл только для таких компонентов как конденсаторы, резисторы и др. Для микросхем поле "Value" не имеет смысла. Только вводит людей в заблуждение.

Перепроверил с добавлением компонента 7400 из стандартной библиотеки. Такой эксперимент действительно не удается повторить с 7400 как Вы описывали. Поэтому у меня и не получилось. Причина - атрибут "Value" для 7400 располагается внутри УГО. Поэтому можно общелкаться по нему, но выпадают там другие контекстные меню, которые не попадали под Ваше объяснение.

Значит tema-electric правильно объяснил мне, что Вы имели в виду.
Тогда вернитесь к нашей с ним переписке и попробуйте вникнуть в объяснение, которое я там дал. А также в предложение tema-electric как изменить логику.
См. мое сообщение и его сообщение.

Если Вы мне сейчас начнете говорить "а как же быть с пустыми полями "Value", теперь не будет надписи TLV2450 под УГО". Здесь ответ такой - в общем случае этого добиться не возможно.
К примеру у меня много схем, в которых есть исполнения. Есть схема с 13-ю исполнениями. Так вот в таких ситуациях не реально отобразить все возможные значения номиналов, типов и еще чего-либо. Я в свое время пришел к решению вообще ничего не отображать рядом с УГО кроме позиционного обозначения. ГОСТ разрешает вообще не указывать номиналы и т.д. кроме позиционных обозначений.
Вся информация по компонентам (номиналы, допуски, типы и т.д.) содержатся в спецификации и ПЭ3. Спецификация в основном для закупки. ПЭ3 и монтажная схема для монтажа.
На схеме в основном отображение номиналов/типов может быть полезным для разработчика и регулировщиков. Но как я сказал, в случае схем с исполнениями, это не реально. Для схем без исполнений, если есть большое желание показывать на схеме номиналы/типы, то для конденсаторов/резисторов/др. использовать поле "Value", а для остального (микросхем и подобного) использовать дополнительное поле "Type" (делать его видимым), а также делать остальные поля видимыми при крайней необходимости (например, "Precision" (Допуск), "Note" (примечание) и др.).

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

С другой стороны новый подход с применением GOST-Tools позволяет расставлять номиналы возле компонентов, потому что теперь они короткие, и не надо в поле Value пихать вся и все. А синхронизация с перечнем и спецификацией выполняется автоматически.

AVL
Если все-таки ГОСТ 8.417-2002 для ПЭ3 и спецификации,
Вообще-то нет. Именно ГОСТ 2.702-2011, ГОСТ 2.105-95, ГОСТ 2.106-96. Напрямую нигде не нашёл, хотя есть образец перечня с обозначением единиц измерения номинала, да и по-логике нужно писать, чтобы не путать с другими обозначениями, например, "Резистор МЛТ-0,25-120 Ом ±10%". Предположим, что его мощность 1 или 2 Вт, а сопротивление 1 или 2 Ом, соответственно. Если не писать единицы измерения, то получится "МЛТ-1-1 ±10%" или "МЛТ-2-2±10%". В конце-концов разобраться можно, но вероятность ошибки возрастает.

Спасибо за информацию об обновлении ГОСТа.

К примеру у меня много схем, в которых есть исполнения. Есть схема с 13-ю исполнениями. Так вот в таких ситуациях не реально отобразить все возможные значения номиналов, типов и еще чего-либо. Я в свое время пришел к решению вообще ничего не отображать рядом с УГО кроме позиционного обозначения.
У нас на каждое исполнение отдельный рисунок. Тем более, что не всегда он ограничивается только изменением номинала.

ГОСТ разрешает вообще не указывать номиналы и т.д. кроме позиционных обозначений.
Скорее наоборот:

Aldan
На мой взгляд, если хотите получить гарантированный результат, следуйте требованиям руководства пользователя без самодеятельности и все должно получиться.
Образец, который ставится вместе со скриптом, преобразуется нормально, а мой - не хочет.

tema-electric
Нас на кафедре за расположение номиналов около элементов в Э3 очень сильно ругали.
Меня тоже учили не писать на схеме, но потом на работе убедили, что с номиналами гораздо удобнее для монтажников и, особенно, регулировщиков/ремонтников.

Сможете Ваш пример привести?
У меня тоже не только номинал, но и тип, а также факт установки/не установки компонента варьируется от исполнения к исполнению. Все это отражается в ПЭ3 и спецификации. Если говорить непосредственно о проводниках, то они ведь полностью соответствуют топологии печатной платы и представляют собой полную схему с покрытием всех исполнений (мы же не можем в зависимости от исполнения добавлять / отрезать дорожки на реальной готовой подложке при условии, что это не прототип и не исключительные ситуации по устранению мелких багов разработки).

Смотря кто убеждал. Если начальник отдела монтажа, настройки, ремонта, тогда понятно. В своё время один из таких начальников настаивал изображать УГО микроконтроллеров в корпусах TQFP квадратными, чтобы выводы УГО точно совпадали с ножками микросхемы. Опять же объяснял это заботой о ремонтниках.
Меня учили, что в первую очередь удобно должно быть разработчику, ибо его ошибки дороже всего обходятся. Поэтому в данном случае я как разработчик считаю, что номиналы загрязняют схему.

Думаю для ситуаций, когда печатается схема для регулировщиков, можно предложить поддержать пункт в меню в eeschema, чтобы включить отображение всех вспомогательных полей такие как номинал, тип. Причем лучше, чтобы было также введено понятие слоев как в печатной плате и управлять видимостью слоя, куда помещены эти атрибуты (номинал, тип и др). Причем помещены на этот слой только те атрибуты только тех компонентов, которые хочется отобразить для таких случаев печати схемы.
У нас в случае ручного монтажа на производстве монтажники, если им дать сборочный чертеж платы без указания номиналов (только поз.обозначения + ПЭ3, а именно в таком виде сборочный чертеж хранится в архиве), все равно сами руками подрисовывают номиналы на своей копии (переносят информацию из ПЭ3 на сборочный чертеж). Поэтому я в проекте pcb номиналы / типы / допуск и др. полезную инфу помещаю на отдельный слой. Этот слой включаю на печать только для монтажников.

AVL
Сможете Ваш пример привести?
К сожалению, нет. Нам запрещено показывать свои схемы на сторону (хотя отдельным заказчикам предоставляем). Даже сотрудники не всех отделов доступ имеют. Я лично смысла не вижу, но не я определяю политику.

У меня тоже не только номинал, но и тип, а также факт установки/не установки компонента варьируется от исполнения к исполнению. Все это отражается в ПЭ3 и спецификации. Если говорить непосредственно о проводниках, то они ведь полностью соответствуют топологии печатной платы и представляют собой полную схему с покрытием всех исполнений (мы же не можем в зависимости от исполнения добавлять / отрезать дорожки на реальной готовой подложке при условии, что это не прототип и не исключительные ситуации по устранению мелких багов разработки).
Зато те элементы, которые не устанавливаются, на схеме рисовать не надо. В одной из последних приведённых разводок на плате в одном посадочном месте присутствовало сразу несколько элементов, которые должны устанавливаться в зависимости от исполнения. Понятно, что на схеме для разводки я нарисовал всё, чтобы попало на плату. Но при оформлении чертежа конкретного исполнения это бессмысленно и даже вредно.
В одной схеме я даже на место резисторов поставил конденсаторы, а вместо диода - резистор, чтобы не делать лишнюю разработку ради пары плат, которые не должны были больше повторяться.

IgorKossak
Смотря кто убеждал. Если начальник отдела монтажа, настройки, ремонта, тогда понятно.
Как раз начальник отдела разработки (это ещё на другой работе). Правда отдельного производства тогда не было, паяли сами, в том числе и я. Но я паял по схеме, а сейчас наши монтажницы паяют по сборочному чертежу и спецификации, схема им вообще не нужна. Автомату - тем более .

Барановский Константин
Вот такая фигня происходит при попытке генерации спецификации:

Файл csv прикладываю. Это я его уже немного преобразовал - удалил ненужные поля (в разъёме названия цепей сделаны полями, чтобы не рисовать сотни разъёмов), заменил запятые табуляцией. Но и исходный файл не обрабатывается.
Образец обрабатывается нормально.
Про косяки с установкой я уже писал ранее.

Удалось проблему повторить на виртуалке Ubuntu.
Проблема не старая, а новая (в новом коде для поддержки новых форматок).
Исправил в ревизии 4155 ветки lp:~kicad-gost-committers/kicad/kicad.


Да, я имел в виду на словах пример объяснить.

Ну насчет таких ситуаций можно пойти дальше Получается, что нужны исполнения не только для атрибутов, но и для УГО
Для pcb я делал инструмент, позволяющий вырезать для текущей сессии все компоненты не относящиеся к определенному исполнению. После чего получал монтажную схему для конкретного исполнения без лишних компонентов на ней. Сборочный чертеж (вид) я тоже делаю отдельный для каждого из исполнений. Однако для схем пока не делал отдельные рисунки для каждого исполнения.
Для схемы можно было бы сделать такой же инструмент для удаления, а лучше скрытия тех компонентов, которые не относятся к выбранному исполнению. Однако еще будет вопрос с проводниками, чтобы огрызки не висели.

Похоже из-за последних изменений BOM-генератора в KiCAD формат csv уже не соответствует тому, который был при написании скрипта. Да и вообще хочу уйти от csv перечня и использовать только файл схемы, ведь внутри все есть. Но сейчас на это нет времени, извините.

Константин, к сожалению и файл схемы скорее всего изменится скоро по аналогии как это было сделано относительно недавно для Pcbnew (переход на S-expressions).
Вообще многократно слышал на developer mailing list, что многие там текущий дизайн eeshema не воспринимают и озвучивают желание переписать eeschema с нуля, чем ходить вокруг до около. С другой стороны, в последнее время много коммитов идет для eeschema. То есть пока выглядит все как эволюция.
Революцию они устроили пока только для BOM.

Собрал, проверил. Перечень получился. Глубоким тестированием пока некогда заниматься, но внешний вид уже как у конфетки

Очень жалко, если формат eeshema поменяется. Там и до библиотечных компонентов недалеко, а там и скрипт для ПЛИСов приедтся переделывать.

Но с другой стороны, старый формат же должно у них хватить ума оставить (legacy). Хотя на примере с BOM не знаю, что и ожидать еще.


Спасибо Константину Барановскому, что уделил время на разработку новых форматок для GOST-doc-gen, имея при этом очень важные другие дела.

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

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

Что я имею в виду я только что Вам написал.

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

Да, интересные все-таки люди бывают.

Сегодня сделал вручную из пары "старых" компонентов пару "новых" во время работы по предложенному подходу, и тут же обжегся в CvPCB. Поле Value пустое оказалось и что за микросхема - не понятно, т.к. она записана в поле Type. Есть обозначение DA10 и корпус. А копуса перепутались до этого. Надо было восстановить порядок.

Провел анализ предложенного Вами алгоритма.

Тестируемые случаи

импортированные схемы из P-Cad:
1) ChipName = "SN74HC00D", Value = "~"
2) ChipName = "К73-17", Value = "0,1 мкФ"
3) ChipName = "7400", Type = "SN74HC00D", Value = "~"
4) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"

оригинальные схемы KiCad сразу после добавления компонента в схему (без каких пока еще корректировок полей)
5) ChipName = "7400", Value = "7400"
6) ChipName = "C", Value = "C"

оригинальные схемы KiCad при использовании в режиме навязанного кривого подхода
7) ChipName = "7400", Value = "SN74HC00D"
8) ChipName = "C", Value = "0,1 мкФ"

оригинальные схемы KiCad при использовании в режиме выправленного подхода
9) ChipName = "7400", Type = "SN74HC00D", Value = "~"
10) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"

тестируемый алгоритм

Результирующие поля после обработки алгоритмом
1) ChipName = "SN74HC00D", Type = "~", Value = "~": OK
2) ChipName = "К73-17", Type = "~", Value = "0,1 мкФ": OK
3,9) ChipName = "7400", Type = "SN74HC00D", Value = "~": OK
4,10) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ": OK
5) [ChipName = "7400", Value = "7400"] => [ChipName = "7400", Type = "7400", Value = "~"]: OK
6) [ChipName = "C", Value = "C"] => [ChipName = "C", Type = "C", Value = "~"]: OK
7) ChipName = "7400", Type = "~", Value = "SN74HC00D": FAILED
8) ChipName = "C", Type = "~", Value = "0,1 мкФ": OK

В пункте 7 я пометил, что тест не пройден, потому что в поле "Value" реально попал не номинал, а тип.
Важно, чтобы тип был типом, а номинал был номиналом. В процессе формирования КД каждое поле обрабатывается своим специфическим алгоритмом. Если пытаться подменить их местами, то КД не будет сформирована корректно (как минимум не правильно будут сформированы группы компонентов и не правильно будет выполнена сортировка, одним словом наступит хаос).

Константин, у меня такой вопрос: при переходе только на файл схемы общие принципы взаимодействия с компонентами библиотек останутся прежними? Спрашиваю потому, что собираюсь сделать некоторое оформление полей компонентов и не хотелось бы, чтобы эта работа была напрасной по причине кардинальных изменений в работе Вашего скрипта.
Если не секрет, когда рассчитываете стать посвободнее и написать новый скрипт?
И еще, если у Вас появится время, помогите побороть странную особенность в работе скрипта: сгенерированные файлы .ods просматриваемые в ВинОфисе имеют нормальный вид за исключением некоторых погрешностей с форматированием, а вот если эти файлы просматривать, как положено, в ЛибреОфисе, то все совсем не так красиво. Наблюдается такая закономерность (проверял на 4-х проектах): если перечень получается больше, чем на одном листе, то первый лист не виден на предварительном просмотре и, следовательно, не печатается; если же перечень помещается на один лист, то тогда этот лист становится виден, но с артефактами: у некоторых групп строк по три строчки пропадают горизонтальные разделительные линии. Не думаю, что эти артефакты будут обязательно проявляться и в других коротких перечнях, а вот невозможность распечатать первый лист в длинных перечнях — стойкая закономерность.
Хочу отметить, что скрипт испытывался на проектах годовой давности. Не может ли это как то повлиять на такой странный результат? Может быть Вы глянете длинный перечень и, если все будет нормально, то перечень из старого проекта? Хотелось бы со всем этим разобраться, т. к. со остальным вопросов вроде бы больше нет.
И еще, когда я генерил перечни из разных проектов, то попался мне один из них с именем «SOR”. Так вот, после всех стандартных действий перечень так и не появлялся. Мне пришла мысль, что, возможно, имя слишком короткое и, после того, как я добавил к нему еще пару букв - все пошло. Лучше убрать такое ограничение на длину названия файла если это не вредит скрипту или указать это ограничение в доке.

Процесс формирования перечня элементов останется прежним. Новая идеология генерации BOM файлов, реализованная в KiCAD в виде плагинов, позволит запускать скрипт из интерфейса EEschema.
Хочу сделать редактор полей элементов, что позволит выполнять групповое редактирование, исключение ненужных элементов из документации и т.п.
Планирую начать работу над этим в конце следующей недели.


На счет отсутствия первого листа при печати, то думаю дело в диапазоне печати - его нужно задать. Для этого необходимо открыть первый лист и выделить ячейки А1:Q46. Это можно сделать разными способами, например, явно указать диапазон ячеек в соответствующем поле:

Нажмите для просмотра прикрепленного файла

и нажать Enter. Или с помощью мыши. Нажать ЛКМ на самой первой (верхней левой) ячейке и не отпуская ЛКМ тянуть вниз, выделяя нужные ячейки:

Нажмите для просмотра прикрепленного файла

После выделения нужно выбрать в меню: "Формат -> Диапазон печати -> Определить".
Теперь на печать должны выводиться все страницы.

На счет пропадания горизонтальных разделительных линий, хотелось бы больше подробностей.


Я бы посмотрел что внутри *.csv, если не жалко.


Никаких ограничений на длину имени файла нет (разве что ограничения файловой системы). Только что переименовал файлы из примера sample -> SOR, все работает. Похоже проблема была в чем-то другом.