Vadim

Выходит так. Только за пикад я уже никогда больше не сяду. Накушался уже. Оказалось проще привыкнуть к неудобствам ментора, чем к багам пикада :)

К большому сожалению, никак :( Все три пункта :( . Может в PADS2005 SP1 что-нибудь изменится в этом плане... Искренне сочувствую Вам, ибо я сам очень капризен в плане настройки системы под себя, но в Logic к большому счастью мне почти все подходит (или я привык? :) )

Во-во-во... :) Это уже по теме. Большое спасибо!!! Посмотрим... :smile3046:

Вы опять ничего не поняли. Чтобы сделать Backannotate, нужно иметь файл платы. Если бы это было нужно лично мне, я бы использовал Backannotate, поскольку в схемных редакторах и редакторах плат я как рыба в воде. Прозвонил бы связи, составил бы таблицу, попросил бы программиста написать утилиту, делающую нетлист для PADS (я в PADS работаю) по полученной таблице, создал бы недостающие компоненты, кинул бы нетлист в редактор плат и наконец сделал бы Backannotate. Тут все правильно, это понятно. Но Вы не учитываете, что ремонтники - люди старой закалки. Есть и пенсионеры. Никаких САПРов не знают. Никаких компонентов создавать не будут. Испокон веков звонили и будут звонить. Составляли таблицы и будут составлять. Вы что, думаете они ради этого освоят САПР? Это сколько же времени надо?!! Да никогда. Еще раз повторяю - ремонтники могут составить таблицу связей в виде текстового файла. Причем в любой нужной форме. Если найдется программа, они будут рисовать символы и сохранять их в библиотеке. Если там будет возможность, будут вручную набивать таблицу связей. Полученную автоматом схему они в случае необходимости будут править вручную. Все. Ничего другого делать они не будут. Неужели ничего такого в природе не существует?

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

Может кто знает программу, рисующую схемы по нетлисту. Чтобы было понятно, о чем речь, обрисую ситуацию. У нас есть отдел ремонта. Платы, на которые нет схем, прозваниваются вручную и составляется список цепей. Потом рисуется схема, чтобы понять логику работы и впоследствии починить эту плату и другие подобные, если они поступят в ремонт. Понятно, что схемы получаются оченьтрудночитаемые, но другого пути нет. Впоследствии если есть смысл схема перерисовывается с целью повышения удобочитаемости. Но это бывает крайне редко. Понятно также, что искомая программа будет выдавать трудночитаемые схемы. Это не пугает. А если потом можно будет отредактировать полученную схему вручную, то это вообще круто. Существует ли сабж в природе?

Разрешите Вас просветить. И не только Вас :) SPECCTRA и близко не стояла по сравнению с PADS Router. Извините за категоричность, но "огромные" возможности SPECCTRA - это величайшая инсинуация прошлого века. Говорю это после четырех лет работы с ней, излазив ее вдоль и поперек. Вся хитрость в том, что она очень сложна и гипотетически у нее очень много возможностей, поэтому у начинающего пользователя создается впечатление, что отрицательные результаты при работе с ней являются следствием недостаточного опыта. А чтобы освоить ее хорошо, нужно очень много времени. По мере ее освоения у пользователя возникают смутные подозрения... Чем больше опыта, тем больше подозрений. А когда все возможности изучены, а обещанного великолепного результата все равно нет, становится мучительно больно за бесцельно потраченное время. А после того, как я попробовал PADS router из PADS2004, меня от SPECCTRA мутит. Это даже не небо и земля, это небо и ад.

Не могу удержаться от замечания: что-то не понравится обязательно. И Вы дальше, следовательно, попробуете в WG, а там Вас ждет изумительный :glare: схемный редактор :) И Вы долго будете пробиваться сквозь трехметровый слой настроек, опций и надуманных ограничений. Но многим это нравится, может быть понравится и Вам, не знаю. Но в любом случае изучать схемный редактор WG гораздо дольше чем PADS. Поэтому может быть стоит попробовать наоборот, сначала WG а потом PADS? По-моему, так Вы быстрее определитесь.

Вообще-то хотелось бы рассказать чем все закончилось. Хотя на самом деле еще ничего не закончилось... Ну да ладно. Конденсаторы 680 мкФ на все платы (48 штук - по одной на плату) помогли очень слабо. Анализ в PSpice показал, что помеха возникает В МОМЕНТ ВЫКЛЮЧЕНИЯ реле. Это подтверждается и результатами прохождения программ контроля. Все реальные сбои происходили, когда программа управления пыталась подать команду на включение реле сразу же после сброса предыдущего реле. И больше никогда. Место "дислокации" помехи - выходы (к сожалению) плат коммутации. К сожалению - потому что выходов на плате - 50, а входов всего 3. На входах плат (+27В, перем. 115В и общий этих двух источников) помеха не возникает никогда!!! Это говорит PSpice и результаты экспериментов. Я безрезультатно пытался задушить помеху на входе +27В обратносмещенным диодом, а душить-то нечего, ее там нет!!! Как помеха проникает в цепи питания, ведь цепи коммутации никак не связаны с цепями питания и управления, этого я не пойму, наверное, никогда... Утешением может служить "щелкание" каким-либо переключателем... ну я даже не знаю... ну например выключателем света при работающем телевизоре. На экране в момент щелчка видна горизонтальная черта. Это ведь никого не удивляет, и меня тоже. Поэтому я забыл о загадке проникновения помехи и задумался о том, как ее задушить. Очевидный путь - душить в месте возникновения. Места возникновения - 400(!!!) выходов плат коммутации питания. Обратносмещенный диод (400 шт) не проходит, потому что может коммутироваться и переменное напряжение. Остается конденсатор с резистором... По моим экспериментам с PSpice, для более-менее уверенного уничтожения помехи нужен резистор не менее 4 ВТ. Вместить их на платы не представляется возможным. Самое интересное, что самый ощутимый результат дала разводка "звездой" проводов общего провода питания по крейтам. Количество сбоев уменьшились процентов на 30. И мне ничего не оставалось делать, как попросить программиста ввести задержку между выключением одного и включением другого реле. И при каждом изменении состояния коммутатора питания сбрасывать его (ведь помеха все равно его сбросит!!!) И после этого - задержка (0.2с) Обошли стороной, так сказать... благо логика функционирования это позволяет. Но, блин, иногда (теперь очень редко) все равно сбоит. Программист уже был подловлен на несуразностях, и есть большая надежда, что в программе что-то не то. Борьба продолжается...

Ну нет слов!!! :cheers: Одно но: много проектов и у меня разводились при использовании авторазмещения, а следом и автотрассировки, только вот отдавать такую гадость в производство я бы не стал.

В SPECCTRA есть, но я этим никогда не пользовался, поэтому сказать, насколько это удобно не могу.

Совершенно верно. Забудьте про авторазмещение вообще. Ес-но, это только мое мнение. Интересно, найдется ли хоть один человек, кто реально сделал проект, используя авторазмещение? <_<

Спасибо всем. Завтра продолжу борьбу (сегодня приболел :( ). Помехоподавляющих цепей в цепи коммутации действительно нет. Дело в том что плата входит в состав тестового комплекса. Таких плат там 16. Предназначены они для коммутации трех проводов источников питания (гальванически развязанных) на любое количество каналов (до 800). Источников питания 2: +27V и переменное 115V. Общий провод у них соединен вместе. С "землей" комплекса в общем случае он не связан. При подключении комплекса к объекту контроля и коммутации двух проводов (+27V и общего 27V) на заданные каналы в объекте контроля клацает реле. Есть или нет в объекте контроля искрогасящая цепочка, не знаю, да и знать не хочу, ибо комплекс обязан нормально работать в любом случае. Но длина проводов от ИП до шины (платы) более метра, после платы до выходных разъемов еще прибл. метр и от разъемов до объекта контроля тоже около того, итого прибл. три метра. Индуктивность их, видимо, все это делает... И умножить на два провода!!! Наверное, в этом дело. Особая благодарность _Sam_ и Serjio за идею :cheers: Но мы еще не подключали 115V !!! Что будет, страшно подумать :( ...

Имеем плату, на которой установлены плисина, стабилизатор 3,3В для ее питания, драйвера реле на ULN2003 и куча реле. Плисина управляется с шины и ее регистры управляют реле через драйвера. Все это запитано от компьютерного источника +5В. Плата исправно работает, реле щелкают и все такое... Но только без нагрузки. Как только, например, коммутируются два провода (с помощью двух реле) источника питания 27В для коммутации внешнего реле (300 мА), на точках конденсатора по питанию +5В при помощи осциллографа наблюдается импульс помехи, просаживающей питание до 0. Это приводит, естественно, к сбросу регистров плисины. Источник 27В гальванически не связан с платой. Его + и - всего лишь коммутируются через контакты реле, установленных на плате. Я пытался увеличить емкость конденсатора до 1000 мкФ, но это помогает слабо. Вопрос даже не в том, что делать, а откуда это берется? По "воздуху" или через текстолит (+5В и коммутируемые цепи разведены с противоположных сторон платы)? Наводочка, так сказать. И кондером не давится? Ну и мощность у нее! Помогите, плис, кто чем мо... то есть кто что знает.

Посмотрите EDGE649, EDGE749 и т д . Восьмиканальный приемопередатчик. Ток если мне не изменяет склероз 125мА. Для увеличения нагр. спос. можно запараллелить несколько каналов. К сожалению, нижний предел около -3В :( Только жутко дорого это. А вот и они: http://www.semtech.com/products/products_l...18_A_LineID_E_4

Спасибо всем откликнувимся. Особо радует, что мысль моя развивается в правильном направлении. :)

В свое время я отказался от отмороженного схемного редактора из ISE и очень доволен. Недавно и рисовалка тестбенчей окончательно вывела меня из себя. Уважаемые плисоводы-гуру, нужен совет. Мне кажется, что сигналы можно описывать и на vhdl. А в этой рисовалке более-менее сложный файл создать практически невозможно. Является ли описание входных воздействий в текстовом виде общепринятой практикой или это мои капризы? Если да, то особо интересует вопрос: можно ли входной сигнал поставить в зависимость от выходного? Особо буду благодарен за какой-нибудь пример. :)

http://www.pcad.ru/forum/11160/ Советов давать не буду. Во-первых, он у меня один, во вторых вряд ли Вы ему последуете. Уж больно он радикальный :)

Спектра может разводить участки одной цепи проводниками разной ширины. Вариантов много. Например : rule class X (pin_width_taper up_down (max_length -1)) Эта команда позволит разводчику уменьшать(увеличивать) ширину проводника, принадлежащему классу Х при подходе к КП в зависимости от ширины КП с неограниченной длинной подхода (на усмотрение разводчика). А если: rule class X (pin_width_taper up_down (max_length 50)), то длина подключения ограничивается 50 милами (если проект в милах). Кроме того, возможна трассировка отрезками разной ширины если цепь, например принадлежит классу, а отрезок этой цепи группе (набор отрезков от-до), а для класса и группы задана разная ширина. Существуют также правила для классов, групп, отдельных цепей и т.д. на конкретном слое. Ну и про регионы не стоит забывать. Короче, вариантов тьма :) А вот насчет гемора согласен :)

Критичные цепи не обязательно разводить в первую очередь. Лучше развести хорошо в конце, чем плохо в начале. Из Ваших сообщений делаю вывод: разведенная вручную плата проигрывает разведенной в автомате при прочих равных условиях в плане наводок и задержек. При всем моем к Вам уважении :cheers: для меня это нонсенс. Видимо, мне еще долго нужно развиваться... :)

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

Давайте начнем с того, чего все чотят добиться - трассировки сравнимой с ручной. Вы говорите 'может получиться' - а вот получается ли? :) Лично я для этого делаю следующие вещи (опускаем подробности настройки правил связанных с технологией производства) 1. При расстановке элементов на плате в уме прикидываю, как будут проходить конкретные цепи и на основании этого объединяю их в классы. Если возникают сомнения в возможности разводки конкретного класса или цепи, развожу их вручную (абы как) вместе с "сомнительными" (мешающими) цепями (классами). Если разводка этих цепей действительно невозможна или возможна не так как я хочу, меняю размещение и (или) концепцию прокладки этих цепей. На практике разводить вручную для проверки возможности разводки мне приходится на 10-20 процентов от всей платы. В результате я конкретно знаю, как должны идти все трассы, сколько ПО будет на каждой трассе (целая туча трасс вообще не будет иметь ПО!!! - улавливаете?), на каких слоях будут идти те или иные цепи (классы). Опять же очень много трасс будут проходить на одном только слое. Далее описываю правила. Запрещаю использовать верхний слой для трасс, которые должны идти на нижнем и наоборот, запрещаю использования ПО в цепях, проходящих на двух слоях, но имеющие в своем составе штыревые выводы (если это согласуется с концепцией разводки), ограничиваю число ПО на трассу для конкретных классов (цепей) и т д. 2. Задаю последовательность трассировки (какой класс или цепь трассировать первой, какой второй и т д) Это сделать достаточно легко. Для этого я представляю, в каком порядке я бы это делал вручную. Если порядок описан полностью (обычно полностью сделать бывает лень :( ), запускаю трассировку и далее все зависит от трассировщика (не люблю трассировщики с преимущественным направлением слоев :angry2: ) Если трассировщик хороший, возникают мелкие проблемы. Например, некоторые трассы упорно не хотят идти по кратчайшему и более логичному пути, что приведет к невозможности трассировки следующих трасс. Останавливаю процесс, удаляю трассы, ставлю запреты (они не влияют на разводку в дальнейшем, ибо я давно уже знаю, как должны проходить проводники в оттрассированной плате :) и ставлю запреты в местах, где не должно быть будущих трасс. Если трассировщик плохой, возникают, соответственно, крупные проблемы вплоть до желания выкинуть его на помойку. Эта участь постигла спектру. Ее вообще невозможно заставить вести трассы так, как хочется. А ограничения, которые призваны помочь ей в этом, она просто игнорирует. Рискую быть заклеванным (уж больно все хвалят Expedition), но все же продолжу: с Expedition у меня в этом плане проблем было гораздо меньше чем со спектрой, но они все же были. Наилучшие результаты показал PADS2004 (BlazeRouter из более старой версии значительно хуже).Его практически не нужно уговаривать. 3. Запускаю оптимизацию. Все Надеюсь, Вы теперь понимаете, что при использовании fanout все вышеописанное рухнет и я не получу желаемых результатов. Зачем мне fanout там, где его быть не должно? Чтобы помешать нормальной разводке? В PADS2004 работаю недавно, сделал три платы, одна не поддалась полной (как ручной) разводке. Вторая простая как грабли, не было смысла заморачиваться. А третью развел в автомате, исключая цепи питания (этот ответственный момент предпочитаю делать вручную). Результат - плата не просто отдаленно напоминает разведенную вручную, она вообще ничем не отличается от ручной. Это была длинная предыстория :) А при использовании описанной Вами концепции я вообще не представляю , как можно получить отличные результаты. Хорошие - может быть иногда. Очень редко. Когда Вы все отдаете на откуп трассировщику (fanout, направление слоев, трассируете всю плату сразу - это все не для современных трассировщиков, к сожалению) Expedition хоть и не SPECCTRA, но все же не TopoR, который в лепешку расшибется, лишь бы развести Вам плату. Не стоит так нагружать Expedition, а то он впадет в ступор. Проверял это на плате, успешно оттрассированной в PADS2004. Хочется верить, что написано все это мной не зря. Может все же вы меня поймете :)

Я то конечно могу... А что, Вы разве не согласны? А я думал что Вы просто забыли про это сказать :( Для начала немного азов: "...команда fanout может быть использована только для ПП с количеством слоев от четырех и более. Для таких многослойных плат эта команда ускоряет работу автотрассировщика и способствует полной трассировке. Если же применить эту команду для плат с числом слоев менее четырех, потенциальное число позиций для ДСО уменьшается. А это может вызвать плохую трассировку платы." Ю.М. Елшин Справочное пособие по работе с подсистемой SPECCTRA От себя добавлю, что последствия использования fanout в вышеприведенной цитате несколько преуменьшены. <_< Если это Вас не убеждает, могу еще чего-нибудь по этому поводу написать :) ЗЫ Только не надо говорить, что мол Expedition не SPECCTRA, тут это не при чем :)

Fill, извините за ехидное замечание :) : Если плата двусторонняя, никогда не используйте проход fanout для всей платы !!!

Рисуем схемы в САПР-нету. Почему? Или нам схемы заказчики дают? А вот еще: Моделируем схемы в САПР - тоже неплохо было бы :) Ведь здесь не только разводчики собрались :)