Да - да под виндой такое наблюдается

А при печати у вас наблюдается ошибка центрирования, описанная в сообщении 492?
Вот настройки:
Нажмите для просмотра прикрепленного файла
А вот результат:
Нажмите для просмотра прикрепленного файла

Тоже самое

Под линухом такая же ошибка.

Application: KiCad
Version: (2011-04-06 bzr2947 GOST)-testing
Build: wxWidgets 2.8.11 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.6)
Platform: Linux 2.6.33.7-server-2mnb i686, 32 bit, Little endian, wxGTK

Надо что-то делать... Думал сам найти где бага, ага... Пробовал вчера скачать исходники - мама дорогая, сколько же геморроя с этим ланчпадом. Насколько проще было на sf. А тут и зарегистрируйся, и rsa-ключи загрузи ("Чтобы загружать свои исправления на сайт" - но я не хочу загружать исправления, я хочу тупо получить актуальные исходники!) и все равно "setsockopt IP_TOS 8: Invalid argument:" и все, висим. Неудивительно, что у них всего три с половиной разработчика. Неужели bazaar не имеет возможности анонимного доступа только на чтение???

Возьмите исходники тут

неужели так не качает (первый абзац на https://code.launchpad.net/kicad ) :

Спасибо. В очередной раз появится свободное время - вытащу.
Так и пробовал. "Гладко было на бумаге". Сначала надо зарегистрироватьтя на Launcpad (вика об этом молчит), ибо bazaar требует launchpad id, причем отдельной командой, про которую эта вика не пишет. Потом требуется создать и загрузить на launchpad rsa-key, ибо иначе. А потом и все, висим часами. Вот такой вот ребус.

тут https://answers.launchpad.net/launchpad/+question/79261 пишут: достаточно создать сист.переменную BZR_SSH=paramiko

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

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

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

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

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

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

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

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

Может не в консерватории дело?
DRC нормально работает и очень помогает.

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

Стесняюсь спросить, а это зачем? Может есть какой-то скрытый смысл, который мне не доступен?

ИМХО, для этого надо очень сильно постараться. Что-то Вы не так делаете.

Не надо химичить. Надо просто прогнать нормальную (не фиктивную) дорожку с переходными отверстиями в нужном месте. Это на этом форуме уже обсуждали.

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


Несколько примеров.

SMD дроссель серии SRR6028. Рекомендуемый изготовителем футпринт:

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

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

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

С левой стороны каким-то чудом мне посчастливилось электрически соединить три площадки вместе. С правой, сколько ни бился, присоединиться к боковым площадкам не удалось, потому видны линии ratnest.

Второй пример: пятиногий футпринт D2Pack. Контактная площадка для теплоотвода (номер 3) состоит из 10 элементарных площадок:
- большой медный прямоугольник на верхнем слое без solder paste
- 5 переходных отверстий для передачи тепла
- 4 небольших контактных площадки на верхнем слое, сделанных ради того, чтобы получить нужную конфигурацию solder paste: паяльная паста на больших контактных площадках должна состоять из небольших изолированных друг от друга "заплаток" (иначе после пайки припой распределится неравномерно), кроме того, паяльная паста не должна наноситься поверх отверстий.

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

Для корпусов QFN центральные контактные площадки должны делаться так же.


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


Пользуюсь. Однако все контактные площадки она не соединяет. Замечено, что после групповой замены футпринта (при неизменной геометрии футпринта, ессно), они отсоединяются от дорожек, а после прогона этой команды назад соединяются не все. Один-два приходится соединять вручную.


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

Если же, несмотря на все усилия, на правильно разведенной плате DRC вываливает две страницы текста, то этот DRC - второсортный.

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


Вот это и есть "химичить". Дорожка, проходящая через полигон, есть криминал и источник проблем.

Тут всего лишь надо поставить галку "Притягивающая контактная площадка" "при создании дорожки" в общих настройках.
И тогда не надо ничего загонять в сетку.



Можно. Сделайте прямоугольную площадку без маски и накройте масками, чтобы получить нужную форму (технология SMD).
И этот фупринт рекомендован производителем. ИМХО, можно иногда отходить от рекомендаций производителя (с головой)
и просто прямоугольную площадку сделать.

Накройте полигоном - все площадки будут соединены.

В особо хитрых случаях можно генерить футпринты и площадки любой формы. Но это отдельная песня.
Вот какой-то СВЧ-делитель (для примера).
Нажмите для просмотра прикрепленного файла



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

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

И еще: при изготовлении трафарета производитель обычно начинает интересоваться - "а что-то у вас окно для пасты великовато? может его побить на более мелкие окна?"



Ну и делайте контактную площадку с отверстием, равным диаметру КП. Снимите галки с медных слоев - металлизации не будет.



Версия KiCAD какая?



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

Все неподключенные - это либо переходное на контактной площадке (осознанно), либо в термопаде (ну нет на нем полигончика).
ЧЯДНТ?

Application: KiCad
Version: (2011-04-08 bzr2952 GOST)-testing
Build: wxWidgets 2.8.11 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.6)
Platform: Linux 2.6.33.7-server-2mnb i686, 32 bit, Little endian, wxGTK

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


То есть, надо со вспомогательных площадок убрать медь? Хм, мысль интересная, попробую.... Нет, ничего не изменилось. Ратнест идет к площадке даже в том случае, если у нее выбран один только слой паяльной пасты, а других слоев нет.


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


Это как? В редакторе модулей нет полигонов. А в редакторе ПП, где полигоны есть, они не помогают: у меня эти компоненты как раз таки накрыты полигонами, толку - ноль.


Я ставлю большое отрицательное смещение, но с галкой лучше, согласен.


Так и делал, все площадки имели один номер


Сделал, это помогло. Спасибо!


Application: PCBnew
Version: (2011-03-29 BZR 2929)-stable
Build: wxWidgets 2.8.12 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.0,wx containers,compatible with 2.6)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Так и делаю, надеясь, что производитель ПП поймет, что я этим хотел сказать...


KiСad не позволяет снять галки со всех медных слоев для стандартной КП с отверстием. Тоже совершенно непонятная дурь: ему-то какое дело до того, какие слои я решил оставить?


Вообще можно сформулировать универсальное правило, по которому надо оценивать качество CAD-а:

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

Вот требования к топологии одного из производителей:

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


Не устраивает - ищите альтернативу первого сорта и используйте ее.

Положил на ftp://109.71.246.126/pub/kicad/library/pcad2kicad/tecad.zip
хорошую free-программу tecad.exe c GUI для трансляции в KiCAD ascii-файлов библиотек и проектов
P-CAD 200x SCH/PCB/LIA.

...скриншоты

У KiCad-а соотношение цена/качество такое, что с ним никто сравняться не может. Несмотря на то, что качество несколько хромает...

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

Вы очень вовремя. В этот же день один из заказчиков попросил "чуть-чуть" подправить проект 4-летней давности. Качество работы программы впечатляет - по плате и посадочным местам придраться практически не к чему - только какой-то косяк с заливкой зон (почему-то залитой оказывается только одна зона. Заливаешь любую другую - на первой заливка пропадает). А вот со схемой и схемными элементами сложности - споткнулась на гетерогенных компонентах, получившиеся схемы открываются пустыми. Ну да ладно - все равно планировалось создавать проект в KiCAD с нуля. Конвертация посадочных мест - уже большое подспорье в переносе проекта. Спасибо!

Погорячился. С гетерогенными все в порядке. Это я как-то неправильно понял данные в его окнах при конвертации. Есть мелкие косяки:
1) При конвертации текстов она почему-то меняет точку привязки по горизонтали с центральной на левую, одновременно сдвигая надпись, чтобы она визуально находилась на том же месте. Естетсвенно, при последующем редактировании надпись съезжает.
2) Игнорирует атрибут "не показывать имена" у отдельных выводов (если у элемента есть и выводы, для которых имена показывать нужно), что в общем-то понятно - кикад имеет такой атрибуд лишь для всего компонента. Хотя логичнее было бы поставить для таких выводов просто размер текста равный 0.
3) Если есть несколько выводов с одинаковыми именами (например, VDD), то оставляет оригинальное имя у одного вывода, дополняя остальные индексами _1, _2 и т.д. накладывая сверху оригинальное имя в виде текста. Считаю это лишним, т.к. кикад не имеет ограничений на одинаковые имена у нескольких выводов.

Можно ли исправить пункты 1 и 2 и отключить обработку по пункту 3?

Конвертацией посадочных мест просто восхищен.


для faa: Снова (заметил на сборке 2896-ГОСТ, сейчас проверил последнюю 2011-03-23 ГОСТ и 2932 с офф.сайта) вылез старый-старый глюк - в редакторе схемных элементов в гетрогенных компонентах при перемещении вывода перемещаются выводы, находящиеся в этой позиции во всех элементах. Аналогично и при блочном перемещении и копировании блока. Касается только выводов, остальные элементы УГО ведут себя адекватно. Поворот работает правильно. И если один из выводов повернуть, то его одиночное перемещение больше не захватывает выводы в других элементах. Надо бы отписать в рассылку...

Посмотрел на свежих сборках - нет такого эффекта.
Возможно была некоторая регрессия при рефакторинге кода.

Не собралась еще?

Понял. подождем свежих сборок.

2011-03-23 лежит.
А вот про 2011-03-29 забыли
Завтра напомню виндовому сборщику.

Посмотрим. Сделаем - сообщу.

Стал печатать - вот что вылезло, плюс старое осталось (сборка win32 2978 Gost testing)
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

А это при печати на принтер (в данном случае в pdf)
Нажмите для просмотра прикрепленного файла

И еще не печатает листы больше А2, жалуется на нехватку памяти.

Под виндой теряет букву диска - посмотрю на досуге.

Артефакты при печати видны под виндой, а под линухом вообще все буквы-цифры пляшут.
Что-то в связке kicad-wx при печати кривеет - бум смотреть.

Пока обхожу Чертить-SVG. И конвертирую, куда и как надо.


Кто жалуется? KiCAD или система?

Application: EESchema
Version: (2011-04-20 bzr2978 GOST)-testing
Build: wxWidgets 2.8.11 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.6)
Platform: Linux 2.6.33.7-server-2mnb i686, 32 bit, Little endian, wxGTK

Вот эта ошибка при печати А1
Нажмите для просмотра прикрепленного файла

Application: EESchema
Version: (2011-04-20 bzr2978 GOST)-testing
Build: wxWidgets 2.9.1 (wchar_t,compiler with C++ ABI 1002,GCC 4.5.0,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Для устранения ошибки удаления буквы привода необходимосделать исправление в файле schframe.cpp. Исправленный файл прилагается.

чего то файл не подключился, странно

Thx.
fixed bzr2980.

Однако, а количество приверженцев KiCad увеличилось, раз библиотеку ukpyr скачало столько пользователей.

Ну а чего, не в пикаде же за 60тр простецкие двухслойки разводить.

А сколько человек сами либы делают

П.С. Ждем win32 версию

ГОСТ-сборка 2011-03-29 лежит на фтп
Зарареная там рядом.
Заодно исправлен баг с печатью в файл из-под вин (см.картинки выше).

KiCad способен на большее, все зависит от "пряморукости" того, кто его пользует

Так и ukpyr тоже многое сам нарисовал и, что очень важно, выложил для всех. Может скоро и следующий апдейт библиотек будет.

Правильно ли я понимаю, что это именно финальный релиз и следующий теперь будет традиционно следующей весной?
И еще, не совсем понятно, почему наша сборка 2011-03-29, а у Жан Пьера http://iut-tice.ujf-grenoble.fr/cao/ на фтп - 2011-03-30? Откуда эта разница в один день, наша сборка от этого ничего не потеряла?

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

Это понятно.
Мне, кстати, разводка понравилась намного больше, чем пикадовская. Особенно обилие удобных хоткеев.
Вот в схематике конечно косячки с проводами и перемещениями, но не фатально.

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

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

Для устранения ошибки масштабирования по размеру листа при выводе на печать в pcbnew необходимо сделать исправления в файле printout_controler.cpp. Исправленный файл прилагается

А нельзя ли это оформлять патчиками? Мне не трудно самому сделать diff, но это времени займет больше.
И кого записать автором коммита? Или хотя бы кому написать "txh ..." в комментарии к коммиту?

ЗЫ: Проверил. При нормальном - старается размещать по центру листа.
При зеркальном - не помогло, выходит за границу. Проверял при масштабе 1.4 и 2.
Пока коммитить не буду.

В сборке 2011-03-29 GOST-stable заметил: при добавлении 3D-представления под виндовсом путь к нему прописывается с обратными косыми. А при сохранении эта одна обратная косая заменяется на две (и в библиотеку и в плату). При загрузке эти две косые опять превращаются в одну. Раньше раздвоения не было. И вообще - корректно ли использование в библиотеке кросс-платформенного пакета обратных косых в путях?

В *nixaх обратная косая в тексте - это символ экранирования для следующего за ней символа. \r\n = ВК ПС, \\ = \
\\ заменяются под виндой на \, а под линухом и макосью на /.
Это позволило (наряду с указанием кодировки в файлах) читать и писать файлы на любых системах.
Теперь можно записать файл схемы, платы, библиотеки в винде и без всяких лишних телодвижений прочитать их в линухе.
Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути править - менять обратные косые на прямые и обратно (подарок вот такой от БГ).
ЕМНИП, в СР-М были прямые косые, в ДОС вдруг стали обратные.

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


И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение.

зачем ? не проще все писать в UTF8 ?в Win нормально воспринимаются пути с прямыми слешами ?

С этого места поподробнее.
Какие поля? Или это модули (посадочные места)?
Компоненты (модули) были залочены?
Сетка крупнее старой?



А разве винда понимает utf8 из файла?
Сколько в ХР не открывал блокнотом файлов в утф8 - такая красота на экране получалась.
Для переноса линух-винда приходилось iconv и dos2unix/unix2dos привлекать.

Да, речь о посадочных местах (и кто придумал обзывать их модулями?). Подправил, скажем, какой-то модуль в библиотеке. Хочу обновить его в плате. Выбираю Посадочное место-> Правка->Change module(s), компонент обновляется но съезжает в текущую сетку. Дорожки от него, естественно, отрываются. Компонент не залочен (заемучаешься лочить все компоненты перед обновлением, да и как-то не приходит в голову, что обновление должно включать в себя сдвиг). Сетка может быть и крупнее и мельче и вообще не кратные - скажем, расстановка в 0.635 а текущая стоит 0.5 или наоборот.

Поля - имеются ввиду RefDes, Value и прочие у посадочных мест. Расставил я их как мне надо для шелкографии или сборочника (как же не хватает еще пары из верхнего/нижнего неэлектрических слоев для сборочника!), потом потребовалось обновить компонент - и расставляй заново. В PCAD в этом смысле было удобно - пока не двигал поле отдельно от компонента - его положение обновляется если изменилось в библиотеке. Но если в плате что-то вручную изменил в поле - подвинул, размер шрифта поменял - все, оно больше не будет затронуто при обновлениях компонента.

wordpad и другие нормальные редакторы понимают.

Исправил центровку при выводе на печать в pcbnew, теперь работает во всех режимах включая зеркалку. Файл printout_controler.cpp используется также и при печати в gerberview, но там вывод производится несколько иначе, поэтому я сделал изменения только для режима печати в pcbnew, а в gerberview оставил как есть. Проверял под windows. Патч прилагается, использовать так: перейти в корневой каталог сборки и запустить patch -p1 -i путь к патчу/pcbnew.patch. На всякий случай прилагаю исправленный файл.