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

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

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


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

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

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

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

Сообщение отредактировал faa - Feb 17 2013, 08:35

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) с тяжеловесностью самого проекта.

break
Посмотрел файлик с платой.
Уважаю
Как мульти делали? Копированием блока?
Тут сразу мысль появилась: если это делать путем добавления платы, то нужно
заводить префикс цепей для каждого подгружаемого файла.
Чтобы имена цепей не пересекались и не было связей между частями.
Это можно сделать внешним обработчиком (на перловке или еще на чем-нибудь) или сразу справшивать при добавлении платы.
Ну и смещение надо для подгружаемого куска, чтобы склеивать в нужном месте, а не двигать исходную.
А без смещения или сдвига грузит поверх того, что было.

Но файлик при включении отображения всех элементов слегка подтормаживает и даже X-ы уносит иногда.
mageia1 x86_64, ядро 3.2.0, 8ГБ, i5 со встроенной графикой.
Падения X-ов при активном изменении масштаба в pcbnew и раньше замечал на конкретно этой машине с ядром и видео-дровами от дистра.
Интеловые дрова и ядро обновил и, казалось, победил падения. Но, видимо, не до конца.
На Вашем проекте X-ы удалось снова уронить Придется еще систему поковырять.

faa
Конкретнее по глюкам можно?
Ладно, пусть не глюки, а особенности. Всё то же - несоответствие отображения в редакторе платы и в редакторе свойств контактной площадки.
Что-то мы уже по кругу идём. Не хочется делать, как с кнопкой очистки, так и скажите, больше не буду приставать.

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

Что не так с DXF? Что там постоянно не так?
1. Дуги. Хотя в сборке 3930 уже нормально, а в предыдущей (или в сборке 3930 от viknn, уже точно не помню) были окружности.
Но это постоянно то появлялось, то исчезало.
2. Вместо заполненного режима получаются контуры.

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

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

Как мульти делали? Копированием блока?
Да.

если это делать путем добавления платы
Зачем такие сложности?
Проще выделить блок, переключить сетку на более крупную, скопировать блок в нужном месте, добавить внешние контуры и отверстия, добавить размеры. Делается за пару минут.
В OrCAD'е (layout) добавлял плату, только сначала смещал исходную. Со связями была такая же ситуация. Но это как раз не страшно.

Aldan
И еще, найдя эту границу – номер сбороки, после которой начались тормоза, можно будет дать пищу для размышлений разработчикам Кикада, чтобы они могли пофиксить баг.
Как-нибудь попробую.

Скорее всего играет роль соотношение навороченности железа и применяемой системы (у меня вин7х64) с тяжеловесностью самого проекта.
Ещё раз повторяю (в последний раз, и так уже, наверное, надоел) Gerbv 2.5.0 от gEDA так не тормозит.

Считаем это особенностью и принимаем как данность.

Сверху-снизу - тут надо один раз договориться в конторе и делать всем однообразно.
Или прописать в РУКах (руководствах по конструированию).
И для такого разъема тоже должна быть основная сторона

В моих сборках есть маленький патчик для дуг в DXF. В основную ветку я его отправлял, но кто-то там его опять похерил.
Как-то так:


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

Не сбрасывать инструмент? Можно, наверное.
Но очистка - это же финальная операция. Пусть сбрасывается

Тут еще косяк: на диалоге keepout зоны не видно слоев для выбора.
Под виндой видно, а под линухом у меня на wx-2.8.10 и wx-2.8.12 не видно.
Никак не раскопаю, в чем там косяк.
Код для диалога keepout зоны и обычной зоны одинаковый, а результат разный

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

Проблема с шагом пертаскивания проводника осталась. Если стоит мелкая сетка (например, 0,05), выбран инструмент проводников ("добавить дорожки и переходные отверстия") и активный слой совпадает со слоем редактируемого проводника, то сетка перемещения не соответствует установленной, а получатся крупнее. Если сбросить инструмент или переключить активный слой, то сетка соответствует.

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

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

Есть ещё проблема с сохранением 3D вида - не сохраняются полигоны, но это уже практически не важно, так как всё равно не удаётся полноценно затаскивать в SolidWorks или другие программы (а хотелось бы, чтобы конструкторы сразу могли рисовать полную конструкцию).

gerbv 2.6.0 и cam350 несколько быстрее, но тоже пулей не летают - проект большой (много слоев и областей металлизации)

Сообщение отредактировал viknn - Feb 20 2013, 16:50

еще мини-тьютор про передачу 3D-моделек из компас в kicad

Из тутора, последняя строчка


А все-же планы такие существуют? Или это более фантастиш?

Вопрос еще назрел насчет питона: он там уже жив или не очень? Кто пробовал?

Поддержка Python 2.x от Miguel Angel вошла в основную ветку в прошлом году (http://www.kicad-pcb.org/display/KICAD/KiCad+Scripting+Reference+Manual).
Но пока и реализация методов и документация не полная. Python-скрипты есть помимо kicad в Компас-3D, во FreeCAD - поэтому вызывают интерес.

В рассылках предлагалась более современная реализация работы с 3D через IDF и STEP
(получение грубой картинки через параметры контура и высоты или реалистичной при возможности подключения 3D-моделек компонентов в программах типа FeeCAD или Компас). Но пока основные разработчики KiCAD более увлечены сменой формата pcb/sch на SWEET.

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

Сообщение отредактировал _Pasha - Feb 23 2013, 05:11