KiCAD версия 3921 гост сборка под Windows

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

Описание рисунка:
Левое верхнее изображение: маска верхнего слоя
Правое верхнее изображение - медь верхнего слоя
Левое нижнее изображение: маска нижнего слоя
Правое нижнее изображение - медь нижнего слоя

Спасибо большое, относительные координаты видел, но не знал, как их сбросить, теперь все в порядке.

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

А Вы компонент сам проверяли, что там в пинах?


Выбор слоев, вкладка "отображать" - текст top, bottom - снять галочки.

KiCAD версия 3921 гост сборка под Windows

PCBNEW
BUG кнопка "Добавить миру для совмещения слоев" рисует окружность с нулевым диаметром. При экспорте в gerber это приводит к формированию предупреждения при открытии этого файла в CAM350.

Спасибо, все получилось.

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

Как? Прочитать, в конце-то концов, документацию, которая идет в комплекте с KiCAD.
Есть переведенная на русском (не совсем актуальная, но в основном соответствует, за исключением новых фич тестовой сборки),
есть на английском (вполне актуальная), на французском и т.д. Даже на японском есть.
На украинском, правда, нет.
Посмотреть примеры, которые идут вместе с KiCAD в demos.

По существу: добавить модуль с отверстием NPTH нужного диаметра в нужные места, где должны быть крепежные отверстия.



Проект в студию Достаточно файлов .pro и .brd (.kicad_pcb, если в новом формате).
Иначе трудно локализовать, где и в чем проблема.



Все равно проблему "не вкурил".
В чем грабли-то? И KiCAD ли тут причиной?



Миру можно и не ставить. Герберы и так прекрасно совмещаются по координатам.
Кто-то из производителей (ЕМНИП, НИЦЭВТ) очень сильно итересовался,
что это там за отверстия по диагонали платы вне контура платы на слое контура и нужны ли они мне.
В результате их (миры) просто удалили из герберов.

Ловите

В таком случае попробуйте открыть drill и gerber в gerbview.
У меня без упомянутых изменений они открываются криво или никак.

зы Файлы созданы в CAM350 V9.5 производственниками.

ззы kicad-sources-2013-01-14-bzr3903

зззы В сверловке ещё надо к METRIC добавить ",LZ" или ",TZ"

- pcbnew 3920, при попытке перемещения узла (Move node) двух несоединенных сегментов, хватаются оба (раньше вроде бы можно было перемещать по одному):


- можно назначить хтокей Ctrl-P на Plot в sch/pcb ?

faa
Некоторая неточность в Pcbnew.
При редактировании свойств контактной площадки элемента, расположенного на нижней стороне, вместо нижних технических слоёв отмечены верхние. И сама контактная площадка отображается цветом верхнего слоя. Хотя внизу и есть предупреждение насчёт замены верхнего и нижнего слоёв.

иногда в pcbnew пропадает возможность редактировать некоторые дорожки - не реагирует на кнопки G/D, в контекстном меню отсутстыуют команды:

Щательнее надо

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

Где на контактных площадках нижнего слоя маска на нижнем слое?
Галочка не там стоит.
KiCAD тут не виноват - автора посадочного места терзать надо.



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



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


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

Подтверждаю: никаких косяков со времен 3622 нету. Много пропустил? Ага, но оно работает и всё тут. Уже 4-тую плату схавало(производство).
--
ЗЫ про хоткеи в пцб, нашел z и x в плане начать дорожку/закончить. Оченно удобняк.

Если сочетание не занято, то почему бы не назначить? Программу это не утяжелит, тем, кому это не нужно - никак не помешает. Да и вообще, это считается правилом хорошего тона (наравне с Ctrl+N для "Создать").

faa
Релиз?
bzr 3894. 3925 не запускается. Правда это вопрос к viknn (но он молчит).

при смене медного слоя цвет слоя меняет, но флажки технических слоев не трогает (что, ИМХО, правильно).
Как же это "правильно", если реально уже всё на других слоях?
Да и с цветом... Когда вообще ничего не меняет, то логика есть, а когда цвет меняет, а слои нет, то неразбериха получается.

На "горячие клавиши", опять таки ИМХО, надо вешать действия, которые существенно облегчают работу
Я давно просил хоткей на действие "Очистка дорожек и переходных отверстий", но, видимо, этим никто не пользуется. Честное слово, проще удалить пару сегментов и нарисовать заново одним, чем лазать через меню. И всё для того, чтобы перетащить сегмент.

Что мешает самостоятельно прописать хоткеи?
Это всё мелочи, недостойные внимания.

Да, у меня тоже не сложилось с 3925 от viknn, но ведь есть 3925 от faa и в ней вроде все в норме: ftp://ftp.kicad.ru/pub/kicad/bzr/win32/

_Pasha
Что мешает самостоятельно прописать хоткеи?
То, что не все действия могут выполняться от кнопок, некоторые принципиально доступны только через меню.

Aldan
Точно. Спасибо!
А то я по-привычке лазаю в "install".

фильтрация компонентов/модулей и extended selection в CvPCB - отлично, наконец сделали !
еще бы добавить такой же фильтр над списком модулей в CvPCB.

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

Я писал, что сборка 3925 с поддержкой программирования на python 2.7 (python 3.x не проверял).
Переносил эти программы на другой ПК с установленным Python 2.7 - все работало.
B 3930 (без python) добавил автономную программу pcad2kicad для конвертации схем от А.Лунева
(верняя кнопка в ней не работает - pcb адаптируйте через встроенный в pcbnew плагин).

viknn
А как так получается, что Pcbnew просто не запускается без всяких сообщений?
Когда не хватало библиотеки, то об этом выскакивало сообщение. С библиотекой всё происходит втихую. Даже никакого намёка на проблему. Или это уже питоновские тараканы?

eeschema 3920. При выводе в PS выводы с инверсией более жирные:

Про какую сборку и какие сообщения говорите? Не ясно.

Application: KiCad
Version: (2013-02-04 BZR 3930 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW
Boost version: 1.49.0
Options: USE_PCBNEW_NANOMETRES=ON
KICAD_GOST=ON
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF

Gerbview нещадно тормозит.
Pcbnew при генерации Отчёта о модулях (файлы для производства) сразу делает всё в дюймах, без вопросов и возможности переключения.

viknn
Version: (2013-01-27 BZR 3925 GOST)-testing с питоном.
Pyton 3.2.3

Пока не было библиотеки, выскакивало окошко, что не хватает python27.dll. Когда скачал и подсунул, то при попытке запуска Pcbnew ничего не происходит. В основном окне KiCAD (под пиктограммами запуска приложений) возникает надпись:
"pcbnew.exe открыто [pid=xxxx]"
и сразу:
"pcbnew.exe закрыто [pid=xxxx]".
По-хорошему, если не подходит версия какой-либо библиотеки, то должно выводиться сообщение об этом, или, на худой конец, номер сообщения об ошибке.

faa
Проверил в bzr3925: при смене медного слоя цвет слоя меняет, но флажки технических слоев не трогает (что, ИМХО, правильно).
В 3130 цвет не меняет. Это специально исправлено?

Application: Pcbnew
Version: (2013-feb-06 BZR 3930 GOST)-testing
Build: wxWidgets 2.8.11 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.5.2,wx containers,compatible with 2.6)
Platform: Linux 3.2.0-desktop-1.mga1 x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.49.0
Options: USE_PCBNEW_NANOMETRES=ON
KICAD_GOST=ON
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF

Переключаю слой КП, меняет:

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

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

ЧЯДНТ?

faa
Переключаю слой КП, меняет:
ЧЯДНТ?
То, что так никто не переносит детали между сторонами платы. Обычно это делается с переносом элемента целиком, кнопкой "T". И при этом цвет в свойствах не меняется (на плате, естественно, меняется). И, кстати, хоть элемент явно находится на нижней стороне платы, в свойствах контактной площадки написано "front". То есть нет полноценной связи между редактором платы и свойствами контактной площадки. Как будто параметр стороны платы передаётся только в одну сторону, или где-то инверсия вместо передачи параметра.
Происходит так:
Имеем элемент с нижней стороны (back). Тыкаюсь в контактную площадку - редактировать. По правой кнопке мыши показывает "(Back)". Захожу в редактирование - показывает "Front". Меняю на "Back". "Ok". Контактная площадка переползает на верхнюю сторону. Ещё раз захожу в редактирование свойств, меняю на "Front", контактная площадка переползает обратно на "Back".
С изначально верхними элементами такого не происходит, там всё соответствует.

Ещё интересный багая особенность.
Если запускать компоненты (CvPcb, Pcbnew) из основного окна KiCAD, то пишет "CvPcb.exe открыто [pid=xxxx]"... "CvPcb.exe закрыто [pid=xxxx]", если из Eeschema - то не пишет ничего.

А гвозди микроскопом забивать не пробовали?
Есть специальная команда - перенос на другую сторону. "Горячая клавиша" F (flip).
Модуль (посадочное место) делаем на фронтальной стороне платы (в редакторе модулей) и вредакторе он _всегда_ будет такой,
потом "флип" (уже на плате) - и он на другой стороне платы (в pcbnew) и тут уже конт.площадка будет на другой стороне.

ЗЫ:Все есть в доке.
"Учите матчасть..." (С) не мой.

faa
Не надо приписывать мне "забивание гвоздей микроскопом", а надо внимательнее читать.
Ещё раз повторяю: После переворачивания посадочного места на другую сторону платы (у меня другая клавиша, но пусть будет "F"), свойства контактной площадки останутся прежними, в том числе и цвет в редакторе свойств контактной площадки. Три отличия - в меню по ПКМ она будет упомянута на правильной стороне платы и в редакторе свойств контактной площадки появится предупреждающая надпись, а также будет написана ориентация посадочного места.
Все слои останутся верхними. А вот это уже нелогично.
И вообще "весело". Тыкаю в "зелёную" площадку, а она в свойствах показывается "красной". А если два посадочных места одно над другим? Тогда надо только очень внимательно смотреть на меню по ПКМ, потому что в редакторе свойств даже не показывается позиционное обозначение модуля, только номер цепи, который на схеме посмотреть невозможно.

Тогда приступим:
1. Проект в студию
2. Версия использовавшегося KiCAD
3. Описание по шагам, что и как делалось, с акцентом на предполагаемые "косяки" KiCAD
Постраюсь воспроизвести последовательность действий.
Далее по результатам.

ЗЫ: Если будете с оказией в "нерезиновой", то можно явочным порядком

faa
Кроме проекта уже всё упоминалось.
1. Проект приложен. (см. 25.7z)
2.

Цитата

Application: Pcbnew
Version: (2013-02-04 BZR 3930 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW
Boost version: 1.49.0
Options: USE_PCBNEW_NANOMETRES=ON
KICAD_GOST=ON
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF

3.
а) Переношу модуль на нижнюю сторону платы.
б) Тыкаюсь ПКМ на контактной площадке, выбираю контактную площадку и "редактировать" (можно горячей кнопкой, всё то же самое).
в) В свойствах контактной площадки все слои верхние, цвет - красный. Уже неточность. (см. рис. bug1a, обведено красным).
г) Есть надписи, которые предупреждают, что всё же площадка снизу. (см. рис. bug1a, обведено зелёным).
д) В свойствах контактной площадки меняю медный слой на "back", цвет меняется (см. рис. bug2a). Надписи остаются прежние.
е) На плате контактная площадка оказывается сверху. (см. рис. bug3)
ё) Снова в свойствах меняю медный слой на "front". (см. рис bug4a)
ж) На плате контактная площадка возвращается на нижний слой.
Получается, что слои контактной площадки берутся только из модуля, а редактирование непосредственно на плате не меняет эти слои, а инвертирует, вместо того, чтобы задавать абсолютные значения. И отображение свойств идёт не по абсолютным (т.е. текущим) значениям, а от начальных свойств (из модуля) плюс инверсия при правке на плате. С техническими слоями такая же ситуация. (Коряво написал, сейчас не соображу как лучше.)

Если будете с оказией в "нерезиновой"
Чур меня!
И если бы и был, то только в специфических местах, снаружи всех транспортных колец.

P.S. Сравнил Gerbview с Gerbv 2.5.0 от gEDA. Gerbv работает ощутимо быстрее. Раньше скорость этих программ была соизмерима.
В Gerbview с недавних пор появились тормоза: сразу после открытия файлов висит рюмка (= песочные часы ) и долго невозможно ничего делать. Да и потом всё происходит очень медленно и печально.

А где файл .pro ?

Какой конкретно? Желательно с координатами.

Тут ничего подсказать не могу - винду не пользую. Под линухом такого не замечал.

Application: KiCad
Version: (2013-02-04 BZR 3930 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.6.2,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Boost version: 1.49.0
Options: USE_PCBNEW_NANOMETRES=ON
KICAD_GOST=ON
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF

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

Я тоже работаю в Виндах и никаких тормозов не обнаруживаю. Поэтому у меня закрадывается подозрение, что, возможно, вы сделали сборку Кикад не совсем корректно? Если так, то рекомендую проверенную временем качество сборок от faa, самую свежую из которых (2930) я себе и поставил: ftp://ftp.kicad.ru/pub/kicad/bzr/win32/

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

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

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

faa
А смысл в файле .pro? Там же ничего нет, кроме имён библиотек и путей к ним, да ещё некоторых начальных установок.
Вот он, пожалуйста.

Какой конкретно? Желательно с координатами.
Практически любой. Например, R147(back) X=87,4; Y=114,8, контактная площадка 1 (X=86,4; Y=114,8).

Aldan
Сборка готовая с сервера, именно оттуда. Я так понимаю, что сделанная viknn.

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

если можно, я встряну в вашу беседу
Нужно.

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

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

Сейчас посмотрел свои gerbview 3930 и 3950. Приложенные 11 gerber-файлов считываются в секунду безо всякой песочницы.

А что мешает может принять эту условность?
Тогда всё встало бы на свои места )

break, я не хотел втягиваться в дискуссию, т. к. не считаю себя уж очень сильным специалистом в Кикад. А поделиться качеством работы сборки, которую я себе поставил, посчитал возможным. Так вот, у меня все работает шустро и без зависаний с «песочными часами».

Нет, ссылка, что я давал ( ftp://ftp.kicad.ru/pub/kicad/bzr/win32/ ), ведет к сборке от faa, которую я себе и поставил. А сборки от viknn располагаются по ссылке ftp://ftp.kicad.ru/pub/kicad/install/win32/ но вряд ли они чем-то сильно отличаются. Хотя попробовать переставить можно, т. к. всегда есть вероятность по каким-нибудь причинам сделать неудачную сборку.

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

Наконец-то понял суть этого вопроса.
Шутка юмора в том, что при создании компонента мы рисуем silkscreen -линии, не имея возможности выбрать сторону размещения этих линий - по дефолту они считаются размещены на слое компонентов.
Следовательно, основной слой-таки всегда верхний, точнее - слой компонентов.
Раньше, даже в пикаде 4.5 - smd всегда рисовал на pintop&slktop итд, ибо разнобой в конце концов приводил к бардаку. (Может, это только со мной такое - не знаю) .
Далее, идя по жизни с пикадом, нашел правильным атрибут "Placement Side" - если кто помнит.
Здесь в принципе такого атрибута или свойства компонента, задаваемого при его создании, и потом поддерживаемого, ессно, при импорте списка цепей, -- не хватает.

viknn
Ваш файл считывается достаточно быстро, но "рюмка" периодически выскакивает. А моя плата, размноженная в 4 раза, практически не позволяет с ней работать.

Aldan
не считаю себя уж очень сильным специалистом в Кикад
Надо быть специалистом в проектировании, чтобы понимать какие функции сделаны удачно, какие - нет.

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

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

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

А сборки от viknn располагаются по ссылке ftp://ftp.kicad.ru/pub/kicad/install/win32/ но вряд ли они чем-то сильно отличаются.
У меня именно эта. Попробую другую. Отличаются даже размерами, хотя там архиваторы разные.

_Pasha
Шутка юмора в том, что при создании компонента мы рисуем silkscreen -линии, не имея возможности выбрать сторону размещения этих линий - по дефолту они считаются размещены на слое компонентов.
Можно рисовать на любой стороне. У меня крепёжные отверстия имеют шелкографию с двух сторон. И в свойствах графических линий это всё задаётся и правится.

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

Aldan
Попробовал другую сборку. Монопенисуально. Хотя размеры всех файлов отличаются.

faa
Спасибо.
И вот ещё вопрос (мелочь, а "приятно"): почему размеры листа в форматах A1 (длинной стороны) и A0 (обе стороны) больше на 1 мм, чем положено? В Eeschema и Pcbnew.

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

Приложите свой файл для пробы. А то кажется, что причина в вашем PC (что за процессор, что за память...)
А сборки, которые собираются - хорошие, а не собираются - те плохие (на размер exe в основном влияет версия gui-библиотек и транслятора g++/vcc)

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

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

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


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

Про инверсию слоев, модули и прочее:
Исторически сложилось так, что у платы есть основная сторона - это сторона установки элементов, обычно верхняя.
Если элементы с двух сторон, то это уже сложная плата, но у нее все равно есть основная сторона - обычно, опять-таки, верхняя.
ИМХО, посадочные места (модули) в редакторе надо всегда делать для этой, основной, стороны.
Тогда при перекидывании посадочного места на нижний (не основной) слой и попытке редактирования
контакной площади такого модуля прямо на плате в левом нижнем углу окна редактирования русским (или английским) по серому
написана сторона платы для этого модуля "обратная сторона платы (посадочное место зеркально)" и предупреждение
Контактная площадка будет перевернута на плате.
Верхний и нижний слой будут изменены местами
Перевод, конечно, корявенький (виноват, исправлюсь), но суть передана верно.
Сама контактная площадка показана так, как она была сделана в редакторе (про основные и не очень стороны смотреть выше).
Что у Вас в этих трех соснах не так - я не вкурил до сих пор.

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

ЗЫ: Готов к дальнейшей дискуссии, хотя тут дискутировать особо и не о чем.

Aldan
break, такой результат был ожидаемым. Если применить логику, то остается предположить, что проблема с подвисаниями и «песочными часами» имеет корни в вашем компьютере.
Комп, конечно, не очень, но с предыдущими сборками такого не наблюдалось, хотя ничего в конфигурации не изменилось. Правда конкретно эту плату я в более старых сборках не смотрел, но несколько более простые так не тормозили.
Опять же, повторяю, Gerbv 2.5.0 от gEDA так не тормозит. Значит дело всё же в KiCAD'е. Насколько я понимаю, оба этих продукта используют GTK.

viknn
Приложите свой файл для пробы.
Вот.

А то кажется, что причина в вашем PC (что за процессор, что за память...)
P4 3000 МГц, 2 ГБ.

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

ИМХО, посадочные места (модули) в редакторе надо всегда делать для этой, основной, стороны.
Я сейчас вспомнил, что был один элемент, который распологался с двух сторон платы - разъём, паяемый на торец платы (правда делал другой человек и в OrCAD'е). Так какая сторона для этого разъёма основная?

На самом деле, есть 3 основные проблемы, которые пока не решаются, хотя, казалось бы, две из них решить достаточно просто.
1. Вывод в DXF. Постоянно одно и то же. Когда-то было исправлено, но потом опять сломалось. Да ещё и дополнительные проблемы появились. Может можно внести положительные изменения в основную ветку, чтобы потом не возвращаться к одному и тому же?
2. Сделать кнопку для "Очистки дорожек и переходных отверстий".
3. Сделать возможность подсветки цепей в Eeschema или как-то узнавать в ней (это наверное проще) номер цепи. Нет, конечно можно открыть файл списка цепей и вытаскивать информацию оттуда, но это не слишком удобно.
Вот эти вещи портят жизнь именно мне, остальные уже другим.


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

Конкретнее по глюкам можно?

Первая нога кверху - это основная сторона .

Что не так с DXF? Что там постоянно не так?

Легко доступную кнопку для очистки принципиально делать не буду.
Чем дальше она закопана, тем правильнее. А то будут претензии "я случайно нажал , а уменя все пропало - кто ж так строит, разработчики %$^%$".

Я стараюсь вешать метки на практически все цепи - сразу снимается проблема с обезличкой.

+1 по каждому пункту.

break, это важное дополнение. Если так, то для полного прояснения ситуации просто необходимо провести испытания одного и того же проекта на старой и на новой сборке. Только после таких испытаний можно будет утверждать, что тормоза появились именно на новых сборках.
И еще, найдя эту границу – номер сбороки, после которой начались тормоза, можно будет дать пищу для размышлений разработчикам Кикада, чтобы они могли пофиксить баг.
Однако, остается неясным, почему у меня, как и у многих, не тормозит. Скорее всего играет роль соотношение навороченности железа и применяемой системы (у меня вин7х64) с тяжеловесностью самого проекта.