[Doomsday.machine 0]

Выяснилась неприятная особенность. При импорте гербер файлов в CAM350 V 9.0.1, в одном из них площадки некоторых переходных отверстий оказались поглощены полигоном, относящимся совершенно к другой цепи, в то время как в expedition на том же слое гербер, эти же самые площадки отделены от этого полигона (как и должно быть). Кто виновен в этом случае: expedition, создающий "неправильный" гербер-файл или CAM350 V 9.0.1, неправильно его читающий? Отпишите, пожалуйста, кто еще с этим сталкивался и вообще что с этим делать. Ведь это же фактички кз питания на землю.

[bureau 0]

Обсуждал данную проблему с Frederik. На следующий день сам попался на этом моменте. Для себя решение нашел увеличив разрядность значений, поставив по максимум(было 2 выставил 5. см. рисунок - пример из САМ). После этого все стало на свои места.

ИМХО: виновен CAM

[Frederic 0]

Выяснилась неприятная особенность. При импорте гербер файлов в CAM350 V 9.0.1, в одном из них площадки некоторых переходных отверстий оказались поглощены полигоном, относящимся совершенно к другой цепи, в то время как в expedition на том же слое гербер, эти же самые площадки отделены от этого полигона (как и должно быть). Кто виновен в этом случае: expedition, создающий "неправильный" гербер-файл или CAM350 V 9.0.1, неправильно его читающий? Отпишите, пожалуйста, кто еще с этим сталкивался и вообще что с этим делать. Ведь это же фактички кз питания на землю.

так и у меня кз плейнов 0V на 1.6V на 40 смонтированных сборках :)

перед отправкой герберов я проверяю в САМ 10, а подготовку делали как оказалось в САМ 7

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

товарииищщи были весьма сильно удивлены разными результатами двух версий САМ

обещали мои гербера обрабатывать в 10

 

рецепт bureau лично не проверял

[Doomsday.machine 0]

bureau, Frederic

Большое спасибо за ответы. САМ 10 пока не пробовал, пока удалось устранить проблему повышением разрядности до 5.5 при формировании гербера в expedition (было 2.4). Получается, при использовании expedition, могут быть ограничения на использование определенных версий программ подготовки к производству. Странное ощущение, с одной стороны проблему вроде удалось локализовать, но неприятный осадок остался, т.к. оказывается могут быть сюрпризы. Все это плохо вяжется с нехилой стоимостью этого пакета...

[Arci0m 0]

2005.1

 

Открываю Цес из ЕЕ. Удаляю клиренсы класса к классу. удаляю клиренс классы. Сохраняю, закрываю (если снова открыть цес, то изменения сохранены).

Делаю BA, открываю ЦЕС всё что изменял (удалял) вернулось.

 

Как побороть баг?

[AlexN 0]

2005.1

 

Открываю Цес из ЕЕ. Удаляю клиренсы класса к классу. удаляю клиренс классы. Сохраняю, закрываю (если снова открыть цес, то изменения сохранены).

Делаю BA, открываю ЦЕС всё что изменял (удалял) вернулось.

 

Как побороть баг?

 

в 2005 два CES - у expedition свой, у DC - свой, и они "борются"при синхронизации, в этом (по утверждению ментора) была львиная доля глюков CES.

наверное CES от DC у вас "главнее", чем в expedition (где-то настраивается). В 2007 ces только один и этой проблемы быть не должно.

 

[Arci0m 0]

да что п не корпоратив в 2005, давно бы в 2007 работал (как на предыдущей работе) и не знал бы таких проблем.

до кучи сейчас работа в ДхД, поэтому буду пробывать из него цес редактировать...

спасибо за наводку.

 

[upd]. Сделал через цес ДхД, откомпилил, упаковал, сделал ФА в ЕЕ, и теже грабли :)). Копаем дальше... :smile3046:

[Frederic 0]

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

 

Вообще генератор маски вам нужен только если не задали Solder_Mask в padstack. Если задали, то просто выдайте в Gerber все что есть на слое Solder_Mask, в результате и получите изображение мест где не будет маски (т.е негатив маски). Если не задали Solder_Mask на уровне padstack, вот тогда придется сгенерить в Mask Generator слой с негативом маски (по контактным площадкам) и его уже использовать при выдаче в Gerber.

 

ЕЕ2007.8

а возможно с помощью Mask_Generator провести проверку на наличие различий между слоем ТОР и импортированного в Ехр гербера L1_Top.gdo после подготовки производства.

импорт и сравнение через Xor сделал, но остается много так сказать артефактов см.картинку

 

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

[Doomsday.machine 0]

Вопрос ко всем, кто пользуется Manufacturing Output Validation. При проверке постоянно возникают ошибки Elements with mismatched property наподобие:

Error 1: DB ELEMENT TYPE: SolderpasteNonViaPad : DCode = 11

Matching Artwork : DCode = 15 At: Start:(325.200000, 170.700000) -- End:(325.200000, 170.700000)

Ошибки относятся, как правило, только к падам (NonViaPad) на слоях Soldermask, Solderpaste, Top и Bottom.

Из документации:

Property mismatch: Errors where an output element's property is not matching to that in

layout. Example of Property mismatch in the case of Gerber is width (D-code) of a

segment with that in layout.

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

Итак, пытаюсь приблизиться к ответу самостоятельно. Удалось выявить следующие закономерности:

1. Описанные ошибки Elements with mismatched property возникают только по отношению к падам типа Radius Corner Rectangle c равными сторонами.

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

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

В общем, имхо налицо баг, поправьте, если я не прав. Замечу, что все вышеописанное относится к EE2007.8, в EE7.9 еще не проверял наличие этого глюка. Для всех, кому интересно, выложил тестовый проект с логом проверки MfgOutputValidation.txt. Буду рад выслушать различные мнения. Особенно интересно, что скажет fill.

EE2007_8.rar

[Doomsday.machine 0]

В дополнение к вышесказанному (хоть это пока и мало кому интересно :) ), открыл тот же самый тестовый проект в EE7.9, надеясь на то, что там баг с MOV отсутствует. Не тут то было, в EE7.9 все гораздо более тоскливо. По результатам MOV в проекте 1238 несуществующих в реальности ошибок на самый разный вкус. При этом визуальное сравнение никаких видимых различий между гербером и слоем в проекте не выявляет. Особенно радует наличие ошибок на слоях Test.botpaste и Test.botmask, которые вообще пустые. Ну что сказать, это просто песня .

EE7_9.rar

[fill 2]

да что п не корпоратив в 2005, давно бы в 2007 работал (как на предыдущей работе) и не знал бы таких проблем.

до кучи сейчас работа в ДхД, поэтому буду пробывать из него цес редактировать...

спасибо за наводку.

 

[upd]. Сделал через цес ДхД, откомпилил, упаковал, сделал ФА в ЕЕ, и теже грабли :)). Копаем дальше... :smile3046:

 

 

Поищите на megratec (да и здесь по моему тоже) я расписывал процедуру удаления CES схемы и восстановления ее из данных CES платы.

[Doomsday.machine 0]

Здравствуйте, Александр. Уделите, пожалуйста, внимание и моему вопросу тоже, если вам не сложно. :rolleyes:

[fill 2]

Здравствуйте, Александр. Уделите, пожалуйста, внимание и моему вопросу тоже, если вам не сложно. :rolleyes:

 

Похоже на явный баг, причем появившийся недавно - проверил проект в 2005_Sp3 - нет ошибок.

В 7.9 - есть. Вообще про MOV в базе всего два упоминания - видимо никто не применяет, иначе давно бы был DR.

[Inpharh 0]

Небольшой глюк. Ситуация: есть две FPGA, соединены диф.парами,

если просто провести трассы от фанаута до фанаута - все нормально;

если предварительно свапануть две пары, то при прокладывании первого сегмента трасс экспедишн задумывается на пару секунд, последующие сегменты прокладываются без тормозов;

если провести трассу без промежуточных сегментов, т.е. тыкнуть на фанаут, нажать F3 и тыкнуть на ответный фанаут - все нормально;

если фанауты делать после свапирования - все нормально.

Выглядит это довольно странно, раньше такого не было.

Маршрут DC-EE, версия 2007.8.

Единственное отличие от предыдущих проектов - использование CES вместо нетлиста ЕЕ.

В предыдущих версиях иногда бывали тормоза при прокладке трасс, помогало выключение Cross Probe, сейчас не помогает.

Есть у кого-нибудь идеи?

[ClayMan 0]

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