Прошу помочь в следующем вопросе. В библиотеку PcbLib добавлено несколько футпринтов, а в SchLib соответственно дополнены ссылки на эти футпринты для некоторых символов. Как теперь обновить схему, но так, чтобы текущий футпринт символа в схеме сохранился. Вроде бы простая операция, аналогичная ForceUpdate в P-CAD2006sp2. Я решил воспользоваться командой Update from libraries, окна настроек и результата прикрепляю. Однако список футпринтов у символов в схеме не обновляется. Что делаю не так? Все ведь описано в хелпе...

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

Скорее всего не найдена библиотека с Footprint/
Следует или проинсталировать ее или добавить в проект

Библиотека подключена как библиотека проекта. Обновление списка футпринтов происходит только при выставленной галке Update wich models are the current models, но, естественно, текущий футпринт у компонентов на схеме не сохраняется...

Так оно и есть, надо лечить. +1 в копилку.

Имею следующие вопросы:

1. Как одним махом для всей библиотеки футпринтов выполнить команду Edit>Set Reference>Center? И можно ли для новых футпринтов назначить ее по умолчанию? Сходу найти не удалось... Пока приходится делать для каждого футпринта...

2. Как в SCH и PCB редакторах назначить выделение объектов по умолчанию как touching rectangle, а не inside area? Мне кажется такой способ выделения более продуктивным...

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

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


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

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

Дошел-таки до интересного места: на плату ввел два радиатора, установил component type на mecanical и ECO замечательно это восприняла! Однако радиаторы с креплением к плате и эти пады надо посадить на GND, что и было проделано на плате.
Если теперь делать forward ECO из схемы данные пины все время норовят отсоединиться от GND, это и понятно... Каким образом ПРАВИЛЬНО это предотвратить? :
1. Запретить различия Extra pins in nets в Project Option>Comparator.
2. Запретить Remove pins from nets в Project Option>ECO generation.
3. Как либо по-другому?

Есть ли потенциальная опасность первых двух методов?
Второй метод выводит на экран соотв предупреждение типа: "...некоторые различия найдены, но игнорируются... Проверьте Project Option..." Представляю увидеть такое после перерыва в работе над проектом или передаче его др. лицу... Типа: "...две больницы в городе сгорело, а так все хорошо..."

Если у вас сомпонент имеет Pin, и он одключен на схеме к Gnd- должно работать.
Если хотите, что бы при утом был не видим- сделайте его HIDE, и подключите к Gnd

Я так понял, что на плате радиаторы есть, а на схеме нету, для того и поставлен атрибут "Mechanical". Но делать электрические соединения к неэлектрическим объектам бессмысленно. Мне кажется правильным добавить радиатор на схему как standart и подключить к земле. Тогда возможно будет выполнять над ним полноценную проверку по rules (clearance, height...). Кроме того, присутствие гальванической связи - это необходимая информация для читающего схему.
Делать предложенные настройки по pins в данном случае нельзя, т.к. подключение к сетям пинов (либо отключение существующих) будет проигнорировано на всём (и на плате, и на схеме).

Если сделать так, то при попытке ECO из схемы прога пытается удалить и пины радиаторов и сами радиаторы. И это плохо, что ж теперь все время контролировать? Ведь forward ECO еще десятки раз придется делать... С другой стороны, единственное, что остается - сделать символ радиатора с двумя пинами. Каким образом такое оформить?

Если на схеме стоит символ радиатора с пином на землю и типа standart, то проблем не должно быть (если радиатор на PCB - это библиотечный элемент, а не рисованный из примитивов).
А что изменят два пина? И непонятно, что имеется ввиду под словом "forward"?

Да нет, все будет нормально - два пина на схему и нет проблем. просто не верится, что это единственный и правильный путь. Кроме того, я не догоняю как вы это предлагаете сделать? Символ в библиотеку для радиатора добавить? Но тогда надо кроме пинов еще и графику их связи сделать, а то на схеме будет их не видно? Получается, что в PCAD'е, что в AD - решение проблемы одно и тоже. Мне казалось, что в AD есть более продуманный путь... Forward ECO - это ECO из схемы в плату, Backward ECO - из платы в схему.

И еще хотел спросить по поводу интерактивного трассировщика AD. Почитал хелп - ужас! Разрабы видимо решили дать больший контроль пользователю за процессом трассировки, а получилось, что автоматизации по сути - никакой: сплошь и рядом успевай только хоткеи нажимать. Особенно добивает неумение программы автоматом выбрать разумную ширину трека. В Пикаде при старте трассировки с пада ширина проводника автоматом выбирается по ширине площадки, а при входе в пад - ширина трека пытается подстроиться под ширину принимающего пада - все это автоматом. Очень удобно. В AD же фактически нужную ширину выбирать приходиться вручную. Плюс еще переключаться между режимами трассировки и т. п. А если нужно переместить via с уже подключенным проводником - они перемещаются под любым углом (как захочет пользователь), в Пикаде - под 45 град. = меньше постредактирования. Вообщем, или я привык к Пикаду, или интеракт трассировка в AD однозначно менее интеллектуальна... Что скажете?

достаточно один пин, да и тот HIDE
Так что на схеме его видно не будет

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

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

Остался последний "затык" на текущий момент - классы цепей. Они определены на плате, а в схеме естественно их нет и ECO ругается:

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

Я пока считаю, что в схеме определять классы не надо, потому что зачем они схеме? И чтобы ECO не ругалась, сделал настройку: Project>ProjectOption>ECO generation>Remove Net Classes = Ignore Differenses. Это правильно?

Да, и еще вопрос насчет того, как на готовой к автотрассировке двусторонней плате задать что-то типа правила: все НЕ МЕТАЛЛИЗИРОВАННЫЕ котактные площадки разводить только на Bottom? Например, электролиты. Или все же лучше в библиотеке на их пады наложить круглые keepout в слое TOP?

1 Правильно.
2 можно. Но долго объяснять

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

Нормально.

Интересно, сколько у Вас (и у других) по времени занимает процесс "разводки" платы (как этот источник питания, нет высокоскоростных трасс, cpld, fpga, и т.д.)? У меня в среднем тратится примерно 15% времени это работа с принципиальной схемой, 70% предварительная компоновка, 5% собственно прокладка линий и оставшиеся 10% времени это оптимизация компоновки и прокладки. ИМХО оптимальное расположение элементов решает все, время на это и надо тратить. Причем, при возрастании плотности размещения и количества элементов, доля самой "трассировки" стремительно уменьшается. Считаю, что для данных задач пользоваться автотрассировщиками смысла нет. Это чисто личный подход, никому не навязываю следовать.

Не считал.
Но для схем где все компоненты новые

30%- библиотеки, 20% схема, 20% первичная (100% разведенных связей) разводка и модернизация схем и библиотек. 20% доводка платы. 10% формирование отчетных документов

Для модернизации схем соотношение конечно другие

Т.е. размещение компонентов Вы ОСОБО не делаете, стоят как бог послал, и как послал, так Вы и разводите. Или не так?

Можете выложить рисунок - как вы себе представляете такое изображение на схеме?


Согласен абсолютно. Но речь идет об интерактивной трассировке - это, ИМХО, самое важное после компоновки. И пока я не вижу преимуществ интерактивного трассировщика AD перед P-CAD2006sp2. Это печально. Ширина проводника фактически задается вручную (в пределах design rules). Наиболее востребованная, ИМХО, команда:
1. Route/Unroute To First Object - нужно сдвинуть чуть компонент (ATmega8, к примеру), unroute его до первых via, передвинул на 2.2 мм и route его заново. Хотя с некоторым трудом такое можно проделать и сейчас...


Как сделать keepout я вроде представляю и уже делал... Но... есть другой путь? Хотя бы кратко...

В правилах с помощюю запросов сформировать критерий для указанных PAD/ Можно сначала их (PAD)в одельный класс вынести, тогда проще


Как раз нет. Не люблю аторазводчиков. Разводка вместе с расстановкой.

Вот уже и плату развел и дошел до DRC. Однако при запуске она не может найти неких два файла... потому, что не там ищет. Пакет установлен в D:/Program Files/Altium Designer/, а файлы ищутся почему- то по пути: D:/Program Files/Altium Designer 6/. Я уже все настройки пересмотрел - нигде нет ссылок на ошибочный путь. Глянул в реестр - там в явном виде ничего подобного нет. Может это все не у меня одного?

Preference/pcb editor/report
Там указаны ссылки на шаблоны, в том числе и для DRC

Владимир, спасибо огромное! Как я пропустил, не понимаю... Видимо второпях...

В общем и целом закончил первый проект. Впечатления положительные. Очень сильная сторона AD - работа с библиотеками и сама концепция библиотек и компонентов. Так резво все отредактировать и как нужно - в Пикаде только мечта... Осталось с языком запросов разобраться - как сказано в хлпе - енто очень важный момент...

С пополнением приверженцев AD6

Имею следующие вопросы:
1. Оформление библиотек. Очень полезно обозначать footprint pad designators не безликими цифрами, а буквами, отражающими "функцию" пада: коллектор, эмиттер, база - C,E,B и т. д. Тогда на плате очень удобочитаемо. Но это приводит к невозможности иметь в библиотеке "универсальные" футпринты, ведь в один и тот же TO-220, к примеру, пакуют все что угодно. Правильно ли (из этих соображений) при оформлении библиотек придерживаться правила: каждый символ = свой футпринт даже если сами футпринты одинакового типа (TO-92, TO-220, SOT-23 и т. д.)?

2. По поводу создания правила для разводки электролитов (их падов) только на Bottom в случае неметаллизированных отверстий падов. У меня такие пады (электролиты, некоторые разъемы и т. д.) легко выделяются с помощью запроса:
(ObjectKind = 'Pad') And (PadStackMode = 'Top-Middle-Bottom') And (HoleDiameter = PadXSize_TopLayer) And (HoleDiameter = PadYSize_TopLayer)
и даже с панели PCB filter можно сразу сформировать правило для трассировки таких падов, задав для такого запроса: RoutingLayers = Bottom only. Только не работает это правило. Причина видимо в том, что в языке запросов разводятся не пады а цепи, но тут затык: одна и та же цепь содержит как нужные мне пады, так и те, которые можно развести в обоих сигнальных слоях. Короче запрос составлен неполно для решаемой задачи... Есть предложения?

1 не так и много Sot23, Sot23_EBC, Sot23_GDS, Sot23_ACA Ну еще 3-4 варианта и все. Фантазия кончается

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

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

Однако представляется очевидным - автотрассировщики не понимают таких "односторонних" падов и норовят развести их на Top. Уже обсуждалось решение делать кипауты для этих падов еще на этапе создания компонента в библиотеке, но, ей Богу, некрасиво. ИМХО, проблема должна решаться на уровне стека КП. Владимир предлагал другое решение - через написание "суррогатного" правила зазоров между pad и line на Top. И это оригинальное решение работает.
Тем не менее, изначально я для себя решил в библиотеке делать компоненты с максимальным кол-вом "степеней свободы" для трассировки неметаллизированнных падов. Например, КП 1N4004 в данном случае имеет у меня форму на Top как round 2mm. Но встает проблема: как бы выделить на разведенной плате все КП, которые не подключены к трассам на слое Top, а затем удалить их определение на этом слое как, естественно, ненужное. Даже в AltiumSupport обратился, но пока нет ответа.

Кстати, в суппорте ответили, что диалог Update from libraries еще функционально не закончен (это насчет апдейта списка футпринтов из библиотеки). Они сказали, что в будущем возможно сделают такой апдейт как мной ожидается).
Насчет трасс, обязательно доходящих к центрам падов (это можно видет при настройке отображения слоев) они сказали, что это необходимо для визуального контроля факта соединения пада с трассой. На мои предложения поручить такой контроль программе а не пользователю, прозвучало что-то типа нашего "мы будем посмотреть" с некоторой иронией. Я то сам прекрасно понимаю, что вопросы мелочные, но все равно приятно, что хоть что-то ответили...
Особое оживление вызвала проблема с наложение атрибутов при размещ компонента из панели библиотек методом drag and drop. Были предложены несколько вариантов решения, однако в моем случае они практически не работали, что вызвало всеобщее удивление ребят из европейского центра поддержки. Получалось так, что проблема получается при работе в пакете, и проявляется по-разному до и после перезапуска пакета. Короче, обещали посмотреть...
Также обратил их внимание на работу опции Use DirectX (см. ранее в этом топике). Обещали разобраться, но сказали что с моей видеокартой (GF 7300 GO) это не связано, т. к. карта поддерживается их реализацией режима DirectX в пакете.

Короче ждем очередного сервис-пака с особенной надеждой.