Странный warning - SPMHNI-184, Как побороть? Опции

[Hoodwin]

Вот делаю генерацию нетлиста, и в netrev.lst сыпятся следующие предупреждения:

Код

#1   WARNING(SPMHNI-184): Device library warning detected.

WARNING: X9 component device pin number mismatch; cannot replace.

#2   WARNING(SPMHNI-184): Device library warning detected.

WARNING: X4 component device pin number mismatch; cannot replace.

#3   WARNING(SPMHNI-184): Device library warning detected.

WARNING: X35 component device pin number mismatch; cannot replace.

#4   WARNING(SPMHNI-184): Device library warning detected.

WARNING: X3 component device pin number mismatch; cannot replace.

Идиотизм ситуации в том, что число выводов у УГО и у символа одинаково. А ворнинг есть.
Как узнать, отчего он такой?

[Uree]

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

[Hoodwin]

А как такое может быть, если проект получен трансляцией проекта от layout?
И можно подробнее, что это за файлы, где их искать?

Если обобщать опыт того, к чему собственно оно прицепилось, то предыстория такая:
1. Были разъемы, у которых имелись контактные площадки для монтажа. Ну, например, D-SUB имеет два ушка под винты.
2. Были разъемы, у которых имелись направляющие отверстия, которые также были оформлены как пины в футпринте.
3. Все такие дополнительные пины имели имена в футпринтах Layout, так как оно по-другому невозможно.
4. После трансляции получились футпринты с нормальными электрическими пинами, которые уже стали брыкаться на несоответствие схеме при создании нетлиста для PCB Editor.
5. Проблемы эти я порешал так. Для части разъемов (как, скажем, направляющие отверстия) просто удалил текст с названием пина. Old1 в каком то посте учил меня, что такое действие делает пин механическим. Для другой части разъемов я добавил пины в УГО, но при этом переименовал их. Например, был пин H1 (hole 1), а стал (S11 - screen на стороне 1 по порядку первый).
6. В любом случае количество пинов и имена в файлах dra -> psm, соответствует тому, что дан в схеме на УГО.
7. И оно все равно ругается этими гнусными ворнингами.

Причем, если я в схеме заменяю свойство PCB Footprint на те, что я уже как-то раньше сделал с нуля в PCB Editor, а не экспортнул из конвертированного .brd, то ворнинги пропадают...

В общем то, мне было бы наплевать на них, если бы эта гадина не удаляла эти разъемы с платы...
Те, что без ворнингов, остаются на плате.

Сообщение отредактировал Hoodwin - Dec 28 2011, 07:57

[Uree]

Проверьте библиотеки на наличие девайс-файлов, расширение у них текстовое, а содержание примерно следующее:

(DEVICE FILE: CNI-HDMIX-S24A-

PACKAGE CONN_HDMI_L1220
CLASS IO
PINCOUNT 23

PINORDER 'CNI-HDMIX-S24A-B' '+5V-POWER' 'CEC-GND' 'CLK-SHIELD' 'D0-SHIELD' 'D1-SHIELD' 'D2-SHIELD',
'HDMI-CEC' 'HOT-PLUG-DET' NC 'TMDS-CLK-N' 'TMDS-CLK-P' 'TMDS-D0-N' 'TMDS-D0-P' 'TMDS-D1-N',
'TMDS-D1-P' 'TMDS-D2-N' 'TMDS-D2-P' 'TMDS-SCL' 'TMDS-SDA'
PINUSE 'CNI-HDMIX-S24A-B' POWER GROUND GROUND GROUND GROUND GROUND UNSPEC UNSPEC NC UNSPEC UNSPEC,
UNSPEC UNSPEC UNSPEC UNSPEC UNSPEC UNSPEC UNSPEC UNSPEC
FUNCTION G1 'CNI-HDMIX-S24A-B' 18 17 11 8 5 2 13 19 14 12 10 9 7 6 4 3 1 15 16

GROUND DGND ; 23 22 21 20

PACKAGEPROP INSERTION THD
PACKAGEPROP PARENT_PART_TYPE 'CNI_HDMI_N-L1220'
PACKAGEPROP PARENT_PPT CNI_HDMI
PACKAGEPROP PARENT_PPT_PART 'CNI-HDMIX-S24A-B'
PACKAGEPROP PART_DESCRIPTION 'CON HDMI RECEPT SMD RHT ANGLE 1775040-2 BLK SMD019'
PACKAGEPROP PART_NAME CNI_HDMI
PACKAGEPROP PART_NUMBER 'CNI-HDMIX-S24A-B'
PACKAGEPROP SCD_LINK 'http://twdocs.adb.pl/doc/87128_CNI_Series'
PACKAGEPROP STATUS ACTIVE
PACKAGEPROP VALUE '1775040-2'

END

И может получится такая штука: девайс-файл сгенерирован по первоначальному футпринту, потом этот футпринт был откорректирован, девайс-файл к нему не коректировался. В итоге получим разное описание выделенной части девайс-файла и аналогичного описания в пэкейджинге(файлы pstchip.dat, pstpin.dat). Вот на это скорее всего Аллегро и возмущается. Не уверен, но уж очень подозрительно похоже звучит "Device library warning..."
Самое простое решение, если такие девайс-файлы есть - удалить их. При наличии файлов пэкеджинга они не нужны. Ну может на всякий случай бэкап сделать...

[Hoodwin]

Ну, девайс файлы действительно были, в них были списки пинов, и я их поправил. Причем пробовал и руками, и через Create Device в меню File.
Но проблема не ушла. Зато я понял ее природу. Я уже на эти грабли наступал, но по другому поводу. Теперь вот понял, что и здесь то же самое.

Суть такая. Библиотеки то я поправил, а в .brd сидит старый футпринт. И у него локальная база футпринтов в brd имеет приоритет перед всеми PSMPATH. И когда я пытаюсь что-то ему менять, то он видит изменения, но старый футпринт автоматически заменить внешним не хочет. А между старым и новым - конфликт. Причем если я пытаюсь вызвать вручную Update Symbols, то оно тоже ругается, говорит, что у символа больше нет старых пинов - H1, H2, ...

Так их потому и нету, что они стали механическими...

Видимо, надо пробовать другой способ, просто даменить футпринт, пускай оно его в .brd не найдет...

[Uree]

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

[Hoodwin]

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

Вот проверил, работает удовлетворительно такой вариант:

Нужно сохранить измененный футпринт с другим именем - создать новый psm, подправить свойство PCB Footprint в схеме, и тогда уже делать нетлист. Так как новое имя футпринта в .brd остутствует, то он ищется в путях PSMPATH, где успешно находится, но не выкидывается с платы, а оставляется со старыми координатами и ориентацией.