[tema-electric 0]

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

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

В менеджере компонентов заполняю следующим образом для Вашего примера:

1) резисторы: поле "Наименование" Резистор, поле "Тип" 0805, поле "Номинал" 3 кОм, поле "Допуск" 5%

2) резисторные сборки: поле "Наименование" Резисторная сборка, поле "Тип" YC164, поле "Номинал" 1 кОм, поле "Допуск" 5%

 

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

 

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

 

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

Чип 0805 1 кОм ±5 %

 

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

[AVL 0]

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

Ранее я писал, что библиотека mixture.lib содержит обобщенные названия компонентов, которые в конкретной схеме приобретают совершенно конкретные значения.

Как образовалось наименование «с_сар»? Изначально в кикадовских библиотеках были графические обозначения двух типов конденсаторов постоянной емкости: «сар» — конденсатор и «сарр» — конденсатор поляризованный, т. е. электролитический. Позже, когда я всем компонентам раздал префиксы по ГОСТ из этих двух обозначений «сар» и «сарр» получились «с_сар» и «с_сарр». Таким образом, префикс «с» говорит о том, что это конденсаторы, а «сар» и «сарр» позволяет отличить обычный конденсатор от электролитического. Все это важно только до момента выбора компонента из библиотеки. Далее, в самой схеме, различение обычного конденсатора от электролитического обеспечивает его графическое изображение и никакие «сар» и «сарр» не применяются и на схеме Вы их не найдете.

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

Поскольку перечень формируется по конкретной схеме на которой нет никаких «с_сар», непонятно откуда же они и для чего в нем появляются? То же самое происходит и со всеми другими компонентами из библиотеки mixture.lib.

Вы все ждете у моря погоды, что КД сгенерируется на основе произвольной сырой схемы полностью без Вашего участия ;)

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

 

Одно из Ваших предложений было - добавить обработку префиксов полей 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 у компонента в схеме, либо открываем менеджер компонентов и смотрим в нем, ну и конечно же смотрим КД.

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

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

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

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

 

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

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

[AVL 0]

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

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

Здесь хочу добавить, что пока не вижу обоснования прикручивать эту программную обработку префиксов атрибутов 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 тоже используется информация прямо из файла схемы, а именно она вычитывается из атрибутов компонентов схемы. Мало того, используется информация текущего состояния схемы после того как файл схемы был открыт, и возможно, в добавок отредактирован без сохранения и повторного открытия (текущая сессия).

[tema-electric 0]

А вот другой пример, позиционное обозначение DR - резисторная сборка.

А DD - это сборка сборок, а DA - сборка устройств :a14:

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

[AVL 0]

А DD - это сборка сборок, а DA - сборка устройств :a14:

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

Нет, согласно ГОСТ (номер ГОСТа на прошлой неделе указывал, сейчас нет под рукой) имеет значение позиция символа. В случае двухбуквенных обозначений для каждой буквы своя таблица по интерпретации в ГОСТе.

У ведущей буквы D, на сколько помню, варианты интерпретации: микросхема, микросборка и еще что-то.

У следующей буквы, видимо, детализация:

DD - цифровая микросхема

DA - аналоговая микросхема

DR - резисторная сборка

? - диодная сборка

по аналогии если рассуждать DC - конденсаторная сборка - я никогда не встречал.

 

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

 

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

[tema-electric 0]

номер

2.710 :)

 

Сколько лет этому ГОСТу, а ничего не меняется.

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

[faa 4]

Нет, согласно ГОСТ (номер ГОСТа на прошлой неделе указывал, сейчас нет под рукой) имеет значение позиция символа. В случае двухбуквенных обозначений для каждой буквы своя таблица по интерпретации в ГОСТе.

У ведущей буквы D, на сколько помню, варианты интерпретации: микросхема, микросборка и еще что-то.

У следующей буквы, видимо, детализация:

DD - цифровая микросхема

DA - аналоговая микросхема

DR - резисторная сборка

? - диодная сборка

Резисторные сборки обозначаем как RA (resistor array) или RN (network - если связи есть между резисторами). Внутри УГО ставили *R.

Набор конденсаторов - по аналогии CA или CN (внутри УГО *C).

В перечне - отдельным разделом "Резисторные/конденсаторные сборки".

Нормоконтроль пропускает без вопросов.

Диодные сборки - как набор из диодов VD1.1, VD1.2 и т.д.

 

[AVL 0]

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

Открыл ГОСТ 2.710-81. Эти товарищи по ссылке в принципе ГОСТ не противоречат :)

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

Вот примеры из однобуквенной таблицы:

D - Схемы интегральные, микросборки

E - Элементы разные (ну а чем резисторные сборки не "разные", раз отдельной категории для них нет :) )

Однако у товарищей по ссылке обозначение предприятия внизу написано "ГНБК", а вверху "НИЦС" :)

 

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

 

Резисторные сборки обозначаем как RA (resistor array) или RN (network - если связи есть между резисторами). Внутри УГО ставили *R.

Набор конденсаторов - по аналогии CA или CN (внутри УГО *C).

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

Нормоконтроль пропускает без вопросов.

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

Диодные сборки - как набор из диодов VD1.1, VD1.2 и т.д.

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

 

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

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

[Aldan 0]

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

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

Одно из Ваших предложений было - добавить обработку префиксов полей Chip Name из библиотеки mixture.lib.

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

Я оставил префиксам их изначальное назначение — функциональная группировка компонентов и облегчение их выбора.

Теперь немного о том «откуда ноги растут» у моего пожелания возможно полнее реализовать автозаполнение полей. Здесь дело не только в том, что автоматизация способствует экономии времени, а еще и в психологии пользователя. Пользователь привык по нажатию кнопки получать готовый ВОМ, однако, при запуске менеджера и нажатии кнопки мы получим практически пустой перечень т. к. поля «наименование» не были определены.

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

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

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

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

Я поэтому и спрашивал ранее, почему префикс позиционного обозначения находится в поле chip name в библиотеке mixture.lib вместо того, чтобы находиться в самом позиционном обозначении (я пытался на тот момент вникнуть в логику mixture.lib). Вы, Aldan, тогда сказали, что эти префиксы находятся в поле chip name, чтобы было удобно выбирать библиотечный компонент из списка.

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

Зайдем в библиотеку analog_IC.lib. Просматривая компоненты мы будем видеть их реальные названия без всяких префиксов, т. к. каждое название относится только к одному конкретному компоненту а принадлежность к группе аналоговых микросхем содержится в самом названии библиотеки.

Однако, дойдя до буквы «о» мы увидим «OPAMP1_8» и еще пять других «OPAMP». В данном случае это уже не конкретное название компонента, а условное название группы «OPAMP» - операционные усилители. Сделано это для того, чтобы этими шестью условными компонентами описать несколько тысяч реально существующих операционных усилителей различных фирм.

«OPAMP1_8» означает, что это УГО одного операционного усилителя в корпусе с 8-ю выводами. «OPAMP2_8» означает, что это УГО двух операционных усилителей в корпусе с 8-ю выводами и т. д.

Если конкретные названия микросхем перекочуют в схему без изменения, то условные названия операционных усилителей будут заменены на конкретные названия компонентов в схеме. Таким образом, совершенно не важно как назывался компонент в библиотеке, важно как он в конце-концов называется в схеме. И если черпать информацию именно из схемы, то перечень будет содержать лишь то, что нужно и все косяки типа «с_сар» пропадут.

Как быть с диодной сборкой и другими не простыми наименованиями пока не знаю.

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

Не совсем понимаю, что значит используется информация прямо из файла схемы?

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

Посмотрел реализацию скрипта Константина.

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

[tema-electric 0]

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

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

 

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

 

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

 

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

[tema-electric 0]

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

 

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

[AVL 0]

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

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

Проверил на предыдущем Вашем примере, сгенерировалось нормально.

Есть ли возможность прислать конкретный пример, на котором эта ошибка выпала?

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

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

[Aldan 0]

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

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

К какому типу пользователей Вы себя относите, не понятно.

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

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

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

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

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

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

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

По поводу того, надо ли автоопределять что-то. Думаю что это плюшка-дополнение.

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

Сейчас можно работать и так.

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

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

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

Чем mixture.lib лучше других? У меня все библиотеки собственного изготовления, и я готов их адаптировать под GOST-Tools. И считаю, что без этого нельзя.

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

[AVL 0]

Так, по-спокойнее :) Любое общение по делу важно.

Единственное, Aldan, я не всегда понимаю смысл того, что вы пишите, извините:

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

 

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

Зайдем в библиотеку analog_IC.lib. Просматривая компоненты мы будем видеть их реальные названия без всяких префиксов, т. к. каждое название относится только к одному конкретному компоненту а принадлежность к группе аналоговых микросхем содержится в самом названии библиотеки.

Однако, дойдя до буквы «о» мы увидим «OPAMP1_8» и еще пять других «OPAMP». В данном случае это уже не конкретное название компонента, а условное название группы «OPAMP» - операционные усилители. Сделано это для того, чтобы этими шестью условными компонентами описать несколько тысяч реально существующих операционных усилителей различных фирм.

«OPAMP1_8» означает, что это УГО одного операционного усилителя в корпусе с 8-ю выводами. «OPAMP2_8» означает, что это УГО двух операционных усилителей в корпусе с 8-ю выводами и т. д.

Если конкретные названия микросхем перекочуют в схему без изменения, то условные названия операционных усилителей будут заменены на конкретные названия компонентов в схеме. Таким образом, совершенно не важно как назывался компонент в библиотеке, важно как он в конце-концов называется в схеме. И если черпать информацию именно из схемы, то перечень будет содержать лишь то, что нужно и все косяки типа «с_сар» пропадут.

 

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

 

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

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

 

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

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

[break 0]

:bb-offtopic:

Aldan

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

А у Mentor Graphics это основной принцип. Да ещё всё не собрано в библиотеки, а валяется отдельными файлами.