Tiger

Добрый день Есть референс-дизайн от производителя, в нем есть плата. Хочется эти constrants для референса через экспорт-импорт втащить в нашу плату, поскольку очень уж их много. Экспортировал через Export->More->Techfile... Но увы - при попытке импорта Allegro 17.2 выдает ошибку без подробностей: **** ERROR: ERROR importing technology file. **** Technology file is likely corrupt. Select or generate a new technology file and try again. Пробовал почистить вручную файл от электрических constraint-ов (хоть их там быть не должно), ручками - но легче не стало. Также попробовал экспортировать из моей платы этот файл и его же втянуть обратно - все нормально. Сравнение двух файлов через Diff дает много отличий, наш, что втягивается, имеет размер 130кБ, а тот, что нужно - 260кБ. Полагаю, из-за того, что я многие constraints еще просто не задал. Что посоветуете? Хотфиксы, правда, не стоят пока

Да я бы с радостью, но мне его и домой-то не дают, не говоря уже о том, чтобы послать на сторону. Естественно, утянуть не проблема, но меня попросили не распространять дизайн за пределы локалки, и я пообещал этого не делать. Подскажите лучше, какой тулзой Вы для этого импорта пользуетесь :) Если маршрутом PCAD->Altium->Allegro, или PCAD->PADS->Allegro, то результаты такие же, просто геморроя с маппингом слоев меньше. Боюсь, конечно, но Герберы же сравнить можно легко из обоих САПРов, с Герберами сильно меньше вероятность что-то не заметить.

Обновление: Огромное спасибо всем за советы. Помогло, как бы это не казалось странным, загрузка проекта в PCAD 2002, как было указано в заголовке файла PCB. 69 ошибок всего осталось, и они мелкие. Проблема решена. *.net файла у меня нет, ну да 69 проводников уже легко ручками дорисовать. Вторая часть Мерлезонского балета - это попытка втянуть дизайн через PDIF в Аллегро. То есть втягивается-то нормально, но, поскольку в PDIF нет constraints, то не происходит и соединения с полигонами: дефолтная толщина цепи = 0, clearance = 0 и вместо connectivity получается куча ratsnest-ов и DRC ошибок в местах соединения полигонов с проводниками и отверстиями. Это вопрос уже, наверное, в Кейденсовскую конференцию.

Конечно приятнее, кто б спорил :) Втянуть в Аллегро я и сам втянул, через PDIF, но все равно спасибо! Там mapping файл для установки соответствий слоев ручками надо делать в процессе импорта, и именно ручками, поскольку если, например, полу-родным Altium-ом попытаться втянуть этот PDIF в автомате, он у меня все (ВСЕ!!!) контактные площадки на TOP переносит. Тем не менее, Altium нормально импортирует, но именно PCB, а не PDIF. Насчет функции Аллегро "довести трассы до центров площадок" - грехи, то бишь нарушенные дефолтные рулеса Аллегро не дают, они очень грубые. Вначале их надо поправить, а потом уже доразводить, иначе Аллегро посылает далеко посредством около 5000 DRC Errors. У меня, увы, нет сейчас дизайна под рукой, из которых я бы мог constraints импортом-экспортом втянуть в мою плату, завтра вот буду их долго ручками вбивать, пока DRC не заткнется. А потом и авто-доведу.

В том и дело, что нет его в Design Authoring, или, по крайней мере, я не знаю, как его оттуда вызвать... Если мы, конечно, говорим про один и тот же тул - Capture, опция при открытии - "Allegro Design Authoring - Capture CIS". В Cadence-Allegro спредшите в Capture, понятное дело, можно что угодно создать, кажется, даже Constraints для проводников платы, хотя сам не пробовал еще - только видео смотрел. Но неудобно это очень, нельзя работать с классами и пр., лучше уж сразу в Аллегро ограничения создавать.

Хм... Мне казалось более очевидным, что он встроен в Allegro Design Authoring (Schematic entry tool), по крайней, мере, это хоть было написано прямо, в отличие от догадок по презентации - там как раз прямо не написано. Но, поскольку я его вызвать из Allegro Design Authoring не могу, наверное, правы все-таки Вы :) В любом случае - спасибо!

Спасибо, приду завтра на работу и посмотрю. Дома у меня ни файлов дизайна, не PCAD 2006 нет, кстати, на работе мы это в PCAD2004 смотрели. В нем CompleteRouteToPadCenter, насколько я понимаю, нет. А CompleteRouteToPadCenter обращает внимание на DRC и constraints? Откуда он узнает, какой толщины дорожка должна до-роутиться? Берет уже имеющуюся? Ratsnest = резинки. Все мои знакомые их резинками называют :) Спасибо, попробую. Проблема, правда, что PCAD 2002 на Рутрекере нет, непонятно где брать. Ну да ладно, найду, в конце концов. Есть аналогичный дизайн от этого же субконтрактора, там в заголовке написано "P-CAD 2002 PCB V17.00.50, P-CAD 2002 PCB Binary (Rev 6)". Мне кажется, дело тут не в версии PCAD, а в том, что дюймовый дизайн открыли с установками в метрической системе. Но надо открывать и пробовать, конечно.

Здравствуйте Посмотрел Cadence Webinar про Constraint-driven Design и вдохновился идеей - вместо того, чтобы ставить свойства при редактировании группы цепей, сделать все сразу и по фэн-шуй. Однако, проблема - не могу найти "Constraints" в меню, как показано на вебинаре, чтобы вызвать СМ. Нет его просто в строке меню. Вроде версию продукта открываю правильную, как указано вот здесь: "Constraint Manager is available in Allegro Design Authoring (Schematic entry tool) with the ability to create net classes and defining rule sets, and mapping rule set in net classes." Но увы - в меню-кнопках ничего подходящего не вижу. Хотфиксы, правда, не накатил еще - м.б. дело в них?

Здравствуйте Есть плата в PCAD, не очень-то и простая (DDR2, PCIe - 20 страниц схематики итого). Мы ее получили от субконтрактора, который, в принципе, условия контракта выполнил (из этой платы можно сгенерить герберы и девайс работает), но проблемы в том, что там свыше 1000 проблем, которые сводятся к двум основным типам: 1. Не доведенные до конца цепи (примерно 0.01мм остаток), что дает кучу резинок 2. И stubs от контактных площадок у компонентов, такой же длины, что дает вторую половину кучи резинок. На Герберах, разумеется, этого всего не видно, поскольку резинки не выходят за пределы контактных площадок. Мы сейчас хотим эту плату изменить, но при таком количестве недоразведенных дорожек - и пытаться не стоит. Первопричина проблемы, полагаю, состоит в том, что плата роутилась в чем-то еще (схематика вообще сделана в Оркаде, синхронизироваться с ней через втягивание платы в Аллегро - отдельная задача), а потом ее затянули в PCAD, записали файл в формате PCAD и таким отдали нам. В процессе импорта, видимо, были указаны дюймы, которые милсы, а при импорте указали мм. Ну вот и получилось так. Раздолбайство это было обычное, или попытка поднять дополнительные деньги на саппорте - не важно сейчас. Еще одна проблема - constraints нет, от слова совсем, даже дифпары не указаны как дифпары, если не считать названия цепей N и P. Собственно, хочется спросить совета, что тут можно сделать (кроме очевидного - потребовать с субконтрактора промежуточные файлы со всего маршрута, но там будут свои проблемы). В голову приходит несколько вариантов: 1) Выкинуть его в Specctra и там доразвести автоматом - в смысле, написать do-файл, который проведет оставшиеся проводники 4mils до точки соединения и убьет незавершенные stubs короче тех же 4 mils. Минус - не умею я писать do-файлы и не знаю, можно ли так сделать вообще. 2) Втянуть во что-то более приличное (Altium, Allegro, PADS) через PDIF и доразвести там автоматом. Попробовал - плата после импорта была жестоко обругана DRC, а править существующие дефолтные рулеса, чтобы его заткнуть и предохранить при доразводке дифпары и length matching (constraints-то нет) от оптимизации - это, опять же, огромный геморрой. Понятно, делать-то это все равно потом придется, но как-то сразу не хочется вкладывать массу своего времени непонятно в какого качества дизайн. Что посоветуете? Я в Альтиуме-Аллегре больше работаю, может для PCAD есть какие-то стандартные решения...

Можете ссылку на пример такой сервомашинки привести? Я набрал в Гугле "сервомашинки" и стал смотреть изображения - там и близко нет того, что мне подходит: чтобы нажимала на все кнопки на фото, с силой 1 кг. У меня такие дома тоже валяются. Выше в этом треде есть фото с сервомашинкой, но это не то совсем.

У меня расположено все вот так, поэтому проблема в размере сервомашинок. При том, что экран должен быть виден. Поэтому и ищу маленькие, но сильные электромагниты.

Да, у меня примерно то же самое, но надо на все 6 кнопок нажимать, а не только на выключение :) И на некоторые - парой одновременно, чтобы войти в сервисный режим

Понятно, что проще взять и попробовать, но проблема в том, что посылка месяц идет. Я и так заказал позавчера три штуки разных на поиграться, это месяц доставки, плюс доставка выбранного типа - еще месяц. Итого - начало марта. С учетом того, что мне на заводе приспособления из металла за неделю делают, а иногда и быстрее - я уж не говорю про 3D печать из пластика - март это очень много. Я поэтому и спросил у тех, кто имел практику с подобными вещами, чтобы хоть один месяц из двух сэкономить. Теоретически-то я посчитать могу, в инете куча ссылок, но нужны диаметр провода, число витков, марка стали сердечника, чертеж основания катушки - вряд ли продавец по запросу все это отдаст незнакомому единоразовому покупателю, даже если бы имел, что маловероятно Спасибо за ссылку, там есть даже меньшего размера с большей тягой и ходом штока. Свяжусь с ними. Хотя, конечно, каникулы с 14 декабря до 8 января - это несколько напрягает :) По личному опыту работы с ними - сколько времени проходит от оплаты до отсылки и можно ли им просто денег на счет бросить? У меня отрицательный опыт работы с нашими заводами, если заходишь с улицы. Пока не найдешь там человека, которому можно позвонить, спросить и получить ответ - это хождение по мукам.

Добрый вечер Я делаю приспособление, которое нажимает на кнопки пленочной клавиатуры тестируемого прибора электромагнитами (через штоки, конечно). Прибор сертифицирован и все такое, в общем - вскрывать нельзя. Никак. Только жать кнопки извне. Суть в следующем. Мне нужно килограммовое усилие нажатия на кнопки, но выбранный мной электромагнит дает лишь половину от требуемого, а с учетом того, что он китайский - еще меньше: http://www.uxcell.com/24v-13a-2mm-stroke-0...t-p-254286.html Этот электромагнит имеет устраивающие меня размеры, другие магниты с бОльшим усилием просто не влезают в габариты - иначе придется делать составные штоки, с коленями, а это то еще геморрой. Их там 14 штук. На кнопку мне надо всего лишь нажать и подержать 0.2 сек - этого достаточно, чтобы отработал контроллер в приборе, определяющий нажатие клавиши, т.е. постоянно держать не надо. Отсюда возникает естественное желание увеличить ток, подав бОльшее напряжение на катушку, чтобы получить бОльшее усилие на штоке. Скажем, вместо 24 Вольт подать 36. Или 48. Ясное дело, что электромагнит сгореть не успеет, но есть ли в этом смысл? Поскольку я не спец в конструировании и производстве электромагнитов, хочется спросить у знающих людей: 1. Как обычно рассчитываются электромагниты при производстве? По принципу электродвигателей (номинальная мощность электродвигателя есть мощность, отдаваемая на вал при условии температуры корпуса не более 90С при температуре окружающей среды 20С) или как-то еще? Сопротивление изоляции на пробой вроде не должно влиять на таких напряжениях. 2. Есть ли опасность того, что сердечник войдет в насыщение при токе катушки чуть больше номинального и после этого ток хоть втрое увеличивай - сильнее тяги не будет, ну или разница будет измеряться единицами процентов? Или в сердечнике применяют сталь подешевле, у которой по проницаемости запас еще большой? У меня из примеров в голове только электромагнит магнитофона Маяк-232 (привет тем, кому за 40), на который вначале подавался 48 в импульс для срабатывания на большом расстоянии, а для постоянного удержания оставалось 12 - тот же самый принцип, что хочу применить у себя. С уважением, Николай

Добрый день Заказчику хочется получать чертеж кабелей с термоусадкой. Рисую 3D в Солиде, но, в принципе, перегнать-то сборку можно куда угодно. Суть в моделировании термоусадки. Loft, конечно, рулит, но времени на рисование профилей уходит куча, да и любые переделки ведут к тому, что вся уже сделанная работа летит в ведро. Кто нашел более быстрый способ моделирования термоусаженных трубок, поделитесь, пожалуйста. Собственно, проблема возникла, когда потребовалось обтянуть термоусадкой сборку с 6 проводами и врезанными в 2 провода резисторами, уже обтянутыми термоусадкой же.

Добрый вечер всем! Попал в ловушку: поскольку работаю и дома и в офисе, допустил ошибку, которую заметил только сейчас. Суть в том, что есть старый рабочий дизайн на 10 листов. На него я добавил 5 своих листов и зафиксировал RefDes-ы (Frozen Package = Fix). То есть думал, что зафиксировал - кинул схематику в версионный контроль, но это не SVN, а Git, что привнесло ньюансы - изменения остались на локальной машине, пошел домой и из дома подцепил предыдущую ревизию с сервака, на которой этих изменений еще не было (push, очевидно, сделать забыл). Дальше сделал новую ветку и изменения благополучно остались за кадром. Радость проявилась только теперь, когда я прилично поправил и базу, и старую схематику. Packager благополучно перепаковал все компоненты и ага - после Forward Annotation куча компонентов, среди которых и 440-ножечный разъем, поменялись местами на плате. Вполне логично, в общем - если раньше X1 был на 440 ног, а X2 - на 4, а стало наоборот, то Forward Annotation добросовестно ставит разъем с новым X1 на то самое место, где был старый X1, и получаем кучу резинок от разъема на новом месте к старой разводке :) Можно ли это как-то поправить, кроме как откатиться на старую версию и провести изменения заново, ручками? Например, сделать что-то типа Frozen Package на плате и контролировать Forward Annotation интерактивно, покомпонентно.

Упаковщик запускаю так: Интересная, хоть и очевидная, мысль, приведшая к неожиданным результатам. Даже обидно, что сам не додумался :) Ерунда какая-то получается... Нет его в диалоге. Более того, он же красным должен подсвечиваться вроде, после коррекции символа и Update Libraries. Не подсвечивается. Пошел дальше. Поставил Part на схему прямо из Databook, подправил символ - и тоже нет подсветки и диалога обновления. Вообще непонятно, где в реальности символ находится. То есть я-то знаю, Part сам создавал, а вот где, по мнению VX, должен лежать символ - загадка. Как ни меняй порядок Partition Search Paths для символов - нет изменений. Буду разбираться, теперь хоть понятно, куда рыть. Раньше-то я был убежден, что это схематика брыкается, а это, оказывается, библиотека. Жаль, что разделы (*.pdb) для Parts напрямую смотреть и править нельзя, не из библиотекаря. Хотя понимаю, целостность БД и все такое. Там много типов символов с такой ошибкой, около 30. Один символ ничего не решит :) Я разобраться хочу.

1. Раздел короткий (извиняюсь, обрезал лишнего - сейчас поправил, видно) 2. И случай, увы, мой - я обновляю, точнее, пытаюсь, импортированные символы, к тому же перенесенные из другой схематики, символами из моей ЦБ На скриншоте ниже приведены все, как мне кажется, обстоятельства проблемы, включая сообщение упаковщика об ошибке библиотеки на выбранный символ и отображение его в ЦБ вместе с Part: Я уже правда не знаю, что и думать...

А что подразумевалось под 1)? По текстовому поиску название символьного раздела с длинным именем не находится в каталоге с дизайном и в каталоге с ЦБ. Только в логах, где ругань на ее отсутствие. Алиасы - вряд ли, они должны где-то определяться, а в определении должно быть название раздела. М.б. в базе в сжатом виде лежат? Неужели нельзя просто взять и изменить с помощью какой-то утилиты текстовое название раздела в свойствах символа? Почему оно заблокировано? Для 2) проще переименовать оркадовскую схему в имя библиотеки, откуда взят символ для компонента в базе, импортировать, скопировать листы целиком и вуаля - нужное имя раздела автоматом засунуто в свойства символа. Я это сделал уже давно. Но проблема в том, что дизайн все равно не видит этого символа ни тем способом, что я описал, ни по Replace, которое описали Вы. Даже если заменить и Symbol и Part там - вместе или по отдельности, взятых из Databook. Возможно, корень проблемы кроется в невозможности обновления символа из библиотеки. Т.е. по Replace Symbol в Databook я могу хотя бы выбрать компонент на замену из списка, а по Update Symbol - увы: Почему так - не понятно.

Там МНОГО компонентов. Очень. И разных, увы. И с разным углом поворота в схематике. Так что лучше узнать, как надо по фэн-шуй - банально быстрее будет. А зачем там forward annotation? Я до платы еще не дошел, пакую компоненты пока что.

Добрый день Packager выдает вот такую ругань в преизрядном количестве при данных параметрах: Visit message location ERROR: Block Santaclara, Page 11 - On/Off Switch, Symbol $11I1517: Symbol: FR_DOCK_MOD_REV2_BELKIN_NO_MST_16P2_16_2:CAP_NP not found on Part Number: C0402C272K5RACTU in Parts DataBase. [Please add the symbol's definition in the PDB for this part or change the symbol in the schematic to use one that is referenced in the PDB for the part. Note that if there is a PIN_SET_NAME property on the symbol, its value becomes the effective symbol name for packaging.] Проблема в том, что нет у меня такого раздела в библиотеке символов. Совсем нет: И сам символ поставлен вот отсюда: Тем не менее: И убить/отредактировать это свойство нельзя, как видно из того же скриншота Как получилось - импортировал Оркадовскую схематику, для безопасности в чистый дизайн, и потом перенес целиком страницу из одного дизайна в другой. Точнее, не одну страницу, а пять, и на все элементы на этих страницах Packager ругается. Что пытался сделать: 1. В текстовом редакторе открыл "Generic.hkp" из папки проекта и заменил все "FR_DOCK_MOD_REV2_BELKIN_NO_MST_16P2_16_2" на "MY_LIB_16_2", откуда и были взяты символы при создании соответствующих Parts. Увы, ошибки те же. 2. Обновить символ в схематике. Нет библиотеки для обновления: Что можно попробовать: 1. Открыть в VX2, который уже кушает длинные названия библиотек. Увы, его у меня нет - только VX1.2. 2. Переименовать Оркадовскую схематику из "FR_DOCK_MOD_REV2_BELKIN_NO_MST_16P2_16_2" в "MY_LIB_16_2", импортировать и скопировать листы уже оттуда, с переустановленным свойством Partition. Останавливают две вещи: криво и необходимость снова менять свойства у компонентов (а их там много и разных) Что посоветуете?

Понял, просто уменьшил длину названия схематики в Оркаде - тоже получилось. Вот ведь... Спасибо огромное!

Спасибо большое, буду тогда смотреть у себя. Чтобы было проще отыскать источник проблемы - у Вас скриншот сделан с моего открытого проекта/базы в Менторе, или Вы провели импорт повторно в эту же/свою чистую базу? Спрашиваю, т.к. вижу различие между RefDes компонентов - у меня временные (см. мой скриншот), а у Вас RefDes уже перенесены. Ваша версия VX, сервиспаки?

Исходник в оригинале выложить не могу, увы - он под CNDA - но я удалил в нем все, кроме десятка простых элементов. Проблема осталась и воспроизводится в том, что получилось после удаления. А в локальных символах в Менторе вообще пусто, что, в принципе, закономерно - я же не ручками их ставил. В этот раз даже в разделе Symbols ЦБ ничего не видно на изображении символа. Выложил проект в Менторе 32-бит VX1.2 +ЦБ в LibTools VX1.2(свежесозданная с нуля, чтобы не пакостить в боевую базу)+исходники Оркада (в оригинале идет для Оркад 16.5, но из 16.5 Ментор не импортирует, поэтому проект перезаписан для 16.2 с символами _16_2 в конце имени файла, на всякий случай вложил оба исходника) Все лежит в одном архиве, по названиям каталогов понятно, что к чему относится. https://yadi.sk/d/6YYOkjLurE33x Заранее спасибо за уделенное мне время.

Не совсем так. На уровне символа в Оркаде они есть - я писал, что проверял. Могу прислать скриншот. Проблема в том, что я не могу поставить в другую схему Part из Part View - тот символ, что слинкован с футпринтом, вообще пустой, без ног и поэтому не ставится. И я его могу поставить только из Symbol View. Т.е. существуют три ипостаси (instance) символа после импорта, каждый из которых отличается от другого. На скриншоте два символа рядом: нижний - в схематике после импорта (выделение показывает, что номера ног в символе как-то присутствуют), верхний - поставленный из Symbol View. Третий, из Part View, не ставится вообще Вот так выглядит Part View: Ну и, разумеется, мысль поискать черные пины на черном фоне мне тоже пришла в голову. Увы. Там пусто.