Собственно, вопрос в названии темы.

Так сложилось (исторически), что схемы я рисую в OrCAD'е 10.0 который меня для данных целей по всем статьям устраивает. А вот разводкой занимается человечек, которому PCAD роднее. До поры проблем не было - экспортнул нетлист в формате PCAD и забыл о всех проблеммах, но теперь уровень схем сильно вырос, да и появилась необходимость их сопровождать. А каждый раз делать полную переразводку - это как-то слишком долго, да и неудобно.

Вот, собственно, и озадачился. Увы, чего-то как-то не нашел решения. Может быть Вы подскажите? Буду премного благодарен.

Я тоже схему рисую в одном, а плату - в другом, правда это не оркад и не пикад.
Обычно при изменениях в схеме упаковщик (генератор нетлиста) генерит файлы, видимо в пикаде они называются ECO, которые потом подгружаются в PCB. Я не помню, как это в пикаде, но, вроде бы, даже при полной замене нетлиста "поверх" (т.е. без ECO) расстановка и трассировка не нарушается. Поэтому надо просто попробовать. Обратная аннотация тоже должна так же работать.

Тоже так думал, но... Сформировать нетлист из OrCAD 10 (как и из 9, из 9.2) можно либо в NET, либо в NTL (который на самом деле не NLT, а что-то другое по мнению PCAD'а - увы не помню что именно). А при именении схемы начинается какая-то странная перенумерация цепей - в результате вместо измененного, получается совершенно новый нетлист (это касается только цепей, которым принудительно имя не задавалось).

Да и вообще - чего бы почитать про совместную работу PCAD<=>OrCAD. Ибо сопровождение схемы при такой постановке как-то не идет...

И еще вопрос - в последующих версиях в этой части что-нить поменяли? Имеет смысл смореть на на OrCAD 16.5? Просто для моих целей (схемы) хватило бы и OrCAD 7.5 под Windows 3.11. До сих пор небыло смысла перелезать на что-то более современное. Уж очень не хочется на PCAD переучиваться...

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

ЗЫ А чтобы не происходила "странная перенумерация цепей", нужно паковать схему(аннотировать) выбрав в пэкейджере опцию "Preserve", с отключенной птицей "Regenerate physical nets". По крайней мере в последних версиях Оркада именно так это выглядит.

ЗЫЫ Кстати Вы не почувствуете большой разницы, пересев на какую-нибудь последнюю версию(кроме 16.5 - ее я еще не видел, утверждать не могу) - Оркад схематик разрастался, но принципиальных изменений в нем особо не было.

А чем это поможет решению озвученной проблемы? У меня используется P-CAD везде, просто интересуюсь.

Ай... ашипся Хорошо все написал, но для случая именно упаковки. Для генерации ПКАДовского нетлиста нет таких настроек. Вообще никаких нет. Просто содержимое схемы сливается в *.net файл в формате. понятном ПКАДу.
Зато есть настройки аннотации. Надо в них поковыряться, разобраться какая за что отвечает. Навскидку там тоже есть установки "аннотировать только новое", от случайных переименований это избавит.

Хм... Вообще-то я доверяю своему коллеге, ибо оснований недоверять небыло. Так что априори считаю, что PCAD он знает.
Это я к тому, что NetSync надо посмотреть (как, впрочем, и NetComp). Единственный вопрос - съест ли она нетлист из OrCAD'a.

Ммм... Я, конечно, в последний раз это проходил несколько лет назад, и могу уже ничего не помнить, но помню, что если в пикадовской схеме что-то поменять и передать в плату, то ничего там не перенумеровывается и разводка сохраняется даже для цепей, которые назвались автоматически. При этом передача идет через нетлист с какими-то там опциями типа preserve и т.п. Файл нетлиста (помню хорошо) генерится каждый раз новый. Из этого делаю вывод, что достаточно иметь такое же поведение на строне оркада (генерить нормальный нетлист), чтобы все было ок.
Из-за чего, собственно, начинается это странное перенумеровывывание и почему пикад может все резко проигнорировать? Надо имхо с этим разобраться...

2 Alex A. Mihaylov

Нетлист-то из Оркада оно съест, я его смотрел - он в правильном формате. Вопрос насколько он будет совпадать с нетлистом, сгенеренным из РСВ... Тут трудно сказать, пробовать надо.

2 Vitan

Наверно забыли, но ПКАД похоже единственный, кто передает полные данные в виде нетлиста, а изменения в виде ЕСО-файла. Поэтому импорт нетлиста и импорт ЕСО могут работать по разному. Остальные САПРы обходятся одним механизмом для обеих задач. Как если бы ПКАДовский NetSync был у них встроен нативно и нетлист всегда через него проходил бы.
А поразбираться конечно можно, если время лишнее есть. Я уже разбирался, результаты разборок помню, мне хватило.

На самом деле ситуация простая - кол-во изменений в РСВ прямо зависит от места, куда были внесены изменения на схеме.
Есть схема, в ней 250 резисторов (R1 ... R250). Добавляем в схему еще парочку, причем где-нить вначале(с левой стороны листа, на первом листе). ПКАД дает им новые номера - 251 и 252. Но - в начале, не по феншую, в смысле не по ГОСТу. Делаем ренамбер - о, стало красиво, теперь они с номерами 10 и 12. А теперь момент - все резисторы с номера 10 сдвинулись на единичку. Правильно? Правильно. Генерим нетлист. Втягиваем на готовую плату. Что получается - ранее R10 становится R11, R11 -> R13, R12 -> R14 и т.д. Но ведь на плате резисторы с такими рефдезами уже есть! Итого резисторы с совпадающими рефдезами остаются на своих местах, но оказываются с другим номиналом и подключенные к другим цепям... красота Теперь начиная с R10 начинаем все 240 резисторов ОПЯТЬ расставлять, заново.
Вот так работает нетлист. А ЕСО сработает по другому - он запишет последовательность действий в схематике и эти же действия произведутся в РСВ. В этом и разница.

Нет, ну про ренамбер и спору нет. Понятно, что после ренамбера компоненты в плате поедут. Как ECO работает, тоже понятно. Непонятно только, откуда могут возникать проблемы при генерации нового нетлиста, особенно, если не перенумеровывать рефдесы, а оставить два резистора R251 и R252. Цепи к ним должны появиться в новом нетлисте. Старые цепи никто не трогал. И неужто пикад это все не воспримет при импорте нетлиста поверх старого?

Воспримет, конечно, не вопрос. Но ведь ренамбер все равно придется делать, рано или поздно! Все же делают по стандарту! Никто ведь не оставит R252 рядом с R10. Получается проблема втянуть нетлист останется, просто в полный рост встанет в другой момент времени, но встанет. И избежать ее можно только использованием механизма ЕСО. А для него крайне желательно, чтобы изменений было как можно меньше, тогда их легче проконтролировать. А вот контролировать кол-во изменений в нетлисте, генеренном Оркадом - проблематично. Именно это ТС и ощутил, по мере усложнения схем...

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



Хм... Я поговорил с разводчиком. Про NetSync он слышал, но никогда не использовал, ибо всегда в работе были нативные (PCAD'овские) схемы. А вот ренумбер в OrCAD я делал. А похоже зря... Ну чтож попробуем с учетом этих двух вещей (я не переименовываю компоненты, коллега пытается получить дельту с NetSync). Правда это, к сожалению, не быстро - у меня схема в работе (три ошибки уже, одна из которых в идеале требовала бы ренумбера) но когда я с ней покончу - вопрос. В любом случае я постараюсь отписаться о результатах сюда. Пока всем спасибо...

Так и есть. Допускается нумеровать в зависимости от физического расположения в устройстве или по другим признакам. Поэтому я обычно делаю ренамбер после окончания разводки, чтобы на плате было легко искать элементы. Но можно его не делать вообще.

поясните, уважаемые - это я такой тупой или все тут что-то недоговаривают ?
есть OrCAD15.7 и PCAD2002 , оба легальные.
экспорт нетлиста из оркада:

pcad.dll - реально генерируется ущербный квази pdif для мастер дизайнер;

tango.dll - нетлист генерируется некорректно, о чем даже есть телега "Orc2pro.wri" в " Program files\P-CAD 2002\ ", с потугами приплести OrCAD STD tango.config;

accel.dll - экспортируется некорректно , пропускает (type) - тот же глюк , что и танго.

так кто же и как передает нетлист в одно касание без излишнего головняка ?
поясните , будте добры .

Хм.. Я (обычно) генерю ТРИ нетлиста. pcad.dll (NET) pcadnlt.dll (NLT) и родной оркадовский. Если я все правильно понимаю, то разводчик импорирует NLT, который распознается PCAD'ом как Master Designer или что-то вроде того. Если сказанного мало стукнитесь через недельку в личку. Спрошу у своего разводчика.

Благодарю, pcadnlt помогло.
ЛС у Вас не работает.
Будте добры, спросите - каk импортируют {Value} ?
Я сейча правлю netlist accel.dll текстовым редактором.
Возможно ли скорректирвоать экспорт нетлиста ?

использую Orcad 9.1 и PCAD2006.

При экспорте указываю tango.dll
Только танго в оркаде какое-то не такое, поэтому в получившемся удаляю оркадовские строчки с заголовком и дублирую одну из строк в описаниях компонента.

было

[
C1
C_0402
1.0
]

стало

[
C1
C_0402
C_0402
1.0
]

При импорте полученной танги в Pcad {Value} проставляется правильно.

Благодарю за ответ . я пользуюсь оркад 157 , пока делаю также .

Еще вариант - в ПКАДЕ делать библиотечные компоненты не по типу ( RES1608, CAP0805 ) ,
а по номиналу ( RES1608_10R_5% )
тогда импорт нетлиста в PCAD не требует поля {value}.

экспорт нетлиста с wirelist.dll выдает лист для Exel, который можно потом форматировать , как угодно.