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

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

Собственно, я не удивлюсь, если кто-то из юзеров придумал способ проверки, о котором не додумался суппорт. Прошу поделиться информацией.

Остальным прошу принять к сведению и быть внимательнее.

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

Подобное неподсоединение удалось выловить при помощи CAM-350 (правда из PCAD-200x). Для этого необходимо сделать прямой импорт PCB-файла в ASCII-формате; при этом сохраняются цепи. А в CAM-350 провести проверку Net Check.

Можно импортировать гербера и список цепей (IPC-файл), но такой путь мне показался более трудоёмким.

С помощью камовских средств я вижу два способа.

1. Генерация нетлиста после импорта протеловского pcb файла. Камтастик тут не поможет, так как сам протел IPC нетлист из pcb делать не умеет. Генерация нетлиста из импортированных герберов той же платы. И сравнение в конце концов нетлистов.

2. Анализ гербера с плана на предмет изолированных островков. Если они есть, то это или сплит план, или описанная бяка.

А вот пример где DRC не ругается, но с подключением полигона при производстве могут быть проблемы
Высылаю в ZIP формате, JPG не принимает

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

А не поможет загрузка в CAM350 ODB++ файлов из Протеля (для версии 9 мне это удавалось, хотя подробно не щупал пока), ведь там должен быть Нетлист?

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

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

Так что выход только один: отдать этот файл суппорту, и пусть на нём тренируются...

Все альтиумосквие продукты генерят усеченный ODB++, содержащий только графику. Может что и изменилось, на я до этого не докопался.

Ещё это можно проверить с помощью Valor Enterprise. Затягиваете в него PCB целиком, генерите Current Netlist и сравниваете его с CAD Netlist. Все дела.

Не грузит он РСВ из Протел 2004, даже если их сохранять в ASCII 2.8...

Извините, что пишу здесь, почему-то не могу начать новую тему...

Недавно Protel выдал глюк, стоивший нам весьма больших денег (~3,5к). При генерации герберов с платы эта сволочь каким-то непостижимым образом продублировала один из слоев питания на месте другого, в результате чего на плате отсутствовал полностью один из слоев питания... При повторной генерации этого не повторилось....

Сдается мне, не в протеле дело. Что мешало хотя бы мельком проверить состав герберов и наличие информации на них?

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

З.Ы. А проверяем мы все, что отдаем в изготовление, и не по разу...