Отлов этой ошибки занимает меньше минуты - проверка ERC - и видим, что RAO есть цепь с одним пином на ней, либо без драйвера, либо с драйвером, но без входов... Это не стоит того геморроя, который доставляет предварительный ввод bus contents с последующим update.

А по 4) разъясните... Всю жизнь обозначал просто CLK, разветвлял, и ни один нормоконтроль не говорил, что не по ГОСТ. Видимо не в курсах они... Как и я Или это опционально.

Это у Вас "типа шутка"? Ведь при этом теряется смысл - вместо цепи CLK с тремя разветвлениями имеем 3 цепи. Госту соответствует, смыслу нет.

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

Кстати, в этом учебном проекте совсем нет bus contents, что может означать, что упрщенный путь с именованием шины при вводе вполне кашерен, и может быть вовсе не является основным.

И еще по этому учебному проекту. Большинство символов стоят не в сетке (100th), и при попытке что-либо поредактировать - подвигать символ, например, имеем весь букет дебильной во всей своей красе (иначе не сказать) работы с nets. Неужели это устраивает пользователей DxD??

Сколько смотрю и удивляюсь нормоконтролерам-интерпретаторам ГОСТ, такое впечатление что им нужно проводить ликбез по русскому языку, ибо фразы с ключевым словом "ДОПУСКАЕТСЯ" они воспринимают как обязательные к исполнению и наоборот там где этого слова нет считают необязательными к исполнению. Для тех кто не понял: согласно ГОСТ -
1. Объединение нескольких (или в "сильно запущенном случае" всех ) цепей в шину является допустимой, но необязательной процедурой (т.е. опция).
2. Если кол-во ответвлений данной цепи от шины больше двух, то на третьем ответвлении и далее ставится знак \ и порядковый номер ответвления - и это обязательно т.к. нет слова "ДОПУСКАЕТСЯ".
3. Согласно п.4.14

Т.е. можно просто нарисовать короткие отрезки цепей от пинов и дать им имена и все - не надо их все тащить в одну шину проходящую по всем листам схемы.

На "западных" схемах как правило объединяют в шину сигналы выполняющие одинаковое функциональное назначение и поэтому шин много и читать такие схемы как правило легче, т.к. сразу видно что куда идет и зачем - и кстати это полностью совпадает с основным постулатом ГОСТ - схема должна быть легко читаемой.
Разнородные сигналы объединяют в шину, как правило только для облегчения\ускорения проводки их через иерархию - легче на символ добавить и подсоединить один пин вместо множества пинов.
Поэтому у них и нет проблемы с правкой Bus_Contents т.к. эта операция производится очень редко.




Внимательно посмотрите на скриншот - там одна физическая цепь, но с названием CLK,CLK/1,CLK/2. Если же применить знак | вместо / то название физической цепи будет просто CLK.

Я действительно издеваюсь над поборниками ГОСТ показывая насколько абсурдными бывают их требования

Изначально в DxD не было Bus Contents - он перекочевал из маршрута DC - это просто способ заменить длинное составное имя шины на более простое, а также способ заранее распланировать\ввести нужные сигналы\шины чтобы потом просто при рисовании выбирать их из списка. Вы можете вообще не использовать Bus Contents если вам это не нужно.

Ага, можно и еще это же делать по ГОСТ 2.708-81, и там обозначения разветвлений через / именно "допускается". Однако вот если цепь пошла за пределы листа - то да, будь любезен укажи все листы, куда она пошла. Только суть в том, что тут наглядности еще меньше, чем при рисовании шин. С шинами все таки хоть как-то видно, где искать сигнал, т.е. только у выходов из шины... а без... Где угодно вообще. А вот с обязательностью кол-ва разветвлений сигнала при вводе его в шину это Вы мне глаза открыли... Остается понять, а как с двунаправленными сигналами быть У кого из них число разветвлений ставить? У того, который чаще всех "выход" ?


Что-то не замечал... Все западные схемы, которые мне попадались - выполнены именно как Вы выше сказали - раскиданные компоненты и именованные обрывки цепей к пинам. И ни одной шины. И даже соединений меж компонентов законченных раз-два и обчелся, разве что в аналоговых кусочках. Ужос. Понятно, что у них проблем с шинами и нету

Согласен - надо было написать - На "западных" схемах как правило объединяют (если вообще это делают) в шину сигналы выполняющие одинаковое функциональное назначение.

Внимательно прочитайте ГОСТ 2.708-81 - фраза ДОПУСКАЕТСЯ касается "прерванных в пределах листа линий связи" а не "линий связи объединенных в линии групповой связи" так что будь я на месте нормоконтролера, то пил бы сейчас ваш коньяк


В принципе да, только не надо все доводить до абсурда, когда например мне один раз прислали схему 33 листа с одной шиной через все листы



Вот вам пример одной уважаемой фирмы http://www.megratec.ru/data/ftp/exp_docs/DX_Schematic.pdf

дак я так понял, что SM так и хочет в таком стиле схемы рисовать

Это Вы внимательно прочитайте, к чему я это писал - именно к обрывкам цепей у пинов, к "буржуйской системе", а не к шинам. А у меня пока что нормоконтролеры попадались, слава Богу, которые не в курсе про количества разветвлений

Ну у меня все таки тоже не одна шина, если схема достаточно сложная. Но (например) шина управляющих сигналов есть всегда, и заранее знать, что в нее зайдет, просто не выходит. Или просто какая-то шина локального характера среди кучи преобразователей уровней на разных сигналах... Ну не могу я просто цепи рвать и именовать, не нравится мне это. И если листов со схемой цифровой части больше одного, и надо эту схему куда-то на сторону отдавать, то я указываю, какие сигналы на какие листы идут, и с каких берутся, чтобы облегчить другим понимание схемы. Собственно не в этом суть-то... А в том, что ввести в шину новый сигнал, которого там не было, IMHO операция значительно более частая, чем корочение сигнала с одним именем на сигнал с другим....

А с другой стороны - одна шина через 33 листа - я сам с такой схемой работал, когда в древности подхалтуривал ремонтом станков с ЧПУ на куче плат, набитых К155 логикой, там схемы именно так были оформлены. И ничего, все вполне понимаемо и красиво.


Ну да. Ну есть там шины. Только читаемости от них на мой взгляд ни грамма. Это как раз тот стиль, который я органически не перевариваю Не только по причине именованных обрывков, а еще и по причине выводов сверху и снизу символов.

ЗЫ
Как по мне - надо максимально убыстрить ввод схемы, убрав любые действия, которых могло бы и не быть для достижения тех же целей (в смысле действий в программе, а не действий в смысле "зачем шина, если можно без нее"). А ошибки в виде случайных "описок" в ERC все на раз вылезут.
Тоже и "маршрута через зад" касается - исключительно для убыстрения, и ни для чего более. Т.е. мне быстрее и удобнее что-то попереподключать прямо на плате, видя собственными глазами, как меняется картина расположения соединений, чем глядя на плату это же переподключать в схематике, аннотируя на плату, и смотря, каков результат. В первом случае - было бы допустим 100 переподключений и одна аннотация, а во втором - примерно 200 переподключений и полтора десятка аннотаций.
В общем на мой взгляд - лучший CAD это такой CAD, в котором для достижения той же цели будет произведено меньше всего кликов мыши и нажатий клавиш

ЗЗЫ. Со скриптингом поразбирался вот... Почти ничего из того, что хотел, включая автодобавление bus contents при подведении цепи, невозможно сделать....

да, лично мне именно такой стиль нравится, все логично. но вот очень сильно терзают смутные сомнения, что однако в DxD это сконвертировано из оркада. Я даже уверен в этом на 99.9%. И с огрехами - на последней странице не видно на белом фоне видимо белых же буковок - удобством работы с цветовыми схемами DxD сильно не блещет.

Да исходная схема была в OrCAD_Capture.
По поводу последней страницы не угадали - там просто имена в самой схеме скрыты, поэтому и в PDF не видны.

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

А Вы тут про шины все о чём?
Не было никогда в САПР системах полноценного понятия шины.
(За исключением, простых структур типа AD[7:0] для систем цифрового моделирования)
Да теперь, я уж и не понимаю, зачем это надо для систем проектирования PCB.
Ну есть обрубок цепи с уникальным именем, так и воспринимайте его как индивидуальный проводник общей шины.
Надо занести в список ограничений определённый набор цепей, так его и заносите. В чём проблема?
Фирме MentorGraphics и так безумно сложно в этой жизни.
1. Они зачем-то взялись поменять формат данных с текстового на двоичный, а он стал падать, чего не происходило никогда ранее с текстовым форматом.
2. Они ввели поддержку метрической системы в графическом редакторе, а она упорно не работает. Особенно в символьном редакторе.
3. Отвалилась поддержка русских букв в символьном редакторе.
4. Исчезла поддержка длинных аттрибутов.
5. Бедная буква "я" безбожно глючит будучи последней в слове. (DxPDF)
6. Выкинули цифровой симулятор, что являлось ранее основным достоинством пакета.
7. Ввели пользовательский интерфейс символьного редактора в полное противоречие со схемным редактором (цветовые схемы, реакция на колесо мыши и на колесо мыши + ctrl)
8. Откровенно украли клавишу "save" в схемном редакторе.
... общая потеря "юзестабильности"

Это всем давно известно, но разработчики даже не думают что либо исправить.
Зачем придумываются новые неработающие фичи, и одновременно убиваются уже давно существующие.
Это попытка похоронить продукт?

Так хочется красоты и удобства одновременно. Ну сделаю обрубок, поименую, нарисую толстую линию. Красиво и быстро! А теперь хочу это подвинуть... И наступает целая история, что двигать надо все по отдельности Неудобство. Рисую шину. Теперь все двигается вместе, типа удобно. Однако хочу новую цепь ввести - и тут теперь поджидает куча лишний действий Так что и рыбку съесть, и еще кой чего сделать, ну никак... А другие-то ведь сделали удобно! Я про пикад... Вот смесить функциональность его при подключении проводов, которых нет в шине с текущей функциональностью DxD для проводов, которые там есть - получится просто идеал... А Bus Contents - ну сделать там галку "fixed" - и все, кирдык, ничего не добавишь... Или пропертю "Fixed content". Для тех, кому нужно ограничение. Все бы довольны были, и никаких принципиальных сложностей, и реально удобно!

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

... типа помечтал

Есть два мнения по этому поводу.
1. Они пытаются перевести схему на DxD чтобы воспользоваться его более широкой automation для символов. Но это только предположение
2. DC это детище Veribest, которое было действительно very best, и возможно после покупки Mentor'om настали лицензионные или
юридические проблемы. А может соглашение было такое, что нужно делиться, вот и решили похоронить DC навсегда.
За это говорит и то, что DxD в новых версиях теряет оригинальные фичи и приобретает все то, что уже было в DC.

Непонятно и другое, зачем вообще тогда DxD, если есть Board Station - у него сама идеология программной модели просто идеальна, расширяли бы его покачетственней, чем плодить аж 3 разных схематика параллельных! А так неудивительно, что кругом глюки... Тянуть три разных редактора. Явно с какими-то из них надо кончать По логике - первым именно с DC, как с некроссплатформенным.

Уважаемый SM, мне с одной стороны очень импонирует Ваша приверженность к продуктам основанным на Linux. Тем не менее, возлагать излишние надежды на Board Station я считаю крайне опрометчивым. Продукт действительно существует очень давно, но на UNIX платформе, где он никогда не знал конкурентов. Пока эта платформа была денежной, всё было очень хорошо. Однако, после 2000 года многое изменилось. Рассматривать его как кроссплатформенный недопустимо. Он никогда не появится на платформе Wintel. Не зная же конкурентов он пребывает в крайне убогом состоянии. При этом, ни каких надежд на его восстание из пепла разработчики не испытывают. Он поддерживается исключительно из необходимости осуществления номинальной технической поддержки уже существующим пользователям. Может быть fill меня опровергнет?

А вообще, ситуация действительно очень непонятная.
Сперва перестали развивать PADS Logic по той причине, что PADS комплектуется DxD, чуть позже, под тем же предлогом остановили развитие DC, а в итоге - перелопатили DxD так, что даже самые фанатичные приверженцы DxD отказываются работать с новыми версиями DxD.
Т.е., в результате покупок и слияний убили аж ТРИ графических редактора, при этом каждый из них, до указанных пертрубаций, имел свой независимый рынок. Странно это всё. Может быть расчищают площадку?

Ошибаетесь. Хотите залью BSXE 2007.2 виндовый в закрома? Да в принципе достаточно зайти на сайт mgc и глянуть свежим взглядом....

... Посмотрел, данный продукт под windows действительно существует. Был крайне удивлён. Не ожидал. Хотя пока в душе всё равно отношусь с некоторым недоверием, однако надо попробовать (спасибо, доступ у меня есть).
... Хотя, кто его знает?! Может под него площадка и расчищается!?

Очень большие надежды на это. Ввиду его полнейшей конфигурируемости под себя (он, если не ошибаюсь, весь на скриптовом языке). Сразу пропали бы все "а почему так", "а почему не так" - возьми да поправь так, как надо Да и направление портирования unix->win куда более правильное, чем win->unix под mainwin-ом. Так как в первом случае большая свобода выбора, а во втором mainwin и хоть треснись.

SM

пробовали сравнивать функционал BS и EE (конкретно - редакторы топологии)?

Они там одинаковые
http://electronix.ru/forum/index.php?showt...st&p=600650

1. Board_Stn. для виндов существует с 1998 года. Работает через X-терминал.
2. Design_Architect используется как для разработки схем для плат, так и для топологии микросхем. DA существет уже 20 лет и интерфейс его не меняется ибо те кто нуждается в доп. функциях пишут сами или заказывают у ментора собственные userware (макросы на Ample). И соответсвенно как правило большие фирмы (а именно на них используется данный маршрут) работают на собственных design_kits, а также рассылают их сторонним разработчикам.
3. Вы хотите сказать что в самом DxD нельзя рисовать в миллиметрах в полном объеме? Насколько я вижу проблема только внутри символьного редактора.
Вообще высказывания sh007 больше похожи на раздражение человека за долгие годы привыкшего к чему-то и теперь просто при появлении существенных изменений испытывающего праведный гнев - зачем меняли ведь меня все устраивало, а теперь надо перестраиваться. Если вам нравился старый символьный редактор, то мне он наоборот категорически не нравился ибо я привык из редакторов DA и DC что пин это просто точка, есть просто графика символа которая редактируется щелчком мыши по ней (без вызова доп. команды Stretch), пин не рисуется между телом символа и границей символа и не зависит от этого расстояния и т.д. Поэтому NSE не вызывает у меня таких отрицательных эмоций.
4. Даже в России большинство спокойно рисует в сетке кратной 2,54мм и абсолютно не испытывают насущной потребности в сетке 2,5мм. Не говоря уж обо всем остальном мире. Т.е. о чем вы все время так кричите волнует ограниченный круг лиц.
5. Может быть вы хотите сказать что кириллица поддерживается в полном объеме в Acrobat-е? Или может быть вы хотите сказать что акробатовский документ с кириллицей сделанный в одной программе однозначно правильно отобразится в других? Вот вам пример Нажмите для просмотра прикрепленного файла а вот что я вижу открыв его в редакторе Нажмите для просмотра прикрепленного файла Кстати этот же редактор открывает файл pdf сгенерированный DxPDF нормально, без проблем с буквой я, а Acrobat имеет проблему.
Может для начала обратитесь в Adobe чтобы они начали поддерживать кириллицу в полном объеме? Если бы они сделали бы native фонт с кириллицей то проблема бы исчезла раз и на всегда.
6. Мышь в символьном редакторе действует абсолютно также как в топологическом редакторе ExpeditionPCB, т.е. включив настройки мыши в DxD под Expedition будете иметь одинаковое функционирование во всех трех редакторах. Вопрос только привычки.
7. Синхронизация схем отображений DxD-NSE стоит в ближайших планах Нажмите для просмотра прикрепленного файла. Хотя я струдом представляю насколько это будет правильно ибо непонятно по какому принципу NSE должен выбирать схему отображения - ЦБ может быть подключена к разным проектам, в которых цветовая схема может быть разной - какую из них выбирать?

3. Вот об этом и речь. Ну как же можно рисовать в DxD в метрической сетке в ПОЛНОМ объёме, если симольный редактор не позволяет рисовать в мм?
Раздражение действительно имеет место быть. И дело не только в том, что приходится перепривыкать (что само по себе является непродуктивными трудозатратами), а в том, что вновь появляющийся продукт (NSE) удивительно сырой. Я понимаю, что любая программа может содержать некоторое количество ошибок и глюков, но я не могу себе представить как должно быть составлено ТЗ на разработку программы и какая должна быть методика тестирования, что бы с такими недоработками программа выходила в тираж.
У меня нет особой любви к прежнему символьному редактору (ViewDraw вообще всегда был несколко аскетичен), но прежний символьный редактор без глюков выполнял все заявленные фичи, и был нормально интегрирован со схемным редактором. Форма представления пина действительна несколько необычна. Но это дело привычки, и на функциональности продукта никак не сказывается.
4. Тема мм/inch видимо бесконечна . Тот факт, кто то имеет возможность или желание не соблюдать ГОСТы, равно как и фривольно интерпретировать их в соответствии с техническими возможностями MentorGraphics, ровным счётом ничего не доказывает. ГОСТ оперирует миллиметрами. Мы это уже обсуждали неоднократно. Более того, вопрос всегда ставится в ключе: "Почему метрическая сетка работает неправильно?" Вы же всегда отвечаете: "А оно Вам не надо, и так даже лучше."
Тем не менее, не такое уж и малое число людей заинтересовано в реализации метрической сетки в схемном редакторе.
Стандарт МЭК (Международной электротехнической комиссии) IEC 60617 однозначно предписывает использовать при рисовании символов метрическую сетку. К тому же начертание символов почти полностью соответствует отечественному
5. Я так понял, что исправлять не будут
А в NSE русские символы использовать им тоже ADOBE мешает?
6. Я использую связку DxD / PADS. Да и не логично это. В схемном редакторе переключается, в символьном не переключается.

Вот именно что много раз говорили, а "что о стенку горох". Фривольно интерпритируют ГОСТ как раз те кто говорит что УГО должны быть нарисованы в миллиметрах, хотя все основопологающие документы ГОСТ говорят о модульной сетке.
И ни один документ IEC не говорит об однозначном использовании какой-либо точной сетки.
Насколько я вижу символы нарисованны в какой-то сетке для соблюдения пропорциональности и все, конкретное значение не указано, а если бы было указано, то это было бы бредом ибо давало указание делать несовместимые с другими единицами символы\схемы.

забавно, мне кажется, что во внетренних базах данных используются метрические единицы, о чем можно догадаться, заглянув во всякие ini и в описании настроек DxD. И точность 0.01 микрона...

1. Для начала нарисуем угловой штамп (ГОСТ 2.104-2006). В чём указаны размеры?
2. Ну и что тогда значит фраза из стандарта IEC 60617.
"Symbols have been designed in accordance with
requirements given in the future ISO 11714-1. The
module size M = 2,5 mm has been used."

Теперь по делу.
Я сообщил Вам о том, что DxD в метрической системе работает некорректно.
В ответ, было бы логично ожидать признания с Вашей стороны ошибки в программе и извещения о предполагаемых сроках исправления.
Вы же, начинаете меня убеждать в ненужности данной функции программы, за которую я заплатил деньги.
Пока DxD не содержал поддержки метрической системы, с моей стороны не могло быть никаких претензий (только пожелания).
Сейчас - поддержка метрики штатная функция программы. И по этой причине она должна работать правильно.
Никакие художественные интерпретации стандартов не могут исправить банальную ошибку программиста.

1. Ну тогда я вам тоже:
ГОСТ 2.701-84 причем дам его название, чтоб всем было понятно "СХЕМЫ
ВИДЫ И ТИПЫ. ОБЩИЕ ТРЕБОВАНИЯ К ВЫПОЛНЕНИЮ"

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

Т.е. следуя вашей логике надо взять ГОСТ "ОСНОВНАЯ НАДПИСЬ" и применить его измерения и к схеме и к УГО, несмотря на то что в ГОСТ-ах описывающих правила создания схем и УГО прямо указаны другие размеры. Типа мне так нравится и все.

2. Она означает дословно, что"
Символы разработаны в соответствии требований сформулированных в ISO 11714-1. Использован модульный размер М=2,5мм.

Т.е. для начала надо прочитать стандарт ISO 11714-1 (а лучше ISO 81714-1 ибо он пришел ему на смену) и понять, а какие такие требования там есть (пришлите - мы все с удовольствием почитаем). И заметьте выше сказано использован, а не должен использоваться, т.е. явно возможны альтернативы.

Читаем дальше обрезанную вами фразу:
In accordance with the future IS0 11714-1, clause 7, symbol dimensions (for instance height) may be modified in order to make space for greater number of terminals or for other layout requirements. In all cases, whether the size is enlarged or reduced, or dimensions modified, the thickness of the original line should be maintained without scaling.

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

Ну что так и будете биться о стенку, что должно все быть 2,5мм и ничего другого быть не может?

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

все-таки глючок - кардинально помогает удаление из wdir DxDesigner.xml, DxDesigner.wsp, ICTsLayouts.xml. На каком из них конкретно спотыкается разбираться неинтересно. А спотыкается быть может от того, что какие-то из предыдущих версий в этих xml чего-то попортили. Теперь загрузка листов практически мгновенно.

Сорри, если баян (искал и не нашел). А как обновить в DxD информацию о parts из ЦБ после того, как одновременно с моей работой в DxD кто-то удаленно сделал в ЦБ новый part? Что-то торможу, никак не найду...

Выйди из DxD и зайди, если лень, то измени ЦБ и обратно вернись к родной.
измененные компаненты будут в красном квадрате
вот их и по ПКМ делй update

Ну до этого я и сам догадался, но это какой-то кривой, долгий и муторный путь. Разве нету какой нибудь кнопки "Reload Library" или как-то так?


Не, мне не для апдейта, именно новый парт сделал кто-то, а я хочу его на схему поставить. Теперь что, с каждым новым партом входить-выходить? А апдейт я и без обновления ЦБ сделаю, он апдейтится без какого либо геморроя, лишь красным квадратом "перед тем, как" не выделяется.

ЗЫ. Или это опять считается извращением, когда я рисую схему, а в это время мне кто-то клепает недостающие компоненты в ЦБ?

Как у Вас все круто, однако Библиотекарь есть. Завидую.

Это извращение, имхо. Если кто-то клепает компоненты, партиция должна быть недоступна, и Вы не сможете оттуда компонент на схему поставить. А когда партиция доступна, почем Вы знаете, что компонент уже готов? Может, клепальщик вспомнит что-нибудь и метнется компонент исправлять? Короче, ментор рекомендует использовать исключительно верифицированные компоненты, которые должны находиться в "правильной" библиотеке.

Третий вариант:
в меню File всегда "висят" 6 последних проектов. Загружаем один из них, затем опять предыдущий (он ведь тоже в этом списке) - ЦБ перезагружена - быстро и просто.
В принципе можно даже написать макрос выполняющий это действие и повесить его на меню или клавишу.

Нет, всего лишь компаньон.

Для этого ICQ есть. Сказали - готово, значит готово.



Ага, спасибо, пожалуй самый оптимальный вариант. Правда у меня всего один проект в менторе, так сказать для отработки нюансов работы и оценки, подходит ли мне этот пакет вообще. Придется создать еще один просто так . Хотя недостаток остается - после переоткрытия все листы схемы, открытые ранее, закрыты, и потеряно то состояние экрана (лист, масштаб, центр), которой было на момент закрытия. Этот вопрос можно как-то решить? Чтобы при открытии проекта полностью восстанавливалось состояние на момент закрытия?

наверно как можно через скрипты
неужели так критично, хотя если через 5 минут приходится перескакивать в другой проект для работы
и новые компаненты клепают через 3 минуты

Да не то, чтобы сверхкритично, но раздражает. Как и "bus contents"... Хочется удобства в работе.

Естественно через скрипты можно, но в данном случае я бы предпочел написать скрипт по переподключению ЦБ - это наверняка проще.

А такой тогда вопрос - если сделать пустую ЦБ, и подключить ее, то ничего плохого с проектом не случится, и она подключится? Ну и будет ли все ОК после возврата к основной? Я как-то не хочу эксперименты на рабочем проекте делать

Ничего не грозит.
Проблема может возникнуть (гипотетически) если в обеих ЦБ будут одинаковые символы (имена), но с кардинально разной реализацией и вы переключившись в другую ЦБ вместо последующего возврата в основную ЦБ, сделаете Update символов (т.к. на схеме будет отображено что их надо обновить).

Еще пара мелких вопросов.

1) Запаковка. Есть компонент из двух идентичных гейтов, один гейт на одном листе, другой на другом (может это и не важно). Ставлю вручную один гейт пины 1-2-3, второй гейт 5-6-7. После запаковки они оба оказываются 5-6-7 и ДВА разных корпуса. При этом во всей схеме всего два гейта, т.е. хватит одного корпуса. Какими-то шаманствами все таки запихал их в один корпус, но хочется знать, почему все таки оно так было. Ну и можно как-то сделать, чтобы формат рефдеса был DAn.m где n номер микрухи, а m - гейта?

2) Offsheet и Onshhet коннекторы. Объясните, как их правильно использовать. Вроде ставлю offsheet-ы для соединения между листов, даю на всех листах им одинаковые имена, но реального соединения не получается. Что я не так делаю?

1. Надо смотреть конкретный пример. В принципе должна упаковывать для минимизации корпусов. Опция "Repackage_All" однозначно так делает.
В формате соединений платы m - это номер пина. Так что предложенный вами формат не совместим с форматом представления связей в плате. От отображения номера вентиля (Gate) на схеме в менторе отказались более 10-лет назад.
2. Здесь показан как ответ на вопрос, так и предолжение пользователя как по его мнению должна работать эта функция Нажмите для просмотра прикрепленного файла

Спасибо за ответ, ну а по пункту 1 в части DAn.m и ладно, как всегда - если нормоконтроль что-то хочет, чего нет у меня, то... коньяк

Ну у вас еще остается вариант убрать видимость RefDes и добавить другой атрибут которому присвоить нужное значение:
- в ручную
- написать скрипт это реализовывающий

Ну да, если сильно прижмет, так и сделаю, так как компонентов не шибко много

Перешел с ЕЕ2007.1 на ЕЕ2007.5. При рисовании схемы в DxD номиналы резисторов стали отображаться как "1Kohms" (ранее было "1К"). При этом библиотека осталась прежней, правда Library Meneger ёё "переформатировал". Как можно изменить отображение номиналов элементов?

Вопрос к знатокам Dxd . При трансляции из Оркада в Dxd версии 2005 была возможность даже при работе с kyn нет листом использовать cross probing хотя бы для размещения деталей, т.е. - к сделанному в трансляторе проекту можно было подключить Pcb и спокойно размещать детали в режиме cross probe. В Dxd 2007.6 и 2007.7 такой опции, сколько не искал - не нашел....а жаль, было удобно....

У вас в ЕЕ2007.1 это было сконфигурировано в файле VBUnits.HKP. Сконфигурируйте также в ЕЕ2007.5.



Это заложено в качестве разницы между интегрированным и неинтегрированным маршрутом Нажмите для просмотра прикрепленного файла.

То есть, я так понимаю, праздник закончился....И кому это мешало?

Скорее не мешало, а просто отпала сильная необходимость делать это в новом DxD, т.к. работа через нетлист теперь экзотика. А в случае DxD-iCDB-Exp теперь кросс проб работает налету, без вызова каких-либо доп. меню.

Здравствуйте, Александр! Хотел бы обрисовать Вам реальную ситуацию с Ментором на сегодняшний день. Я живу и работаю в Израиле, и уровень электроники, как Вам , может, известно, у нас не самый низкий. Но специфика работы - следующая, - очень мало компаний, которые работают на сквозном проекте, невыгодно держать разработчика и разводчика, поэтому существуют небольшие фирмы, подобные той, в которой я работаю, которые и разводят печатные платы на разных программах. Из-за относительной дешевизны, 90% фирм разрабатывает схемы на Оркаде, поэтому и приходится работать с нетлистом. А теперь представьте себе, сколько клиентов уже перешло на Аллегро, только потому, что они интегрировали Оркад, а сейчас на пятки наступает Альтиум, он Оркад "кушает" на лету...Очень не хотелось бы, чтобы мою любимую программу постигла участь Pcad. Извините , если был немного резок, просто много лет работаю на Экспедишен и очень не хотел бы ни на какую другую систему переходить, хотя, жизнь может и заставить, - рынок, Сэр.... С уважением - Роман

Я так понимаю для разрабатывающих схемы в OrCAD_Capture есть специальный интерфейс (OrCAD-Expedtion_Interface) при котором схему не надо транслировать в DxD, именно поэтому особо не заморачиваются с доп. возможностями для netlist_flow.
А вообще если используете транслированный проект в DxD, то что вам мешает перейти с netlist_flow на iCDB_flow и иметь нормальный кросс-проб?