[Aldan 0]

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

AVL, мне иногда кажется, что Вы просто посмеиваетесь надо мной, говоря, что ничего не поняли, или же захваченные своим видением «как должно быть» не можете воспринять нечто отличное от этого видения.

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

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

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

Здесь я отвечаю на Ваше предложение о том, что если в свойствах компонента ввести доп. поле и заполнить его у каждого компонента, то это может помочь решить проблемы появления «косяков». В прошлом сообщении я объяснил Вам, что не важно как назывался компонент в библиотеке, главное, как он называется на схеме. Каждый компонент на схеме имеет пару «обозначение-значение», например, обозначение — R1, значение — 1кОм.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ужааасссс! :(

Изменено 18 июня, 2013 пользователем Aldan

[AVL 0]

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

Как правильно должно быть, кто знает?

 

AVL, мне иногда кажется, что Вы просто посмеиваетесь надо мной, говоря, что ничего не поняли, или же захваченные своим видением «как должно быть» не можете воспринять нечто отличное от этого видения.

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

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

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

Здесь я отвечаю на Ваше предложение о том, что если в свойствах компонента ввести доп. поле и заполнить его у каждого компонента, то это может помочь решить проблемы появления «косяков». В прошлом сообщении я объяснил Вам, что не важно как назывался компонент в библиотеке, главное, как он называется на схеме. Каждый компонент на схеме имеет пару «обозначение-значение», например, обозначение — R1, значение — 1кОм.

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

 

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

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

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

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

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

Вы пишите:

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

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

Возможно, я что-то упускаю?

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

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

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

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

[Aldan 0]

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

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

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

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

Я говорю лишь о названии компонента в библиотеке и последующем его названии при установке в схему.

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

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

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

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

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

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

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

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

[tema-electric 0]

разработчиком принудительно заменяется, к примеру, на TLV2452.

...

Но ведь никакого «OPAMP2_8» на схеме нет!

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

 

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

[break 0]

Aldan

Информация отраженная в схеме самодостаточна и нет нужды к ней примешивать еще что-то.

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

 

вводить дополнительные поля и заставлять заполнять их пользователями.

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

 

брать информацию нужно со схемы, а не откуда-то еще.

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

 

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

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

 

наиболее употребимый вариант, на мой взгляд, - дроссели

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

 

AVL

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

Как правильно должно быть, кто знает?

Не тот ГОСТ.

ГОСТ 2.702-75 Правила выполнения электрических схем

3.36. При указании около условных графических обозначений номиналов резисторов и конденсаторов (черт. 11) допускается применять упрощенный способ обозначения единиц измерений:

для резисторов

от 0 до 999 Ом — без указания единиц измерения,

от 1·103 до 999·103 Ом — в килоомах с обозначением единицы измерения строчной буквой к,

от 1·106 до 999·106 Ом — в мегаомах с обозначением единицы измерения прописной буквой М,

свыше 1·109 Ом — в гигаомах с обозначением единицы измерения прописной буквой Г;

для конденсаторов

от 0 до 9999·12-12 Ф — в пикофарадах без указания единицы измерения,

от 1·10-8 до 9999·10-6 Ф — в микрофарадах с обозначением единицы измерения строчными буквами мк.

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

 

tema-electri

И спрашивается, зачем мне каждый раз писать AD820 или OP2177?

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

[tema-electric 0]

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

1) Псевдоним делается 1 раз, по первой необходимости. Делается за 10-30 секунд.

2) Нет разницы, что искать в библиотеке OPAMP2_8 или AD820

3) В настоящий момент применение псевдонимов позволяте автоматически заполнить поле "Тип" у микросхем.

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

[AVL 0]

Я говорю лишь о названии компонента в библиотеке и последующем его названии при установке в схему.

 

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

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

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

Здесь необходимо "разжевать молекулы на атомы" :) чтобы я понял.

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

 

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

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

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

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

Какое новое знание мне нужно применить на практике? :)

А в сообщении я подробно объяснил как формируется поле "Тип".

Здесь добавлю резюме:

1) в скрипте Константина читается атрибут "Марка"

2) а в GOST-doc-gen читается атрибут "Type" при условии, что атрибут "Type" был задан у компонента тем или иным способом (руками в схеме, либо через менеджер компонентов). Если же атрибут "Type" отсутствует (сырая схема), то читается поле Chip Name этого компонента.

 

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

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

 

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

 

Не тот ГОСТ.

ГОСТ 2.702-75 Правила выполнения электрических схем

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

Изменено 19 июня, 2013 пользователем AVL

[break 0]

Что-то у меня ничего не получается с kicadbom2spes. Делаю всё по инструкции (кроме пути - не "Program Files (x86)", а "Program Files"), но:

1. Pyton не устанавливается. Приходится вручную устанавливать отдельно.

2. Не знаю как и куда устанавливается odfpy (причём тоже вручную отдельно), но в консоли пишет только:

running install
running build
running build_py
running build_scripts
running install_lib
running install_scripts
running install_egg_info
Removing C:\Program Files\Python27\Lib\site-packages\odfpy-0.9.6-py2.7.egg-info
Writing C:\Program Files\Python27\Lib\site-packages\odfpy-0.9.6-py2.7.egg-info

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

 

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

Изменено 19 июня, 2013 пользователем break

[Aldan 0]

У нас на предприятии широко используется два типа усилителей: AD820 и OP2177. Все!

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

при использовании даже того-же OPAMP2_8 создайте к нему псевдонимы и они автоматом встанут в поле "Тип", и Вы получите сразу нормальное обозначение в перечне. Но, похоже, Вам лень добавить Alias к тому же OPAMP2_8, которого в схеме нет и быть не может.

Наверное Вы являетесь начальником, так как не замечаете как переходите на менторские нотки: «создайте», «вам лень добавить», «добавьте».., но разве я просил Вас поучать меня, или Вы считаете себя умнее всех?

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

Добавте к OPAMP2_8 поля Title и Type и не будет у Вас проблем

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

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

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

Для такого пользователя, как Вы, работающего с малым количеством комплектации, можно и нужно заполнить все поля компонента при его создании и радоваться, ну а тем, кто работает с разнообразной комплектацией придется пользоваться услугами менеджера Gost doc gen. Все поля у моих компонентов чисты, т. к. их содержание будет изменятся в зависимости от того, какой КОНКРЕТНО компонент в данной схеме они представляют.

-----

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

Недостаточна. На схеме, как правило, не указывается мощность (хотя и можно в УГО, но не все, а только до 5 Вт), точность, и уж точно не указывается тип резистора. Про конденсаторы и говорить нечего, там это ещё важнее. (...) Откровенно говоря, я не вчитывался в этот спор, только просмотрел "по-диагонали" - "слишком много букв", а времени не хватает вникать.

Да, действительно Вы не вчитывались в данную дискуссию, иначе бы заметили, что только что я ответил 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, теперь у Вас нет права говорить, что Вы что-то не поняли, по крайней мере, если не хотите, чтобы я застрелился :) Кикад, библиотека и косяки — все перед Вами и в Вашей власти, так что все вопросы к ним :)

Изменено 19 июня, 2013 пользователем Aldan

[break 0]

Aldan

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

Это как раз прочитал. Мне казалось, что я тоже имею право высказывать своё мнение, а не просто поддакивать.

 

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

У кого как. У меня вообще ничего не выводит. :crying:

[AVL 0]

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 нет, а в перечне — есть. Непорядок :)

У меня чувство, что Вы знаете то, чего я не знаю.

Из Вашего описания я не могу понять что, где и как открыть, чтобы получилось как у Вас. Я даже открыл eeschema и не могу понять что я должен где нажать.

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

Либо сами сможете четко по пунктам изложить, что куда нажать? Вплоть видеоролик сделать этих действий, я уж не знаю.

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

AVL, теперь у Вас нет права говорить, что Вы что-то не поняли, по крайней мере, если не хотите, чтобы я застрелился :) Кикад, библиотека и косяки — все перед Вами и в Вашей власти, так что все вопросы к ним :)

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

Сейчас первым делом мне нужно понять как Вы добавляете компонент.

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

Единственное, прямо сейчас нет под рукой библиотеки analog_IC.lib. Я открывал стандартную библиотеку 74xx. Надеюсь это не играет роли?

[tema-electric 0]

У меня чувство, что Вы знаете то, чего я не знаю.

Нет здесь таинства. Таково поведение программы. Если взять стандартный компонент с определенными полями: Позиционка (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: Сейчас подумал о тильде. Может с ней какие-то фокусы. Поле не может быть пустым, там должна быть она ~. :cranky:

[AVL 0]

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

 

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

 

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

 

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

 

"Тип" в менеджере - это то что менеджер показывает.

Type - это поле, хранящееся в компоненте.

Ваше объяснение понял. Неужели 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". И нет проблем.

 

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

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

Не совсем понял о какой проблеме идет речь.

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

[tema-electric 0]

Неужели Aldan это и имел в виду? :)

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

 

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

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

 

Соответственно возникает вопрос, а зачем идти на поводу кривости дизайна eeschema по указанной проблеме и вбивать в поле "Номинал" тип (марку) реального компонента?

.....

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

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

_____________________________________________________________________________

 

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

 

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

 

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

 

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

 

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

 

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

[AVL 0]

AVL

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

Как правильно должно быть, кто знает?

Не тот ГОСТ.

ГОСТ 2.702-75 Правила выполнения электрических схем

 

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

Сейчас осознал, что они пишут в этом ГОСТе об указании номиналов около УГО (на схеме).

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

 

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