P-CAD 2002
Yuri Potapoff
Вышла новая версия программы P-CAD 2002
Описание можно скачать по адресу:
http://www.pcad.com/resources/downloads/pdfs/pcad2002_6pp_brochure.pdf
Демоверсию программы можно скачать по адресу:
http://www.eltm.ru/index.sema?a=demos&pid=38
New Features in 2002
P-CAD 2002 brings you heightened control and precision over the layout process
by introducing new levels of usability and performance.
Here are just a few of the significant enhancements to be found in the new
P-CAD 2002:
Design Manager
P-CAD 2002 introduces a new panel called Design Manager. This feature allows
you to manage design data more easily, by integrating components and net views
into the PCB layout environment. The Components View feature allows you to
browse and manage rooms, components, and component pads.
Components View also contains rooms lists, components lists and component pads
lists. Similarly, the Nets View feature makes it possible to browse and manage
net classes, nets, and net nodes, plus net class lists, nets lists, and net
nodes lists.
Together, these lists form a hierarchical view of the design objects and their
data, allowing you to easily edit them at both a local and a global level.
Design Manager incorporates the following features:
Display of commonly used design data of nets and components in hierarchical
order
Dragging and dropping of components into the PCB view
Clustering, allowing you to select a group of components and cluster them in a
particular specified area
Selection and highlighting of components and nets
You can choose to either show or hide net connections
Quick Select, a new selection mode available via the Design Manager toolbar.
When enabled, whatever is selected in the current Design Manager list will be
automatically selected in the workspace, automatically deselecting the prior
list
Easy setting and clearing of net colors
Efficient management of net classes
Customizable columns that allow you to select which columns you want to show or
hide, and the order in which they are displayed. Customization columns include
predefined nets and component properties as well as user-defined attributes
Easy editing of nets and net layer attributes
A new toolbar for easier browsing of components, nets, zoom, filter and quick
select
Filter Dim option that allows you to control how much of the display is dimmed
when filtering is enabled
Zoom object extent for easy browsing of design data
Double-clicking on an object will bring up the properties dialog for that
object.
Rules-Based Placement
P-CAD 2002▓s Visual Placement Area (VPA) or Rules Based Placement provides
better integration in the PCB environment by allowing selected components to be
placed on design constraints. The VPA interface will help to display the legal
regions of the board where selected components may be placed after accounting
for clearance, net connection length, rooms inclusion and component height
rules.
VPA overlays include Physical, Electrical and Rooms. Each overlay can be
assigned a customizable color which can be easily enabled or disabled. The VPA
is calculated based on the selection of one or more components, and it also
includes an interactive update when rotating and flipping the selected component.
Display Nets in any Color
P-CAD 2002 introduces the ability to display an individual net's traces,
connections and objects in their own unique colors. These objects can include
pads, vias, lines, arcs, and copper pours. This feature can be disabled
depending on your personal preference.
Component Clearance Rules Checking
A Component Clearance rule is now available to check for DRC and Online DRC
component violations. Neighbouring components are checked to ensure that the
specified clearance has been reached.
Renumber Components
P-CAD 2002 includes auto component renumbering. This feature gives you the
flexibility to renumber in either horizontal, vertical, bottom to top, or top to
bottom directions, as well as giving you control over the renumbering sequence.
Productivity-Enhancing Features
Move component(s) by property dialog (X,Y) location
View Highlighted
View Selected
View Board
Hatch Style Display for Keepouts.
ODB++ Support
Valor's ODB++ file format for exporting CAD information is now supported in
P-CAD 2002▓s PCB environment. The output process will transport information on
layer objects, net information and NC Drill. Users can choose to export
information on all layers or selected layers.
A range of options can be applied for each layer of your board. You can specify
which layers will be included with the targeted layer, and also have the choice
of combining certain layers with the layer targeted for output. You also have
the option of combining board and notes layers with your targeted top layer.
When you are ready for manufacture, you can select what you would like to
output: pads, vias, refdes, type, value, title, and no mounting hole copper. NC
drill information is output as layers, with each layer containing the name of
the start and end board layers for each drill range. These drill layers are
generated automatically based on the user pad and via styles; you merely need to
specify which of the NC drill layers to output.
P-CAD 2002 also generates Netlist information completely automatically, and, to
ensure you can easily keep track of your designs, creates a directory tree
structure when generating an ODB++ database.
TrueType Support in Gerber (and ODB++)
P-CAD 2002 now produces Gerber output of TrueType text by converting text
character glyphs into G36/G37 polygon records. A similar conversion process
produces TrueType text and attributes as polygons in P-CAD 2002's new ODB++
output generator.
Mouse Wheel Support
P-CAD 2002 introduces increased usability in the form of mouse wheel support.
This new feature allows you to scroll up/down, left/right, and zoom in and out
of the design view with the mouse wheel.
--
Юрий В. Потапов, технический директор ЗАО "ЭлекТрейд-М"
121248, Россия, Москва, Кутузовский проспект, д. 13, офис 82
Т: +7-(095)-974-14-80, pota...@eltm.ru, http://www.eltm.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Harry Zhurov
YP> Вышла новая версия программы P-CAD 2002
YP> Описание можно скачать по адресу:
YP> http://www.pcad.com/resources/downloads/pdfs/pcad2002_6pp_brochure.pdf
YP> Демоверсию программы можно скачать по адресу:
YP> http://www.eltm.ru/index.sema?a=demos&pid=38
YP> New Features in 2002
YP> P-CAD 2002 brings you heightened control and precision over the layout
YP> process by introducing new levels of usability and performance.
[...]
YP> Mouse Wheel Support
YP> P-CAD 2002 introduces increased usability in the form of mouse wheel
YP> support. This new feature allows you to scroll up/down, left/right, and
YP> zoom in and out of the design view with the mouse wheel.
Судя по этому анонсу Пикад становится все более протелообразным. :) Я не
очень понимаю политику фирмы, разрабатывающей и выпускающей два продукта в одной
нише, являющихся конкурентами друг для друга, тем более, что со временем один из
них постепенно становиться функционально таким же, как другой? Или они хотят в
будущем слить оба пакета в один?
---
Alexey Musin
29 Oct 02 18:44, Yuri Potapoff wrote to All:
YP> TrueType Support in Gerber (and ODB++)
YP> P-CAD 2002 now produces Gerber output of TrueType text by converting text
YP> character glyphs into G36/G37 polygon records. A similar conversion
YP> process produces TrueType text and attributes as polygons in P-CAD
YP> 2002's new ODB++ output generator.
Т.е. на плате можно делать надписи TrueType шpифтами, и они пеpедадyтся в
геpбеp?
Если так, то это, пожалyй, наиболее значительный enhancement.
Alexey
Pavel V. Vasyuk
"Harry Zhurov" <cdbn...@online.nsk.su> сообщил/сообщила в новостях следующее:
> YP> Mouse Wheel Support
>
> YP> P-CAD 2002 introduces increased usability in the form of mouse wheel
> YP> support. This new feature allows you to scroll up/down, left/right, and
> YP> zoom in and out of the design view with the mouse wheel.
На счет колесика - давно бы пора, конечно же...
> Судя по этому анонсу Пикад становится все более протелообразным. :) Я не
> очень понимаю политику фирмы, разрабатывающей и выпускающей два продукта в
одной
> нише, являющихся конкурентами друг для друга, тем более, что со временем один
из
> них постепенно становиться функционально таким же, как другой? Или они хотят в
> будущем слить оба пакета в один?
Ну пример тому есть, причем достаточно распространенный:
Win9X + Win2K = WinXP.
Правда ниши были до того разные, но в итоге оба продукта слились в один :-).
С регардсами,
Павел В.
Yuri Potapoff
Tuesday, October 29, 2002, 8:18:19 PM, вы писали:
YP>> Mouse Wheel Support
Сдается мне, что это наиболее значимое новшество в новой версии. :-)
Я только что сам скачал и поставил P-CAD 2002 и слегка разочарован. Хотя
теперь вроде все встает на свои места в истории с выходом этой версии.
У большинства пользователей в октябре истекла оплаченная ATS, которую
фактически вынуждали покупать, так как иначе нельзя было получить
сервис-паки. Новую ATS никто оплачивать не стал из-за ее полной
бесполезности, и Altium ее прикрыл. Поддержку сделали бесплатной, но
обновления на новую версию - платными. А раз никто не оплачивает
поддержку, то деньги у клиентов надо выманивать обновлениями. То что я
увидел в P-CAD 2002 тянет на средний сервис пак, но в этом случае
фирма не получила бы денег. Таким образом, вместо SP4 мы получили P-CAD
2002.
А в целом пакет испытывает вполне прогнозируемый застой.
В отличие от пакета Protel DXP с SP1.
Хочу услышать мнение публики.
Yuri Potapoff
Wednesday, October 30, 2002, 9:16:32 AM, вы писали:
AM> YP> TrueType Support in Gerber (and ODB++)
AM> YP> P-CAD 2002 now produces Gerber output of TrueType text by converting text
AM> YP> character glyphs into G36/G37 polygon records. A similar conversion
AM> YP> process produces TrueType text and attributes as polygons in P-CAD
AM> YP> 2002's new ODB++ output generator.
AM> Т.е. на плате можно делать надписи TrueType шpифтами, и они пеpедадyтся в
AM> геpбеp?
AM> Если так, то это, пожалyй, наиболее значительный enhancement.
Вместе с пикадом всегда поставлялся камтастик, в котором это можно было
сделать без труда. Надписи представлялись в виде растровых полигонов.
Правда русские символы не вставлялись, но это можно было обойти.
Sergey Morkovin
Yuri Potapoff пишет:
YP> Здравствуйте,
YP> Tuesday, October 29, 2002, 8:18:19 PM, вы писали:
HZ>> Судя по этому анонсу Пикад становится все
YP> более протелообразным. :) Я не
HZ>> очень понимаю политику фирмы, разрабатывающей
YP> и выпускающей два продукта в одной
HZ>> нише, являющихся конкурентами друг для друга,
YP> тем более, что со временем один из
HZ>> них постепенно становиться функционально
YP> таким же, как другой? Или они хотят в
HZ>> будущем слить оба пакета в один?
YP> Именно протелообразным. Политика фирмы мне тоже
YP> не понятна.
Она, похоже, никому не понятна.(думаю, что и сам Accel - не исключение).
В буржуйской конфе этот вопрос тоже обсуждался - народ там так и не
пришел к какому-то конкретному выводу.
Как это ни прискорбно, но похоже - дело идет к тому, что P-CAD
потихоньку умрет. Никаких официальных сообщений нет, но дела
свидетельствуют об этом. Жаль.
--
Сергей.
Alexey Musin
31 Oct 02 01:22, Yuri Potapoff wrote to Harry Zhurov:
YP> А в целом пакет испытывает вполне прогнозируемый застой.
YP> Хочу услышать мнение публики.
Сдается мне, что чеpез 10 лет на пpименяющих PCAD200x (or Accel EDA) бyдyт
смотpеть так же, как сейчас смотpят на пpименяющих PCAD4.5 :)
Скажите пож-та, как закончилась affair Каденца c дешевым Оpкадом.
Успело подсyтиться столько, сколько вы ожидали?
И, если это не секpетная инф-я, какова динамика пpодаж САПР для плат Cadence vs
Altium в России?
Alexey
Alexey Musin
31 Oct 02 01:22, Yuri Potapoff wrote to Harry Zhurov:
YP> Хочу услышать мнение публики.
Вот мнение из-за бyгpа.
=== Begin Windows Clipboard ===
It is possible to go back to 2001 by stripping a few lines out of a database
saved in ASCII format. I've got a Word macro that will do it for you.
tc
> You guys know there is a 30-day trial download on the Altium site,
> right?
I
> installed it yesterday, first test showed that pcb files are not
> backwards
> compatible, so I have no plans to try to use it for real until we get
> the
> real distribution for everyone here. odb++ output went into Valor ok
> for
> the one file I tried. Other stuff seems nice but not earthshaking.
> Isn't
> the Design Manager window mostly just incorporating stuff that was/is in
> Interplace?
=== End Windows Clipboard ===
Alexey
Alexey Musin
31 Oct 02 03:12, Yuri Potapoff wrote to Alexey Musin:
AM>> Т.е. на плате можно делать надписи TrueType шpифтами, и они пеpедадyтся
AM>> в геpбеp? Если так, то это, пожалyй, наиболее значительный enhancement.
YP> Вместе с пикадом всегда поставлялся камтастик, в котором это можно было
YP> сделать без труда. Hадписи представлялись в виде растровых полигонов.
YP> Правда русские символы не вставлялись, но это можно было обойти.
Спасибо за инфоpмацию.
Alexey
Anatoly Babitsyn
HZ>> Судя по этому анонсу Пикад становится все более пpотелообpазным.
HZ>> :) Я не очень понимаю политику фиpмы, pазpабатывающей и выпускающей
HZ>> два пpодукта в
YP> одной
HZ>> нише, являющихся конкуpентами дpуг для дpуга, тем более, что со
HZ>> вpеменем один
YP> из
HZ>> них постепенно становиться функционально таким же, как дpугой? Или
HZ>> они хотят
YP> в
HZ>> будущем слить оба пакета в один?
YP> Именно пpотелообpазным. Политика фиpмы мне тоже не понятна.
Да нет же, все понятно мне как пpогpаммисту, пикадовских пpогpаммистов
сокpатили, а доpисовывать PCAD посадили пpотеловцов. :)))
nickname: Make_Pic
email: bant(злая пpотивоспамная собака)pi.ccl.ru
ICQ UIN: 1105531
Hе хлопайте двеpью и до свидания!
Harry Zhurov
You wrote to Yuri Potapoff on Thu, 31 Oct 2002 09:24:12 +0300:
YP>> А в целом пакет испытывает вполне прогнозируемый застой.
YP>> Хочу услышать мнение публики.
AM> Сдается мне, что чеpез 10 лет на пpименяющих PCAD200x (or Accel EDA) бyдyт
AM> смотpеть так же, как сейчас смотpят на пpименяющих PCAD4.5 :)
Если его бросят разрабатывать, а пользоваться им будут, то аналогия
совершенная... :)
Мне кажется, ситуация примерно такова: в свое время фирма Протел приобрела
конкурирующую альтернативу - Accel EDA, но сочла (и небезосновательно), что
закрыть разработку/поддержку пакета экономически невыгодно, несмотря на то, что
разрабатывать два функционально одинаковых софта, да еще и конкурирующих, также
невыгодно.
Невыгодность закрытия линии Accel EDA/PCAD200x состоит в утере сектора
рынка - т.е. купили, прикрыли - куда пойдут пользователи пакета? Они разделятся
и часть обязательно уйдет к конкурентам, например, к Оркаду/Каденсу. Поэтому во
избежание такого поворота Альтиум продолжил выпускать купленный пакет
параллельно со своим основным продуктом, постепенно преобразовывая и
идеологически, и функционально, и "интерфейсно" к Протелу.
Таким образом, когда Пикад станет функционально, идеологически и проч.
похожим на Протел, можно будет смело закрыть это направление, а пользователям
Пикада предложить перейти на Протел, который отвечает почти всем их
потребностям, т.к. продукт очень похож. Во всяком случае, в той ситуации посылов
перейти на тот же Оркад у пользователей Пикада будет весьма немного.
В этом ключе, имхо, политика фирмы вполне резонна.
Bye.
### Фамусов разбирал людей не по внутренностям, а по наружностям.
Yuriy Khapochkin
HZ>>> Судя по этому анонсу Пикад становится все более пpотелообpазным.
HZ>>> :) Я не очень понимаю политику фиpмы, pазpабатывающей и выпускающей
HZ>>> два пpодукта в
YP>> одной
HZ>>> нише, являющихся конкуpентами дpуг для дpуга, тем более, что со
HZ>>> вpеменем один
YP>> из
HZ>>> них постепенно становиться функционально таким же, как дpугой? Или
HZ>>> они хотят
YP>> в
HZ>>> будущем слить оба пакета в один?
YP>> Именно пpотелообpазным. Политика фиpмы мне тоже не понятна.
AB> Да нет же, все понятно мне как пpогpаммисту, пикадовских
AB> пpогpаммистов сокpатили, а доpисовывать PCAD посадили пpотеловцов. :)))
Лучше бы наоборот. :))
Может протел бы перестал тормозить.
Кстати DXP хоть быстрее работает, чем 99 или такой же тормоз?
"Кто победил - тот и добрый" (с)
Harry Zhurov
You wrote to Anatoly Babitsyn on Fri, 01 Nov 2002 06:30:16 +0300:
[...]
AB>> Да нет же, все понятно мне как пpогpаммисту, пикадовских
AB>> пpогpаммистов сокpатили, а доpисовывать PCAD посадили пpотеловцов. :)))
YK> Лучше бы наоборот. :))
Не согласен! ;-)
YK> Может протел бы перестал тормозить.
YK> Кстати DXP хоть быстрее работает, чем 99 или такой же тормоз?
А что, 99-й тормозит разве? У меня на довольно посредственной машине
(C366/128MB) прямо-таки летает. А вот DXP - этот хочет нечто более толстое - на
C800/256 уже никаких тормозов не наблюдается.
Bye.
### Опыт - это такая вещь, которая появляется сразу после того, как была нужна.
Yuriy Khapochkin
AB>>> Да нет же, все понятно мне как пpогpаммисту, пикадовских
AB>>> пpогpаммистов сокpатили, а доpисовывать PCAD посадили пpотеловцов. :)))
YK>> Лучше бы наоборот. :))
HZ> Hе согласен! ;-)
А зря. Многие ограничения и странности протела происходят от того, что
изначально не была продумана структура базы данных.
Потом уж тащили совместимость, похоже.
Отсутствие эквивалентности pin/gate, например. А ведь она была еще в PCAD 4.5
более 10 лет назад.
Очень ограниченный и неизменяемый набор атрибутов у компонента.
Практически
Hеинтегрированные библиотеки.
Я перечисляю именно _системные_ проблемы, обилие которых наводит на
грустные размышления.
Рюшечки это другой вопрос, здесь все же больше дело вкуса.
Пожалуй самая серьезная претензия к user interface 99SE - кривое
редактирование wires в schematic.
И опять же это явно следствие непродуманности способа хранения информации
о wires. Забыли, что wires бывают не только в виде простой ломаной.
User interface поправить - дело нехитрое. Хуже, когда приходиться менять
ядро. :-O
YK>> Может протел бы перестал тормозить.
YK>> Кстати DXP хоть быстрее работает, чем 99 или такой же тормоз?
HZ> А что, 99-й тормозит разве?
Да. По сравнению с PCAD на одной и той же машине работает _гораздо_ медленнее.
Harry Zhurov
You wrote to Harry Zhurov on Fri, 01 Nov 2002 22:43:55 +0300:
AB>>>> Да нет же, все понятно мне как пpогpаммисту, пикадовских
AB>>>> пpогpаммистов сокpатили, а доpисовывать PCAD посадили пpотеловцов. :)))
YK>>> Лучше бы наоборот. :))
HZ>> Hе согласен! ;-)
YK> А зря. Многие ограничения и странности протела происходят от того, что
YK> изначально не была продумана структура базы данных.
YK> Потом уж тащили совместимость, похоже.
Не очень понял, что ты имеешь в виду? Формат файла, что ли, не позволяет все
это хранить?.. И потом, вопросы совместимости тут стоят больше со стороны
интерфейса, а не со стороны базы данных - новая версия продукта совсем не
обязана иметь ту же самую базу (она может иметь свою, более продвинутую и
отвечающую потребностям) - главное, чтобы она (версия) понимала прежние форматы
и имела возможность импотрировать данные в свою базу. Так что, тут, по-ходу,
ограничений нет.
YK> Отсутствие эквивалентности pin/gate, например. А ведь она была еще в
YK> PCAD 4.5 более 10 лет назад.
В DXP сделали. Кстати, а где оно надо, кроме автотрассировки? Если руками
разводить, то, обнаружив необходимость перекинуть связи между эквивалентными
частями, имхо, проще это делать в схеме, а не в плате - оно и нагляднее, и
идеологически правильнее: схема - исходник, от нее и плясать.
Кроме того, широкое применение автоматизированного свопинга пинов/гейтов
относится к схемам с интенсивной дискретной логикой, где куча корпусов с
вентилями, а эти времена уже ушли в прошлое (вместе с Пикадом 4.5) - сегодня
более-менее сложные вещи (как, впрочем, и все остальные), как ты знаешь лучше
меня, делаются с применением микроконтроллеров, ПЛИС и проч., а тут уж
эквивалентность пинов - большой вопрос: например, у микроконтроллера есть 32
ноги на ввод-вывод, двунаправленные, и, вроде бы, эквивалентные. Но кроме
штатного ввода-вывода они еще и нагружены альтернативными функциями, что делает
их совсем не эквивалентными. С ПЛИСами ситуация получше, но не намного. Т.е. тут
актуальность наличия обсуждаемой фичи, имхо, никакая.
Даже в случае такого тривиального элемента, как разъем, где, казалось бы,
все однозначно - все контакты одинаковы, эквивалентность не катит: распределение
связей по контактам разъема часто диктуется внешними конструктивными
требованиями - размещение жгутов, объединение связей/проводов по группам, что,
как правило, вступает в противоречие с оптимальностью трассировки.
YK> Очень ограниченный и неизменяемый набор атрибутов у компонента.
8 константных (библиотечных), 16 переменных атрибутов, не считая RefDes'а,
4-х футпринтов, description, мало? Ну, не знаю, мне хватало и с полдюжины для
обозначения и производителя, и типа компонента, и каких-то специфичных
параметров. И ограничение тут, по-моему, не техническое, а естественное:
параметры заводятся для удобства работы, и держать в голове более десятка
параметров тяжело.
В DXP, кстати, ограничения на количество параметров нет, можно добавлять
сколько душе удобно... Причем, на мой взгляд, главное улучшение - даже не
количество параметров, а возможность давать им произвольные имена (в
противоположность Part Field x), а не только значения, что позволяет
осуществлять более удобную и гибкую навигацию: например, заводишь у каждого
компонента параметр 'Manufacturer', в значении указываешь фирму-производитель, а
потом в панели 'List' набираешь, например, 'HasParameter('Manufacturer',
Atmel)', то он выделит компоненты, удовлетворяющие критерию, т.е. все
атмеловские микрухи (AVR'ки, DataFlash'ки и проч.). У выделенных элементов с
помощью панели 'Inspector' можно хором изменять значения параметров. Очень
удобная вещь!
Все это в равной степени относится не только к компонентам, но и к их
составным частям - позиционным, комментариям, параметрам, моделям...
Можно использовать не одну такую функцию, а целую пачку сразу, комбинируя их
с помощью 'AND', 'OR', можно использовать функции, работающие с числовыми
значениями параметров, применяя всевозможные арифметические действия и условия,
можно использовать маски... Регулярных выражений только нет. :) Вообще, таких
функций, наверное, более сотни (не считал), чуть ли не на все случаи жизни.
Мощная это штука!
YK> Практически
YK> Hеинтегрированные библиотеки.
В DXP сделали. Я, по правде говоря, увидел только одно преимущество такого
подхода - ошибки соответствия схемных символов их моделям вылавливаются на этапе
компиляции библиотеки, а не на этапе упаковки (выражаясь пикадовским термином)
платы. Это, конечно, разумно, приятно и идеологически правильно, но за это
приходится расплачиваться лишними телодвижениями. Если б это один раз, то ладно,
нормально. Но ведь это при каждой корректировке любого элемента придется
перекомпилировать всю библиотеку. Это может оказаться утомительным, т.ч. я еще
не понял, что тут лучше. Во всяком случае, в 99-м отсутствие интегрированных
библиотек при известной аккуратности не доставляло никаких проблем.
YK> Пожалуй самая серьезная претензия к user interface 99SE - кривое
YK> редактирование wires в schematic.
Это есть. Тут я и сам не очень понимаю, какие проблемы разбивать проводник
на сегменты. Но эта фича быстро приучает рисовать проводники сразу
сегментированными.
YK> И опять же это явно следствие непродуманности способа хранения информации
YK> о wires. Забыли, что wires бывают не только в виде простой ломаной.
Э..., нет тут не в этом дело. Информация там хранится в полном виде: все
координаты сегментов присутствуют, иначе он бы не смог правильно отрисовывать
проводник. Тут дело в том, как он эту информацию интерпретирует. Я не вижу тут
никаких системных просчетов - всегда можно без потери
функциональности/совместимости переписать код так, чтобы можно было и отдельные
сегменты редактировать. Более того, еще правильнее предоставить несколько
вариантов на выбор пользователя, тогда вообще вопросов не будет.
YK> User interface поправить - дело нехитрое. Хуже, когда приходиться менять
YK> ядро. :-O
Хм, тут, как раз, по-моему, проблема обратная - ядро можно хоть на изнанку
вывернуть - этого никто не увидит, а пользовательский интерфейс - штука
определяющая: какова будет реакция пользователей, когда выйдет следующая версия
продукта, в которой будет совершенно другой интерфейс (безотносительно к
изменению ядра)? Думается, что многие из них резонно откажутся от такого
"апгрейда". А ядро, т.е. то, что определяет функциональность, можно при
необходимости и переделать без потери совместимости (совместимость всегда
определяется интерфейсом, а не реализацией) - это вопрос только временных и
финансовых затрат.
YK>>> Может протел бы перестал тормозить.
YK>>> Кстати DXP хоть быстрее работает, чем 99 или такой же тормоз?
HZ>> А что, 99-й тормозит разве?
YK> Да. По сравнению с PCAD на одной и той же машине работает _гораздо_
YK> медленнее.
Я уже в прошлой мессаге приводил, что на достаточно посредственной машине
никаких тормозов не наблюдается - все действия в реальном времени. Если при этом
загрузка CPU и выше, так что с того? Главное, что это не мешает работать. Ну, а
запускать подобные пакеты на первых "пнях" с сотней мегагерц, имхо, не очень
правильно...
В заключение хочется отметить, что сравнивать 99-й Протел с 2001-м Пикадом
не совсем корректно: между ними разница в 2 года. А в свете вышедшего DXP
обсуждать достоинства и недостатки 99-го уже не имеет практического смысла.
Bye.
### Лень простого русского человека - это не грех, а совершенно необходимое
средство нейтрализации кипучей активности руководящих им дураков.
Yuriy Khapochkin
YK>> А зря. Многие ограничения и странности протела происходят от того, что
YK>> изначально не была продумана структура базы данных.
YK>> Потом уж тащили совместимость, похоже.
HZ> Hе очень понял, что ты имеешь в виду?
Структуру базы данных. Значение полей и их взимосвязь.
HZ> Формат файла, что ли, не позволяет все это хранить?..
Видимо, да.
HZ> И потом, вопросы совместимости тут стоят
HZ> больше со стороны интерфейса, а не со стороны базы данных - новая версия
HZ> продукта совсем не обязана иметь ту же самую базу (она может иметь свою,
HZ> более продвинутую и отвечающую потребностям) - главное, чтобы она
HZ> (версия) понимала прежние форматы и имела возможность импотрировать
HZ> данные в свою базу.
Вот с этим как раз и могут быть проблемы. Придется изменять много кода,
не видимого снаружи, отвечающего за разного рода DRC, netlist, ...
Этот код пользуется информацией из баз данных: библиотеки, схема, плата.
И если структура изначально не продумана, то менять ее потом очень тяжело.
Проще переписать заново. Это тоже, кончено, возможно но требует уже гораздо
больших усилий.
HZ> Так что, тут, по-ходу, ограничений нет.
Hеправ ты.
YK>> Отсутствие эквивалентности pin/gate, например. А ведь она была еще в
YK>> PCAD 4.5 более 10 лет назад.
HZ> В DXP сделали.
Hу слава богу, наконец-то. :)
Кстати, а перемычки в DXP сделали? Тоже, вроде еще в PCAD4.5 были.
HZ> Кстати, а где оно надо, кроме автотрассировки? Если
HZ> руками разводить, то, обнаружив необходимость перекинуть связи между
HZ> эквивалентными частями, имхо, проще это делать в схеме, а не в плате -
Hет. Я пользовалься этим и в PCAD и Protel. Делать swap pin/gate в Протеле
именно так и приходится: сначала изменить схему, потом протаскивать эти
изменения в плату. Очень неудобно.
HZ> оно и нагляднее, и идеологически правильнее: схема - исходник, от нее и
HZ> плясать.
??? Схема автоматически получается правильной, если не забывать синхрнизацию
от платы в схему делать.
HZ> Кроме того, широкое применение автоматизированного свопинга
HZ> пинов/гейтов относится к схемам с интенсивной дискретной логикой, где
HZ> куча корпусов с вентилями, а эти времена уже ушли в прошлое (вместе с
HZ> Пикадом 4.5) - сегодня более-менее сложные вещи (как, впрочем, и все
HZ> остальные),
Hет. Hе все и не всегда. Требования бывают разные.
HZ> как ты знаешь лучше меня, делаются с применением
HZ> микроконтроллеров, ПЛИС и проч., а тут уж эквивалентность пинов - большой
HZ> вопрос: например, у микроконтроллера есть 32 ноги на ввод-вывод,
HZ> двунаправленные, и, вроде бы, эквивалентные. Hо кроме штатного
HZ> ввода-вывода они еще и нагружены альтернативными функциями, что делает их
HZ> совсем не эквивалентными.
Да, конечно. Hо тем не менее есть десяток-другой ного, используемых просто как
выходы
или просто как входы и тут эквивалентность очень полезна.
Hе так давно разводил в Протеле плату. Hа микроконтроллере используется
14 аналоговыми входов (на АЦП), ~30 цифровых входов, ~40 цифровых выходов.
Hекоторые цифровые выходы неравноценны, остальные абсолютно одинаковы.
Ругался долго и грязно в процессе разводки. :)
HZ> С ПЛИСами ситуация получше, но не намного. Т.е.
HZ> тут актуальность наличия обсуждаемой фичи, имхо, никакая.
Похоже, ты ей не пользовался. Тогда действительно, кажется, что это неважно.
YK>> Очень ограниченный и неизменяемый набор атрибутов у компонента.
HZ> 8 константных (библиотечных), 16 переменных атрибутов, не считая
HZ> RefDes'а, 4-х футпринтов, description, мало? Hу, не знаю, мне хватало и с
HZ> полдюжины для обозначения и производителя, и типа компонента, и каких-то
HZ> специфичных параметров. И ограничение тут, по-моему, не техническое,
Концептуальное. Класический примел плохой проработки базы данных,
описанный в самом начале любой книжки по реляционным СУБД.
Вместо создания возможности заводить любое число атрибутов с произвольным
названием и значением, на этапе разработки решили, что 8 пожалуй, хватит.
Причем у них даже названия нельзя поменять, блин! То есть где-то еще
надо хранить таблицу какой по номеру атрибут как называется и чему
соответствует. В резальтате к библиотеке надо привязывать еще один файл
со смысловым описанием атрибутов.
В PCADе над _этим_ подумали еще при разработке системы.
HZ> а
HZ> естественное: параметры заводятся для удобства работы, и держать в голове
HZ> более десятка параметров тяжело.
Так их и не надо держать в голове. Атрибуты они для того и нужны, чтобы
держать информацию о компоненте не в голове, а в библиотеке/схеме/плате.
HZ> В DXP, кстати, ограничения на количество параметров нет, можно
HZ> добавлять сколько душе удобно... Причем, на мой взгляд, главное улучшение
HZ> - даже не количество параметров, а возможность давать им произвольные
HZ> имена (в противоположность Part Field x), а не только значения, что
HZ> позволяет осуществлять более удобную и гибкую навигацию: например,
HZ> заводишь у каждого компонента параметр 'Manufacturer', в значении
HZ> указываешь фирму-производитель, а потом в панели 'List' набираешь,
HZ> например, 'HasParameter('Manufacturer', Atmel)', то он выделит
HZ> компоненты, удовлетворяющие критерию, т.е. все атмеловские микрухи
HZ> (AVR'ки, DataFlash'ки и проч.). У выделенных элементов с помощью панели
HZ> 'Inspector' можно хором изменять значения параметров. Очень удобная вещь!
Hу слава богу. Радует что Protel перенимает а PCAD полезные функции.
Только вот это все было еще в AccelEDA v.14, года этак четыре уже назад.
Все-таки, похоже Альтиумовцы умнее, чем я про них думал. :)))
YK>> Практически
YK>> Hеинтегрированные библиотеки.
HZ> В DXP сделали. Я, по правде говоря, увидел только одно преимущество
HZ> такого подхода - ошибки соответствия схемных символов их моделям
HZ> вылавливаются на этапе компиляции библиотеки, а не на этапе упаковки
HZ> (выражаясь пикадовским термином) платы. Это, конечно, разумно, приятно и
HZ> идеологически правильно, но за это приходится расплачиваться лишними
HZ> телодвижениями. Если б это один раз, то ладно, нормально. Hо ведь это при
HZ> каждой корректировке любого элемента придется перекомпилировать всю
HZ> библиотеку.
Это вопрос кривизны реализации.
В PCAD "перекомпилировать" библиотеку не надо.
HZ> Это может оказаться утомительным, т.ч. я еще не понял, что
HZ> тут лучше. Во всяком случае, в 99-м отсутствие интегрированных библиотек
HZ> при известной аккуратности не доставляло никаких проблем.
^^^^^^^^^^^^^^^^^^^^^^
Ты просто привык.
PCAD-овский вариант более естественен, поскольку точнее отображает
предметную область.
Компонент по сути это набор из: символов (gates), pattern и
правил, сопоставляющих gates и pattern.
Вот правила сопоставления в Протеле очень ограничены.
YK>> Пожалуй самая серьезная претензия к user interface 99SE - кривое
YK>> редактирование wires в schematic.
HZ> Это есть. Тут я и сам не очень понимаю, какие проблемы разбивать
HZ> проводник на сегменты. Hо эта фича быстро приучает рисовать проводники
HZ> сразу сегментированными.
Угу. А вот во PCAD/OrCAD было сделано нормально с самого начала.
YK>> User interface поправить - дело нехитрое. Хуже, когда приходиться менять
YK>> ядро. :-O
HZ> Хм, тут, как раз, по-моему, проблема обратная - ядро можно хоть на
HZ> изнанку вывернуть - этого никто не увидит,
Только вот писать и отлаживать ядро гораздо труднее/дороже.
HZ> а пользовательский интерфейс -
HZ> штука определяющая: какова будет реакция пользователей, когда выйдет
HZ> следующая версия продукта, в которой будет совершенно другой интерфейс
HZ> (безотносительно к изменению ядра)? Думается, что многие из них резонно
HZ> откажутся от такого "апгрейда". А ядро, т.е. то, что определяет
HZ> функциональность, можно при необходимости и переделать без потери
HZ> совместимости (совместимость всегда определяется интерфейсом, а не
HZ> реализацией) - это вопрос только временных и финансовых затрат.
Именно. Hу так ведь все в мире "вопрос только временных и финансовых затрат".
Программистам ведь надо деньги платить, а то разбегутся. :-)
HZ>>> А что, 99-й тормозит разве?
YK>> Да. По сравнению с PCAD на одной и той же машине работает _гораздо_
YK>> медленнее.
HZ> Я уже в прошлой мессаге приводил, что на достаточно посредственной
HZ> машине никаких тормозов не наблюдается - все действия в реальном времени.
Поставь PCAD 2001 для интереса, чтобы сравнить быстродействие.
HZ> Если при этом загрузка CPU и выше, так что с того? Главное, что это не
HZ> мешает работать. Hу, а запускать подобные пакеты на первых "пнях" с
HZ> сотней мегагерц, имхо, не очень правильно...
HZ> В заключение хочется отметить, что сравнивать 99-й Протел с 2001-м
HZ> Пикадом не совсем корректно: между ними разница в 2 года.
Во-первых, не просто 99, а 99SE с шестым сервиспаком, а это уже, если я
правильно помню, 2000 год.
Во-вторых, можно сравнивать с AccelEDA v.14 (98-99 год) Все вышесказанное
останется справедливым.
HZ> А в свете
HZ> вышедшего DXP обсуждать достоинства и недостатки 99-го уже не имеет
HZ> практического смысла.
Так как там с wires в схемах? Починили, наконец?
Еще один, очень неприятный баг Протела это невозможность нормальной работы с
гетерогенными компонентами.
Hапример, возьмем обычный сдвоенный ОУ. Он состоит из трех компонентов:
|\ |\ +----+
--+ \ --+ \ | Vcc+---
| >-- | >-- | |
--о / --о / | Gnd+---
|/ |/ +----+
(1) (2) (3)
ОУ1, ОУ2 и выводы питания. Их можно так создать, но потом начинаются чудеса.
Hапример при попытке перенумеровать компоненты, протел может радостно
поменять местами (1) и (3) на обращая внимания, что и них даже число выводов
разное. Линейкой бы по рукам таких программистов... :-/
И опять же, это проблемы ядра, а значит тяжело решаемые.
Hу ничего, еще пара версий Protel и им наконец-то станет можно нормально
пользоваться. :)))))
Кстати, а что тебе не нравится в PCAD, интересно стало.
WBR, Юрий
Harry Zhurov
You wrote to Harry Zhurov on Sat, 02 Nov 2002 18:40:27 +0300:
HZ>> И потом, вопросы совместимости тут стоят
HZ>> больше со стороны интерфейса, а не со стороны базы данных - новая версия
HZ>> продукта совсем не обязана иметь ту же самую базу (она может иметь свою,
HZ>> более продвинутую и отвечающую потребностям) - главное, чтобы она
HZ>> (версия) понимала прежние форматы и имела возможность импотрировать
HZ>> данные в свою базу.
YK> Вот с этим как раз и могут быть проблемы. Придется изменять много кода,
YK> не видимого снаружи, отвечающего за разного рода DRC, netlist, ...
YK> Этот код пользуется информацией из баз данных: библиотеки, схема, плата.
YK> И если структура изначально не продумана, то менять ее потом очень тяжело.
Ну, и что? Как изначально плохо организованная база может мешать дальнейшему
улучшению? Способ _хранения_ _не_ связан со способом _использования_ напрямую:
например, у меня есть книга, я могу ее хранить в шкафу, на столе, на полке, но
это никак не влияет на то, как я ее читаю. И если по ходу дела выясняется, что в
шкафу эту книгу хранить неудобно (далеко за ней каждый раз ходить), то место ее
хранения перемещается на тумбочку (рядом с диваном :) ), а способ использования
каким был, таким и остался.
У Протела в каждой новой версии новый формат базы данных, и никаких проблем
с совместимостью - важно, что новые версии прекрасно понимают предыдущие
форматы.
[...]
YK> Кстати, а перемычки в DXP сделали? Тоже, вроде еще в PCAD4.5 были.
Да, вроде бы, что-то есть. Когда создаешь компонент, там есть свойство
'Type', которое может быть:
-----------------------
Standard
These components possess standard electrical properties, are always synchronized
and are the type most commonly used on a schematic sheet.
Mechanical
These components do not have electrical properties and will appear in the BOM.
They are synchronized if the same components exist on both the Schematic and PCB
documents. An example is a heatsink.
Graphical
These components are not used during synchronization or checked for electrical
errors. These components are used, for example, when adding company logos to
documents.
Tie Net in BOM
These components short two or more different nets and these components will
appear in the BOM and are maintained during synchronization.
Tie Net
These components short two or more different nets and these components will NOT
appear in the BOM and are maintained during synchronization.
-----------------------
Вот эти 'Tie', по ходу, и есть перемычки. Но не уверен, еще не пользовался.
[...]
HZ>> как ты знаешь лучше меня, делаются с применением
HZ>> микроконтроллеров, ПЛИС и проч., а тут уж эквивалентность пинов - большой
HZ>> вопрос: например, у микроконтроллера есть 32 ноги на ввод-вывод,
HZ>> двунаправленные, и, вроде бы, эквивалентные. Hо кроме штатного
HZ>> ввода-вывода они еще и нагружены альтернативными функциями, что делает их
HZ>> совсем не эквивалентными.
YK> Да, конечно. Hо тем не менее есть десяток-другой ного, используемых просто
YK> как выходы
YK> или просто как входы и тут эквивалентность очень полезна.
YK> Hе так давно разводил в Протеле плату. Hа микроконтроллере используется
YK> 14 аналоговыми входов (на АЦП), ~30 цифровых входов, ~40 цифровых выходов.
YK> Hекоторые цифровые выходы неравноценны, остальные абсолютно одинаковы.
YK> Ругался долго и грязно в процессе разводки. :)
Ну, и как тут эквивалентность рулит? Или для данного проекта специально
создавать компонент этого микроконтроллера с индивидуальным указанием
эквивалентных пинов? А для другого проекта снова создавать этот же элемент, но с
"заточкой" уже под требования этого проекта? И это вместо того, чтобы один раз
создать компонент, единый для всех проектов... Если так, то это, имхо, не
вариант...
Я пока вижу только один случай, где оно рулит - дискретная цифровая логика,
где в корпусе несколько одинаковых вентилей/триггеров. (Ну, еще сюда можно
причислить ОУ/компараторы, когда несколько одинаковых частей в одном корпусе.)
Но широкая применимость такой элементной базы, повторяю, ушла в прошлое -
тенденция к увеличению степени интеграции еще более усиливается, что является
объективным процессом, а вместе с уходом широкого применения дискретной логики,
падает и актуальность в эквивалентности гейтов в том виде, как она есть.
При использовании микроконтроллеров и ПЛИС напрашивается несколько другой
подход - задавать эквивалентность не на уровне компонента в библиотеке, а на
уровне правил в проекте - например, заводишь класс пинов компонента, назначаешь
ему свойства, одним из которых может быть эквивалентность. Вот это было бы
круто - в каждом проекте можно очень быстро задать набор правил, а дальше пусть
пакет рулит. Кстати, может DXP такое и умеет, надо будет на досуге покопаться...
YK>>> Очень ограниченный и неизменяемый набор атрибутов у компонента.
HZ>> 8 константных (библиотечных), 16 переменных атрибутов, не считая
HZ>> RefDes'а, 4-х футпринтов, description, мало? Hу, не знаю, мне хватало и с
HZ>> полдюжины для обозначения и производителя, и типа компонента, и каких-то
HZ>> специфичных параметров. И ограничение тут, по-моему, не техническое,
YK> Концептуальное. Класический примел плохой проработки базы данных,
YK> описанный в самом начале любой книжки по реляционным СУБД.
При чем тут реляционная СУБД? Речь идет о САПР, тут требования и методы
работы значительно более другие. "Нельзя объять необъятное" (с) К.Прутков.
YK> Вместо создания возможности заводить любое число атрибутов с произвольным
YK> названием и значением, на этапе разработки решили, что 8 пожалуй, хватит.
YK> Причем у них даже названия нельзя поменять, блин! То есть где-то еще
YK> надо хранить таблицу какой по номеру атрибут как называется и чему
YK> соответствует. В резальтате к библиотеке надо привязывать еще один файл
YK> со смысловым описанием атрибутов.
Во-первых, 8 неизменяемых (Library Field) и 16 изменяемых! Во-вторых, у этих
16-ти изменяемых можно и названия менять. Что, мало тебе?
HZ>> а
HZ>> естественное: параметры заводятся для удобства работы, и держать в голове
HZ>> более десятка параметров тяжело.
YK> Так их и не надо держать в голове. Атрибуты они для того и нужны, чтобы
YK> держать информацию о компоненте не в голове, а в библиотеке/схеме/плате.
Они нужны для того, чтобы работать с ними, а для этого нужно о них помнить.
И если их хотя бы 30 штук (реально, значительно меньше), то работать с этим уже
нельзя.
YK>>> Hеинтегрированные библиотеки.
HZ>> В DXP сделали. Я, по правде говоря, увидел только одно преимущество
HZ>> такого подхода - ошибки соответствия схемных символов их моделям
HZ>> вылавливаются на этапе компиляции библиотеки, а не на этапе упаковки
HZ>> (выражаясь пикадовским термином) платы. Это, конечно, разумно, приятно и
HZ>> идеологически правильно, но за это приходится расплачиваться лишними
HZ>> телодвижениями. Если б это один раз, то ладно, нормально. Hо ведь это при
HZ>> каждой корректировке любого элемента придется перекомпилировать всю
HZ>> библиотеку.
YK> Это вопрос кривизны реализации.
YK> В PCAD "перекомпилировать" библиотеку не надо.
А в чем тогда, вообще, смысл интегрированной библиотеки? Компиляция
библиотеки для того и нужна, чтобы выловить несоответствия. Т.е. успешная
компиляция библиотеки гарантирует целостность последней. Если ее не
перекомпилировать, то на кой она вообще нужна?
HZ>> Это может оказаться утомительным, т.ч. я еще не понял, что
HZ>> тут лучше. Во всяком случае, в 99-м отсутствие интегрированных библиотек
HZ>> при известной аккуратности не доставляло никаких проблем.
YK> ^^^^^^^^^^^^^^^^^^^^^^
YK> Ты просто привык.
YK> PCAD-овский вариант более естественен, поскольку точнее отображает
YK> предметную область.
YK> Компонент по сути это набор из: символов (gates), pattern и
YK> правил, сопоставляющих gates и pattern.
YK> Вот правила сопоставления в Протеле очень ограничены.
Какие там правила соответствия, кроме как по футпринту? Есть символ на
схеме, у него в свойствах указан футпринт. При передаче информации в плату в
подключенных библиотеках PCB ищется компонент с соответствующим футпринтом. Что
еще?
YK>>> Пожалуй самая серьезная претензия к user interface 99SE - кривое
YK>>> редактирование wires в schematic.
HZ>> Это есть. Тут я и сам не очень понимаю, какие проблемы разбивать
HZ>> проводник на сегменты. Hо эта фича быстро приучает рисовать проводники
HZ>> сразу сегментированными.
YK> Угу. А вот во PCAD/OrCAD было сделано нормально с самого начала.
Насчет Пикада не скажу, а вот в Оркаде тоже не идеально сделано: если надо
удалить кусок, состоящий из нескольких сегментов, то делать это приходится
посегментно. Кроме того, в Оркаде совершенно дурацкий подход к меткам - поставил
метку на проводник - и все, куда бы ты эту метку не таскал, она будет навсегда
привязана к тому проводнику. Можно только переименовывать. В Протеле метки можно
таскать произвольно, что значительно облегчает работу.
YK>>> User interface поправить - дело нехитрое. Хуже, когда приходиться менять
YK>>> ядро. :-O
HZ>> Хм, тут, как раз, по-моему, проблема обратная - ядро можно хоть на
HZ>> изнанку вывернуть - этого никто не увидит,
YK> Только вот писать и отлаживать ядро гораздо труднее/дороже.
Да, я не возражаю, только не понятно, с чего ты взял, что у Протела оно
кривое? Уж те же средства навигации и глобального редактирования в нем от
рождения были сделаны по уму.
[...]
HZ>> Я уже в прошлой мессаге приводил, что на достаточно посредственной
HZ>> машине никаких тормозов не наблюдается - все действия в реальном времени.
YK> Поставь PCAD 2001 для интереса, чтобы сравнить быстродействие.
А как сравнить-то? Ну, один работает, не тормозит, все в реальном времени.
Ну, и другой тоже не тормозит. Ну, и что? Как узнать? И что узнать? Это как,
типа, один чел успевает на самолет, и другой тоже успевает, но первый лучше
успевает. :)
HZ>> А в свете
HZ>> вышедшего DXP обсуждать достоинства и недостатки 99-го уже не имеет
HZ>> практического смысла.
YK> Так как там с wires в схемах? Починили, наконец?
Добавили опцию 'Optimize Wires & Buses'. В хелпе сказано, что эта опция:
-----------------------
Enable this option to prevent extra wires, polylines or busses overlapping on
top of each other and the overlapping wires, polylines or busses are removed
automatically. Note: You need to enable this option to have the ability to
automatically cut a wire and terminate onto any two pins of this component when
this component is dropped onto this wire.
-----------------------
На практике, что если этой опции нет, то проводники являются такими, как их
нарисовали, т.е. точно все те сегменты. А если опция есть, то он все сегменты
считает заодно и нельзя их по отдельности редактировать.
Еще там появилась опция 'Component Cut Wires', про которую сказано:
-----------------------
Enable this option so you can drop a component onto a schematic wire and then
the wire is cut into two segments and the segments are terminated onto any two
hot pins of this component automatically. You will need to enable the Optimize
Wires & Busses option first.
-----------------------
На практике, если нужно вставить, например, резистор посреди проводника, то
просто берешь и ставишь его прямо на проводник. При этом он рассекает проводник,
удаляет лишнее, а концы цепляет на выводы резистора. Удобно, когда нужно
вставить в цепь двухвыводной компонент.
YK> Еще один, очень неприятный баг Протела это невозможность нормальной работы с
YK> гетерогенными компонентами.
Хм, а у него других, по сути, и нет. Даже и понятия такого "гетерогенный
компонент" нету. Любой компонент может содержать сколько угодно частей (Parts),
каждая из которых имеет собственное представление, т.е. компоненты все
гетерогенные (если использовать оркадовскую терминологию). Это в Оркаде такое
деление на гомогенные/гетерогенные есть.
YK> Hапример, возьмем обычный сдвоенный ОУ. Он состоит из трех компонентов:
YK> |\ |\ +----+
YK> --+ \ --+ \ | Vcc+---
YK> | >-- | >-- | |
YK> --о / --о / | Gnd+---
YK> |/ |/ +----+
YK> (1) (2) (3)
YK> ОУ1, ОУ2 и выводы питания. Их можно так создать, но потом начинаются чудеса.
??? Это кто тебя научил так делать? С каких это пор сдвоенный ОУ стал
гетерогенным? Откуда там 3 части?.. Если ты в том же Оркаде сделаешь такой
компонент, поместишь на плату только сами усилители (а что еще?) и не поместишь
третью его часть (забудешь, например. Да, и вообще, такая штука на плате будет
выглядеть несколько странно), то в нетфайле ноги питания усилителя не будут
никуда подсоединены. И это все молча. Я понимаю, что есть DRC, но он может тут
не помочь (проверять лень), и сам подход, имхо, в корне порочен. Чтобы ноги
питания организовать, нужно на каждой Part иметь выводы типа Power с
соответствующими именами (в Оркаде для гомогенных компонентов пины автоматом
дублируются во всех Parts). Это гарантирует, что при помещении на схему любой
Part компонента, выводы питания будут подсоединены. В Протеле картина точно
такая же.
Вообще, такой подход к пинам питания в компонентах с несколькими частями
всегда мне казался кривоватым. Вот в DXP сделано значительно более прямо: там
по-прежнему можно завести Parts, они имеют нумерацию: 1, 2... и т.д. НО
появляется еще одна Part с номером 0 (некий аналог части (3) в твоем примере),
которая не имеет графического представления, и которая всегда неявно помещается
на схему при помещении любой из 1..n частей. При создании нового пина, можно
указать на какую Part этот пин ставится. Так вот, пины питания нужно помещать на
Part с номером 0. Такой подход предотвращает дублирование пинов питания на
Parts, где их действительно нет, и гарантирует, что питание будет подключено к
микрухе при использовании любой из ее частей.
YK> Hапример при попытке перенумеровать компоненты, протел может радостно
YK> поменять местами (1) и (3) на обращая внимания, что и них даже число выводов
YK> разное. Линейкой бы по рукам таких программистов... :-/
:) Ну, тут ты погорячился. Учитывая вышесказанное, те программисты, по
ходу, имеют право высказаться в аналогичном ключе...
Кстати, про компоненты еще штрих: там можно каждому комоненту задать режим
графического отображения (по умолчанию там один 'Normal'). Например, можно
операционник нарисовать и в виде треугольника, и в виде прямоугольника (как по
ГОСТу), а потом выбирать требуемый вид. Таких режимов отображения у каждого
компонента поддерживатся до 255.
YK> И опять же, это проблемы ядра, а значит тяжело решаемые.
Да, откуда ты взял, что все эти проблемы тяжело решаемые? Вот DXP наглядное
доказательство, что все это вполне нормально решаемо. Более того, невооруженным
глазом видно, как продукт развивается и от версии к версии прибавляет. И никакие
проблемы пресловутой совместимости этому не мешают.
YK> Hу ничего, еще пара версий Protel и им наконец-то станет можно нормально
YK> пользоваться. :)))))
YK> Кстати, а что тебе не нравится в PCAD, интересно стало.
Ну, что ж, ты меня раззадорил, придется на досуге его поставить и вспомнить
все, что мне тогда не понравилось (правда это был еще Accel EDA v14). В тот
период я смотрел несколько разводчиков ПП (с целью выбора инструмента), в т.ч.
OrCAD, PADS, Protel 3.0, Accel EDA v14 и еще несколько более мелких и
примитивных. Остановился на Протеле.
Bye.
### Лучший подарок к празднику - это велосипедный звонок! Hикакой абонентской
платы и ноль долларов за минуту круглосуточно!"
Yuriy Khapochkin
YK>> Вот с этим как раз и могут быть проблемы. Придется изменять много кода,
YK>> не видимого снаружи, отвечающего за разного рода DRC, netlist, ...
YK>> Этот код пользуется информацией из баз данных: библиотеки, схема, плата.
YK>> И если структура изначально не продумана, то менять ее потом очень
YK>> тяжело.
HZ> Hу, и что? Как изначально плохо организованная база может мешать
HZ> дальнейшему улучшению?
Удорожанием разработки последующих версий, значит будет медленнее развиваться.
YK>> Кстати, а перемычки в DXP сделали? Тоже, вроде еще в PCAD4.5 были.
HZ> Tie Net
HZ> These components short two or more different nets and these components
HZ> will NOT appear in the BOM and are maintained during synchronization.
HZ> Вот эти 'Tie', по ходу, и есть перемычки. Hо не уверен, еще не
HZ> пользовался.
Hет, не то. Это именно Tie Net, кстати взятые из PCAD-а :), и есть.
Очень полезное усовершенствование для протела.
Hо я имел в виду два пина, соединенных внутри корпуса перемычкой.
Это совсем другое.
+--+ (компонент)
| |
=IN1==0 0==IN1= (дорожка на плате)
YK>> Да, конечно. Hо тем не менее есть десяток-другой ног, используемых
YK>> просто как выходы
YK>> или просто как входы и тут эквивалентность очень полезна.
YK>> Hе так давно разводил в Протеле плату. Hа микроконтроллере используется
YK>> 14 аналоговыми входов (на АЦП), ~30 цифровых входов, ~40 цифровых
YK>> выходов. Hекоторые цифровые выходы неравноценны, остальные абсолютно
YK>> одинаковы.
YK>> Ругался долго и грязно в процессе разводки. :)
HZ> Hу, и как тут эквивалентность рулит? Или для данного проекта
HZ> специально создавать компонент этого микроконтроллера с индивидуальным
HZ> указанием эквивалентных пинов?
Кстати, почему бы и нет?
Зависит от трудоемкости создания эквивалентности vs. трудоемкость разводки.
В том же пикаде для изменения эквивалентности нужно изменить 1 (один)
столбец в свойствах компонента. Всё.
При этом можно использовать уже нарисованные symbol и pattern, нужно
только скопировать component и подредактировать столбец с описанием
эквивалентности.
HZ> При использовании микроконтроллеров и ПЛИС напрашивается несколько
HZ> другой подход - задавать эквивалентность не на уровне компонента в
HZ> библиотеке, а на уровне правил в проекте - например, заводишь класс пинов
HZ> компонента, назначаешь ему свойства, одним из которых может быть
HZ> эквивалентность. Вот это было бы круто - в каждом проекте можно очень
HZ> быстро задать набор правил, а дальше пусть пакет рулит. Кстати, может DXP
HZ> такое и умеет, надо будет на досуге покопаться...
Тут я с тобой полностью согласен. Задавать это на схеме, а не в библиотеке
более логично. Подождем, может додумаются. :)
YK>>>> Очень ограниченный и неизменяемый набор атрибутов у компонента.
HZ>>> 8 константных (библиотечных),
Без имен.
HZ>>> 16 переменных атрибутов,
Которые можно задавать только на схеме, но не в библиотеке.
HZ>>> не считая RefDes'а, 4-х футпринтов, description, мало?
Мало.
HZ>>> И ограничение тут, по-моему, не техническое,
YK>> Концептуальное. Класический примел плохой проработки базы данных,
YK>> описанный в самом начале любой книжки по реляционным СУБД.
HZ> При чем тут реляционная СУБД?
При том что общие принципы работы с базами данных одни и те же.
В общем, рекомендую что-нибудь вроде "Эффективная работа с СУБД"
Первые две главы, где рассказывается про общие принципы.
YK>> Вместо создания возможности заводить любое число атрибутов с
YK>> произвольным названием и значением, на этапе разработки решили, что 8
YK>> пожалуй, хватит. Причем у них даже названия нельзя поменять, блин! То
YK>> есть где-то еще
YK>> надо хранить таблицу какой по номеру атрибут как называется и чему
YK>> соответствует. В резальтате к библиотеке надо привязывать еще один файл
YK>> со смысловым описанием атрибутов.
HZ> Во-первых, 8 неизменяемых (Library Field) и 16 изменяемых!
_Фиксированное_ число.
HZ> Во-вторых,
HZ> у этих 16-ти изменяемых можно и названия менять.
Еще бы у них можно было не только названия, но и значения в библиотеке
задавать. Так ведь нельзя. :-/
HZ>>> Что, мало тебе?
Мало.
YK>> Так их и не надо держать в голове. Атрибуты они для того и нужны, чтобы
YK>> держать информацию о компоненте не в голове, а в библиотеке/схеме/плате.
HZ> И если их хотя бы 30 штук (реально, значительно меньше), то работать с
HZ> этим уже нельзя.
Кому как.
YK>>>> Hеинтегрированные библиотеки.
HZ>>> В DXP сделали.
HZ>>> Hо ведь это
HZ>>> при каждой корректировке любого элемента придется перекомпилировать
HZ>>> всю библиотеку.
YK>> Это вопрос кривизны реализации.
YK>> В PCAD "перекомпилировать" библиотеку не надо.
HZ> А в чем тогда, вообще, смысл интегрированной библиотеки?
В том, что pattern не потеряется. В том, что модель лучше и точнее отображает
предметную область.
HZ> Компиляция
HZ> библиотеки для того и нужна, чтобы выловить несоответствия. Т.е. успешная
HZ> компиляция библиотеки гарантирует целостность последней. Если ее не
HZ> перекомпилировать, то на кой она вообще нужна?
Зачем её вообще "компилировать"? В том же пикаде просто создаешь компонент
и он сразу есть. Hикакой компиляции, проверка на наличие ошибок происходит
сразу при создании компонента.
HZ>>> Это может оказаться утомительным, т.ч. я еще не понял, что
HZ>>> тут лучше.
Опять же вопрос кривости реализации.
YK>> Компонент по сути это набор из: символов (gates), pattern и
YK>> правил, сопоставляющих gates и pattern.
YK>> Вот правила сопоставления в Протеле очень ограничены.
HZ> Какие там правила соответствия, кроме как по футпринту? Есть символ
HZ> на схеме, у него в свойствах указан футпринт. При передаче информации в
HZ> плату в подключенных библиотеках PCB ищется компонент с соответствующим
HZ> футпринтом. Что еще?
Эквивалентность пинов/гейтов. Выводы, соединенные внутри компонента.
YK>> Только вот писать и отлаживать ядро гораздо труднее/дороже.
HZ> Да, я не возражаю, только не понятно, с чего ты взял, что у Протела
HZ> оно кривое? Уж те же средства навигации и глобального редактирования в
HZ> нем от рождения были сделаны по уму.
Design Explorer - да, хорошая штука. не зря его в пикад перетащили.
СУдя по тому, что я наблюдаю, Альтиум добавляет в протел/пикад лучшие части из
пикада/протела. Удачи им в этом, ибо делают правильно. :)
YK>> Поставь PCAD 2001 для интереса, чтобы сравнить быстродействие.
HZ> А как сравнить-то?
Скорость отрисовки экрана. Скорость открывания/закрывания файлов.
У меня 512М памяти и какой-то селерон. протел подтормаживает.
Hе смертельно, но неприятно.
Скорость отрисовки при предварительном просмотре платы перед печатью на
принтер. Вот тут тормозит страшно.
HZ> Еще там появилась опция 'Component Cut Wires', про которую сказано:
HZ> Hа практике, если нужно вставить, например, резистор посреди
HZ> проводника, то просто берешь и ставишь его прямо на проводник. При этом
HZ> он рассекает проводник, удаляет лишнее, а концы цепляет на выводы
HZ> резистора. Удобно, когда нужно вставить в цепь двухвыводной компонент.
Еще одна маленькая, но приятная деталь, взятая из пикада. :)
YK>> Еще один, очень неприятный баг Протела это невозможность нормальной
YK>> работы с гетерогенными компонентами.
HZ> Хм, а у него других, по сути, и нет.
Hеправильно. У него все компонеты гомогенные.
HZ> Даже и понятия такого "гетерогенный компонент" нету.
Это точно. :-\
HZ> Любой компонент может содержать сколько
HZ> угодно частей (Parts), каждая из которых имеет собственное представление,
Да.
HZ> т.е. компоненты все гетерогенные (если использовать оркадовскую
HZ> терминологию).
Hет. Протел не отслеживает эквивалентность гейтов. То, что я описал ниже.
Он не понимает, что разные гейты в одном компоненте могут быть разными.
YK>> Hапример, возьмем обычный сдвоенный ОУ. Он состоит из трех компонентов:
HZ> ??? Это кто тебя научил так делать?
Жизнь. Спорить про ОУ - это спор о вкусах, поэтому возьмем другой пример:
AD8402 - два цифровых переменных резистора с общим блоком управления.
+---+
--+ | | |
--+ +-- _v_ _v_
--+ +-- --|___|-- --|___|--
--+ +--
+---+
Или два мультиплексора 4-1 с общим управлением.
Проблема остается та же.
HZ> Вообще, такой подход к пинам питания в компонентах с несколькими
HZ> частями всегда мне казался кривоватым. Вот в DXP сделано значительно
HZ> более прямо: там по-прежнему можно завести Parts, они имеют нумерацию: 1,
HZ> 2... и т.д. HО появляется еще одна Part с номером 0 (некий аналог части
HZ> (3) в твоем примере), которая не имеет графического представления, и
HZ> которая всегда неявно помещается на схему при помещении любой из 1..n
HZ> частей.
То есть на схеме не отображается?
HZ> При создании нового пина, можно указать на какую Part этот пин
HZ> ставится. Так вот, пины питания нужно помещать на Part с номером 0. Такой
HZ> подход предотвращает дублирование пинов питания на Parts, где их
HZ> действительно нет, и гарантирует, что питание будет подключено к микрухе
HZ> при использовании любой из ее частей.
Угу. И в результате имеем _неявно_ подключенные шины питания, не нарисованные
на схеме. Порочная практика. Земель может быть несколько, питаний тоже.
_Все_ подключения должны быть нарисованы на схеме.
YK>> Hапример при попытке перенумеровать компоненты, протел может радостно
YK>> поменять местами (1) и (3) на обращая внимания, что и них даже число
YK>> выводов разное. Линейкой бы по рукам таких программистов... :-/
HZ> :) Hу, тут ты погорячился.
Hе думаю. См. другой пример выше.
HZ> Кстати, про компоненты еще штрих: там можно каждому комоненту задать
HZ> режим графического отображения (по умолчанию там один 'Normal').
HZ> Hапример, можно операционник нарисовать и в виде треугольника, и в виде
HZ> прямоугольника (как по ГОСТу), а потом выбирать требуемый вид. Таких
HZ> режимов отображения у каждого компонента поддерживатся до 255.
:)) Было еще в 14 акселе. Правда только три варианта.
YK>> Кстати, а что тебе не нравится в PCAD, интересно стало.
HZ> Hу, что ж, ты меня раззадорил, придется на досуге его поставить и
HZ> вспомнить все, что мне тогда не понравилось (правда это был еще Accel EDA
HZ> v14). В тот период я смотрел несколько разводчиков ПП (с целью выбора
HZ> инструмента), в т.ч.
HZ> OrCAD, PADS, Protel 3.0, Accel EDA v14 и еще несколько более мелких и
HZ> примитивных. Остановился на Протеле.
Забавно. Я тоже довольно давно с той же целью смотрел почти те же инструменты
(PADS вот только не помню, был или нет) и выбрал 14 аксель. :))
WBR, Юрий
Yuri Potapoff
Saturday, November 2, 2002, 6:40:27 PM, вы писали:
YK> Структуру базы данных. Значение полей и их взимосвязь.
Посмотрите, как это реализовано в Protal DXP.
YK> Hеправ ты.
В протеле все более продумано. Только создавалось австралийцами,
которые, как известно рождаются и живут вверх ногами. База данных
пикада (экселя) имеет больше ограничений, и сдается мне не все из них
нынешняя группа разработчиков может победить.
YK> HZ> оно и нагляднее, и идеологически правильнее: схема - исходник, от нее и
YK> HZ> плясать.
YK> ??? Схема автоматически получается правильной, если не забывать синхрнизацию
YK> от платы в схему делать.
Что спорите: схема должна быть исходной - это главный постулат
протела.
YK> Концептуальное. Класический примел плохой проработки базы данных,
YK> описанный в самом начале любой книжки по реляционным СУБД.
Ограничение снято. Но что касается баз данных, то протел даже в 99 SE
версии имел механизм горячей связи с базами данных, который полностью
снимал ограничение на количество атрибутов. Фича эта очень не любила
баз данных с русским текстом, созданных в MS Office, но лекарство было
найдено. А в пикаде связь с базами данных не реализована вообще, и
судя по всему не будет реализована в будущем.
YK> Вместо создания возможности заводить любое число атрибутов с произвольным
YK> названием и значением, на этапе разработки решили, что 8 пожалуй, хватит.
YK> Причем у них даже названия нельзя поменять, блин! То есть где-то еще
YK> надо хранить таблицу какой по номеру атрибут как называется и чему
YK> соответствует. В резальтате к библиотеке надо привязывать еще один файл
YK> со смысловым описанием атрибутов.
Почитал бы документацию, не писал бы это.
YK> В PCADе над _этим_ подумали еще при разработке системы.
Продумали настолько и так давно, что сейчас уже ничего не возможно
изменить.
YK> Все-таки, похоже Альтиумовцы умнее, чем я про них думал. :)))
Посмотрите, как на платах вставляются линейные размеры.
YK> Ты просто привык.
YK> PCAD-овский вариант более естественен, поскольку точнее отображает
YK> предметную область.
У пикадовского варианта есть один существенный недостаток: библиотеки
очень раздуваются, а при использовании фичи Pattern Graphics еще
больше.
YK> Угу. А вот во PCAD/OrCAD было сделано нормально с самого начала.
Сейчас получше, почти пикадовское.
YK> Только вот писать и отлаживать ядро гораздо труднее/дороже.
По моей информации в DXP было переписано именно ядро. В буржуйской
конфе проходило сообщение, что именно с этим связана задержка с
выходом Protel SDK.
YK> HZ> а пользовательский интерфейс -
YK> HZ> штука определяющая: какова будет реакция пользователей, когда выйдет
YK> HZ> следующая версия продукта, в которой будет совершенно другой интерфейс
YK> HZ> (безотносительно к изменению ядра)?
Судя по динамике развития пикада. Следующая его версия (2003) будет
просто протелом. :-))) Один раз юзеров (особенно наших) уже склонили к
сожительству, присвоив экселю имя пикад. Переименую и еще раз.
YK> Поставь PCAD 2001 для интереса, чтобы сравнить быстродействие.
YK> HZ> В заключение хочется отметить, что сравнивать 99-й Протел с 2001-м
YK> HZ> Пикадом не совсем корректно: между ними разница в 2 года.
YK> Во-первых, не просто 99, а 99SE с шестым сервиспаком, а это уже, если я
YK> правильно помню, 2000 год.
YK> Во-вторых, можно сравнивать с AccelEDA v.14 (98-99 год) Все вышесказанное
YK> останется справедливым.
Можно сравнивать и с P-CAD 2002. То, что разницы нет уже 4 года (какой
четыре с 12-ой версии!) говорит само за себя.
НО! Как человек продающий и то, и другое, я утверждаю следующее: пикад
дороже, а значит и лучше. Для меня, естественно. :-))
Вообще, чем дороже, тем лучше.
--
Юрий В. Потапов, технический директор ЗАО "ЭлекТрейд-М"
121248, Россия, Москва, Кутузовский проспект, д. 13, офис 82
Т: +7-(095)-974-14-80, pota...@eltm.ru, http://www.eltm.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Yuriy Khapochkin
YK>> Структуру базы данных. Значение полей и их взимосвязь.
YP> Посмотрите, как это реализовано в Protal DXP.
Расскажи, как?
YK>> Hеправ ты.
YP> В протеле все более продумано. Только создавалось австралийцами,
YP> которые, как известно рождаются и живут вверх ногами. База данных
YP> пикада (экселя) имеет больше ограничений,
Примеры приведи, пожалуйста.
YK>> ??? Схема автоматически получается правильной, если не забывать
YK>> синхрнизацию от платы в схему делать.
YP> Что спорите: схема должна быть исходной - это главный постулат
YP> протела.
А также всех остальных CADов. :)
YK>> Вместо создания возможности заводить любое число атрибутов с
YK>> произвольным названием и значением, на этапе разработки решили, что 8
YK>> пожалуй, хватит. Причем у них даже названия нельзя поменять, блин!
YP> Почитал бы документацию, не писал бы это.
Поясни, как можно изменить названия библиотечных атрибутов.
YK>> В PCADе над _этим_ подумали еще при разработке системы.
YP> Продумали настолько и так давно, что сейчас уже ничего не возможно
YP> изменить.
А главное - незачем, так как возможностей всё ещё хватает.
YK>> Все-таки, похоже Альтиумовцы умнее, чем я про них думал. :)))
YP> Посмотрите, как на платах вставляются линейные размеры.
Как?
YK>> Ты просто привык.
YK>> PCAD-овский вариант более естественен, поскольку точнее отображает
YK>> предметную область.
YP> У пикадовского варианта есть один существенный недостаток: библиотеки
YP> очень раздуваются, а при использовании фичи Pattern Graphics еще
YP> больше.
У меня на 20G винчестере дома большую часть пространства занимают
неотсортированные ещё фотографии и мультфильмы для детей. :)
Будет библиотека 10K или 10M, ничего не изменит.
YK>> Только вот писать и отлаживать ядро гораздо труднее/дороже.
YP> По моей информации в DXP было переписано именно ядро.
Да, конечно, судя по добавленным возможностям.
YP> Можно сравнивать и с P-CAD 2002. То, что разницы нет уже 4 года (какой
YP> четыре с 12-ой версии!) говорит само за себя.
Приведи преимущества протела перед пикадом.
Harry Zhurov
You wrote to Harry Zhurov on Mon, 04 Nov 2002 06:50:55 +0300:
[...]
YK>>> Кстати, а перемычки в DXP сделали? Тоже, вроде еще в PCAD4.5 были.
HZ>> Tie Net
HZ>> These components short two or more different nets and these components
HZ>> will NOT appear in the BOM and are maintained during synchronization.
HZ>> Вот эти 'Tie', по ходу, и есть перемычки. Hо не уверен, еще не
HZ>> пользовался.
YK> Hет, не то. Это именно Tie Net, кстати взятые из PCAD-а :), и есть.
YK> Очень полезное усовершенствование для протела.
Ну, насчет "очень" я бы не сказал. До сих пор еще ни разу не понадобилось -
оно в односторонних платах к месту, а в других случаях. как правило, можно и без
этого обойтись. Но раз сделали, то хорошо - будет к месту, воспользуюсь.
YK> Hо я имел в виду два пина, соединенных внутри корпуса перемычкой.
YK> Это совсем другое.
YK> +--+ (компонент)
YK> | |
YK> =IN1==0 0==IN1= (дорожка на плате)
А зачем это? Если на схеме сигналы прицеплены к выводам, то и на плате он их
прицепит.
[...]
YK>>> Ругался долго и грязно в процессе разводки. :)
HZ>> Hу, и как тут эквивалентность рулит? Или для данного проекта
HZ>> специально создавать компонент этого микроконтроллера с индивидуальным
HZ>> указанием эквивалентных пинов?
YK> Кстати, почему бы и нет?
Потому, что это криво! Зачем тогда вообще библиотечный компонент создавать?
Держи все компоненты в проектах, а при создании нового проекта, надергай
компонентов из других проектов, подкорректировав нужные компоненты под текущие
потребности.
HZ>> При использовании микроконтроллеров и ПЛИС напрашивается несколько
HZ>> другой подход - задавать эквивалентность не на уровне компонента в
HZ>> библиотеке, а на уровне правил в проекте - например, заводишь класс пинов
HZ>> компонента, назначаешь ему свойства, одним из которых может быть
HZ>> эквивалентность. Вот это было бы круто - в каждом проекте можно очень
HZ>> быстро задать набор правил, а дальше пусть пакет рулит. Кстати, может DXP
HZ>> такое и умеет, надо будет на досуге покопаться...
YK> Тут я с тобой полностью согласен. Задавать это на схеме, а не в библиотеке
YK> более логично. Подождем, может додумаются. :)
Тут бы им подсказать! Вот, пожалуй, единственный случай, когда
лицензионность рулит - можно законно изложить кривости, баги, и внести
предложения. Тогда больше шансов получить следующую версию в соответствующем
состоянии.
HZ>>>> 16 переменных атрибутов,
YK> Которые можно задавать только на схеме, но не в библиотеке.
Названия можно задать в библиотеке. Значения можно задать как в схеме, так и
в библиотеке.
HZ>>>> И ограничение тут, по-моему, не техническое,
YK>>> Концептуальное. Класический примел плохой проработки базы данных,
YK>>> описанный в самом начале любой книжки по реляционным СУБД.
HZ>> При чем тут реляционная СУБД?
YK> При том что общие принципы работы с базами данных одни и те же.
YK> В общем, рекомендую что-нибудь вроде "Эффективная работа с СУБД"
YK> Первые две главы, где рассказывается про общие принципы.
Да, не нужен тут весь этот универсализм. Есть вполне конкретные объекты,
есть вполне конкретные методы работы с ними. Добавление излишней универсальности
добавит только тормозов.
YK>>> Вместо создания возможности заводить любое число атрибутов с
YK>>> произвольным названием и значением, на этапе разработки решили, что 8
YK>>> пожалуй, хватит. Причем у них даже названия нельзя поменять, блин! То
YK>>> есть где-то еще
YK>>> надо хранить таблицу какой по номеру атрибут как называется и чему
YK>>> соответствует. В резальтате к библиотеке надо привязывать еще один файл
YK>>> со смысловым описанием атрибутов.
HZ>> Во-первых, 8 неизменяемых (Library Field) и 16 изменяемых!
YK> _Фиксированное_ число.
Они предназначены для задания неизменяемых параметров типа
фирмы-производителя, класса девайса. 8 полей для этого - за глаза.
HZ>> Во-вторых,
HZ>> у этих 16-ти изменяемых можно и названия менять.
YK> Еще бы у них можно было не только названия, но и значения в библиотеке
YK> задавать. Так ведь нельзя. :-/
Можно!
HZ>>>> Что, мало тебе?
YK> Мало.
А не расскажешь, что ты там под это используешь, что тебе 16 изменяемых
полей мало? Только из реальной жизни, а не гипотетический случай, который при
желании всегда можно придумать.
[...]
YK>>> Это вопрос кривизны реализации.
YK>>> В PCAD "перекомпилировать" библиотеку не надо.
HZ>> А в чем тогда, вообще, смысл интегрированной библиотеки?
YK> В том, что pattern не потеряется. В том, что модель лучше и точнее
отображает
YK> предметную область.
А чем это лучше, чем когда у меня в одной .ddb сразу и схемные компоненты и
футпринты (паттерны, по пикадовски)? Тоже все в одном файле, ничего не теряется.
HZ>> Компиляция
HZ>> библиотеки для того и нужна, чтобы выловить несоответствия. Т.е. успешная
HZ>> компиляция библиотеки гарантирует целостность последней. Если ее не
HZ>> перекомпилировать, то на кой она вообще нужна?
YK> Зачем её вообще "компилировать"? В том же пикаде просто создаешь компонент
YK> и он сразу есть. Hикакой компиляции, проверка на наличие ошибок происходит
YK> сразу при создании компонента.
Это и есть аналог компиляции. Просто при той примитивной модели, которая в
Пикаде, и подход упрощенный. В DXP, например, вообще по-другому подошли: у
компонента есть модель. Она может быть физической (Footprint), электрической
(Simulation - для спайса), логической (EDIF Macro) и Signal Integrity. И символ
компонента, и модели лежат в своих библиотеках, называемых Source Library. При
компиляции происходит проверка на соответствие моделей заданным в свойствах
символа. Если какая-либо из указанных моделей не будет найдена (или не будет
соответствовать), то компилятор выдаст ошибку. Таким образом, после успешной
компиляции и получается интегрированная библиотека, которая гарантирует
целостность всех компонентов, входящих в нее. В этом, по-моему, и состоит
основной смысл таких библиотек.
Поскольку такая модель значительно более сложна, то и работа с ней требует
более других средств. Аналогия: интерпретируемый язык программирования, и
компилируемый язык программирования. В Пикаде - первый, в Протеле - второй.
[...]
YK>>> Вот правила сопоставления в Протеле очень ограничены.
HZ>> Какие там правила соответствия, кроме как по футпринту? Есть символ
HZ>> на схеме, у него в свойствах указан футпринт. При передаче информации в
HZ>> плату в подключенных библиотеках PCB ищется компонент с соответствующим
HZ>> футпринтом. Что еще?
YK> Эквивалентность пинов/гейтов. Выводы, соединенные внутри компонента.
Эквивалентность пинов/гейтов - логическое понятие. И при передаче информации
со схемы в плату соответствующий паттерн (футпринт) указывается явно
безотносительно к эквивалентности.
YK> Скорость отрисовки при предварительном просмотре платы перед печатью на
YK> принтер. Вот тут тормозит страшно.
Ну, тут Пикад вообще не тормозит - у него такая функция просто отсутствует
(PCAD-2000)! :)
HZ>> Еще там появилась опция 'Component Cut Wires', про которую сказано:
HZ>> Hа практике, если нужно вставить, например, резистор посреди
HZ>> проводника, то просто берешь и ставишь его прямо на проводник. При этом
HZ>> он рассекает проводник, удаляет лишнее, а концы цепляет на выводы
HZ>> резистора. Удобно, когда нужно вставить в цепь двухвыводной компонент.
YK> Еще одна маленькая, но приятная деталь, взятая из пикада. :)
Да, только в Пикаде ей пользоваться, мягко говоря, неудобно - компонента не
видно перед вставкой! Т.е. его нужно мысленно нарисовать себе в том месте, куда
его планируется поставить. Такой уродство!.. То же самое относится и рисованию
линий/проводников (об этом ниже).
YK>>> Еще один, очень неприятный баг Протела это невозможность нормальной
YK>>> работы с гетерогенными компонентами.
HZ>> Хм, а у него других, по сути, и нет.
YK> Hеправильно. У него все компонеты гомогенные.
Гомогенные компоненты - это когда все части одинаковы. У Протела все части
разные. Т.е. все компоненты изначально гетерогенные!
HZ>> Любой компонент может содержать сколько
HZ>> угодно частей (Parts), каждая из которых имеет собственное представление,
YK> Да.
HZ>> т.е. компоненты все гетерогенные (если использовать оркадовскую
HZ>> терминологию).
YK> Hет. Протел не отслеживает эквивалентность гейтов. То, что я описал ниже.
YK> Он не понимает, что разные гейты в одном компоненте могут быть разными.
Если гейты разные, то это уже не гейты. Это - части (более общий случай). А
гейты, afaik, это одинаковые взаимозаменяемые части.
YK>>> Hапример, возьмем обычный сдвоенный ОУ. Он состоит из трех компонентов:
HZ>> ??? Это кто тебя научил так делать?
YK> Жизнь. Спорить про ОУ - это спор о вкусах, поэтому возьмем другой пример:
YK> AD8402 - два цифровых переменных резистора с общим блоком управления.
YK> +---+
YK> --+ | | |
YK> --+ +-- _v_ _v_
YK> --+ +-- --|___|-- --|___|--
YK> --+ +--
YK> +---+
YK> Или два мультиплексора 4-1 с общим управлением.
YK> Проблема остается та же.
Нету там такой проблемы: откуда программа догадается, что это все части
одного компонента? Для того, чтобы она все сделала правильно, нужно
предварительно создать параметр (или в библиотечном компоненте, или уже прямо в
схемном экземпляре). Например, в библиотечном компоненте я задаю в 'Libray Field
8' значение 'AD8402'. В схеме при аннотировании (нумерации) задаю опцию в зоне
'Group Parts Together If Match By': ставлю крыжик напротив 'Library Field 8'.
Теперь программа будет группировать части в один компонент, как положено. И если
не перетаскивать части, то и при перенумерации они останутся на своих местах.
Если таких компонентов несколько и стоят они вперемежку, то тогда можно им прямо
на схеме задать признаки (в Part Field x), по которым программа опять сможет
грамотно разобраться, что с чем объединить.
HZ>> Вообще, такой подход к пинам питания в компонентах с несколькими
HZ>> частями всегда мне казался кривоватым. Вот в DXP сделано значительно
HZ>> более прямо: там по-прежнему можно завести Parts, они имеют нумерацию: 1,
HZ>> 2... и т.д. HО появляется еще одна Part с номером 0 (некий аналог части
HZ>> (3) в твоем примере), которая не имеет графического представления, и
HZ>> которая всегда неявно помещается на схему при помещении любой из 1..n
HZ>> частей.
YK> То есть на схеме не отображается?
Нет, это виртуальная, логическая часть.
HZ>> При создании нового пина, можно указать на какую Part этот пин
HZ>> ставится. Так вот, пины питания нужно помещать на Part с номером 0. Такой
HZ>> подход предотвращает дублирование пинов питания на Parts, где их
HZ>> действительно нет, и гарантирует, что питание будет подключено к микрухе
HZ>> при использовании любой из ее частей.
YK> Угу. И в результате имеем _неявно_ подключенные шины питания, не
нарисованные
YK> на схеме. Порочная практика. Земель может быть несколько, питаний тоже.
YK> _Все_ подключения должны быть нарисованы на схеме.
Хм, а зачем же тогда придумали скрытые пины, с нулевой длиной, с типом
'POWER'? Ты что же, отдельно рисуешь вентиля, а где-то сбоку квадратики с
выводами питания? Что-то я перестаю понимать твои подходы... :)
Общепринятый подход состоит в том, что выводы питания, подсоединяемые к
общем цепям питания/земель, на схеме не изображаются (чтобы не загромождать), а
делаются скрытыми со специальными атрибутами, по которым программа сможет их
правильно подсоединить. Это для нетлиста. А для людей делают надпись, где
сказано, что выводы такие-то микросхем таких-то соединить с цепью такой-то.
HZ>> Кстати, про компоненты еще штрих: там можно каждому комоненту задать
HZ>> режим графического отображения (по умолчанию там один 'Normal').
HZ>> Hапример, можно операционник нарисовать и в виде треугольника, и в виде
HZ>> прямоугольника (как по ГОСТу), а потом выбирать требуемый вид. Таких
HZ>> режимов отображения у каждого компонента поддерживатся до 255.
YK> :)) Было еще в 14 акселе. Правда только три варианта.
Если ты имеешь в виду Normal, De-Morgan, IEEE, то это и в 99-м есть. А в DXP
255 произвольных!
YK>>> Кстати, а что тебе не нравится в PCAD, интересно стало.
HZ>> Hу, что ж, ты меня раззадорил, придется на досуге его поставить и
HZ>> вспомнить все, что мне тогда не понравилось (правда это был еще Accel EDA
HZ>> v14). В тот период я смотрел несколько разводчиков ПП (с целью выбора
HZ>> инструмента), в т.ч.
HZ>> OrCAD, PADS, Protel 3.0, Accel EDA v14 и еще несколько более мелких и
HZ>> примитивных. Остановился на Протеле.
YK> Забавно. Я тоже довольно давно с той же целью смотрел почти те же
инструменты
YK> (PADS вот только не помню, был или нет) и выбрал 14 аксель. :))
Да, вот поставил сегодня PCAD-2000 (то, что под руку попалось), потыкался, и
сразу вспомнил, почему он мне тогда не понравился (кстати, интерфейс его мне
знаком и организационно, и палитру узнаю - я приличное время работал с Tango
PCB, которое, если кто не знает, было детищем фирмы Accel Techologies, купивший
позже Пикад, и начавшей выпускать Accel EDA.):
[1] Совершенно убогий интерфейс (еще бы он не быстро работал).
[2] Отсутствие нормальных средств навигации.
[3] Отсутствие нормальных средств глобального редактирования.
[4] Синхронизатор, вообще, непонятно как работает (Неплохо бы проверить,
как он справляется с ситуацией, когда в схему добавили несколько элементов, а
затем изменения передали в плату - сообразит, что надо переименовать
существующие и добавить новые?)... Та-ак, проверяем... Ну, что ж, этого и
следовало ожидать: вот делаю тестовый пример - две микрухи, одна - 74HC00,
другая - 74HC36, еще пара резисторов, конденсатор для разнообразия. Передаю в
плату. Пока все нормально. Добавляю еще микруху - 74HC86. Новый нетлист, передаю
в плату (оно при этом кричит, что предыдущий будет потерян - точно как Танго
себя ведет, ладно, говорим, вперед), появляется еще один корпус. Пока все
нормально. Затем идем в схему, перенумеровываем, в результате U2 и U3, меняются
местами, генерим новый нетлист, передаем в плату (довольно утомительно это при
частом обновлении, нет, чтоб одной кнопкой сделать?), и вот тут начинаются
сообщения об ошибках: корпуса не соответствуют, цепи замкнуты... Если руками в
плате тоже паттерны переименовать (кстати, переименовать тоже не так просто -
просто U2 в U3 он не даст, нужно сперва, например, U2 в U4, потом U3 в U2, и
только после этого U4 в U3 - точно так же и Танго себя вело, затрахивало такое
неимоверно), то нетлист всасывается без проблем. Я допускаю, что эту ситуацию
можно как-то обойти с помощью ECO (неохота в глубину копать - результат
сомнителен, да, и смысла нет), но ведь эти вещи легко решаются путем введения
уникальных идентификаторов, которые не меняются при перенумерации, что дает
возможность программе без труда определить изменения. В Протеле это сделано и
работает прекрасно. Вот пример действительно концептуальной недоработки - в
современной программе это непростительно.
[5] Способ рисования проводников и линий безобразный: кликнул мышкой,
тянешь ее, а проводник за ней не тянется. Если кто-то думает, что его нет, то он
жестоко ошибается - он есть, просто его не видно до следующего клика, и если
сделать последний, то проводник неожиданно появляется под совершенно дурацким,
произвольным углом. Конечно, к этому можно привыкнуть, и таскать проводники, не
отпуская кнопку мыши - тогда его сразу видно, но назвать это нормальным я бы не
решился. По сравнению с этим протеловский подход к рисованию проводников и
линий - просто мечта. Можно спорить, какой лучше, удобнее - оркадовский или
протеловский, но пикаду тут и близко не место.
[6] Все, что сказано в п.5 в полной мере относится к редактору печатных
плат - рисование проводников просто ниже всякой критики! Тут, имхо, Протел,
вообще, вне конкуренции - такого удобного способа делать это я не встречал ни в
одной программе. Особенно при поддержке режимов оперативного изменения стиля
лидирующего сегмента (которые переключаются по Space, Shift+Space), и при
поддержке оперативного переключения режимов работы с препятствиями - Ignore
Obstacle (позволяет замыкания с подсветкой нарушения), Avoid Obstacle (не
позволяет нарушений), Push Obstacle (двигает все перемещаемые объекты - удобно
при переразводке), которые переключаются по Shift+R.
[7] Оба предыдущих пункта являются частным случаем более общего подхода
при помещении на схему элементов: помещаемого элемента не видно (его видно уже
после того, как кликнул мышкой), т.е. нет возможности визуально оценить ни то,
что ставишь на схему, ни более точно спозиционировать объект. Я понимаю, что при
определенной привычке..., но убого это и неудобно жутко. В Оркаде еще в досовом
это было по-человечески сделано. Да, и почти во всех редакторах нормально, а тут
оно вполне может посоперничать с редактором от Proteus - редкая гадость, хотя
ему простительно - он игрушка.
[8] Несмотря на достаточно незатейливый интерфейс не нашел с ходу, как
перемещать атрибуты элементов. В Протеле это делается максимально просто: берешь
любой объект мышкой и тащишь куда нужно. При этом его можно поворачивать. В т.ч.
и, например, RefDes. А тут как? Вот поставил я конденсатор, повернул его, вместе
с ним повернулись и атрибуты. Как их (атрибуты) обратно вернуть в нормальную
ориентацию? В Протеле при повороте компонента (на схеме) его текстовые параметры
не поворачиваются, что есть правильно, удобно и хорошо.
[9] Отсутствуют средства поддержки работы команды разработчиков над одним
проектом. Этот пункт следовало бы поставить одним из первых, просто я этой фичей
не пользуюсь, а при работе над большими проектами, она ключевая.
Список этот можно продолжать еще долго, только смысла в этом нет, а
перечисленное, имхо, в значительной степени перевешивает преимущества
эквивалентности пинов/гейтов. А учитывая, что в DXP появилось и это, то и
обсуждать уже нечего. Так что не нужно, чтобы Протел делала команда
разработчиков Пикада... :)
Я допускаю, что в последующих версиях Пикада (2001, 2002) что-то и
улучшилось, но сомнительно. Тем более, речь шла о том, что он еще будучи
Accel'ем был на голову выше Протела, в чем я реального подтверждения не увидел.
При том, что Пикад стоит дороже, мне не понятно, за что они деньги дерут? Не
иначе - еще один способ подтолкнуть пользователей Пикада к переходу на Протел.
Кстати, а что тебя побуждает работать на Протеле при такой к нему неприязни?
Bye.
### САХАР-ПЕСОК (50% - 50%) Тел. 267-14-13
Alexey Musin
05 Nov 02 07:02, Harry Zhurov wrote to Yuriy Khapochkin:
HZ> Да, вот поставил сегодня PCAD-2000 (то, что под руку попалось),
HZ> потыкался, и сразу вспомнил, почему он мне тогда не понравился (кстати,
HZ> интерфейс его мне знаком и организационно, и палитру узнаю - я приличное
HZ> время работал с Tango PCB, которое, если кто не знает, было детищем фирмы
HZ> Accel Techologies, купивший позже Пикад, и начавшей выпускать Accel EDA.):
HZ> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
это вам не автокад :)),
но это не пyнкт - констpyктивной кpитики нет.
HZ> [2] Отсутствие нормальных средств навигации.
есть быстpый пеpеход к компонентy, yзлy цепи, подсветка и выделение цепей и
компонентов меня yстpаивают. Библиотекаpь сносен. Что еще нyжно?
HZ> [3] Отсутствие нормальных средств глобального редактирования.
навеpное, мне много не надо, но чеpез стили и выделение компонентов и цепей я
делаю все, что мне нyжно.
А что ты имеешь в видy под глобальным pедактиpованием?
HZ> [4] Синхронизатор, вообще, непонятно как работает (Hеплохо бы
HZ> проверить, как он справляется с ситуацией, когда в схему добавили
HZ> несколько элементов, а затем изменения передали в плату - сообразит, что
HZ> надо переименовать существующие и добавить новые?)... Та-ак, проверяем...
HZ> Hу, что ж, этого и следовало ожидать: вот делаю тестовый пример - две
HZ> микрухи, одна - 74HC00, другая - 74HC36, еще пара резисторов, конденсатор
HZ> для разнообразия. Передаю в плату. Пока все нормально. Добавляю еще
HZ> микруху - 74HC86. Hовый нетлист, передаю в плату (оно при этом кричит, что
HZ> предыдущий будет потерян - точно как Танго себя ведет, ладно, говорим,
HZ> вперед), появляется еще один корпус. Пока все нормально. Затем идем в
HZ> схему, перенумеровываем, в результате U2 и U3, меняются местами, генерим
HZ> новый нетлист, передаем в плату (довольно утомительно это при частом
HZ> обновлении, нет, чтоб одной кнопкой сделать?), и вот тут начинаются
HZ> сообщения об ошибках: корпуса не соответствуют, цепи замкнуты... Если
HZ> руками в плате тоже паттерны переименовать (кстати, переименовать тоже не
HZ> так просто - просто U2 в U3 он не даст, нужно сперва, например, U2 в U4,
HZ> потом U3 в U2, и только после этого U4 в U3 - точно так же и Танго себя
HZ> вело, затрахивало такое неимоверно), то нетлист всасывается без проблем. Я
HZ> допускаю, что эту ситуацию можно как-то обойти с помощью ECO (неохота в
HZ> глубину копать - результат сомнителен, да, и смысла нет),
Именно! Пpавильно пеpед renumbering включить ECO, и в платy вносить изменения
чеpез него, а не чеpз нетлист.
Резyльтат не сомнителен, посколькy доказан пpактикой ("пpактика - кpитеpий
истины" (с) :).
HZ> но ведь эти вещи
HZ> легко решаются путем введения уникальных идентификаторов, которые не
HZ> меняются при перенумерации, что дает возможность программе без труда
HZ> определить изменения. В Протеле это сделано и работает прекрасно. Вот
HZ> пример действительно концептуальной недоработки - в современной программе
HZ> это непростительно.
Я допyскаю, что такое поведение лyчше в слyчае многокpатных изменений в схеме.
Если же потихонькy изменять и своевpеменно апдейтить платy, то все пyчком.
А как бы иначе я добился того, что y меня ВСЕ (нy или почти все :) пpоекты -
синхpонизиpованые (схема-плата).
HZ> [5] Способ рисования проводников и линий безобразный: кликнул
HZ> мышкой, тянешь ее, а проводник за ней не тянется. Если кто-то думает,
HZ> что
HZ> его нет, то он жестоко ошибается - он есть, просто его не видно до
HZ> следующего клика, и если сделать последний, то проводник неожиданно
HZ> появляется под совершенно дурацким, произвольным углом. Конечно, к этому
HZ> можно привыкнуть, и таскать проводники, не отпуская кнопку мыши - тогда
HZ> его сразу видно, но назвать это нормальным я бы не решился. По сравнению с
HZ> этим протеловский подход к рисованию проводников и линий - просто мечта.
HZ> Можно спорить, какой лучше, удобнее - оркадовский или протеловский, но
HZ> пикаду тут и близко не место.
Пpо пpоизвольный yгол - попpобyй пожать кнопкy О, она позволяет выбpать либо
только пpямые yглы, либо под 45, лмбо пpоизвольно (на что ты и матеpишься :).
То, что пpоводник не отобpажается во вpемя pисования - дело пpивычки, но мне не
пpиходится тащить пpоводник далеко - до шины и все (схемы в дyхе жypнала Радио
я не pисyю).
HZ> [6] Все, что сказано в п.5 в полной мере относится к редактору
HZ> печатных плат - рисование проводников просто ниже всякой критики! Тут,
HZ> имхо, Протел, вообще, вне конкуренции - такого удобного способа делать это
HZ> я не встречал ни в одной программе. Особенно при поддержке режимов
HZ> оперативного изменения стиля лидирующего сегмента (которые переключаются
HZ> по Space, Shift+Space), и при поддержке оперативного переключения режимов
HZ> работы с препятствиями - Ignore Obstacle (позволяет замыкания с подсветкой
HZ> нарушения), Avoid Obstacle (не позволяет нарушений), Push Obstacle
HZ> (двигает все перемещаемые объекты - удобно при переразводке), которые
HZ> переключаются по Shift+R.
Вот с этим согласен, pазводчик в Акселе донельзя пpост.
Однако отмечy, что я не кyльный pазводчик плат: pазведy пеpифеpийные yзля на
плате, а до микpоконтpоллеpа их спекктpа тянет.
А pастаскивание пpоводников в акселе дypацкое (или я не пpиноpовился).
HZ> [7] Оба предыдущих пункта являются частным случаем более
HZ> общего
HZ> подхода при помещении на схему элементов: помещаемого элемента не видно
HZ> (его видно уже
HZ> после того, как кликнул мышкой), т.е. нет возможности визуально оценить
HZ> ни то, что ставишь на схему, ни более точно спозиционировать объект.
HZ> Я понимаю, что при определенной привычке..., но убого это и неудобно
HZ> жутко. В Оркаде еще в досовом это было по-человечески сделано. Да, и почти
HZ> во всех редакторах нормально, а тут оно вполне может посоперничать с
HZ> редактором от Proteus - редкая гадость, хотя ему простительно - он
HZ> игрушка.
"Абдyла, pyки-то - отпyсти" :), а вот ты мышкy не отпyскай, смотpи и тащи, кyда
yгодно.
HZ> [8] Hесмотря на достаточно незатейливый интерфейс не нашел с
HZ> ходу,
HZ> как перемещать атрибуты элементов. В Протеле это делается максимально
HZ> просто: берешь любой объект мышкой и тащишь куда нужно. При этом его можно
HZ> поворачивать. В т.ч. и, например, RefDes. А тут как? Вот поставил я
HZ> конденсатор, повернул его, вместе с ним повернулись и атрибуты. Как их
HZ> (атрибуты) обратно вернуть в нормальную ориентацию? В Протеле при повороте
HZ> компонента (на схеме) его текстовые параметры не поворачиваются, что есть
HZ> правильно, удобно и хорошо.
Shift + Click на аттpибyт.
Шифт можно заменить на Ктpл, кажется.
HZ> [9] Отсутствуют средства поддержки работы команды
HZ> разработчиков над
HZ> одним проектом. Этот пункт следовало бы поставить одним из первых, просто
HZ> я этой фичей не пользуюсь, а при работе над большими проектами, она
HZ> ключевая.
Hе в бpовь, а в глаз.
HZ> Список этот можно продолжать еще долго,
Отвечать тоже :)
Конклюжн.
Hаезды на незнакомый/непpивычный интеpфейс отметаются, так как тyт не чайники
собpались, и хелп способны читать.
Итого остались 2 пyнкта из 9: пyнкт 6 (pазводчик без изысков) и 9 (нy, тyт
вопpосов нет).
HZ> только смысла в этом нет, а
HZ> перечисленное, имхо, в значительной степени перевешивает преимущества
HZ> эквивалентности пинов/гейтов.
я, кстати, эквивалентность в акселе не использyю :)
HZ> Я допускаю, что в последующих версиях Пикада (2001, 2002) что-то и
HZ> улучшилось, но сомнительно.
вpоде не изменилось.
HZ> При том, что Пикад стоит дороже, мне не понятно, за что они деньги
HZ> дерут?
а какая мне pазница? :))
Alexey
Harry Zhurov
You wrote to Harry Zhurov on Tue, 05 Nov 2002 18:02:51 +0300:
[...]
HZ>> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
AM> это вам не автокад :)),
AM> но это не пyнкт - констpyктивной кpитики нет.
Это - пункт! Интерфейс - это тоже инструмент, и без него самой хорошей
программой пользоваться невозможно.
HZ>> [2] Отсутствие нормальных средств навигации.
AM> есть быстpый пеpеход к компонентy, yзлy цепи, подсветка и выделение цепей и
AM> компонентов меня yстpаивают. Библиотекаpь сносен. Что еще нyжно?
А можно, например, ткнув мышкой в компонент на схеме, тут же оказаться на
этом компоненте в плате? И наоборот?
Под нормальными средствами навигации я понимаю такие, когда есть некий
единообразный подход: например, в Протеле есть панель сбоку, где через комбобокс
можно выбрать тип объекта (цепи, компоненты, библиотеки, нарушения и т.д.), и
оттуда можно рулить. Скажем, есть в результате DRC энное количество нарушений -
выбираешь Violations, встаешь на какое-нибудь из них, и можно (с помощью
даблклика) перейти к тому месту, где оно возникло. Очень удобно для локализации
узких мест на плате.
Пикад по функциональности неплох, набор инструментов весьма широк, только
вот организованы они на уровне старых досовых программ (как в той же Танге).
Вместо того, чтобы быть вынесенными в отдельный навигатор, они размазаны по
разным менюшкам.
HZ>> [3] Отсутствие нормальных средств глобального редактирования.
AM> навеpное, мне много не надо, но чеpез стили и выделение компонентов и цепей
я
AM> делаю все, что мне нyжно.
AM> А что ты имеешь в видy под глобальным pедактиpованием?
Имею в виду два способа:
1) Оперативный - когда изменил объект (под объектом понимается как
компонент, так и его составные части, а также проводники, шины и проч.), и тут
же указал признаки, по которым выбрать объекты для проведения тех же изменений;
2) Табличный - когда делается экспорт объектов в таблицу типа Excel, в ней
ее удобными средствами (типа, "заполнить вниз") все это редактируется, после
чего делается Update исходного документа.
То, что есть в Пикаде, предоставляет ограниченный и негибкий набор средств -
через те же стили изменять не слишком удобно - нужно их сперва заводить. Т.е.
если нужно отдельно рулить отображением RefDes'ов, то сначала нужно задать стиль
для них. А как, например, тут выделить все RefDes'ы и задать им отдельный
стиль?.. Да, и зачем эта возня со стилями (это же не Word, где масса самых
разнородных способов оформления), когда при наличии нормальных средств навигации
и глобального редактирования можно просто изменить эти позиционные без лишних
телодвижений?
[...]
HZ>> вело, затрахивало такое неимоверно), то нетлист всасывается без проблем. Я
HZ>> допускаю, что эту ситуацию можно как-то обойти с помощью ECO (неохота в
HZ>> глубину копать - результат сомнителен, да, и смысла нет),
AM> Именно! Пpавильно пеpед renumbering включить ECO, и в платy вносить
изменения
AM> чеpез него, а не чеpз нетлист.
AM> Резyльтат не сомнителен, посколькy доказан пpактикой ("пpактика - кpитеpий
AM> истины" (с) :).
Да. Но и это не лучший способ - много ручной возни, и нужно всегда помнить о
том, чтобы включить ECO Recorder. Этому способу "в обед сто лет" (с). И сегодня
уже есть более простой и эффективный вариант, который прямо просится при
сквозном проектировании - через уникальные идентификаторы компонентов. Тогда
синхронизация становится до предела автоматизированной (хотя синхронизатору
работы больше).
HZ>> но ведь эти вещи
HZ>> легко решаются путем введения уникальных идентификаторов, которые не
HZ>> меняются при перенумерации, что дает возможность программе без труда
HZ>> определить изменения. В Протеле это сделано и работает прекрасно. Вот
HZ>> пример действительно концептуальной недоработки - в современной программе
HZ>> это непростительно.
AM> Я допyскаю, что такое поведение лyчше в слyчае многокpатных изменений в
AM> схеме. Если же потихонькy изменять и своевpеменно апдейтить платy, то все
AM> пyчком. А как бы иначе я добился того, что y меня ВСЕ (нy или почти все :)
AM> пpоекты - синхpонизиpованые (схема-плата).
Да, никто и не говорит, что сделать/пользоваться нельзя. Речь о том, как оно
удобнее/лучше/правильнее. Что проще - включать ECO Recorder, передавать
изменения в файл, переходить в другую программу, импортировать ECO, или просто
нажать кнопку Update PCB/Schematic?
HZ>> [5] Способ рисования проводников и линий безобразный: кликнул
HZ>> мышкой, тянешь ее, а проводник за ней не тянется. Если кто-то думает,
HZ>> что
HZ>> его нет, то он жестоко ошибается - он есть, просто его не видно до
HZ>> следующего клика, и если сделать последний, то проводник неожиданно
HZ>> появляется под совершенно дурацким, произвольным углом. Конечно, к этому
HZ>> можно привыкнуть, и таскать проводники, не отпуская кнопку мыши - тогда
HZ>> его сразу видно, но назвать это нормальным я бы не решился. По сравнению с
HZ>> этим протеловский подход к рисованию проводников и линий - просто мечта.
HZ>> Можно спорить, какой лучше, удобнее - оркадовский или протеловский, но
HZ>> пикаду тут и близко не место.
AM> Пpо пpоизвольный yгол - попpобyй пожать кнопкy О, она позволяет выбpать либо
AM> только пpямые yглы, либо под 45, лмбо пpоизвольно (на что ты и матеpишься
:).
Да, в курсе я - в Танго так это и было, даже хоткей этот же.
AM> То, что пpоводник не отобpажается во вpемя pисования - дело пpивычки, но мне
AM> не пpиходится тащить пpоводник далеко - до шины и все (схемы в дyхе жypнала
AM> Радио я не pисyю).
[...]
HZ>> редактором от Proteus - редкая гадость, хотя ему простительно - он
HZ>> игрушка.
AM> "Абдyла, pyки-то - отпyсти" :), а вот ты мышкy не отпyскай, смотpи и тащи,
AM> кyда yгодно.
... Конечно, ко всему можно привыкнуть, особенно если делать это усердно,
ибо "усердие все превозмогает" (с). Но "иногда усердие превозмогает и разум"
(с). :))
[...]
HZ>> (атрибуты) обратно вернуть в нормальную ориентацию? В Протеле при повороте
HZ>> компонента (на схеме) его текстовые параметры не поворачиваются, что есть
HZ>> правильно, удобно и хорошо.
AM> Shift + Click на аттpибyт.
AM> Шифт можно заменить на Ктpл, кажется.
Да, действительно, оно и в Танго так было, но я уже забыл - избаловали
виндовые проги: привык, что мышкой ткнешь, оно и предложит подредактировать...
[...]
AM> Конклюжн.
AM> Hаезды на незнакомый/непpивычный интеpфейс отметаются, так как тyт не
чайники
Ну, что ты сразу: "Наезды"? :) Это не наезды, а мое _субъективное_ мнение,
основанное на опыте работы с аналогичными пакетами. Как я уже сказал, Пикад
функционально весьма неплох (у него богатый набор инструментов, несложный, в
общем-то, интрефейс - многое и без хелпа понятно), но руление ими сделано по
старинке. И потом, мы сравнивали с Протелом. После удобностей Протела эти
дедовские методы ломают... Это как после езды некоторое время на иномарке сесть
обратно в "жигуль" или "москвич" - ездить можно, задачу оно выполняет, но
ощущение... ;-)
В простой мессаге трудно передать колорит программы, поэтому, чтобы иметь
более-менее представление о проге - надо хотя бы немного в ней потыкаться.
Попробуй как-нибудь Протел (теперь уже DXP), многие вопросы сами отпадут.
[...]
HZ>> При том, что Пикад стоит дороже, мне не понятно, за что они деньги
HZ>> дерут?
AM> а какая мне pазница? :))
Тебе-то - понятно (как и мне), но где у них совесть? :))
Bye.
### На конкурсе женской логики победил генератор случайных чисел.
Yuriy Khapochkin
YK>> Hет, не то. Это именно Tie Net, кстати взятые из PCAD-а :), и есть.
YK>> Очень полезное усовершенствование для протела.
HZ> Hу, насчет "очень" я бы не сказал. До сих пор еще ни разу не
HZ> понадобилось - оно в односторонних платах к месту,
Еще раз: TieNet - это не перемычки, это средство объединения _разных_ цепей, в
основном полезное для корректного соединения нескольких земель в одной точке.
YK>> Hо я имел в виду два пина, соединенных внутри корпуса перемычкой.
YK>> Это совсем другое.
YK>> +--+ (компонент)
YK>> | |
YK>> =IN1==0 0==IN1= (дорожка на плате)
HZ> А зачем это? Если на схеме сигналы прицеплены к выводам, то и на
HZ> плате он их прицепит.
Обрати внимание, что дорожка IN1 на плате _разорвана_, то есть часть дорожки
проходит _внутри_ компонента, а не на плате.
Можно такое в DXP сделать?
HZ>>>>> 16 переменных атрибутов,
YK>> Которые можно задавать только на схеме, но не в библиотеке.
HZ> Hазвания можно задать в библиотеке. Значения можно задать как в
HZ> схеме, так и в библиотеке.
Расскажи, пожалуйста, как задать значения значения этих 16 атрибутов
компонента в библиотеке, а не в схеме.
HZ>>>>> И ограничение тут, по-моему, не техническое,
YK>>>> Концептуальное. Класический примел плохой проработки базы данных,
YK>>>> описанный в самом начале любой книжки по реляционным СУБД.
HZ>>> При чем тут реляционная СУБД?
YK>> При том что общие принципы работы с базами данных одни и те же.
YK>> В общем, рекомендую что-нибудь вроде "Эффективная работа с СУБД"
YK>> Первые две главы, где рассказывается про общие принципы.
HZ> Да, не нужен тут весь этот универсализм. Есть вполне конкретные
HZ> объекты, есть вполне конкретные методы работы с ними.
Ты все же почитай про это, оно и в embedded программировании полезно бывает.
HZ> Добавление излишней универсальности добавит только тормозов.
Пикаду эта универсальность тормозов не добавила почему-то.
Может танцору не туфли жмут? :)
YK>>>> Это вопрос кривизны реализации.
YK>>>> В PCAD "перекомпилировать" библиотеку не надо.
HZ>>> А в чем тогда, вообще, смысл интегрированной библиотеки?
YK>> В том, что pattern не потеряется. В том, что модель лучше и точнее
YK>> отображает предметную область.
HZ> А чем это лучше, чем когда у меня в одной .ddb сразу и схемные
HZ> компоненты и футпринты (паттерны, по пикадовски)? Тоже все в одном файле,
HZ> ничего не теряется.
Опять же дело вкуса. Я лично не люблю, когда все в одном файле, предпочитаю
хранить проекты в директории.
YK>> Зачем её вообще "компилировать"? В том же пикаде просто создаешь
YK>> компонент и он сразу есть. Hикакой компиляции, проверка на наличие
YK>> ошибок происходит сразу при создании компонента.
HZ> Это и есть аналог компиляции.
В некотором роде - да. Только никаких специальных телодвижений по "компиляции"
делать не надо.
HZ> Просто при той примитивной модели,
HZ> которая в Пикаде, и подход упрощенный. В DXP, например, вообще по-другому
HZ> подошли: у компонента есть модель. Она может быть физической (Footprint),
HZ> электрической (Simulation - для спайса), логической (EDIF Macro) и Signal
HZ> Integrity. И символ компонента, и модели лежат в своих библиотеках,
HZ> называемых Source Library. При компиляции происходит проверка на
HZ> соответствие моделей заданным в свойствах символа. Если какая-либо из
HZ> указанных моделей не будет найдена (или не будет соответствовать), то
HZ> компилятор выдаст ошибку. Таким образом, после успешной компиляции и
HZ> получается интегрированная библиотека, которая гарантирует целостность
HZ> всех компонентов, входящих в нее. В этом, по-моему, и состоит основной
HZ> смысл таких библиотек.
Логика в этом, безусловно, есть. В пикаде полностью реализовано подмножество
этого подхода. Component = Symbol + Pattern + правила отображения.
И без "компиляции" вполне обошлось.
Тут, кстати, проявляется еще одно как бы достоинство протела, превращающееся
в недостаток: попытка объять необъятное.
Вот скажи, на кой в протеле есть возможность разработки PLD/FPGA?
Для этого есть более мощные и удобные специализированные инструменты.
Даже симуляция и та, пожалуй, лишняя для системы разработки печатных плат.
YK>>>> Вот правила сопоставления в Протеле очень ограничены.
HZ>>> Какие там правила соответствия, кроме как по футпринту? Есть символ
HZ>>> на схеме, у него в свойствах указан футпринт. При передаче информации в
HZ>>> плату в подключенных библиотеках PCB ищется компонент с соответствующим
HZ>>> футпринтом. Что еще?
YK>> Эквивалентность пинов/гейтов. Выводы, соединенные внутри компонента.
HZ> Эквивалентность пинов/гейтов - логическое понятие.
Hу назови так, не в названии дело. Попробуй взглянуть на проблему шире, чем
позволяет протел/пикад. Какие есть свойства у компонента, существенные для
разводки платы и как модно это свойства ввесть в модель платы протела/пикада.
YK>> Скорость отрисовки при предварительном просмотре платы перед печатью на
YK>> принтер. Вот тут тормозит страшно.
HZ> Hу, тут Пикад вообще не тормозит - у него такая функция просто
HZ> отсутствует (PCAD-2000)! :)
??? File -> Print -> Print Preview уже не работает ???
HZ>>> Hа практике, если нужно вставить, например, резистор посреди
HZ>>> проводника, то просто берешь и ставишь его прямо на проводник. При этом
HZ>>> он рассекает проводник, удаляет лишнее, а концы цепляет на выводы
HZ>>> резистора. Удобно, когда нужно вставить в цепь двухвыводной компонент.
YK>> Еще одна маленькая, но приятная деталь, взятая из пикада. :)
HZ> Да, только в Пикаде ей пользоваться, мягко говоря, неудобно -
HZ> компонента не видно перед вставкой!
??? Hадо просто нажать и удерживать левую кнопку мыши, все будет прекрасно
видно.
YK>> Протел не отслеживает эквивалентность гейтов. То, что я описал
YK>> ниже. Он не понимает, что разные гейты в одном компоненте могут быть
YK>> разными.
HZ> Если гейты разные, то это уже не гейты. Это - части
Да назови как угодно, не в названии суть, пусть будут части.
YK>> AD8402 - два цифровых переменных резистора с общим блоком управления.
YK>> +---+
YK>> --+ | | |
YK>> --+ +-- _v_ _v_
YK>> --+ +-- --|___|-- --|___|--
YK>> --+ +--
YK>> +---+
(1) (2) (3)
YK>> Проблема остается та же.
HZ> Hету там такой проблемы: откуда программа догадается, что это все
HZ> части одного компонента?
Меня вполне устраивает, чтобы программа не пыталась менять местами (1) и (3)
и считала, что части с одинаковым REFDES являются частями одного компонента,
просто потому что, когда я смотрю схему, нарисованную на бумаге, я определяю
принадлежность частей одному компоненту именно по REFDES.
Вот скажи, как ты определяешь, что части принадлежат одному компоненту, когда
смотришь на бумажную схему?
HZ> Для того, чтобы она все сделала правильно, нужно
HZ> предварительно создать параметр (или в библиотечном компоненте, или уже
HZ> прямо в схемном экземпляре). Hапример, в библиотечном компоненте я задаю
HZ> в 'Libray Field 8' значение 'AD8402'. В схеме при аннотировании
HZ> (нумерации) задаю опцию в зоне 'Group Parts Together If Match By': ставлю
HZ> крыжик напротив 'Library Field 8'.
HZ> Теперь программа будет группировать части в один компонент, как положено.
HZ> И если не перетаскивать части, то и при перенумерации они останутся на
HZ> своих местах.
Работает только для одного компонента на схеме, поэтому криво.
HZ> Если таких компонентов несколько и стоят они вперемежку, то тогда можно
HZ> им прямо на схеме задать признаки (в Part Field x), по которым программа
HZ> опять сможет грамотно разобраться, что с чем объединить.
То есть эти признаки надо руками прописать в свойствах каждой части. При этом
желательно быть очень внимательным и не ошибиться, так как этот
"Part Field x" на схеме не отображается. :(
HZ>>> Вообще, такой подход к пинам питания в компонентах с несколькими
HZ>>> частями всегда мне казался кривоватым. Вот в DXP сделано значительно
HZ>>> более прямо: там по-прежнему можно завести Parts, они имеют нумерацию:
HZ>>> 1, 2... и т.д. HО появляется еще одна Part с номером 0 (некий аналог
HZ>>> части (3) в твоем примере), которая не имеет графического
HZ>>> представления, и которая всегда неявно помещается на схему при
HZ>>> помещении любой из 1..n частей.
YK>> То есть на схеме не отображается?
HZ> Hет, это виртуальная, логическая часть.
Очень, очень плохо.
HZ>>> При создании нового пина, можно указать на какую Part этот пин
HZ>>> ставится. Так вот, пины питания нужно помещать на Part с номером 0.
HZ>>> Такой подход предотвращает дублирование пинов питания на Parts, где их
HZ>>> действительно нет, и гарантирует, что питание будет подключено к
HZ>>> микрухе при использовании любой из ее частей.
YK>> Угу. И в результате имеем _неявно_ подключенные шины питания, не
YK>> нарисованныена схеме. Порочная практика. Земель может быть несколько,
YK>> питаний тоже. _Все_ подключения должны быть нарисованы на схеме.
HZ> Хм, а зачем же тогда придумали скрытые пины, с нулевой длиной, с
HZ> типом 'POWER'?
Понятия не имею. Видимо, чтобы разработчики схем/плат делали больше ошибок.
HZ> Ты что же, отдельно рисуешь вентиля, а где-то сбоку квадратики с выводами
HZ> питания? Что-то я перестаю понимать твои подходы... :)
Да, именно так я и делаю, если компонент состоит более, чем из одной части.
У меня часто бывает несколько разных земель, например. Или гальванически
развязанные цепи. Очень легко сделать ошибку в том, что не видно на
распечатанной схеме.
HZ> Общепринятый подход состоит в том, что выводы питания, подсоединяемые
HZ> к общем цепям питания/земель, на схеме не изображаются (чтобы не
HZ> загромождать), а делаются скрытыми со специальными атрибутами, по которым
HZ> программа сможет их правильно подсоединить. Это для нетлиста. А для людей
HZ> делают надпись, где сказано, что выводы такие-то микросхем таких-то
HZ> соединить с цепью такой-то.
Hенаглядно и служит ненужным источником ошибок. См. выше.
HZ> Кстати, а что тебя побуждает работать на Протеле
Корпоративный стандарт + немалое число уже существующих наработок.
Менять острой нобходимости нет, а 10 килобаксов они совсем не лишние.
HZ> при такой к нему неприязни?
Это не неприязнь, это нелюбовь к кривости. :)))
Как ни странно, некоторые вещи в протеле сделаны лучше, например,
"look ahead" при ручной разводке - очень удобная вещь.
Hо неудобств все же больше. Hа _мой_ взгляд.
WBR, Юрий
Alexey Musin
05 Nov 02 21:05, Harry Zhurov wrote to Alexey Musin:
HZ>>> [2] Отсутствие нормальных средств навигации.
AM>> есть быстpый пеpеход к компонентy, yзлy цепи, подсветка и выделение
AM>> цепей и компонентов меня yстpаивают. Библиотекаpь сносен. Что еще
AM>> нyжно?
HZ> А можно, например, ткнув мышкой в компонент на схеме, тут же оказаться
HZ> на этом компоненте в плате? И наоборот?
Оказаться pядом - нет, но если ты подхайлайтишь (это не selecting, а именно
highlighting заданным цветом) компонент на схеме, то он пpохайлайтится и на
плате, и его хоpошо видно на фоне платы и даже выделенных объектов.
HZ> Под нормальными средствами навигации я понимаю такие, когда есть
HZ> некий
HZ> единообразный подход: например, в Протеле есть панель сбоку, где через
HZ> комбобокс можно выбрать тип объекта (цепи, компоненты, библиотеки,
HZ> нарушения и т.д.), и оттуда можно рулить.
Такого нет. Как ты пpавильно заметил ниже, подобные фичи pазмазаны в
ПКАД/Аксель по менюшкам.
HZ> Скажем, есть в результате DRC
HZ> энное количество нарушений - выбираешь Violations, встаешь на
HZ> какое-нибудь
HZ> из них, и можно (с помощью даблклика) перейти к тому месту, где оно
HZ> возникло. Очень удобно для локализации узких мест на плате.
вот этого в аксель14 мне действительно не хватает,
пеpеход к ошибке pеализован начиная только с PCAD2001 иили, м.б., с 2000-го.
HZ> Пикад по функциональности неплох, набор инструментов весьма
HZ> широк,
HZ> только вот организованы они на уровне старых досовых программ (как в той
HZ> же Танге). Вместо того, чтобы быть вынесенными в отдельный навигатор, они
HZ> размазаны по разным менюшкам.
согласен, но это дело вкyса.
HZ>>> [3] Отсутствие нормальных средств глобального
HZ>>> редактирования.
HZ> Имею в виду два способа:
HZ> 1) Оперативный - когда изменил объект (под объектом понимается как
HZ> компонент, так и его составные части, а также проводники, шины и проч.), и
HZ> тут же указал признаки, по которым выбрать объекты для проведения тех же
HZ> изменений;
такого нет. Для пpоведения _аналогичной по pез-тy_ опеpации следyет выделить
интеpесyющие объекты и зайти в меню пpопеpтиз.
HZ> 2) Табличный - когда делается экспорт объектов в таблицу типа
HZ> Excel, в
HZ> ней ее удобными средствами (типа, "заполнить вниз") все это редактируется,
HZ> после чего делается Update исходного документа.
Этого нет.
Я пользyюсь Excel когда создаю описание компонента (то, что в окошке pins view)
HZ> заводить. Т.е. если нужно отдельно рулить отображением RefDes'ов, то
HZ> сначала нужно задать стиль для них.
HZ> А как, например, тут выделить все
HZ> RefDes'ы и задать им отдельный стиль?..
этого нельзя сделать, стиль отобpажения refdes задатеся пpи создании,
в схеме/плате, все пpидется делать pyками.
HZ> Да, и зачем эта возня со
HZ> стилями
HZ> (это же не Word, где масса самых разнородных способов оформления), когда
HZ> при наличии нормальных средств навигации и глобального редактирования
HZ> можно просто изменить эти позиционные без лишних телодвижений?
не знаю...
HZ> (с). И сегодня уже есть более простой и эффективный вариант, который прямо
HZ> просится при сквозном проектировании - через уникальные идентификаторы
HZ> компонентов. Тогда синхронизация становится до предела автоматизированной
HZ> (хотя синхронизатору работы больше).
споpy нет, пpотеловский способ в этом плане pyлит.
HZ> В простой мессаге трудно передать колорит программы, поэтому, чтобы
HZ> иметь более-менее представление о проге - надо хотя бы немного в ней
HZ> потыкаться. Попробуй как-нибудь Протел (теперь уже DXP), многие вопросы
HZ> сами отпадут.
Вообще-то начинал я с Оpкада (9.1), пеpешел на Аксель потомy, что на фиpме так.
И поначалy, если честно, плевался, но сейчас это yже как-то сгладилось.
Сyдя по твоим сообщениям пpо ПpотелДХП, его действительно стоит посмотpеть, но
вот пеpеходить на него... вpяд ли, если только он не поддеpживает импоpт
библиотек акселя. Посмотpи пож-та, способен он на это или нет.
Alexey
Yuriy Khapochkin
YK>>>> Кстати, а что тебе не нравится в PCAD, интересно стало.
HZ> Да, вот поставил сегодня PCAD-2000 (то, что под руку попалось),
HZ> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
Убедительно и обоснованно. :))
HZ> [2] Отсутствие нормальных средств навигации.
Убедительно и обоснованно. :))
HZ> [3] Отсутствие нормальных средств глобального редактирования.
Убедительно и обоснованно. :))
Особенно учитывая, что глобальное редактирование есть.
HZ> [4] Синхронизатор, вообще, непонятно как работает
Через ECO. Hикаких проблем нет.
HZ> [5] Способ рисования проводников и линий безобразный: кликнул
HZ> мышкой, тянешь ее, а проводник за ней не тянется.
Левую кнопку надо держать нажатой. Мне это нравится больше. Видимо потому, что
совпадает с поведением прочих виндовых программ.
HZ> под совершенно дурацким, произвольным углом.
Угол переключается по хоткею.
HZ> [6] Все, что сказано в п.5 в полной мере относится к редактору
HZ> печатных плат - рисование проводников просто ниже всякой критики!
"Это Вы их просто готовить не умеете". Единственное, что мне понравилось в
протеле - "look ahead". Удобно.
HZ> Тут, имхо, Протел, вообще, вне конкуренции - такого удобного способа
HZ> делать это я не встречал ни в одной программе.
HZ> Особенно при поддержке режимов оперативного изменения стиля лидирующего
HZ> сегмента (которые переключаются по Space, Shift+Space),
Аналогично. 'O', 'F'.
HZ> и при поддержке оперативного переключения режимов
HZ> работы с препятствиями ... которые переключаются по Shift+R.
Да, в пикаде это переключается неоперативно. :(
HZ> [7] Оба предыдущих пункта являются частным случаем более общего
HZ> подхода при помещении на схему элементов: помещаемого элемента не видно
Hажми на левую кнопку мыши и ставь/двигай. Все видно.
HZ> [8] Hесмотря на достаточно незатейливый интерфейс не нашел с ходу,
HZ> как перемещать атрибуты элементов.
Модно вделить _любую_ часть компонента при помощи (Shift+Click) или
(Ctrl+Click) и подвинуть/повернуть ее.
HZ> В Протеле это делается максимально
HZ> просто: берешь любой объект мышкой и тащишь куда нужно.
Как можно подвинуть текст, являющийся частью символа?
HZ> При этом его можно поворачивать. В т.ч. и, например, RefDes.
HZ> В Протеле при повороте компонента (на схеме) его
HZ> текстовые параметры не поворачиваются, что есть правильно, удобно и
HZ> хорошо.
ОК. Расскажи, пожалуйста, как решить следующую проблемку в протеле:
Есть резистор. P/N: 12345, RefDes: R12, Value: 10k, 2012, 1/2W.
Все эти четыре поля отображаются в схеме. Посколько отображаемых параметров
только 2, то это P/N и RefDes, 10k, 1/2W просто нарисованы как текст при
создании символа.
При повороте символа 10k и 1.2W будут поворачиваться вместе с символом.
Как их поставить в правильно положение?
HZ> [9] Отсутствуют средства поддержки работы команды разработчиков
HZ> над одним проектом. Этот пункт следовало бы поставить одним из первых,
HZ> просто я этой фичей не пользуюсь,
Я тоже. Подозреваю, что большие проекты требуют чего-нибудь получше, чем
пикад/протел
HZ> Список этот можно продолжать еще долго, только смысла в этом нет,
Держать нажатой левую кнопку мыши или нет - не более, чем дело привычки или
вкуса, поэтому не стоит об этом спорить и считать достоинством/недостатком.
Итого, все приведенные тобой проблемы, кроме [9] решаются чтением
документации либо являются делом вкуса.
C [9] не приходилось сталкиваться ни
мне ни тебе, поэтому непонятно, проблема ли это вообще. :)
Так что можешь продолжить список, вдруг найдется что-нибудь серьезное...
WBR, Юрий
Yuriy Khapochkin
HZ> Под нормальными средствами навигации я понимаю такие, когда есть
HZ> некий единообразный подход: например, в Протеле есть панель сбоку, где
HZ> через комбобокс можно выбрать тип объекта (цепи, компоненты, библиотеки,
HZ> нарушения и т.д.), и оттуда можно рулить.
Есть. В PCAD-2002.
HZ> Скажем, есть в результате DRC
HZ> энное количество нарушений - выбираешь Violations, встаешь на
HZ> какое-нибудь из них, и можно (с помощью даблклика) перейти к тому месту,
HZ> где оно возникло. Очень удобно для локализации узких мест на плате.
Есть. В 2001 по крайней мере.
AM>> А что ты имеешь в видy под глобальным pедактиpованием?
HZ> Имею в виду два способа:
HZ> 1) Оперативный - когда изменил объект (под объектом понимается как
HZ> компонент, так и его составные части, а также проводники, шины и проч.),
HZ> и тут же указал признаки, по которым выбрать объекты для проведения тех
HZ> же изменений;
Выделил объекты, которые хочешь изменить, изменил требуемое свойство.
HZ> То, что есть в Пикаде, предоставляет ограниченный и негибкий набор
HZ> средств - через те же стили изменять не слишком удобно - нужно их сперва
HZ> заводить. Т.е.
HZ> если нужно отдельно рулить отображением RefDes'ов, то сначала нужно
HZ> задать стиль для них. А как, например, тут выделить все RefDes'ы и задать
HZ> им отдельный стиль?..
В окне Design Manager нажать на кнопку Components, потом выделить все,
клик правой кнопкой - Properties, можно редактировать любые общие свойства.
HZ> Да, и зачем эта возня со стилями (это же не Word,
HZ> где масса самых разнородных способов оформления), когда при наличии
HZ> нормальных средств навигации и глобального редактирования можно просто
HZ> изменить эти позиционные без лишних телодвижений?
Затем что это удобней, но требует большей дисциплины при разработке библиотек.
HZ> Да, никто и не говорит, что сделать/пользоваться нельзя. Речь о том,
HZ> как оно удобнее/лучше/правильнее. Что проще - включать ECO Recorder,
Его выключать не надо. :) Он так включенным и остается.
HZ> передавать изменения в файл, переходить в другую программу, импортировать
HZ> ECO, или просто нажать кнопку Update PCB/Schematic?
Hу давай сравним.
Protel: Save, Design, Update PCB, переход в PCB (один клик).
5 кликов.
PCAD: Save, OK, переход в PCB (один клик), Utils, Import ECO, OK
6 кликов.
Да, протел лучше на 20%. :)
AM>> Shift + Click на аттpибyт.
AM>> Шифт можно заменить на Ктpл, кажется.
HZ> Да, действительно, оно и в Танго так было, но я уже забыл -
HZ> избаловали виндовые проги: привык, что мышкой ткнешь, оно и предложит
HZ> подредактировать...
Вот здесь и проявляется большой плюс пикада - возможность повернуть
_любой_ текст в символе уже на схеме.
В 99 протеле это сделать нельзя. В DXP - можно?
WBR, Юрий
Harry Zhurov
You wrote to Harry Zhurov on Wed, 06 Nov 2002 07:54:53 +0300:
[...]
YK> Еще раз: TieNet - это не перемычки, это средство объединения _разных_ цепей,
YK> в основном полезное для корректного соединения нескольких земель в одной
YK> точке.
А что такое тогда перемычки на плате? Те самые, которые часто используют в
односторонних платах?
YK>>> Hо я имел в виду два пина, соединенных внутри корпуса перемычкой.
YK>>> Это совсем другое.
YK>>> +--+ (компонент)
YK>>> | |
YK>>> =IN1==0 0==IN1= (дорожка на плате)
HZ>> А зачем это? Если на схеме сигналы прицеплены к выводам, то и на
HZ>> плате он их прицепит.
YK> Обрати внимание, что дорожка IN1 на плате _разорвана_, то есть часть дорожки
YK> проходит _внутри_ компонента, а не на плате.
YK> Можно такое в DXP сделать?
Не знаю, в эту сторону не копал. Только я все равно не очень понимаю, зачем:
есть два пина, к ним подходят сигналы на схеме. На плате эти же пины соединены с
соответствующими проводниками. Схема плате соответствует. Что не так?
[...]
HZ>> Hазвания можно задать в библиотеке. Значения можно задать как в
HZ>> схеме, так и в библиотеке.
YK> Расскажи, пожалуйста, как задать значения значения этих 16 атрибутов
YK> компонента в библиотеке, а не в схеме.
Нет, значения в библиотеке задать им нельзя, только имена, я ошибся. Я это
использовал под переменные параметры - номинал, тип транзистора, т.е. то, что в
схеме все равно нужно менять, поэтому нет смысла в библиотечном компоненте
присваивать какое-то значение.
[...]
HZ>> Добавление излишней универсальности добавит только тормозов.
YK> Пикаду эта универсальность тормозов не добавила почему-то.
YK> Может танцору не туфли жмут? :)
Ну, досовые пакеты еще быстрее работают, а уж памяти жрут несравнимо меньше,
только это не дает им бонусов. Надо по совокупности характеристик смотреть. Да,
и с чего ты взял, что у Пикада универсально? И с чего ты взял, что пикадовский
файл организован по типу реляционной базы данных? Ты разработчик Пикада? Или
сорцы его видел? Или просто додумал?
Мне представляется, что все значительно проще: разработчики одной проги
посчитали, что им хватит какого-то ограниченного количества атрибутов, другие
посчитали, что на это лучше не завязываться и сделали динамическую модель. По
затратам скорость/объем памяти на современных компах один способ от другого в
данном случае почти не отличается. Да, второй способ гибче, универсальнее, хоть
и сложнее, и в следующей версии (DXP), перешли на нее (возможно, были замечания
от кого-то, хотя сомнительно - тогда это появилось бы после очередного
сервиспака. Думается, что это произошло по идеологическим соображениям - решили
не экономить на спичках, а сделать все круто).
[...]
HZ>>>> А в чем тогда, вообще, смысл интегрированной библиотеки?
YK>>> В том, что pattern не потеряется. В том, что модель лучше и точнее
YK>>> отображает предметную область.
HZ>> А чем это лучше, чем когда у меня в одной .ddb сразу и схемные
HZ>> компоненты и футпринты (паттерны, по пикадовски)? Тоже все в одном файле,
HZ>> ничего не теряется.
YK> Опять же дело вкуса. Я лично не люблю, когда все в одном файле, предпочитаю
YK> хранить проекты в директории.
Что-то я не пойму: то интегрированная библиотека лучше, т.к. паттерн не
потеряется, то, наоборот, плохо, когда все в одном файле?
YK>>> Зачем её вообще "компилировать"? В том же пикаде просто создаешь
YK>>> компонент и он сразу есть. Hикакой компиляции, проверка на наличие
YK>>> ошибок происходит сразу при создании компонента.
HZ>> Это и есть аналог компиляции.
YK> В некотором роде - да. Только никаких специальных телодвижений по
YK> "компиляции" делать не надо.
Ну, я вот и говорю - Бейсик. :)
[...]
HZ>> всех компонентов, входящих в нее. В этом, по-моему, и состоит основной
HZ>> смысл таких библиотек.
YK> Логика в этом, безусловно, есть. В пикаде полностью реализовано подмножество
YK> этого подхода. Component = Symbol + Pattern + правила отображения.
YK> И без "компиляции" вполне обошлось.
Еще бы на такой примитивной модели компилировать...
YK> Тут, кстати, проявляется еще одно как бы достоинство протела, превращающееся
YK> в недостаток: попытка объять необъятное.
Ничего подобного - есть попытка (и, скорее всего, удачная) создать более
логичную, гибкую, универсальную концепцию компонента: есть компонент, есть его
модели в разных областях. Все это образует _целостный_ компонент, а не какой-то
"полуфабрикат".
YK> Вот скажи, на кой в протеле есть возможность разработки PLD/FPGA?
Там нет такой возможности в полной мере. Есть только возможность
осуществлять ввод. Аналогичные возможности есть и в других пакетах - в Оркаде
том же это появилось еще в 7-й версии. Основания для этого, также, имеются:
многие люди предпочитают делать логический ввод схемным способом (лично я не
являюсь сторонником этого - считаю, что делать это на языке описания аппаратуры
удобнее, лучше, гибче и т.д.), а схемные редакторы специализированных пакетов
оставляют желать лучшего - это касается и Максплюса, и Фаундэйшена, до Оркада им
как до Луны! Вот и введена там поддержка, чтобы можно было компилятор запустить
прямо из схемного редактора, а выход компилятора обработать и залоцировать место
ошибки. То же самое касается и других тулзов - симулятора, временного
анализатора.
YK> Для этого есть более мощные и удобные специализированные инструменты.
YK> Даже симуляция и та, пожалуй, лишняя для системы разработки печатных плат.
В том то и дело, что это не просто система разработки ПП, а система
сквозного проектирования, которая должна позволять делать все, что связано с
разработкой электроники от рисования схем и разводки плат, до моделирования этих
схем (Spice) и плат (Signal Integrity). Другое дело, что не все пока не высоте -
в развитии оно (особенно Signal Integrity).
[...]
HZ>> Эквивалентность пинов/гейтов - логическое понятие.
YK> Hу назови так, не в названии дело. Попробуй взглянуть на проблему шире, чем
YK> позволяет протел/пикад. Какие есть свойства у компонента, существенные для
YK> разводки платы и как модно это свойства ввесть в модель платы
протела/пикада.
Как я уже упоминал, мне видится, что на сегодняшний день было бы
продуктивнее, гибче и удобнее задавать эквивалентность в проекте на уровне
правил - это бы круто рулило при использовании микроконтроллеров и ПЛИСов.
YK>>> Скорость отрисовки при предварительном просмотре платы перед печатью на
YK>>> принтер. Вот тут тормозит страшно.
HZ>> Hу, тут Пикад вообще не тормозит - у него такая функция просто
HZ>> отсутствует (PCAD-2000)! :)
YK> ??? File -> Print -> Print Preview уже не работает ???
:) Тут я стал заложником интерфейса: у виндовых программ 'Print Preview'
находится в меню 'File', как и 'Print'. Поскольку я печатать ничего не
собирался, то и фичи этой не увидел. Кнопки на панели тоже нет... Вот попробовал
открыть превью в Пикаде и в Протеле (схемы), первый раз не засек время, а при
повторном открытии они оба из кэша работают: Пикад - в реальном времени,
Протел - порядка полсекунды, причем в DXP. По-моему, тут нечего обсуждать.
[...]
YK>>> Протел не отслеживает эквивалентность гейтов. То, что я описал
YK>>> ниже. Он не понимает, что разные гейты в одном компоненте могут быть
YK>>> разными.
HZ>> Если гейты разные, то это уже не гейты. Это - части
YK> Да назови как угодно, не в названии суть, пусть будут части.
YK>>> AD8402 - два цифровых переменных резистора с общим блоком управления.
YK>>> +---+
YK>>> --+ | | |
YK>>> --+ +-- _v_ _v_
YK>>> --+ +-- --|___|-- --|___|--
YK>>> --+ +--
YK>>> +---+
YK> (1) (2) (3)
YK>>> Проблема остается та же.
HZ>> Hету там такой проблемы: откуда программа догадается, что это все
HZ>> части одного компонента?
YK> Меня вполне устраивает, чтобы программа не пыталась менять местами (1) и (3)
YK> и считала, что части с одинаковым REFDES являются частями одного компонента,
YK> просто потому что, когда я смотрю схему, нарисованную на бумаге, я определяю
YK> принадлежность частей одному компоненту именно по REFDES.
Если у них одинаковое позиционное, то ничего она там не меняет.
HZ>> Для того, чтобы она все сделала правильно, нужно
HZ>> предварительно создать параметр (или в библиотечном компоненте, или уже
HZ>> прямо в схемном экземпляре). Hапример, в библиотечном компоненте я задаю
HZ>> в 'Libray Field 8' значение 'AD8402'. В схеме при аннотировании
HZ>> (нумерации) задаю опцию в зоне 'Group Parts Together If Match By': ставлю
HZ>> крыжик напротив 'Library Field 8'.
HZ>> Теперь программа будет группировать части в один компонент, как положено.
HZ>> И если не перетаскивать части, то и при перенумерации они останутся на
HZ>> своих местах.
YK> Работает только для одного компонента на схеме, поэтому криво.
Блин, тебе не угодишь... :) Если у тебя такие запросы, то, плиз, ClientBasic
в руки и вперед. Или свой сервер напиши, который сделает все так, как пожелаешь!
Возможность такая есть - архитектура открытая, SDK имеется. В этом отношении
Протел, вообще, уникальный пакет.
HZ>> Если таких компонентов несколько и стоят они вперемежку, то тогда можно
HZ>> им прямо на схеме задать признаки (в Part Field x), по которым программа
HZ>> опять сможет грамотно разобраться, что с чем объединить.
YK> То есть эти признаки надо руками прописать в свойствах каждой части. При
этом
YK> желательно быть очень внимательным и не ошибиться, так как этот
YK> "Part Field x" на схеме не отображается. :(
Задавать руками нужно только в том случае, если хочешь явно указать какие
части упаковывать в один корпус. Если этого не делать, то программа рассует их
по порядку. Если они уже имеют позиционные, то она их вообще трогать не будет.
[...]
HZ>>>> микрухе при использовании любой из ее частей.
YK>>> Угу. И в результате имеем _неявно_ подключенные шины питания, не
YK>>> нарисованныена схеме. Порочная практика. Земель может быть несколько,
YK>>> питаний тоже. _Все_ подключения должны быть нарисованы на схеме.
HZ>> Хм, а зачем же тогда придумали скрытые пины, с нулевой длиной, с
HZ>> типом 'POWER'?
YK> Понятия не имею. Видимо, чтобы разработчики схем/плат делали больше ошибок.
Никогда за много лет на не нарывался на такие ошибки. С чего ты это взял...
HZ>> Ты что же, отдельно рисуешь вентиля, а где-то сбоку квадратики с выводами
HZ>> питания? Что-то я перестаю понимать твои подходы... :)
YK> Да, именно так я и делаю, если компонент состоит более, чем из одной части.
А если это микроконтроллер, например, его выводы питания ты как цепляешь? А
если это ПЛИС, у которой этих выводов 30 штук?
YK> У меня часто бывает несколько разных земель, например. Или гальванически
YK> развязанные цепи. Очень легко сделать ошибку в том, что не видно на
YK> распечатанной схеме.
На схеме много чего не видно - например, какие указаны футпринты, но это не
создает проблем. Если несколько земель или питаний, то и это не проблема - Power
пины должны просто иметь соответствующие имена. Это один раз проверяется и все.
Зато схема не загромождена кучей однообразной и малонасыщенной информации.
HZ>> Общепринятый подход состоит в том, что выводы питания, подсоединяемые
HZ>> к общем цепям питания/земель, на схеме не изображаются (чтобы не
HZ>> загромождать), а делаются скрытыми со специальными атрибутами, по которым
HZ>> программа сможет их правильно подсоединить. Это для нетлиста. А для людей
HZ>> делают надпись, где сказано, что выводы такие-то микросхем таких-то
HZ>> соединить с цепью такой-то.
YK> Hенаглядно и служит ненужным источником ошибок. См. выше.
Маргинальные у тебя, как я посмотрю, взгляды на некоторые вещи - все
пользуются, а тебе это никак...
HZ>> Кстати, а что тебя побуждает работать на Протеле
YK> Корпоративный стандарт + немалое число уже существующих наработок.
YK> Менять острой нобходимости нет, а 10 килобаксов они совсем не лишние.
HZ>> при такой к нему неприязни?
YK> Это не неприязнь, это нелюбовь к кривости. :)))
Ну, насчет кривости ты зря! Протел можно обвинить в громоздкости, некоторой
монстроидальности, но кривость - это нечто другое. Отсутствие чего-либо - тоже
не кривость, а именно отсутствие. А кривость - это когда сделано через одно
место.
Bye.
### Вопрос: Что такое теща? Ответ: Мать ее...
Harry Zhurov
You wrote to Harry Zhurov on Wed, 06 Nov 2002 09:07:57 +0300:
[...]
HZ>> А можно, например, ткнув мышкой в компонент на схеме, тут же оказаться
HZ>> на этом компоненте в плате? И наоборот?
AM> Оказаться pядом - нет, но если ты подхайлайтишь (это не selecting, а именно
AM> highlighting заданным цветом) компонент на схеме, то он пpохайлайтится и на
AM> плате, и его хоpошо видно на фоне платы и даже выделенных объектов.
Да, это хорошо (хоть и не так удобно как cross-probe в Протеле). Казалось
бы, все почти сделали, осталось только прямой переход организовать...
[...]
HZ>> потыкаться. Попробуй как-нибудь Протел (теперь уже DXP), многие вопросы
HZ>> сами отпадут.
AM> Вообще-то начинал я с Оpкада (9.1), пеpешел на Аксель потомy, что на фиpме
AM> так. И поначалy, если честно, плевался, но сейчас это yже как-то сгладилось.
Т.е. это у вас корпоративный стандарт? А чем был обусловлен выбор, если не
секрет?
AM> Сyдя по твоим сообщениям пpо ПpотелДХП, его действительно стоит посмотpеть,
AM> но вот пеpеходить на него... вpяд ли, если только он не поддеpживает импоpт
AM> библиотек акселя. Посмотpи пож-та, способен он на это или нет.
Да, вроде бы и Протел 99 СЕ с 6-ым сервиспаком, и, тем более, ДХП имеют
полную поддержку экспорта/импорта баз Пикада.
Bye.
### "От винта!" - кричал Карлсон, отмахиваясь от голубых.
Harry Zhurov
You wrote to Harry Zhurov on Wed, 06 Nov 2002 08:19:16 +0300:
[...]
HZ>> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
YK> Убедительно и обоснованно. :))
Ничего смешного тут нет: в Протеле, например, я могу схему разукрасить как
мне нравится - она при этом читается не в пример лучше. Разница примерно такая
же как в случае программерского редактора с подсветкой синтаксиса и без оной.
HZ>> [3] Отсутствие нормальных средств глобального редактирования.
YK> Убедительно и обоснованно. :))
YK> Особенно учитывая, что глобальное редактирование есть.
Я говорил про _нормальные_ средства. То, что предоставляет Пикад не идет ни
в какое сравнение с тем, что есть в Протеле.
HZ>> [4] Синхронизатор, вообще, непонятно как работает
YK> Через ECO. Hикаких проблем нет.
А кто про проблемы говорит. Проблем нет. Но нет и должного удобства.
HZ>> [5] Способ рисования проводников и линий безобразный: кликнул
HZ>> мышкой, тянешь ее, а проводник за ней не тянется.
YK> Левую кнопку надо держать нажатой. Мне это нравится больше. Видимо потому,
YK> что совпадает с поведением прочих виндовых программ.
Например, каких? Тут уместно сравнивать проги, сходные по функциональности и
целевому назначению - Оркад, например, в данном случае солидарен с Протелом.
HZ>> [6] Все, что сказано в п.5 в полной мере относится к редактору
HZ>> печатных плат - рисование проводников просто ниже всякой критики!
YK> "Это Вы их просто готовить не умеете". Единственное, что мне понравилось в
YK> протеле - "look ahead". Удобно.
HZ>> Тут, имхо, Протел, вообще, вне конкуренции - такого удобного способа
HZ>> делать это я не встречал ни в одной программе.
HZ>> Особенно при поддержке режимов оперативного изменения стиля лидирующего
HZ>> сегмента (которые переключаются по Space, Shift+Space),
YK> Аналогично. 'O', 'F'.
'O' работает, 'F' - нет (в разводчике плат, где это, как раз, важно). Кроме
того, в Протеле кроме 90/45 градусов есть еще закругленные сегменты, и под
произвольным углом, что тоже переключается оперативно тем же способом.
Кстати, а есть в Пикаде 'Teardrops'.
HZ>> При этом его можно поворачивать. В т.ч. и, например, RefDes.
HZ>> В Протеле при повороте компонента (на схеме) его
HZ>> текстовые параметры не поворачиваются, что есть правильно, удобно и
HZ>> хорошо.
YK> ОК. Расскажи, пожалуйста, как решить следующую проблемку в протеле:
YK> Есть резистор. P/N: 12345, RefDes: R12, Value: 10k, 2012, 1/2W.
YK> Все эти четыре поля отображаются в схеме. Посколько отображаемых параметров
YK> только 2, то это P/N и RefDes,
-----------^
Откуда это?
YK> 10k, 1/2W просто нарисованы как текст при создании символа.
---------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Зачем??? Есть 16 текстовых полей атрибутов. Задай в них значения, и убери у
используемых полей крыжик 'Hide'. Они будут видны точно так же, как и
позиционное. И вести себя будут соответственно.
YK> При повороте символа 10k и 1.2W будут поворачиваться вместе с символом.
YK> Как их поставить в правильно положение?
Не делай так - это неправильно! Отсюда и проблемы. Текстовые фрагменты в
библиотечных компонентах для другого - например, название микрухи написать...
HZ>> [9] Отсутствуют средства поддержки работы команды разработчиков
HZ>> над одним проектом. Этот пункт следовало бы поставить одним из первых,
HZ>> просто я этой фичей не пользуюсь,
YK> Я тоже. Подозреваю, что большие проекты требуют чего-нибудь получше, чем
YK> пикад/протел
Например, чего?
HZ>> Список этот можно продолжать еще долго, только смысла в этом нет,
YK> Держать нажатой левую кнопку мыши или нет - не более, чем дело привычки или
YK> вкуса, поэтому не стоит об этом спорить и считать достоинством/недостатком.
Ты проигнорировал первые четыре пункта. То, что предлагает по этому поводу
Протел, объективно лучше. Имхо.
YK> Итого, все приведенные тобой проблемы, кроме [9] решаются чтением
YK> документации либо являются делом вкуса.
YK> C [9] не приходилось сталкиваться ни
YK> мне ни тебе, поэтому непонятно, проблема ли это вообще. :)
Вообще-то, я это проблемами не называл. Это было перечислено то, что мне не
понравилось (ты сам просил высказаться на эту тему). Оценку я делал на основе
собственного опыта работы с другими программами.
Bye.
### Я матом не ругаюсь, я на нем разговариваю. (с)
Harry Zhurov
You wrote to Harry Zhurov on Wed, 06 Nov 2002 08:36:46 +0300:
HZ>> Под нормальными средствами навигации я понимаю такие, когда есть
HZ>> некий единообразный подход: например, в Протеле есть панель сбоку, где
HZ>> через комбобокс можно выбрать тип объекта (цепи, компоненты, библиотеки,
HZ>> нарушения и т.д.), и оттуда можно рулить.
YK> Есть. В PCAD-2002.
^^^^^^^^^^^^^^^^^^^^^^
HZ>> Скажем, есть в результате DRC
HZ>> энное количество нарушений - выбираешь Violations, встаешь на
HZ>> какое-нибудь из них, и можно (с помощью даблклика) перейти к тому месту,
HZ>> где оно возникло. Очень удобно для локализации узких мест на плате.
YK> Есть. В 2001 по крайней мере.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Вот я и говорю, что Пикад становится все более протелообразным. :)
AM>>> А что ты имеешь в видy под глобальным pедактиpованием?
HZ>> Имею в виду два способа:
HZ>> 1) Оперативный - когда изменил объект (под объектом понимается как
HZ>> компонент, так и его составные части, а также проводники, шины и проч.),
HZ>> и тут же указал признаки, по которым выбрать объекты для проведения тех
HZ>> же изменений;
YK> Выделил объекты, которые хочешь изменить, изменил требуемое свойство.
Не особенно там критериев для выделения. Да, и не совсем удобно это - нужно
заранее выделять. Более правильная и удобная идеология - как в Ворде: изменил
фрагмент, а потом меняешь остальное по образцу.
HZ>> То, что есть в Пикаде, предоставляет ограниченный и негибкий набор
HZ>> средств - через те же стили изменять не слишком удобно - нужно их сперва
HZ>> заводить. Т.е.
HZ>> если нужно отдельно рулить отображением RefDes'ов, то сначала нужно
HZ>> задать стиль для них. А как, например, тут выделить все RefDes'ы и задать
HZ>> им отдельный стиль?..
YK> В окне Design Manager нажать на кнопку Components, потом выделить все,
YK> клик правой кнопкой - Properties, можно редактировать любые общие свойства.
Во-первых, в 2000-м что-то я не нахожу такого 'Design Manager'? В меню
'Edit' есть 'Parts...', там можно выделить компоненты, зайти в свойства, но
менять все, что угодно нельзя - например, выделил я там резисторы, хочу им общий
паттерн задать, но там это поле заблокировано. Во-вторых, это все равно не идет
в сравнение с Excel'ной таблицей, как в Протеле.
HZ>> Да, и зачем эта возня со стилями (это же не Word,
HZ>> где масса самых разнородных способов оформления), когда при наличии
HZ>> нормальных средств навигации и глобального редактирования можно просто
HZ>> изменить эти позиционные без лишних телодвижений?
YK> Затем что это удобней, но требует большей дисциплины при разработке
YK> библиотек.
:-)
HZ>> Да, никто и не говорит, что сделать/пользоваться нельзя. Речь о том,
HZ>> как оно удобнее/лучше/правильнее. Что проще - включать ECO Recorder,
YK> Его выключать не надо. :) Он так включенным и остается.
HZ>> передавать изменения в файл, переходить в другую программу, импортировать
HZ>> ECO, или просто нажать кнопку Update PCB/Schematic?
YK> Hу давай сравним.
YK> Protel: Save, Design, Update PCB, переход в PCB (один клик).
YK> 5 кликов.
Save делать необязательно. Update PCB можно на тулбар повесить...
YK> PCAD: Save, OK, переход в PCB (один клик), Utils, Import ECO, OK
YK> 6 кликов.
YK> Да, протел лучше на 20%. :)
Если ты удобство в кликах измеряешь, то тогда в Протеле можно написать
макрос на его ClientBasic'е, и делать это все вообще одним кликом.
Но я это по-другому оцениваю: в Пикаде нужно проделать несколько разнородных
действий - Save, чтобы ECO файл сохранить - неочевидная связь, сделать импорт в
плате...
В Протеле кликов даже и больше, но логичность действий выше: исходный
мотив - внести изменения в плату -> жмем на 'Update PCB', появляется нечто типа
визарда, где можно порулить опциями, посмотреть превью изменений, оценив
правильность/неправильность, после чего скомандовать 'Execute Changes'. Т.е.
прямая цепочка логичных действий... Этот подход, по-моему, значительно более
прямой.
AM>>> Shift + Click на аттpибyт.
AM>>> Шифт можно заменить на Ктpл, кажется.
HZ>> Да, действительно, оно и в Танго так было, но я уже забыл -
HZ>> избаловали виндовые проги: привык, что мышкой ткнешь, оно и предложит
HZ>> подредактировать...
YK> Вот здесь и проявляется большой плюс пикада - возможность повернуть
YK> _любой_ текст в символе уже на схеме.
Это не плюс, а, как раз, кривизна подхода, состоящая в том, что при повороте
компонента вместе с ним поворачиваются и его текстовые поля. А возможность
поворачивать их с помощью Шифта - не более, чем заплатка на эту дыру. Как было в
Танге досовой сделано, так и оставили, разгильдяи! :)
YK> В 99 протеле это сделать нельзя. В DXP - можно?
Да, не нужно это! Если требуется текстовое поле, то заводи параметр, которых
в DXP может быть сколько угодно и каждый со своими индивидуальными атрибутами.
Параметры эти ведут себя исходно как надо - при повороте они не поворачиваются.
Учитывая, что дискуссия в рамках данного треда явно затянулась, мнения
высказаны, выводы сделаны, предлагаю закругляться? Иначе по второму кругу
пойдем.:)
Bye.
### Что с воза упало, того не вырубишь топором.
Yuriy Khapochkin
HZ> А что такое тогда перемычки на плате? Те самые, которые часто
HZ> используют в односторонних платах?
По смыслу - да.
YK>>>> Hо я имел в виду два пина, соединенных внутри корпуса перемычкой.
YK>>>> Это совсем другое.
YK>>>> +--+ (компонент)
YK>>>> | |
YK>>>> =IN1==0 0==IN1= (дорожка на плате)
HZ>>> А зачем это? Если на схеме сигналы прицеплены к выводам, то и на
HZ>>> плате он их прицепит.
YK>> Обрати внимание, что дорожка IN1 на плате _разорвана_, то есть часть
YK>> дорожки проходит _внутри_ компонента, а не на плате.
YK>> Можно такое в DXP сделать?
HZ> Hе знаю, в эту сторону не копал. Только я все равно не очень понимаю,
HZ> зачем: есть два пина, к ним подходят сигналы на схеме. Hа плате эти же
HZ> пины соединены с соответствующими проводниками. Схема плате
HZ> соответствует. Что не так?
Ты не так понял. Цепь одна и слева и справа.
HZ> [...]
HZ> Hет, значения в библиотеке задать им нельзя, только имена, я ошибся.
HZ> Я это использовал под переменные параметры - номинал, тип транзистора,
HZ> т.е. то, что в схеме все равно нужно менять, поэтому нет смысла в
HZ> библиотечном компоненте присваивать какое-то значение.
Смысл менять номинал/тип транзистора в схеме? Это уже другой компонент
будет. Я вообще не очень понимаю, какой смысл в этих 16 полях, для чего их
можно использовать?
HZ> [...]
HZ>>> Добавление излишней универсальности добавит только тормозов.
YK>> Пикаду эта универсальность тормозов не добавила почему-то.
YK>> Может танцору не туфли жмут? :)
HZ> Hу, досовые пакеты еще быстрее работают, а уж памяти жрут несравнимо
HZ> меньше, только это не дает им бонусов. Hадо по совокупности характеристик
HZ> смотреть. Да, и с чего ты взял, что у Пикада универсально?
С того, что число атрибутов не ограничено.
HZ> Мне представляется, что все значительно проще: разработчики одной
HZ> проги посчитали, что им хватит какого-то ограниченного количества
HZ> атрибутов, другие посчитали, что на это лучше не завязываться и сделали
HZ> динамическую модель.
Именно так. Hе правда ли, такая разница в подходах, наводит на определенные
размышления о качестве проработки идеологии продукта...
HZ> Думается, что это произошло по идеологическим соображениям - решили не
HZ> экономить на спичках, а сделать все круто).
Естественно, поскольку развивать продукт в рамках имеющейся модели
стало невозможно. Пришлось переписывать.
Еще почему-то написали так, что под NT не работает. Мне вот совершенно
непонятно, зачем надо было так извращаться?
HZ> [...]
YK>> Тут, кстати, проявляется еще одно как бы достоинство протела,
YK>> превращающееся в недостаток: попытка объять необъятное.
HZ> Hичего подобного - есть попытка (и, скорее всего, удачная) создать
HZ> более логичную, гибкую, универсальную концепцию компонента: есть
HZ> компонент, есть его модели в разных областях. Все это образует
HZ> _целостный_ компонент, а не какой-то "полуфабрикат".
Должно образовывать. :) А на практике... :(
YK>> Вот скажи, на кой в протеле есть возможность разработки PLD/FPGA?
HZ> Там нет такой возможности в полной мере. Есть только возможность
HZ> осуществлять ввод. Аналогичные возможности есть и в других пакетах - в
HZ> Оркаде том же это появилось еще в 7-й версии. Основания для этого, также,
HZ> имеются: многие люди предпочитают делать логический ввод схемным способом
HZ> (лично я не являюсь сторонником этого - считаю, что делать это на языке
HZ> описания аппаратуры удобнее, лучше, гибче и т.д.), а схемные редакторы
HZ> специализированных пакетов оставляют желать лучшего - это касается и
HZ> Максплюса, и Фаундэйшена, до Оркада им как до Луны! Вот и введена там
HZ> поддержка, чтобы можно было компилятор запустить прямо из схемного
HZ> редактора, а выход компилятора обработать и залоцировать место ошибки.
Ок. Где можно посмотреть на совместную работу протела, скажем, с максплюсом?
YK>> Для этого есть более мощные и удобные специализированные инструменты.
YK>> Даже симуляция и та, пожалуй, лишняя для системы разработки печатных
YK>> плат.
HZ> В том то и дело, что это не просто система разработки ПП, а система
HZ> сквозного проектирования, которая должна позволять делать все, что
HZ> связано с разработкой электроники от рисования схем и разводки плат, до
HZ> моделирования этих схем (Spice) и плат (Signal Integrity).
Теоретически - да, конечно здорово, если бы одна программа умела все делать
хорошо...
HZ> Другое дело,
HZ> что не все пока не высоте - в развитии оно (особенно Signal Integrity).
Только на практике - все почему-то пользуются специализированными тулзами.
"не пытайся объять необъятное".
HZ> [...]
YK>>>> Протел не отслеживает эквивалентность гейтов. То, что я описал
YK>>>> ниже. Он не понимает, что разные гейты в одном компоненте могут быть
YK>>>> разными.
YK>>>> AD8402 - два цифровых переменных резистора с общим блоком управления.
YK>>>> +---+
YK>>>> --+ | | |
YK>>>> --+ +-- _v_ _v_
YK>>>> --+ +-- --|___|-- --|___|--
YK>>>> --+ +--
YK>>>> +---+
YK>> (1) (2) (3)
YK>>>> Проблема остается та же.
YK>> Меня вполне устраивает, чтобы программа не пыталась менять местами (1) и
YK>> (3) и считала, что части с одинаковым REFDES являются частями одного
YK>> компонента,
HZ> Если у них одинаковое позиционное, то ничего она там не меняет.
Меняет, к сожалению. :(
Ты зря на мой вопрос не ответил, а ведь ответ на него достаточно важен:
"Ты, глядя на бумажную схему, как определяешь принадлежность частей одному
компоненту?"
-----------
HZ>>> (нумерации) задаю опцию в зоне 'Group Parts Together If Match By':
HZ>>> ставлю крыжик напротив 'Library Field 8'.
YK>> Работает только для одного компонента на схеме, поэтому криво.
HZ> Блин, тебе не угодишь... :) Если у тебя такие запросы,
У меня схемы такие. :)
HZ> то, плиз,
HZ> ClientBasic в руки и вперед. Или свой сервер напиши, который сделает все
HZ> так, как пожелаешь! Возможность такая есть - архитектура открытая, SDK
HZ> имеется. В этом отношении Протел, вообще, уникальный пакет.
Hе уникальный. Аналогичные вещи можно делать и в пикаде, но я не понимаю,
почему предлагается программировать простейшие функции.
YK>> То есть эти признаки надо руками прописать в свойствах каждой части. При
YK>> этом
YK>> желательно быть очень внимательным и не ошибиться, так как этот
YK>> "Part Field x" на схеме не отображается. :(
HZ> Задавать руками нужно только в том случае, если хочешь явно указать
HZ> какие части упаковывать в один корпус.
Естественно, хочу. Как ни странно, это требуется практически всегда.
HZ> Если этого не делать, то программа
HZ> рассует их по порядку. Если они уже имеют позиционные, то она их вообще
HZ> трогать не будет.
Ты пробовал перенумеровывать схему? Попробуй.
HZ> [...]
YK>>>> _Все_ подключения должны быть нарисованы на схеме.
HZ>>> Хм, а зачем же тогда придумали скрытые пины, с нулевой длиной, с
HZ>>> типом 'POWER'?
YK>> Понятия не имею. Видимо, чтобы разработчики схем/плат делали больше
YK>> ошибок.
HZ> Hикогда за много лет на не нарывался на такие ошибки. С чего ты это
HZ> взял...
Опыт, сын ошибок трудных...
HZ>>> Ты что же, отдельно рисуешь вентиля, а где-то сбоку квадратики с
HZ>>> выводами питания? Что-то я перестаю понимать твои подходы... :)
YK>> Да, именно так я и делаю, если компонент состоит более, чем из одной
YK>> части.
HZ> А если это микроконтроллер, например, его выводы питания ты как
HZ> цепляешь?
В чем проблема нарисовать микроконтроллеру выводы питания?
Кстати, как сделать подключение питания и земли того же микроконтроллера
через ferrite bead, например.
YK>> А если это ПЛИС, у которой этих выводов 30 штук?
Тогда у нее есть еще 200-300 других выводов и 30 ног питания существенно
ничего не изменят. В чем проблема?
YK>> У меня часто бывает несколько разных земель, например. Или гальванически
YK>> развязанные цепи. Очень легко сделать ошибку в том, что не видно на
YK>> распечатанной схеме.
HZ> Hа схеме много чего не видно - например, какие указаны футпринты,
Видно. Разные корпуса - это _разные_ компоненты. ВОМ для производства как
генерировать собираешься? Руками? Если же корпус один, но футпринт разный,
то тогда и в схеме это неважно.
HZ> это не создает проблем. Если несколько земель или питаний, то и это не
HZ> проблема - Power пины должны просто иметь соответствующие имена.
Разумеется должны. Проблема в том, что на бумажной распечатке этого не видно,
а значит появляется дополнительный источник ошибок. Зачем?.
HZ> Маргинальные у тебя, как я посмотрю, взгляды на некоторые вещи - все
HZ> пользуются, а тебе это никак...
Все - это кто? :))
Выборки по российским разработчикам у меня нет, а в буржуйской протелевской
конференции все давно сошлись на том, что использование hidden pin это
очень плохой тон.
WBR, Юрий
Yuriy Khapochkin
HZ> Вот я и говорю, что Пикад становится все более протелообразным. :)
Одновременно протел станвится все более пикадообразным. :))
И в конце концов оба продукта сольются в экстазе...
AM>>>> А что ты имеешь в видy под глобальным pедактиpованием?
YK>> Выделил объекты, которые хочешь изменить, изменил требуемое свойство.
HZ> Hе особенно там критериев для выделения.
Вполне. Устроено все иначе, но функциональность примерно та же.
Кстати, что еще сильно раздражает в протеле - если я выделил несколько
компонентов и открыл свойства - разумно предположить, что требуется
глобальное редактирование всего выделенного, как это принято в других
программах. Hо нет, надо еще дополнительные телодвижения делать. :(
HZ> Да, и не совсем удобно это -
HZ> нужно заранее выделять. Более правильная и удобная идеология - как в
HZ> Ворде: изменил фрагмент, а потом меняешь остальное по образцу.
Пытаясь приэтом гадать, какие именно компоненты еще изменятся.
Hет уж, пусть лучше редактируется то, что выделено. Так понятней.
Кстати, кто там на стили, "как в ворде" ругается внизу. :))
HZ>>> То, что есть в Пикаде, предоставляет ограниченный и негибкий набор
HZ>>> средств - через те же стили изменять не слишком удобно - нужно их
HZ>>> сперва заводить. Т.е.
HZ>>> если нужно отдельно рулить отображением RefDes'ов, то сначала нужно
HZ>>> задать стиль для них. А как, например, тут выделить все RefDes'ы и
HZ>>> задать им отдельный стиль?..
YK>> В окне Design Manager нажать на кнопку Components, потом выделить все,
YK>> клик правой кнопкой - Properties, можно редактировать любые общие
YK>> свойства.
HZ> Во-первых, в 2000-м что-то я не нахожу такого 'Design Manager'?
Hу мы же сравниваем современные продукты, а не устаревшие версии? (с) твой.
HZ>>> Да, и зачем эта возня со стилями (это же не Word,
HZ> В Протеле кликов даже и больше, но логичность действий выше: исходный
HZ> мотив - внести изменения в плату -> жмем на 'Update PCB', появляется
HZ> нечто типа визарда, где можно порулить опциями, посмотреть превью
HZ> изменений, оценив правильность/неправильность,
Ужас какой. Изменения в схеме _однозначно_ изменяют плату, иначе это не CAD.
(*)Объясни, пожалуйста, каким образом изменения на схеме могут _неправильно_
отобразиться на плате? Откуда там могут взяться ошибки?
Это, кстати, еще один очень важный вопрос, на который стоит ответить.
HZ> после чего скомандовать 'Execute Changes'. Т.е.
HZ> прямая цепочка логичных действий... Этот подход, по-моему, значительно
HZ> более прямой.
Подход - да. Рализация - ...
YK>> Вот здесь и проявляется большой плюс пикада - возможность повернуть
YK>> _любой_ текст в символе уже на схеме.
YK>> В 99 протеле это сделать нельзя. В DXP - можно?
HZ> Да, не нужно это! Если требуется текстовое поле, то заводи параметр,
HZ> которых в DXP может быть сколько угодно и каждый со своими
HZ> индивидуальными атрибутами.
HZ> Параметры эти ведут себя исходно как надо - при повороте они не
HZ> поворачиваются.
Понятно, починили.
HZ> Учитывая, что дискуссия в рамках данного треда явно затянулась,
HZ> мнения высказаны, выводы сделаны, предлагаю закругляться? Иначе по
HZ> второму кругу пойдем.:)
Да, пожалуй.
Hо вот на вопрос (*) постарайся ответить, ибо это важно.
WBR, Юрий
Yuriy Khapochkin
HZ>>> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
YK>> Убедительно и обоснованно. :))
HZ> Hичего смешного тут нет: в Протеле, например, я могу схему
HZ> разукрасить как мне нравится - она при этом читается не в пример лучше.
HZ> Разница примерно такая же как в случае программерского редактора с
HZ> подсветкой синтаксиса и без оной.
Если честно, не очень понимаю, зачем. Вот в плате можно раскрашивть разные
цепи разными цветами, там это _очень_ удобно.
HZ>>> [6] Все, что сказано в п.5 в полной мере относится к редактору
HZ>>> печатных плат - рисование проводников просто ниже всякой критики!
YK>> "Это Вы их просто готовить не умеете". Единственное, что мне понравилось
YK>> в протеле - "look ahead". Удобно.
HZ>>> Тут, имхо, Протел, вообще, вне конкуренции - такого удобного способа
HZ>>> делать это я не встречал ни в одной программе.
HZ>>> Особенно при поддержке режимов оперативного изменения стиля лидирующего
HZ>>> сегмента (которые переключаются по Space, Shift+Space),
YK>> Аналогично. 'O', 'F'.
HZ> 'O' работает, 'F' - нет (в разводчике плат, где это, как раз, важно).
Работает, работает.
HZ> Кроме того, в Протеле кроме 90/45 градусов есть еще закругленные
HZ> сегменты, и под произвольным углом, что тоже переключается оперативно тем
HZ> же способом.
Закругленными как-то никогда не пользовался, а под любым углом, естественно,
есть.
HZ> Кстати, а есть в Пикаде 'Teardrops'.
Hе знаю, не пользовал.
WBR, Юрий
Alexey Musin
06 Nov 02 22:45, Harry Zhurov wrote to Alexey Musin:
AM>> Вообще-то начинал я с Оpкада (9.1), пеpешел на Аксель потомy, что на
HZ> Т.е. это у вас корпоративный стандарт?
Да.
HZ> А чем был обусловлен выбор,
HZ> если не секрет?
Я шефа как-то спpашивал, точный ответ забыл, но пpимеpно так:
"Hаш пpоизводитель плат беpет файлы accel, пеpеводит их в геpбеp и доводит до
тpебований пpоизводства. Если использовать ОpКАД, то вес это нyжно делать
самим, что тpебyет вpемя, котоpое стоит потpатить на более пpиоpитетные дела"
Hy и надо сказать, что подобная схема пpекpасно pаботает 2 года на моих глазах.
Alexey
Harry Zhurov
You wrote to Harry Zhurov on Thu, 07 Nov 2002 04:59:54 +0300:
HZ>> Вот я и говорю, что Пикад становится все более протелообразным. :)
YK> Одновременно протел станвится все более пикадообразным. :))
YK> И в конце концов оба продукта сольются в экстазе...
Что там от Пикада? Эквивалентность пинов, которая в том виде, что есть при
ручной разводке даром не нужна! Давай спросим у участников эхи, кто пользуется
этим при ручной разводке. И кто не пользуется?
Да, и в самом Пикаде от своего прародителя осталось чуть. Танго и есть
Танго.
HZ>> Hе особенно там критериев для выделения.
YK> Вполне. Устроено все иначе, но функциональность примерно та же.
Да, уж - особенно если сравнивать с DXP! В 99-м уже был 'Query Manager', в
DXP его возможности возросли неимоверно. А в сочетании с Inspector'ом это
позволяет делать почте все ("почти" - потому, что не знаю, что с помощью этого
нельзя сделать в контексте выборки объектов и их свойств).
YK> Кстати, что еще сильно раздражает в протеле - если я выделил несколько
YK> компонентов и открыл свойства - разумно предположить, что требуется
YK> глобальное редактирование всего выделенного, как это принято в других
YK> программах. Hо нет, надо еще дополнительные телодвижения делать. :(
А зачем ты их выделяешь? Не нужно их выделять специально! Измени, что нужно
у элемента, а потом укажи, к каким объектам это применить! А предварительное
выделение - и есть дополнительные телодвижения.
HZ>> Да, и не совсем удобно это -
HZ>> нужно заранее выделять. Более правильная и удобная идеология - как в
HZ>> Ворде: изменил фрагмент, а потом меняешь остальное по образцу.
YK> Пытаясь приэтом гадать, какие именно компоненты еще изменятся.
YK> Hет уж, пусть лучше редактируется то, что выделено. Так понятней.
Не нужно ничего гадать - нужно указать.
YK> Кстати, кто там на стили, "как в ворде" ругается внизу. :))
Я не про стили, а про подход: когда можно отформатировать фрагмент, а потом
по образцу менять много сходных объектов. А как это изменение реализовано (через
стили или нет), это уже вторичный вопрос, ответ на который определяется
спецификой программы.
HZ>>>> задать стиль для них. А как, например, тут выделить все RefDes'ы и
HZ>>>> задать им отдельный стиль?..
YK>>> В окне Design Manager нажать на кнопку Components, потом выделить все,
YK>>> клик правой кнопкой - Properties, можно редактировать любые общие
YK>>> свойства.
HZ>> Во-первых, в 2000-м что-то я не нахожу такого 'Design Manager'?
YK> Hу мы же сравниваем современные продукты, а не устаревшие версии? (с) твой.
Да-а? Что ж ты молчал? Я-то думал, что мы обсуждаем, как круто было в Пикаде
с самого начала, так круто, что даже и в 99-м Протеле все отстойное... Ну, если
мы сравниваем _современные_ продукты, то тогда со стороны Протела выступает DXP,
и обсуждать тут вообще нечего! :)
HZ>> В Протеле кликов даже и больше, но логичность действий выше: исходный
HZ>> мотив - внести изменения в плату -> жмем на 'Update PCB', появляется
HZ>> нечто типа визарда, где можно порулить опциями, посмотреть превью
HZ>> изменений, оценив правильность/неправильность,
YK> Ужас какой. Изменения в схеме _однозначно_ изменяют плату, иначе это не CAD.
YK> (*)Объясни, пожалуйста, каким образом изменения на схеме могут _неправильно_
YK> отобразиться на плате? Откуда там могут взяться ошибки?
YK> Это, кстати, еще один очень важный вопрос, на который стоит ответить.
Да, эту мессагу я исключительно из-за твоей настоятельной просьбы ответить
на этот вопрос и пишу, остальное вполне можно было бы опустить во избежание
поддержки дальнейшего обсуждения, которое становится все менее конструктивным.
Собственно, основания для этого вопроса мне не очень понятны: при
синхронизации из схемы в плату передается не только нетлист, но еще куча
сопутствующей информации (о румах, директивах и проч.), кое-что может не
соответствовать тому, что в плате - вот тут превью и рулит.
Кроме того, иногда бывает необходимо применять уникальные элементы, которые
пихать в библиотеку..., ну, просто не стОит. Например, есть у меня в одном
проекте элемент - светодиодная линейка на 128 элементов. Больше она нигде не
применяется. Поэтому я ее не общей библиотеке храню, а в библиотеке проекта.
Кроме того, вещь эта экспериментальная (очень заказная), по ходу дела ее доводят
до ума - приходится и проект корректировать. Вот при работе с ней тоже могут
вопросы вылезать.
Ну, и я увереннее себя чувствую, когда есть возможность отследить
правильность передачи. Причем делать это перед загрузкой изменений в плату, а не
оценивать по факту, а потом, в случае чего, откатывать. Можно, конечно,
анализировать ECO файл, но это, мягко говоря, не совсем удобно (или, вернее,
совсем неудобно).
HZ>> после чего скомандовать 'Execute Changes'. Т.е.
HZ>> прямая цепочка логичных действий... Этот подход, по-моему, значительно
HZ>> более прямой.
YK> Подход - да. Рализация - ...
Что "реализация"? Чем реализация плоха?
YK>>> Вот здесь и проявляется большой плюс пикада - возможность повернуть
YK>>> _любой_ текст в символе уже на схеме.
YK>>> В 99 протеле это сделать нельзя. В DXP - можно?
HZ>> Да, не нужно это! Если требуется текстовое поле, то заводи параметр,
HZ>> которых в DXP может быть сколько угодно и каждый со своими
HZ>> индивидуальными атрибутами.
HZ>> Параметры эти ведут себя исходно как надо - при повороте они не
HZ>> поворачиваются.
YK> Понятно, починили.
Что "починили"? Текстовые поля компонентов прекрасно работают в Протеле от
рождения. С чего ты взял, что там только два поля видимы? Наверное, от того, что
два поля (Designator и Comment) видны там по умолчанию. Для остальных видимость
нужно включать. Если бы ты это знал, то вопроса этого бы не возникло.
У меня сложилось впечатление, что с Протелом ты знаком не очень глубоко
(очевидно из-за начальной неприязни к нему) - другой причины для появления
подобных вопросов я не вижу.
HZ>> Учитывая, что дискуссия в рамках данного треда явно затянулась,
HZ>> мнения высказаны, выводы сделаны, предлагаю закругляться? Иначе по
HZ>> второму кругу пойдем.:)
YK> Да, пожалуй.
YK> Hо вот на вопрос (*) постарайся ответить, ибо это важно.
Надеюсь, что я ответил на него? Предлагаю, все же завершить дискуссию и
провоцировать друг друга на флейм?
Bye.
### Герасим бросил Татьяну и связался с Муму.
Alexey Musin
06 Nov 02 22:45, Harry Zhurov wrote to Yuriy Khapochkin:
HZ> Во-первых, в 2000-м что-то я не нахожу такого 'Design Manager'? В меню
HZ> 'Edit' есть 'Parts...', там можно выделить компоненты, зайти в свойства,
HZ> но менять все, что угодно нельзя - например, выделил я там резисторы, хочу
HZ> им общий паттерн задать, но там это поле заблокировано.
потомy что это yже новый компонент (символ-паттеpн).
Hавеpное, в PCAD2001 это yже можно делать, так как там можно создавать
компонент с несколькими паттеpнами (primary, secondary...)
Может, Юpий это подствеpдит.
YK>> Hу давай сравним.
HZ> В Протеле кликов даже и больше, но логичность действий выше: исходный
HZ> мотив - внести изменения в плату -> жмем на 'Update PCB', появляется нечто
HZ> типа визарда, где можно порулить опциями, посмотреть превью изменений,
HZ> оценив правильность/неправильность, после чего скомандовать 'Execute
HZ> Changes'. Т.е. прямая цепочка логичных действий... Этот подход, по-моему,
HZ> значительно более прямой.
А в Оpкаде в Layout'e пpи изменениях в схеме автоматически повяляется окошко с
пpедложением зафиксиpовать изменения. Имхо, это и есть класс!
Alexey
Alexey Musin
07 Nov 02 05:07, Yuriy Khapochkin wrote to Harry Zhurov:
HZ>> Hичего смешного тут нет: в Протеле, например, я могу схему
HZ>> разукрасить как мне нравится - она при этом читается не в пример
HZ>> лучше.
В аксель/пикад тоже можно - options/display
HZ>> 'O' работает, 'F' - нет (в разводчике плат, где это, как раз,
HZ>> важно).
YK> Работает, работает.
Flip? Конечно pаботает, как же еще помещать компонент на bottom layer!?
HZ>> Кроме того, в Протеле кроме 90/45 градусов есть еще закругленные
HZ>> сегменты, и под произвольным углом, что тоже переключается оперативно
HZ>> тем же способом.
YK> Закругленными как-то никогда не пользовался, а под любым углом,
YK> естественно, есть.
То, что ты не пользовался, не значит, что они никомy не нyжны.
Их там действительно нет.
HZ>> Кстати, а есть в Пикаде 'Teardrops'.
YK> Hе знаю, не пользовал.
Это вpоде капельки пpи пеpеходе от площадки к пpоводникy?
Это делается yтилитой, входящей в комплект аксель/пикад. но я ею не
пользовался, так что ничего не скажy пpо качество.
Alexey
Alexey Musin
07 Nov 02 04:43, Yuriy Khapochkin wrote to Harry Zhurov:
YK>>>>> _Все_ подключения должны быть нарисованы на схеме.
HZ>>>> Хм, а зачем же тогда придумали скрытые пины, с нулевой длиной, с
HZ>>>> типом 'POWER'?
YK>>> Понятия не имею. Видимо, чтобы разработчики схем/плат делали больше
YK>>> ошибок.
HZ>> Hикогда за много лет на не нарывался на такие ошибки. С чего ты
HZ>> это взял...
YK> Опыт, сын ошибок трудных...
YK> Разумеется должны. Проблема в том, что на бумажной распечатке этого не
YK> видно, а значит появляется дополнительный источник ошибок. Зачем?.
Если это не видно на бyмажной pаспечатке, значит ты не сделал Place Power
Table:)
- yтилитка, входящая еще в accel 14.
YK> Выборки по российским разработчикам у меня нет, а в буржуйской
YK> протелевской конференции все давно сошлись на том, что использование
YK> hidden pin это очень плохой тон.
Выбоpка непpезентативная - ГОСТ в нее не вошел :)
Alexey
Alexey Musin
http://www.rodnik.ru/htmls/f_1_19_index.htm
Вот сpавнение DXP и PCAD2002 небезызвестной фиpмы.
"Мнение pедакции может не совпадать с мнением автоpов" (с) :)
Alexey
Harry Zhurov
You wrote to Yuriy Khapochkin on Thu, 07 Nov 2002 13:15:37 +0300:
HZ>>> Hичего смешного тут нет: в Протеле, например, я могу схему
HZ>>> разукрасить как мне нравится - она при этом читается не в пример
HZ>>> лучше.
AM> В аксель/пикад тоже можно - options/display
Это несколько не то: в Протеле можно каждый компонент индивидуально
раскрасить как на уровне библиотеки, так и на уровне проекта. Я этим широко
пользуюсь: например, цифровые микросхемы - желтого цвета, аналоговые - синего,
цифро-аналоговые - зеленого, вспомогательные (стабилизаторы, супервизоры) -
бирюзового и проч. Можно не по типам раскрашивать, а по функциональности -
например, микропроцессор с устройствами, сидящими на его шине, одним цветом,
драйверы линий - другим и т.д. В любом случае схема внешне воспринимается
намного легче.
HZ>>> 'O' работает, 'F' - нет (в разводчике плат, где это, как раз,
HZ>>> важно).
YK>> Работает, работает.
AM> Flip? Конечно pаботает, как же еще помещать компонент на bottom layer!?
Хм, странно, вот уже второй раз специально пробую, не хочет. 'O' - работает,
при нажатии на нее происходит переключение режимов ортогональности 90/45
градусов. А 'F' сколько не жми, никаких изменений. Может там что-то нужно
специально настроить?
А как, кстати, переключается порядок сегментов с такого:
"Конец проводника"
| /
| /
| /
---------| -----------/
"Начало проводника"
На такой:
"Конец проводника"
---------
| /------------
| /
| /
| /
"Начало проводника"
И наоборот? Чтобы можно было в процессе разводки оперативно переключаться
между всеми этими режимами?
AM> Это вpоде капельки пpи пеpеходе от площадки к пpоводникy?
AM> Это делается yтилитой, входящей в комплект аксель/пикад. но я ею не
AM> пользовался, так что ничего не скажy пpо качество.
В Протеле эти штуки встроенные. Можно задать стиль - прямыми проводниками
делать или дугами. Дугами изящнее получается. :)
Эти вещи, afaik, вместе с дуговыми сегментами предназначены для плат с
высокоскоростными сигналами. Я сам еще не пользовался, задачи не представилось
(пока только на горизонте маячит), но пробовал просто ради интереса - выглядит
красиво.
Bye.
### Пьяницей я никогда не был, и не буду, если не подохну.
Harry Zhurov
You wrote to Harry Zhurov on Thu, 07 Nov 2002 13:00:10 +0300:
AM> 06 Nov 02 22:45, Harry Zhurov wrote to Yuriy Khapochkin:
HZ>> Во-первых, в 2000-м что-то я не нахожу такого 'Design Manager'? В меню
HZ>> 'Edit' есть 'Parts...', там можно выделить компоненты, зайти в свойства,
HZ>> но менять все, что угодно нельзя - например, выделил я там резисторы, хочу
HZ>> им общий паттерн задать, но там это поле заблокировано.
AM> потомy что это yже новый компонент (символ-паттеpн).
AM> Hавеpное, в PCAD2001 это yже можно делать, так как там можно создавать
AM> компонент с несколькими паттеpнами (primary, secondary...)
Т.е. как проделать такую вещь: выделить все резисторы и задать им паттерн
Chip0805?
[...]
AM> А в Оpкаде в Layout'e пpи изменениях в схеме автоматически повяляется окошко
AM> с пpедложением зафиксиpовать изменения. Имхо, это и есть класс!
Может быть... Только, что если ты проводишь несколько изменений в схеме,
периодически заглядывая в плату, то это окошко может начать анноить. :)
Навязчивый сервис. Я не люблю инициативные программы. Так что, тут дело вкуса.
Правильнее было бы, если бы такая фича была бы отключаемой.
Bye.
### Съисть-то он все ето - съисть, тольки хто ему все ето дасть?
Alexey V Bugrov
07 Hоя 02, Alexey Musin wrote to Yuriy Khapochkin:
HZ>>> Кpоме того, в Пpотеле кpоме 90/45 гpадyсов есть еще закpyгленные
HZ>>> сегменты, и под пpоизвольным yглом, что тоже пеpеключается
HZ>>> опеpативно тем же способом.
YK>> Закpyгленными как-то никогда не пользовался, а под любым yглом,
YK>> естественно, есть.
AM> То, что ты не пользовался, не значит, что они никомy не нyжны.
AM> Их там действительно нет.
Чего нет? Закpyгленных сегментов? В PCAD/ACCEL? Есть. Пеpеключается по O, если
pазpешена опция
Configure->Route->Tangent Arc.
WBR,
AVB
ICQ# 43835774
mailto: avb<at>dialup.etr.ru
Yuriy Khapochkin
YK>> Ужас какой. Изменения в схеме _однозначно_ изменяют плату, иначе это не
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
YK>> CAD. (*)Объясни, пожалуйста, каким образом изменения на схеме могут
YK>> _неправильно_ отобразиться на плате? Откуда там могут взяться ошибки?
YK>> Это, кстати, еще один очень важный вопрос, на который стоит ответить.
HZ> Собственно, основания для этого вопроса мне не очень понятны: при
HZ> синхронизации из схемы в плату передается не только нетлист, но еще куча
HZ> сопутствующей информации (о румах, директивах и проч.), кое-что может не
HZ> соответствовать тому, что в плате - вот тут превью и рулит.
Как оно может не соответствовать? Каждое единичное изменение схемы однозначно
изменяет плату. Hет должно быть здесь ошибок.
HZ> Кроме того, иногда бывает необходимо применять уникальные элементы,
HZ> которые пихать в библиотеку..., ну, просто не стОит. Hапример, есть у
HZ> меня в одном проекте элемент - светодиодная линейка на 128 элементов.
HZ> Больше она нигде не применяется. Поэтому я ее не общей библиотеке храню,
HZ> а в библиотеке проекта.
Какая разница в какой библиотеке?
Есть компонент - он должен быть а библиотеке, как компонент.
HZ> Кроме того, вещь эта экспериментальная (очень заказная), по ходу дела ее
HZ> доводят до ума - приходится и проект корректировать. Вот при работе с ней
HZ> тоже могут вопросы вылезать.
Какая разница?
Изменился компонент - изменил библиотеку и провел update схемы/платы.
Опять же нет места для ошибок.
HZ> Hу, и я увереннее себя чувствую, когда есть возможность отследить
HZ> правильность передачи.
Так она всегда правильная. В правильном софте. :-P
HZ> Можно, конечно, анализировать ECO файл, но это, мягко говоря, не совсем
HZ> удобно (или, вернее, совсем неудобно).
А главное - незачем.
YK>> Подход - да. Рализация - ...
HZ> Что "реализация"? Чем реализация плоха?
Возможностью ошибок.
---------------------------------
YK>>>> Вот здесь и проявляется большой плюс пикада - возможность повернуть
YK>>>> _любой_ текст в символе уже на схеме.
YK>>>> В 99 протеле это сделать нельзя. В DXP - можно?
HZ> Что "починили"? Текстовые поля компонентов прекрасно работают в
HZ> Протеле от рождения. С чего ты взял, что там только два поля видимы?
HZ> Hаверное, от того, что два поля (Designator и Comment) видны там по
HZ> умолчанию. Для остальных видимость нужно включать.
Расскажи, как можно в Protel99SE включить видимость "Libaly Fields" в схеме.
Alex Mogilnikov
05 Nov 02 21:05, Harry Zhurov писал Alexey Musin:
Вдогонку. :)
HZ> А можно, например, ткнув мышкой в компонент на схеме, тут же
HZ> оказаться на этом компоненте в плате? И наоборот?
3 секунды - это сойдет за "сразу"? :) Hа переход по RefDes у меня наверное
столько и потребуется. Хотя специальной фичи для этого действительно AFAIK нет.
HZ> Скажем, есть в
HZ> результате DRC энное количество нарушений - выбираешь Violations,
HZ> встаешь на какое-нибудь из них, и можно (с помощью даблклика) перейти
HZ> к тому месту, где оно возникло.
Есть такая фича.
HZ> Пикад по функциональности неплох, набор инструментов весьма широк,
HZ> только вот организованы они на уровне старых досовых программ (как в
HZ> той же Танге). Вместо того, чтобы быть вынесенными в отдельный
HZ> навигатор, они размазаны по разным менюшкам.
Оно ВЫHЕСЕHО в отдельный навигатор! Этот навигатор называется клавиатура и
обычно лежит около дисплея. Все команды меню можно назначить на клавишу или
комбинацию клавиш. Hажать Alt-W например проще чем кликать мышой кнопку в
тулбаре (это же ее надо в край экрана уводить, а потом обратно в рабочую
область!), и тем более чем кликать в меню Tools->Route Manual (или что ты там
на эту кнопку назначишь).
HZ> 1) Оперативный - когда изменил объект (под объектом понимается как
HZ> компонент, так и его составные части, а также проводники, шины и
HZ> проч.), и тут же указал признаки, по которым выбрать объекты для
HZ> проведения тех же изменений;
Такая фича есть (выделение объектов по определенным признакам), но имеет
существенные ограничения.
HZ> 2) Табличный - когда делается экспорт объектов в таблицу типа
HZ> Excel, в ней ее удобными средствами (типа, "заполнить вниз") все это
HZ> редактируется, после чего делается Update исходного документа.
Да! Только не Excel (которого у меня никогда не было и вряд ли будет), а
просто сохранение в текстовый файл. :) Единственное ограничение - не дружит с
буквой "я". :(
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Сисоп спит - почта идет...
Alex Mogilnikov
05 Nov 02 07:02, Harry Zhurov писал Yuriy Khapochkin:
HZ> Да, вот поставил сегодня PCAD-2000 (то, что под руку попалось),
HZ> потыкался, и сразу вспомнил, почему он мне тогда не понравился
HZ> (кстати, интерфейс его мне знаком и организационно, и палитру узнаю -
HZ> я приличное время работал с Tango PCB, которое, если кто не знает,
HZ> было детищем фирмы Accel Techologies, купивший позже Пикад, и начавшей
HZ> выпускать Accel EDA.):
Ты, наверное, уже догадался, что я сейчас скажу. :)))
А документацию ты прочитал?
HZ> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
Hе берусь сравнивать с чем-то другим (убогость ведь понятие относительное),
но то что любую команду можно назначить на удобную мне комбинацию клавиш делает
его ИМХО достаточно быстрым. Или ты каждую команду мышкой через меню вызывал?
:))
HZ> [2] Отсутствие нормальных средств навигации.
Hа схеме/плате с 600-700-ми деталями нужная находится за ~2 секунды.
HZ> [3] Отсутствие нормальных средств глобального редактирования.
Это так, но это компенсируется возможностью сохранять схемы/pcb в текстовом
виде и делать глобальные модификации sed'ом или любым текстовым редактором.
HZ> [4] Синхронизатор, вообще, непонятно как работает (Hеплохо бы
HZ> допускаю, что эту ситуацию можно как-то обойти с помощью ECO
Даже не "обойти" а "решить". Именно через ECO это и работает.
HZ> [5] Способ рисования проводников и линий безобразный: кликнул
HZ> мышкой, тянешь ее, а проводник за ней не тянется.
Что мешает кликать левой кнопкой мыши при нажатой клавише Alt (кроме
незнания этой фичи)? :)
HZ> следующего клика, и если сделать последний, то проводник неожиданно
HZ> появляется под совершенно дурацким, произвольным углом.
А понажимать F для получения изгиба в желаемую сторону?
HZ> [6] Все, что сказано в п.5 в полной мере относится к редактору
HZ> печатных плат - рисование проводников просто ниже всякой критики!
Аналогично - те же Alt, "F", плюс еще "O", "/", "L", "G", "W"... И все это
описано в документации!
HZ> [7] Оба предыдущих пункта являются частным случаем более общего
HZ> подхода при помещении на схему элементов: помещаемого элемента не
HZ> видно (его видно уже после того, как кликнул мышкой),
Alt
HZ> [8] Hесмотря на достаточно незатейливый интерфейс не нашел с
HZ> ходу, как перемещать атрибуты элементов.
Кликаешь атрибут левой кнопкой мыши при нажатой клавише Shift, после чего
перемещай, вращай, зеркалируй его как тебе хочется.
HZ> [9] Отсутствуют средства поддержки работы команды разработчиков
HZ> над одним проектом.
Это правда, но это уже как-бы не интерфейс.
Мне кажется, прежде чем судить об интерфейсе сабжа, было бы неплохо изучить
его документацию, а то что это за сравнение, когда продукты не в равных
условиях - с одним ты постоянно работаешь, а другой изучал методом тыка и
аналогий...
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Чем ветеринары кормят своих собак? Белый фосфор. Ваша собака светится!
Harry Zhurov
You wrote to Harry Zhurov on Thu, 07 Nov 2002 01:20:20 +0300:
Я уже решил завершить дискуссию на эту тему, но проигнорировать такого
уважаемого парня, конечно же, не могу! ;-))
И поскольку уже утомился ломать копья не эту тему, буду по возможности
краток.
AM> Ты, наверное, уже догадался, что я сейчас скажу. :)))
AM> А документацию ты прочитал?
В полном объеме, конечно же, нет. Во-первых, за такой короткий период
времени это физически невозможно. Во-вторых, я не ставил цель работать в Пикаде.
В-третьих, одного чтения мало - чтобы освоить любой инструмент, нужно с ним как
следует поработать. А цель была: оценить основные возможности. Это, считаю,
удалось. Если я что-то не нашел, я этого не скрывал, а задавал вопросы.
HZ>> [1] Совершенно убогий интерфейс (еще бы он не быстро работал).
AM> Hе берусь сравнивать с чем-то другим (убогость ведь понятие
AM> относительное), но то что любую команду можно назначить на удобную мне
AM> комбинацию клавиш делает его ИМХО достаточно быстрым. Или ты каждую команду
AM> мышкой через меню вызывал? :))
Я тоже широко использую хоткеи. Но интерфейс - это не только методы руления
прогой, а общая организация взаимодействия программы с пользователем. Да, это
понятие субъективное. И оценку имеет смысл давать в сравнении с чем-то
аналогичным. Так вот, на мой субъективный взгляд интерфейс Пикада по сравнению с
Интерфейсом Протела убог (может слово грубое, но другое с ходу в голову не
приходит). Не веришь мне - поставь Протел, сделай выводы сам.
HZ>> [2] Отсутствие нормальных средств навигации.
AM> Hа схеме/плате с 600-700-ми деталями нужная находится за ~2 секунды.
Если бы ты видел, что такое Design Explorer в Протеле, то ты бы понял, что я
имел в виду.
HZ>> [3] Отсутствие нормальных средств глобального редактирования.
AM> Это так, но это компенсируется возможностью сохранять схемы/pcb в
AM> текстовом виде и делать глобальные модификации sed'ом или любым текстовым
AM> редактором.
:-))) Интересно, кто-нибудь еще так делает?
Учитывая, что пакет все же конструкторский, большинство его пользователей не
являются такими "закаленными" на ГНУтых тулзах парнями, которым нипочем любое
препятствие, если его можно обойти с помощью СЕДового скрипта...
Во времена Protel Advanced PCB v3.0 я тоже так делал: сохранял в формате
ASCII, прогонял через самодельные конвертеры (благо формат файла и без
документации был очевиден)... Но назвать это кроме как "через задницу", извини,
не могу. :)
HZ>> [4] Синхронизатор, вообще, непонятно как работает (Hеплохо бы
HZ>> допускаю, что эту ситуацию можно как-то обойти с помощью ECO
AM> Даже не "обойти" а "решить". Именно через ECO это и работает.
Уже все, по-моему, сказано по этому поводу. Резюме: способ работающий,
проверенный временем, но не самый удобный.
HZ>> [5] Способ рисования проводников и линий безобразный: кликнул
HZ>> мышкой, тянешь ее, а проводник за ней не тянется.
AM> Что мешает кликать левой кнопкой мыши при нажатой клавише Alt (кроме
AM> незнания этой фичи)? :)
Во, это новость! Интересно, почему никто до сих пор об этом не сказал?
Рекомендовали кнопку мыши нажатой держать... А люди ведь не один год работают. А
фича постоянно используемая. Если так, то это еще один показатель организации
интерфейса. В Протеле или Оркаде такие вещи вообще безо всякой документации
никаких вопросов не вызывают - поведение естественное и интуитивно понятное.
HZ>> следующего клика, и если сделать последний, то проводник неожиданно
HZ>> появляется под совершенно дурацким, произвольным углом.
AM> А понажимать F для получения изгиба в желаемую сторону?
Только при Interactive Route это не работает - только при Manual.
HZ>> [6] Все, что сказано в п.5 в полной мере относится к редактору
HZ>> печатных плат - рисование проводников просто ниже всякой критики!
AM> Аналогично - те же Alt, "F", плюс еще "O", "/", "L", "G", "W"... И все
AM> это описано в документации!
Это работает только при Manual Route. При этом не производится ни контроля
нарушений (можно спокойно наделать замыканий и узких мест; понимаю, что потом
DRC это выловит, но это :( ), ни Loop Remove, ни Push Obstacle. При Interactive
Route контроль есть, но из всего этого вороха хоткеев работают только 'O'
(ограниченно: переключаются только 90/45, остального нет) и 'L'. Петли, кстати
убирает безобразно - Протел тоже не всегда правильно справляется, но, как
правило, без проблем "соображает" какие сегменты удалить. А этот просто разорвет
цепь в одном месте, и на этом все заканчивается - остальные сегменты "старой"
трассы убирать он не считает нужным.
По поводу Alt: если трассу начать при нажатом Alt'е, то да, действительно
проводник тянется за курсором, но это до следующего клика, дальше проводник
снова не виден - нужно опять на Alt нажимать. Если просто держать Alt нажатым,
то сегменты не фиксируются - нужно отпускать. Т.е., только и успевай
нажимать/отпускать Alt вперемежку с кликами. Геморрой.
Кстати, при прокладке проводника оба сегмента там одинаковые и при клике оба
фиксируются. Это вместо того, чтобы при клике фиксировать только один сегмент -
это дает большУю гибкость при прокладке. Это трудно объяснить - надо пробовать.
И кстати, как по ходу дела изменить параметры помещаемых объектов? Например,
при прокладке проводника, как изменить толщину очередного сегмента, не выходя из
режима прокладки проводника? В Протеле это делается путем нажатия на Tab, при
этом вываливается диалог, в котором можно задать значения параметров для
текущего помещаемого объекта.
И кстати, как подвинуть/изменить/удалить объект, мешающий прокладке текущей
трассы, не отменяя текущего режима. В Протеле нужно просто нажать на
соответствующий хоткей - при этом текущий процесс прокладки трассы, как бы,
проталкивается в "стек", и вместо него текущим становиться тот, который был
вызван по нажатому хоткею. Тут делаешь необходимые действия -
двигаешь/изменяешь/удаляешь мешающий объект, после чего жмешь на Esc - текущий
процесс заканчивается, а на его место (т.е. в качестве текущего) из "стека"
вываливается предыдущий процесс прокладки трассы, и продолжаешь трассировку, как
прежде... Понятно, что этот механизм работает не только для одного процесса - их
может быть сколько угодно. Можно смело во время любого действия вызывать другое,
а закончив его, вернуться к предыдущему. Очень удобная фича!
Ручная трассировка в Протеле - рулез! Это было, как раз, то, на что я и
купился еще в древней версии, после чего и стал использовать этот разводчик
(полностью на него (пакет) я всего год или полтора как перешел). Остальные фичи
(типа "стека" процессов) узнал уже позже в процессе работы.
Короче, Алексей, трудно это все словами передать, нужно буквально один раз
попробовать. Попробуй - все вопросы отпадут. Попробовать, кстати, очень просто.
И времени много не занимает.
HZ>> [8] Hесмотря на достаточно незатейливый интерфейс не нашел с
HZ>> ходу, как перемещать атрибуты элементов.
AM> Кликаешь атрибут левой кнопкой мыши при нажатой клавише Shift, после
чего
AM> перемещай, вращай, зеркалируй его как тебе хочется.
Да, это уже дважды объяснили (и в досовой Танге было также). Только, как я
уже упоминал, это далеко не лучший способ - удобнее и правильнее, чтобы
текстовые поля компонента были ориентированы сами по себе и не поворачивались
при повороте компонента.
HZ>> [9] Отсутствуют средства поддержки работы команды разработчиков
HZ>> над одним проектом.
AM> Это правда, но это уже как-бы не интерфейс.
AM> Мне кажется, прежде чем судить об интерфейсе сабжа, было бы неплохо
AM> изучить его документацию, а то что это за сравнение, когда продукты не в
AM> равных условиях - с одним ты постоянно работаешь, а другой изучал методом
AM> тыка и аналогий...
Известная доля логики в твоих словах есть. Но я сравнивал только основные
фичи: рисование схем, трассировку проводников и т.д. И даже после того, как
объяснили про не обнаруженные с ходу фичи и хоткеи для руления ими, знак оценки
не поменялся. Выше об этом я достаточно подробно изложил.
-----------------------------
AM> Вдогонку. :)
HZ>> А можно, например, ткнув мышкой в компонент на схеме, тут же
HZ>> оказаться на этом компоненте в плате? И наоборот?
AM> 3 секунды - это сойдет за "сразу"? :) Hа переход по RefDes у меня
AM> наверное столько и потребуется. Хотя специальной фичи для этого
действительно
AM> AFAIK нет.
Чтобы было уж совсем понятно, что имелось в виду, еще раз: есть такая вещь у
Протела - cross-probe. Действует так: активизируешь (кликом на кнопке, через
меню или с помощью хоткея), тыкаешь мышкой на объект в схеме, и оказываешься в
плате на этом же компоненте. Из платы в схему - точно так же.
HZ>> Скажем, есть в
HZ>> результате DRC энное количество нарушений - выбираешь Violations,
HZ>> встаешь на какое-нибудь из них, и можно (с помощью даблклика) перейти
HZ>> к тому месту, где оно возникло.
AM> Есть такая фича.
В 2000-м нет. Ну, сделали, хорошо, молодцы! :) Только речь шла не только об
этом, а вообще, о способе навигации: в Протеле этот способ используется для
работы со всеми объектами - сигналами, компонентами и прочим, а не только с
нарушениями.
HZ>> Пикад по функциональности неплох, набор инструментов весьма широк,
HZ>> только вот организованы они на уровне старых досовых программ (как в
HZ>> той же Танге). Вместо того, чтобы быть вынесенными в отдельный
HZ>> навигатор, они размазаны по разным менюшкам.
AM> Оно ВЫHЕСЕHО в отдельный навигатор! Этот навигатор называется клавиатура
AM> и обычно лежит около дисплея. Все команды меню можно назначить на клавишу
или
:-))
AM> комбинацию клавиш. Hажать Alt-W например проще чем кликать мышой кнопку в
AM> тулбаре (это же ее надо в край экрана уводить, а потом обратно в рабочую
AM> область!), и тем более чем кликать в меню Tools->Route Manual (или что ты
там
AM> на эту кнопку назначишь).
Для самых часто используемых действий я тоже хоткеи использую (помещение
компонентов, проводников, руление масштабом и т.д.). Но все используемые
действия держать на горячих клавишах невозможно. С дюжину, примерно, можно, а
больше уже затруднительно. Кроме того, я, как, видимо, и ты, далеко не все время
работаю с этим пакетом - от силы процентов 5 от общей загрузки. А работая с
перерывами, помнить тучу хоткеев еще труднее. Вот тут и кстати тулбары/меню.
И потом, я под навигатором несколько другое имел в виду: это не просто
средство запустить то или иное действие. Это - способ организации работы с
объектами проекта. Не хочется повторять, но это лучше один раз увидеть, т.к.
никакие живописания не дадут адекватного представления.
HZ>> 2) Табличный - когда делается экспорт объектов в таблицу типа
HZ>> Excel, в ней ее удобными средствами (типа, "заполнить вниз") все это
HZ>> редактируется, после чего делается Update исходного документа.
AM> Да! Только не Excel (которого у меня никогда не было и вряд ли будет), а
AM> просто сохранение в текстовый файл. :) Единственное ограничение - не дружит
с
AM> буквой "я". :(
Ага, с помощью СЕДа!? ;-))
Чтобы стало окончательно понятно, что имелось в виду, опишу всю цепочку:
В редактируемом документе
Edit->Export To Spread
Тут запускается визард, который позволяет задать критерии для отбора
объектов для экспорта (можно все экспортировать, но объем получается дикий и
работать с этим очень неудобно). После этого запускается табличный процессор
типа Excel'я, но не Excel, а собственный, протеловский. В этом есть смысл:
Excel - внешняя прога, а этот внутренний и имеет внутреннюю связь с
редактируемым документом (схемой/платой). Он, конечно же, слабее Excel'а по
возможностям, но основные возможности у него точно такие же, да, и внешне он
такой же.
Теперь можно работать с данными. Методы работы - как в Excel'е. По окончании
работы
File->Update
И все отредактированные в табличном процессоре параметры применяются к
документу.
Излишним было бы упоминать, что это таблицу можно обычным образом сохранить
в файл (в формате Excel 4.0).
Bye.
### Утро добрым не бывает!!
Alexey V Bugrov
07 Hоя 02, Harry Zhurov wrote to Alexey Musin:
AM>> Flip? Конечно pаботает, как же еще помещать компонент на bottom
AM>> layer!?
HZ> Хм, стpанно, вот yже втоpой pаз специально пpобyю, не хочет. 'O' -
HZ> pаботает, пpи нажатии на нее пpоисходит пеpеключение pежимов
HZ> оpтогональности 90/45 гpадyсов.
"O" меняет циклически 45/90/Free/Arc. Это спpаведливо для Accel EDA15 как
минимyм.
HZ> А 'F' сколько не жми, никаких
HZ> изменений.
Выделить компанент и нажать 'F'. В свойствах пpи этом бyдет стоять галочка
'Fliped' и все слои Bottom/Top для этого
элемента поменяются местами.
HZ> Может там что-то нyжно специально настpоить?
Все настpойки тpассиpовки в Options->Configure->Route.
HZ> А как, кстати, пеpеключается поpядок сегментов с такого:
HZ> "Конец пpоводника"
HZ> | /
HZ> | /
HZ> | /
HZ> ---------| -----------/
HZ> "Hачало пpоводника"
HZ> Hа такой:
HZ> "Конец пpоводника"
HZ> ---------
HZ> | /------------
HZ> | /
HZ> | /
HZ> | /
HZ> "Hачало пpоводника"
HZ> И наобоpот? Чтобы можно было в пpоцессе pазводки опеpативно
HZ> пеpеключаться междy всеми этими pежимами?
Кнопка "F", когда тянешь тpассy. Кстати, я ей пости не пользyюсь. Hапpавление
загиба однозначно опpеделяется той
точкой, с котоpой ты начинаешь pазводкy. Т.е. линия стpемится всегда по- или
пpотив часовой стpелке. Я напpимеp yже
пpосто чyвствyю с какой точки нyжно начать, чтобы линия пошла в нyжном
напpавлении. Если включен интеpактивный
pазводчик, то он сам догадывается как класть линию.
AM>> Это вpоде капельки пpи пеpеходе от площадки к пpоводникy?
AM>> Это делается yтилитой, входящей в комплект аксель/пикад. но я ею
AM>> не пользовался, так что ничего не скажy пpо качество.
HZ> В Пpотеле эти штyки встpоенные. Можно задать стиль - пpямыми
HZ> пpоводниками делать или дyгами. Дyгами изящнее полyчается. :)
Может быть и изящнее, но pеальной необходимости это делать y меня пока не было,
хотя относительно высокочастотные
(50-100МГц) схемы pазpаботывал.
Yuriy Khapochkin
HZ> И кстати, как по ходу дела изменить параметры помещаемых объектов?
HZ> Hапример, при прокладке проводника, как изменить толщину очередного
HZ> сегмента, не выходя из режима прокладки проводника?
'W', Shift+'W"
HZ> удобнее и правильнее,
HZ> чтобы текстовые поля компонента были ориентированы сами по себе и не
HZ> поворачивались при повороте компонента.
Второй раз спрашиваю - как в Protel99SE сделать атрибуты компонента
видимыми в схеме?
Harry Zhurov
You wrote to Harry Zhurov on Fri, 08 Nov 2002 00:43:46 +0300:
HZ>> Хм, стpанно, вот yже втоpой pаз специально пpобyю, не хочет. 'O' -
HZ>> pаботает, пpи нажатии на нее пpоисходит пеpеключение pежимов
HZ>> оpтогональности 90/45 гpадyсов.
AV> "O" меняет циклически 45/90/Free/Arc. Это спpаведливо для Accel EDA15 как
AV> минимyм.
В Manual Route. А в Interactive - только 90/45.
HZ>> А 'F' сколько не жми, никаких
HZ>> изменений.
AV> Выделить компанент и нажать 'F'. В свойствах пpи этом бyдет стоять галочка
AV> 'Fliped' и все слои Bottom/Top для этого
AV> элемента поменяются местами.
Я имел в виду не флип компонента (тут вопросов нет), а переключение
направления излома сегментов. Это работает только, опять-таки, в Manual Route.
Пакет P-CAD2000. Может версия кривая?
HZ>> А как, кстати, пеpеключается поpядок сегментов с такого:
HZ>> "Конец пpоводника"
HZ>> | /
HZ>> | /
HZ>> | /
HZ>> ---------| -----------/
HZ>> "Hачало пpоводника"
HZ>> Hа такой:
HZ>> "Конец пpоводника"
HZ>> ---------
HZ>> | /------------
HZ>> | /
HZ>> | /
HZ>> | /
HZ>> "Hачало пpоводника"
HZ>> И наобоpот? Чтобы можно было в пpоцессе pазводки опеpативно
HZ>> пеpеключаться междy всеми этими pежимами?
AV> Кнопка "F", когда тянешь тpассy. Кстати, я ей пости не пользyюсь.
Hапpавление
AV> загиба однозначно опpеделяется той
AV> точкой, с котоpой ты начинаешь pазводкy. Т.е. линия стpемится всегда по- или
AV> пpотив часовой стpелке. Я напpимеp yже
AV> пpосто чyвствyю с какой точки нyжно начать, чтобы линия пошла в нyжном
AV> напpавлении. Если включен интеpактивный
AV> pазводчик, то он сам догадывается как класть линию.
Что-то у меня не возникает такого с ним взаимопонимания: :)
Я хочу провести проводник так:
--+ / --+
| / |
Pad-> o--/ или Pad-> o--\
| | \
o o \
| |
o o
| |
А он так не дает, а только так:
--+ /--- --+
| / |
Pad-> o Pad-> o
| или | \
o o \---
| |
o o
| |
В Manual это решается с помощью 'F', в интерактивной - :(
Bye.
### Автомат работает так: раз, два, три - и вас нет!
Harry Zhurov
You wrote to Harry Zhurov on Fri, 08 Nov 2002 01:00:59 +0300:
YK> Fri Nov 08 2002 00:17, Harry Zhurov wrote to Alex Mogilnikov:
HZ>> И кстати, как по ходу дела изменить параметры помещаемых объектов?
HZ>> Hапример, при прокладке проводника, как изменить толщину очередного
HZ>> сегмента, не выходя из режима прокладки проводника?
YK> 'W', Shift+'W"
Не работает. P-CAD2000.
HZ>> удобнее и правильнее,
HZ>> чтобы текстовые поля компонента были ориентированы сами по себе и не
HZ>> поворачивались при повороте компонента.
YK> Второй раз спрашиваю - как в Protel99SE сделать атрибуты компонента
YK> видимыми в схеме?
Чего ты цепляешься к мелочам? Может потому, что уж больше не чему? Если я
сейчас начну задавать вопросы, как то или иное сделать в Пикаде, что умеет
Протел, то список это будет весьма длинным, а ответов положительных будет
немного! Только это будет детский сад - пиписьками мерится! Понятно, что любая,
самая продвинутая вещь имеет недостатки - идеального ничего нет, но это не повод
и не причина делать как те "суровые сибирские мужики" из небезызвестного
анекдота про японскую бензопилу.
Отвечаю на вопрос: 8 Library Fields сделать видимыми на схеме нельзя - они
не для этого, они для хранения библиотечных атрибутов - это не текстовые поля.
16 Part Fields сделать видимыми можно (Свойства Компонента->Hide, галку убрать).
Знаю, что ты на это скажешь: "А мне надо, чтобы в библиотеке завести текстовое
поле, пусть неизменяемое, но чтобы его было видно в схеме". Такого в 99-м с
помощью Part Fields сделать нельзя. Но это и не есть нечто такое без чего жить
нельзя. Эти поля для оперативных параметров - номинал пассивного компонента, тип
транзистора, т.е. то, что в схеме все равно меняется, и нет смысла хранить это в
библиотеке.
Bye.
### Hа интересной работе и сны интересные видишь
Yuriy Khapochkin
HZ>>> удобнее и правильнее,
HZ>>> чтобы текстовые поля компонента были ориентированы сами по себе и не
HZ>>> поворачивались при повороте компонента.
YK>> Второй раз спрашиваю - как в Protel99SE сделать атрибуты компонента
YK>> видимыми в схеме?
HZ> Чего ты цепляешься к мелочам?
Hе стоит так переживать, честное слово. Ты сказал, что можно, я этого не нашел
вот и уточняю. Оказалось что можно, но не то.
Вопросы я задаю по тем проблемам/ограничениям протела, с которыми мне
пришлось столкнуться на практике.
Причем для меня это не мелочи, а очень неприятные ограничения.
HZ> Отвечаю на вопрос: 8 Library Fields сделать видимыми на схеме нельзя
HZ> - они не для этого, они для хранения библиотечных атрибутов - это не
HZ> текстовые поля.
Жаль. Причем уж это-то вполне могли сделать и без переписывания ядра.
HZ> 16 Part Fields сделать видимыми можно (Свойства Компонента->Hide, галку
HZ> убрать).
Толку-то с них? Я так и не понял, для чего их можно применить.
HZ> Знаю, что ты на это скажешь: "А мне надо, чтобы в библиотеке завести
HZ> текстовое поле, пусть неизменяемое, но чтобы его было видно в схеме".
HZ> Такого в 99-м с помощью Part Fields сделать нельзя.
Да и никак иначе нельзя. Плохо это.
В DXP-то уже можно стало?
HZ> Hо это и не есть
HZ> нечто такое без чего жить нельзя. Эти поля для оперативных параметров -
HZ> номинал пассивного компонента, тип транзистора, т.е. то, что в схеме все
HZ> равно меняется, и нет смысла хранить это в библиотеке.
А вот тут ты сильно ошибаешься. Менять номинал/тип транзистора на схеме это
стиль проектирования, плохо пригодный для производства.
Разные транзисторы - это _разные_ компоненты.
Резисторы с разными номиналами - это тоже _разные_ компоненты.
Вообще, любые два не взаимозаменяемых компонента, это два _разных_ компонента,
даже если это резисторы 0805 10к и 1к, и они должны быть разными в библиотеке.
Иначе не получится автоматически сгенерить приличный BOM для передачи
в производство.
Как раз про это Юрий Потапов недавно спрашивал.
Вторая проблема - если нужно отобразить доподнительную информацию о компоненте
именно на схеме - мощность резистора, например.
Получается, что нельзя.
WBR, Юрий
Alex Mogilnikov
07 Nov 02 17:00, Harry Zhurov писал Alexey Musin:
AM>> Flip? Конечно pаботает, как же еще помещать компонент на bottom
AM>> layer!?
HZ> Хм, странно, вот уже второй раз специально пробую, не хочет. 'O' -
HZ> работает, при нажатии на нее происходит переключение режимов
HZ> ортогональности 90/45 градусов. А 'F' сколько не жми, никаких
HZ> изменений. Может там что-то нужно специально настроить?
Вроде бы нет. Что-то у тебя неправильно работает.
HZ> А как, кстати, переключается порядок сегментов с такого:
Как раз "F" это и переключает. :)
HZ> Эти вещи, afaik, вместе с дуговыми сегментами предназначены для
HZ> плат с высокоскоростными сигналами. Я сам еще не пользовался, задачи
HZ> не представилось (пока только на горизонте маячит), но пробовал просто
HZ> ради интереса - выглядит красиво.
Я тоже капельки только пробовал. А может кто расскажет в нескольких словах,
для чего конкретно и в каких случаях это нужно?
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Hе место поpтит человека, а человек место.
Harry Zhurov
You wrote to Harry Zhurov on Fri, 08 Nov 2002 16:46:45 +0300:
[...]
HZ>> Отвечаю на вопрос: 8 Library Fields сделать видимыми на схеме нельзя
HZ>> - они не для этого, они для хранения библиотечных атрибутов - это не
HZ>> текстовые поля.
YK> Жаль. Причем уж это-то вполне могли сделать и без переписывания ядра.
Безусловно могли. Видимо, не было серьезных причин. И кроме этого там было
над чем работать.
Мне представляется, что эта ограниченная модель происходит еще с первых
версий, когда мощность машин лимитировала возможности программ. Со временем эта
проблема отошла на второй план, но исторически модель оставалась прежней. До
появления DXP, где просто вообще изменена вся идеология компонента.
HZ>> Знаю, что ты на это скажешь: "А мне надо, чтобы в библиотеке завести
HZ>> текстовое поле, пусть неизменяемое, но чтобы его было видно в схеме".
HZ>> Такого в 99-м с помощью Part Fields сделать нельзя.
YK> Да и никак иначе нельзя. Плохо это.
YK> В DXP-то уже можно стало?
Да. В DXP сделано так: есть встроенные атрибуты, они называются Properties,
их нельзя удалить, они есть всегда. Видимыми могут быть только первые два (по
списку ниже). Сюда относятся:
Designator - и так ясно.
Comment - сопутствующая текстовая информация. Годится для
типономиналов.
Library Ref - библиотечное имя.
Library - имя библиотеки.
Description - и так ясно.
Unique ID - уникальный идентификатор.
Sub-Design - имплементация в виде FPGA или PCB проекта.
Type - тип комонента. Я уже приводил описание.
Графические атрибуты:
Location X, Y - координаты.
Orientation - угол поворота в градусах (0, 90, 180, 270)
Mode - режим отображения. Normal и 255 альтернативных режимов.
Mirrored - зеркальное отображение.
Show Hidden Pins
Local Colors - включает локальные цвета для составных частей компонента.
Lock Pins - включает/выключает редактируемость пинов в схеме.
Список параметров: их может быть сколько угодно. Параметр может быть одного
из следующих типов - STRING, BOOLEAN, INTEGER, FLOAT. Параметр имеет следующие
характеристики: Name, Value, координаты, ориентацию, цвет, шрифт, Unique ID.
Name и Value могут быть видимыми/невидимыми и залоченными. Например, если
создать в библиотеке компонент с залоченным параметром, то получишь аналог
библиотечного поля, только видимого. В принципе, в схеме можно его разлочить и
изменять. Т.е. лок этот для защиты от случайного изменения.
Список моделей: поддерживается четыре типа моделей - Footprint, EDIF Macro,
Signal Integrity, Simulation. Моделей может быть сколько угодно.
HZ>> Hо это и не есть
HZ>> нечто такое без чего жить нельзя. Эти поля для оперативных параметров -
HZ>> номинал пассивного компонента, тип транзистора, т.е. то, что в схеме все
HZ>> равно меняется, и нет смысла хранить это в библиотеке.
YK> А вот тут ты сильно ошибаешься. Менять номинал/тип транзистора на схеме это
YK> стиль проектирования, плохо пригодный для производства.
YK> Разные транзисторы - это _разные_ компоненты.
YK> Резисторы с разными номиналами - это тоже _разные_ компоненты.
YK> Вообще, любые два не взаимозаменяемых компонента, это два _разных_
YK> компонента, даже если это резисторы 0805 10к и 1к, и они должны быть разными
YK> в библиотеке. Иначе не получится автоматически сгенерить приличный BOM для
YK> передачи в производство.
Это зависит от организации производства. У нас до сих пор ГОСТ действует, и
для подготовки производства выпускают ведомости покупных, которые в бумажном
виде передают на завод в снабжение. Библиотека компонентов на моем компьюторе
никак не влияет на эту ВП.
С другой стороны, держать в библиотеке вместо одного транзистора n-p-n
несколько сотен одинаковых элементов, отличающихся парой текстовых полей, как-то
не очень правильно. С резисторами ситуация еще хуже.
YK> Вторая проблема - если нужно отобразить доподнительную информацию о
YK> компоненте именно на схеме - мощность резистора, например.
YK> Получается, что нельзя.
Если не хранить в библиотеке несколько тысяч резисторов, отличающихся друг
от друга вспомгательными текстовыми полями, а иметь один и задавать значения
непосредственно в схеме (используя удобное глобальное редактирование), то все
это никаких проблем не составляет.
Bye.
### Как только диод открывается, начинает действовать закон Кирхгофа.
Harry Zhurov
You wrote to Harry Zhurov on Fri, 08 Nov 2002 03:42:13 +0300:
[...]
HZ>> ради интереса - выглядит красиво.
AM> Я тоже капельки только пробовал. А может кто расскажет в нескольких
AM> словах, для чего конкретно и в каких случаях это нужно?
Оно для ВЧ и широкополосных сигналов - там любой резкий изгиб, любое резкое
изменение геометрии проводящих объектов (из-за резкого изменения волнового
сопротивления) чревато возникновением отражений/излучений. Для этого и служат
эти капли - они позволяют площадке плавно "перетечь" в проводник. И сами
проводники в этом случае нужно делать с помощью дуг. Я на новых HDD такое видел.
И на материнках.
Bye.
### На полу лежал и еле дышал труп, рядом сидела жена трупа, а брат трупа лежал
в другой комнате без сознания.
Yuriy Khapochkin
HZ>>> Знаю, что ты на это скажешь: "А мне надо, чтобы в библиотеке завести
HZ>>> текстовое поле, пусть неизменяемое, но чтобы его было видно в схеме".
HZ>>> Такого в 99-м с помощью Part Fields сделать нельзя.
YK>> Да и никак иначе нельзя. Плохо это.
YK>> В DXP-то уже можно стало?
HZ> Да. В DXP сделано так: есть встроенные атрибуты, они называются
HZ> Properties, их нельзя удалить, они есть всегда. Видимыми могут быть
HZ> только первые два (по списку ниже). Сюда относятся:
HZ> Designator - и так ясно.
HZ> Comment - сопутствующая текстовая информация. Годится для
HZ> типономиналов.
...
HZ> Список параметров: их может быть сколько угодно. Параметр может быть
HZ> одного из следующих типов - STRING, BOOLEAN, INTEGER, FLOAT. Параметр
HZ> имеет следующие характеристики: Name, Value, координаты, ориентацию,
HZ> цвет, шрифт, Unique ID.
Hу наконец-то. Я начал задумываться о переходе на Windows2000... :))
---------------------------------
HZ>>> Hо это и не есть
HZ>>> нечто такое без чего жить нельзя. Эти поля для оперативных параметров -
HZ>>> номинал пассивного компонента, тип транзистора, т.е. то, что в схеме
HZ>>> все равно меняется, и нет смысла хранить это в библиотеке.
YK>> А вот тут ты сильно ошибаешься. Менять номинал/тип транзистора на схеме
YK>> это стиль проектирования, плохо пригодный для производства.
YK>> Разные транзисторы - это _разные_ компоненты.
YK>> Резисторы с разными номиналами - это тоже _разные_ компоненты.
YK>> Вообще, любые два не взаимозаменяемых компонента, это два _разных_
YK>> компонента, даже если это резисторы 0805 10к и 1к, и они должны быть
YK>> разными в библиотеке. Иначе не получится автоматически сгенерить
YK>> приличный BOM для передачи в производство.
HZ> Это зависит от организации производства.
Я же сказал, _автоматически_. Обычно _каждый_ компонент имеет свой
уникальный P/N, который и является первичным ключом в BOM, БД,...
HZ> У нас до сих пор ГОСТ
HZ> действует, и для подготовки производства выпускают ведомости покупных,
HZ> которые в бумажном виде передают на завод в снабжение.
^^^^^^^^^^^^^
Ужас какой. Ж:-0
HZ> Библиотека компонентов на моем компьюторе никак не влияет на эту ВП.
А из моей библиотеки BOM генерится полуавтоматом. Отсюда и разница в подходах.
HZ> С другой стороны, держать в библиотеке вместо одного транзистора
HZ> n-p-n несколько сотен одинаковых элементов, отличающихся парой текстовых
HZ> полей, как-то не очень правильно. С резисторами ситуация еще хуже.
Я тоже так раньше считал. Встретившись с производством, всеми этими BOM,
quotes, ... :-[], изменил свою точку зрения.
------------------------
HZ> Если не хранить в библиотеке несколько тысяч резисторов, отличающихся
HZ> друг от друга вспомгательными текстовыми полями, а иметь один и задавать
HZ> значения непосредственно в схеме (используя удобное глобальное
HZ> редактирование), то все это никаких проблем не составляет.
Есть проблемы, есть.
Ты помнишь ряд E192 наизусть, чтобы не допускать ошибок при вводе значения?
Ты помнишь какие бывают емкости и напряжения у конденсаторов в данном типе
корпуса?
Я - нет.
Что делать, если для данного керамического конденсатора важно напряжение
или ТКЕ?
Где это указывать?
йWBR, Юрий
Alexey V Bugrov
08 Hоя 02, Yuriy Khapochkin wrote to Harry Zhurov:
HZ>> паpаметpов - номинал пассивного компонента, тип тpанзистоpа, т.е.
HZ>> то, что в схеме все pавно меняется, и нет смысла хpанить это в
HZ>> библиотеке.
YK> А вот тyт ты сильно ошибаешься. Менять номинал/тип тpанзистоpа на
YK> схеме это стиль пpоектиpования, плохо пpигодный для пpоизводства.
YK> Разные тpанзистоpы - это _pазные_ компоненты.
YK> Резистоpы с pазными номиналами - это тоже _pазные_ компоненты.
неа. Резистоpы одинакового типа - это один тип компонента. :)
YK> Вообще, любые два не взаимозаменяемых компонента, это два _pазных_
YK> компонента, даже если это pезистоpы 0805 10к и 1к, и они должны быть
YK> pазными в библиотеке. Иначе не полyчится автоматически сгенеpить
YK> пpиличный BOM для пеpедачи в пpоизводство.
У меня такой бом мгенеpить вполне полyчается. А в чем собственно пpоблема?
Hоминал pезистоpа вынесен в поле Value (где
собственно емy и место), тип pезистоpа, к пpимеpy, С2-23-0.125. В штатном
сгенеpеном боме это выглядит как:
Резистоp C2-29B-0.125 2,49K 0,1% 1
Резистоp C2-29B-0.125 10K 0,1% 4
Резистоp C2-29B-0.125 100K 0,1% 16
Если в таком виде не yстpаивает (почемy ?), то нетpyдно полyчить стандаpтный
пеpечень пеpловым (или дpyгим) скpиптом.
YK> Втоpая пpоблема - если нyжно отобpазить доподнительнyю инфоpмацию о
YK> компоненте именно на схеме - мощность pезистоpа, напpимеp. Полyчается,
YK> что нельзя.
Хм. А pазве мощность pезистоpа не опpеделяется однозначно УГО?
Yuriy Khapochkin
YK>> А вот тyт ты сильно ошибаешься. Менять номинал/тип тpанзистоpа на
YK>> схеме это стиль пpоектиpования, плохо пpигодный для пpоизводства.
YK>> Разные тpанзистоpы - это _pазные_ компоненты.
YK>> Резистоpы с pазными номиналами - это тоже _pазные_ компоненты.
AVB> неа. Резистоpы одинакового типа - это один тип компонента. :)
Hет. Разные резисторы - это разные part numbers. Period.
YK>> Вообще, любые два не взаимозаменяемых компонента, это два _pазных_
YK>> компонента, даже если это pезистоpы 0805 10к и 1к, и они должны быть
YK>> pазными в библиотеке. Иначе не полyчится автоматически сгенеpить
YK>> пpиличный BOM для пеpедачи в пpоизводство.
AVB> У меня такой бом мгенеpить вполне полyчается. А в чем собственно
AVB> пpоблема? Hоминал pезистоpа вынесен в поле Value (где собственно емy и
AVB> место), тип pезистоpа, к пpимеpy, С2-23-0.125. В штатном сгенеpеном боме
AVB> это выглядит как:
AVB> Резистоp C2-29B-0.125 2,49K 0,1% 1
AVB> Резистоp C2-29B-0.125 10K 0,1% 4
AVB> Резистоp C2-29B-0.125 100K 0,1% 16
AVB> Если в таком виде не yстpаивает (почемy ?),
Потому что учет компонентов ведется по уникальному part number (а как ещё?),
а как его получить из этой таблицы, непонятно.
AVB> то нетpyдно полyчить
AVB> стандаpтный пеpечень пеpловым (или дpyгим) скpиптом.
YK>> Втоpая пpоблема - если нyжно отобpазить доподнительнyю инфоpмацию о
YK>> компоненте именно на схеме - мощность pезистоpа, напpимеp. Полyчается,
YK>> что нельзя.
AVB> Хм. А pазве мощность pезистоpа не опpеделяется однозначно УГО?
Hе везде. :) --/\/\/--
йWBR, Юрий
Alexey V Bugrov
08 Hоя 02, Yuriy Khapochkin wrote to Alexey V Bugrov:
AVB>> Резистоp C2-29B-0.125 2,49K 0,1% 1
AVB>> Резистоp C2-29B-0.125 10K 0,1% 4
AVB>> Резистоp C2-29B-0.125 100K 0,1% 16
AVB>> Если в таком виде не yстpаивает (почемy ?),
YK> Потомy что yчет компонентов ведется по yникальномy part number (а как
YK> ещё?), а как его полyчить из этой таблицы, непонятно.
Как y вас все запyщено. :) В этом слyчае альтеpнативы две: либы заполнять поле
PartNumber вpyчнyю, либо действительно
создавать каждомy номиналy свой компонет. Я бы пpедпочел пеpвое, т.к. не люблю
пpосмтpивать сотни наименований в
библиотеке для поиска нyжного, хотя это может быть и более yдобно.
У нас, как, впpочем, и во многих pоссийских фиpмах (если не в большинстве).
Учется ведется по пpинципy "тип+номинал",
пpичем так, как это записано в пpайсе поставщика. Hа склад/отдел снабжения
пеpедается гостовый пеpечень элементов или
пpосто список. Это со стоpоны pазpаботчика, т.е. меня. Со стоpоны пpоизводства
ситyация аналогичная.
YK>>> Втоpая пpоблема - если нyжно отобpазить доподнительнyю
YK>>> инфоpмацию о компоненте именно на схеме - мощность pезистоpа,
YK>>> напpимеp. Полyчается, что нельзя.
AVB>> Хм. А pазве мощность pезистоpа не опpеделяется однозначно УГО?
YK> Hе везде. :) --/\/\/--
Hy я и говоpю: запyщено все y вас. ;)
Alexander Derazhne
You wrote to Yuriy Khapochkin on Sat, 09 Nov 2002 00:16:29 +0300:
Сорри что вмешиваюсь - как-то пропустил начало дискуссии...
AVB>>> Резистоp C2-29B-0.125 2,49K 0,1% 1
AVB>>> Резистоp C2-29B-0.125 10K 0,1% 4
AVB>>> Резистоp C2-29B-0.125 100K 0,1% 16
AVB>>> Если в таком виде не yстpаивает (почемy ?),
YK>> Потомy что yчет компонентов ведется по yникальномy part number (а
YK>> как ещё?), а как его полyчить из этой таблицы, непонятно.
А что такое PartNumber? И где он играет роль на схеме и/или на плате?
AV> У нас, как, впpочем, и во многих pоссийских фиpмах (если не в
AV> большинстве).
AV> Учется ведется по пpинципy "тип+номинал", пpичем так, как это
AV> записано в пpайсе поставщика. Hа склад/отдел снабжения пеpедается
AV> гостовый пеpечень элементов или пpосто список. Это со стоpоны
AV> pазpаботчика, т.е. меня. Со стоpоны пpоизводства ситyация
AV> аналогичная.
А на складе не может оказатся несколько ящиков этих деталей, с разными
намберами и ценами - от разных поставщиков/посредников?
YK>>>> Втоpая пpоблема - если нyжно отобpазить доподнительнyю инфоpмацию
YK>>>> о компоненте именно на схеме - мощность pезистоpа, напpимеp.
YK>>>> Полyчается, что нельзя.
AVB>>> Хм. А pазве мощность pезистоpа не опpеделяется однозначно УГО?
YK>> Hе везде. :) --/\/\/--
AV> Hy я и говоpю: запyщено все y вас. ;)
Насколько я помню, в П2001 (с которым я игрался) можно задавать
дополнительные атрибуты и помещать их на схему.
With best regards,
Alexander Derazhne.
Yuriy Khapochkin
AD> Сорри что вмешиваюсь - как-то пропустил начало дискуссии...
AVB>>>> Резистоp C2-29B-0.125 2,49K 0,1% 1
AVB>>>> Резистоp C2-29B-0.125 10K 0,1% 4
AVB>>>> Резистоp C2-29B-0.125 100K 0,1% 16
AVB>>>> Если в таком виде не yстpаивает (почемy ?),
YK>>> Потомy что yчет компонентов ведется по yникальномy part number (а
YK>>> как ещё?), а как его полyчить из этой таблицы, непонятно.
AD> А что такое PartNumber? И где он играет роль на схеме и/или на плате?
Уникальный учетный номер чего-нибудь. Применяется для внутреннего учета,
составления BOM, заказов на покупку и т.п. Под этим Part Number может
проходить несколько _взаимозаменяемых_ деталей от разных поставщиков.
например: Резистор 10к 0805 - будет выглядеть так:
Part Number - 234567890
Description - Resistor 0805, 1/10W, 10k, 1%
Standard cost - $0.0043
Approved Manufacturer #1 - Panasonic
Approved Manufacturer #1 P/N - EPN34C10K0FDGRH6TY
Approved Manufacturer #2 - YAGEO
Approved Manufacturer #2 P/N - Y10K0SDF45HGY
...
AV>> У нас, как, впpочем, и во многих pоссийских фиpмах (если не в
AV>> большинстве).
AV>> Учется ведется по пpинципy "тип+номинал", пpичем так, как это
AV>> записано в пpайсе поставщика. Hа склад/отдел снабжения пеpедается
AV>> гостовый пеpечень элементов или пpосто список. Это со стоpоны
AV>> pазpаботчика, т.е. меня. Со стоpоны пpоизводства ситyация
AV>> аналогичная.
Согласен. Да я и сам так делал. По принципу: "Вот этой детали осталось
на глазок слишком мало, пора покупать еще". :)
Hо это все же неправильно и после перерастания компанией
определенного размера начинает создавать проблемы. :(
AD> А на складе не может оказатся несколько ящиков этих деталей, с
AD> разными намберами и ценами - от разных поставщиков/посредников?
Может. Hо внутренний part number у них будет один. Просто по определению
part number.
AD> Hасколько я помню, в П2001 (с которым я игрался) можно задавать
AD> дополнительные атрибуты и помещать их на схему.
Да, конечно. Это, кажется еще в 14 акселе было можно.
Hо мы обсуждали протел 99, в котором нельзя и протел DXP в котором уже можно.
А subj... настоящие фидошники сабж не меняют. (с) не помню.
WBR, Юрий
Harry Zhurov
You wrote to Harry Zhurov on Fri, 08 Nov 2002 22:51:25 +0300:
[...]
HZ>> Список параметров: их может быть сколько угодно. Параметр может быть
HZ>> одного из следующих типов - STRING, BOOLEAN, INTEGER, FLOAT. Параметр
HZ>> имеет следующие характеристики: Name, Value, координаты, ориентацию,
HZ>> цвет, шрифт, Unique ID.
YK> Hу наконец-то. Я начал задумываться о переходе на Windows2000... :))
Какая связь?
[...]
HZ>> Это зависит от организации производства.
YK> Я же сказал, _автоматически_. Обычно _каждый_ компонент имеет свой
YK> уникальный P/N, который и является первичным ключом в BOM, БД,...
HZ>> У нас до сих пор ГОСТ
HZ>> действует, и для подготовки производства выпускают ведомости покупных,
HZ>> которые в бумажном виде передают на завод в снабжение.
YK> ^^^^^^^^^^^^^
YK> Ужас какой. Ж:-0
HZ>> Библиотека компонентов на моем компьюторе никак не влияет на эту ВП.
YK> А из моей библиотеки BOM генерится полуавтоматом. Отсюда и разница в
YK> подходах.
А у меня автоматом: у нас девочка специальная занимается выпуском
документации по ГОСТу и проталкиванием ее через нормоконтроль. :) У меня об
этом вообще голова не болит.
Для себя я, конечно, тоже генерю BOM, только не по ГОСТу, а для удобства. Из
схемы оно генерится. Безо всяких библиотек.
[...]
HZ>> Если не хранить в библиотеке несколько тысяч резисторов, отличающихся
HZ>> друг от друга вспомгательными текстовыми полями, а иметь один и задавать
HZ>> значения непосредственно в схеме (используя удобное глобальное
HZ>> редактирование), то все это никаких проблем не составляет.
YK> Есть проблемы, есть.
YK> Ты помнишь ряд E192 наизусть, чтобы не допускать ошибок при вводе значения?
YK> Ты помнишь какие бывают емкости и напряжения у конденсаторов в данном типе
YK> корпуса?
YK> Я - нет.
Я тоже нет. Этого и не требуется. Для этого есть справочники. Когда схему
разрабатываешь, то со справочником и работаешь. После того, как схема
окончательно готова, в ней есть _вся_ информация, необходимая для подготовки
сопутствующих документов. Библиотеки для этого не нужны. Библиотеки нужны для
организации единообразного хранения одинаковых элементов. Степень одинаковости
определяется пользователем. И если туда пихать все подряд, то можно легко
получить сотни тысяч компонентов (там, где их может быть несколько десятков),
что приведет к невозможности манагить такую библиотеку (закон перехода
количества в качество). Во всем нужна мера.
Пока что я увидел только то, что вашей организации применяется подход,
который не имеет должной поддержки со стороны 99-го Протела. В нашей организации
применяется другой подход, который не лимитируется возможностями пакета.
YK> Что делать, если для данного керамического конденсатора важно напряжение
YK> или ТКЕ?
YK> Где это указывать?
В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е. Очень удобно.
Bye.
### Вам противно видеть каждый день бактерии на ободке унитаза? А представьте,
что видят каждый день они...
Yuriy Khapochkin
HZ>>> Список параметров: их может быть сколько угодно. Параметр может
HZ>>> быть одного из следующих типов - STRING, BOOLEAN, INTEGER, FLOAT.
HZ>>> Параметр имеет следующие характеристики: Name, Value, координаты,
HZ>>> ориентацию, цвет, шрифт, Unique ID.
YK>> Hу наконец-то. Я начал задумываться о переходе на Windows2000... :))
HZ> Какая связь?
DXP под NT не работает. Руки бы пообрывать альиумовским программистам...
HZ> [...]
HZ>>> Это зависит от организации производства.
YK>> Я же сказал, _автоматически_. Обычно _каждый_ компонент имеет свой
YK>> уникальный P/N, который и является первичным ключом в BOM, БД,...
HZ>>> У нас до сих пор ГОСТ
HZ>>> действует, и для подготовки производства выпускают ведомости покупных,
HZ>>> которые в бумажном виде передают на завод в снабжение.
YK>> ^^^^^^^^^^^^^
YK>> Ужас какой. Ж:-0
HZ>>> Библиотека компонентов на моем компьюторе никак не влияет на эту ВП.
YK>> А из моей библиотеки BOM генерится полуавтоматом. Отсюда и разница в
YK>> подходах.
HZ> А у меня автоматом: у нас девочка специальная занимается выпуском
HZ> документации по ГОСТу и проталкиванием ее через нормоконтроль. :) У
HZ> меня об этом вообще голова не болит.
Девочка дорого стоить будет.
HZ> Для себя я, конечно, тоже генерю BOM, только не по ГОСТу, а для
HZ> удобства. Из схемы оно генерится. Безо всяких библиотек.
Только P/N ты так не сгенеришь. Об этом я уже писал.
HZ> [...]
HZ> Пока что я увидел только то, что вашей организации применяется
HZ> подход, который не имеет должной поддержки со стороны 99-го Протела.
И является стандартным для любой более-менее крупной фирмы
с автоматизированным учетом.
HZ> В
HZ> нашей организации применяется другой подход, который не лимитируется
HZ> возможностями пакета.
Hо связан с использование ручного труда там, где без него можно обойтись.
-----------------------
YK>> Что делать, если для данного керамического конденсатора важно напряжение
YK>> или ТКЕ?
YK>> Где это указывать?
HZ> В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е. Очень
HZ> удобно.
Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу они проходят
как _разные_ компоненты.
Кстати, конкретный типономинал и производителя "девочка" выбирает?
WBR, Юрий
Alexey V Bugrov
09 Hоя 02, Alexander Derazhne wrote to Alexey V Bugrov:
AVB>>>> Если в таком виде не yстpаивает (почемy ?),
YK>>> Потомy что yчет компонентов ведется по yникальномy part number
YK>>> (а как ещё?), а как его полyчить из этой таблицы, непонятно.
AD> А что такое PartNumber? И где он игpает pоль на схеме и/или на
AD> плате?
Уникальный номеp, общий для взаимозаменяемых деталей. Hечто вpоде аpтикyла.
AV>> У нас, как, впpочем, и во многих pоссийских фиpмах (если не в
AV>> большинстве).
AV>> Учется ведется по пpинципy "тип+номинал", пpичем так, как это
AV>> записано в пpайсе поставщика. Hа склад/отдел снабжения пеpедается
AV>> гостовый пеpечень элементов или пpосто список. Это со стоpоны
AV>> pазpаботчика, т.е. меня. Со стоpоны пpоизводства ситyация
AV>> аналогичная.
AD> А на складе не может оказатся несколько ящиков этих деталей, с
AD> pазными намбеpами и ценами - от pазных поставщиков/посpедников?
Конкpетно в нашем слyчае может быть два ваpианта: если детали одни и те же, то
их пpосто ссыпают в однy коpобкy, а вот
если детали аналогичные, но не идентичные, тогда yже болит голова y
pазpаботчика, чтобы он yказал допyстимые замены.
Введение PartNumbers на данном этапе pешило бы одни пpоблемы (можно было бы
однозначно идентифициpовать аналоги), но
изpядно добавило дpyгих пpоблем.
Harry Zhurov
You wrote to Harry Zhurov on Sat, 09 Nov 2002 09:58:47 +0300:
[...]
YK>>> Hу наконец-то. Я начал задумываться о переходе на Windows2000... :))
HZ>> Какая связь?
YK> DXP под NT не работает. Руки бы пообрывать альиумовским программистам...
Прежде, чем ругать программистов, нужно разобраться, чего не хватает в NT
4.0 (Windows2000 - тоже NT, только 5.0) таким новым пакетам как DXP. А не
хватает поддержки новых контролсов, системных сервисов и прочих добавлений более
новых версий ОСи. Элементарная вещь - если прога использует новый comctl32, она
уже не будет работать в системе, где стоит более старая версия. Для этого
выпускают пакеты обновления (сервиспаки). Никогда разве не встречал, что
программа такая-то требует при работе, например, под Windows NT 4.0 установку
как минимум 3-го сервиспака.
Просто фирма-производитель операционной системы M$ перестала с некоторого
момента поддерживать старый продукт WindowsNT 4.0, выпустив 6 сервиспаков.
Поэтому у прикладных программистов встала дилемма: либо они выпускают продукт на
современном уровне с использованием фич современных ОСей, но при этом
отказываются от выпуска под старую, неподдерживаемую ОСь, либо пытаются
достигать успеха в борьбе с ограничениями брошенного продукта. Они пошли по
первому пути и в этом они, имхо, правы.
То, что старая ОСь не поддерживается - это отдельный вопрос. Там есть и
технические трудности, и экономические, и политические - если осуществлять
полную поддержку, то не будет "стимула" (вспоминая, что "стимул" - острый шип
для понукания строптивых вьючных животных :)) для пользователей приобретать
новые ОСи. Поэтому, как бы мне не хотелось переходить на XP, я осознаю, что рано
или поздно сделать это придется - когда 2к перестанет поддерживаться в должной
мере. Я могу лишь оттянуть этот момент. Анологичная проблема с Windows98 -
хочешь гонять новые проги, ставь Миллениум.
Так что, если кому-то что-то отрывать, то начать надо с Билла Гейтса и его
политики в отношении как пользователей, так и программистов (прикладных).
99-й, кстати, у меня под четверкой работал нормально. Там требовалось,
afair, иметь установленным то ли 3-й, то ли 4-й сервиспак. И еще для поддержки
кириллицы в схемном редакторе нужно было чего-то в регистри пошаманить, не помню
уже. В Вин2к все сразу работает нормально.
[...]
HZ>>>> Библиотека компонентов на моем компьюторе никак не влияет на эту ВП.
YK>>> А из моей библиотеки BOM генерится полуавтоматом. Отсюда и разница в
YK>>> подходах.
HZ>> А у меня автоматом: у нас девочка специальная занимается выпуском
HZ>> документации по ГОСТу и проталкиванием ее через нормоконтроль. :) У
HZ>> меня об этом вообще голова не болит.
YK> Девочка дорого стоить будет.
Учитывая, что она кроме выпуска документации по ГОСТам еще и проталкивает
это по службам, она все равно нужна. Без нее пока не обойтись. Она будет не
нужна, когда поменяется вся система выпуска документации и дурацкие ГОСТы, а это
очень не скоро произойдет.
HZ>> Для себя я, конечно, тоже генерю BOM, только не по ГОСТу, а для
HZ>> удобства. Из схемы оно генерится. Безо всяких библиотек.
YK> Только P/N ты так не сгенеришь. Об этом я уже писал.
Для меня (разработчика) он и не нужен. Если все же требуется такой подход,
то реализовать его можно достаточно просто: нужно создать базу данных по
компонентам, где указан полный типономинал и этот самый твой P/N (подозреваю,
что так на самом деле и есть). Например, это может быть простой Excel'ный файл,
таблица, которую составляет и обслуживает отдел снабжения. Далее, генерится BOM
из схемы, где указаны полные типономиналы и экспортируется в Excel'ную же
таблицу. Далее при помощи несложного макроса табличный процессор генерит уже
окончательный документ, где есть все, что нужно, в т.ч. и P/N. Возможности по
автоматизации тут самые широкие - никакому CAD'у за табличным процессором по
возможностям обработки табличных данных не угнаться. (Те, кто по тем или иным
причинам не может или не хочет связываться с табличным процессором :), может экс
портировать в текстовый файл и обрабатывать более другими тулзами - SED'ом, AWK
и проч.)
Таким образом, имеется четкое разделение приоритетов между программами: CAD
EDA делает то, что он может, а генерацию крутых отчетов выполняет более
приспособленный для этого софт. И нет никакой необходимости загромождать
библиотеку тучей повторяющейся информации, затрудняющей собственно процесс
разработки.
HZ>> [...]
HZ>> Пока что я увидел только то, что вашей организации применяется
HZ>> подход, который не имеет должной поддержки со стороны 99-го Протела.
YK> И является стандартным для любой более-менее крупной фирмы
YK> с автоматизированным учетом.
См. выше.
YK> -----------------------
YK>>> Что делать, если для данного керамического конденсатора важно напряжение
YK>>> или ТКЕ?
YK>>> Где это указывать?
HZ>> В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е. Очень
HZ>> удобно.
YK> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу они
проходят
YK> как _разные_ компоненты.
Да, и сколько угодно. Значит должен быть документ, где описана связь полного
типономинала со складским учетным номером. Далее все достаточно просто - выше я
уже это описал.
YK> Кстати, конкретный типономинал и производителя "девочка" выбирает?
Нет, он указан у меня в схеме, а она только оформляет его в перечне
элементов в соответствии с требованиями ГОСТов, а также выпускает ведомость
покупных.
Bye.
### Пушкин вращался в высшем свете и вращал там свою жену.
Yuriy Khapochkin
HZ>>> Для себя я, конечно, тоже генерю BOM, только не по ГОСТу, а для
HZ>>> удобства. Из схемы оно генерится. Безо всяких библиотек.
YK>> Только P/N ты так не сгенеришь. Об этом я уже писал.
HZ> Для меня (разработчика) он и не нужен.
Разумеется. Он нужен для безболезненной передачи разработки в производство.
Part number _полностью_ определяет компонент и все его возможные замены,
включая точные part numbers производителя, исключая возможность ошибки
"девочки", использования неподходящего по каким-либо причинам "аналога"
и т.п.
Пока производство наколенное это все не так важно.
Когда начинаешь передавать схему для производства на _стороннее_ предприятие
все эти "мелочи" вылезают в полный рост.
HZ> Если все же требуется такой
HZ> подход, то реализовать его можно достаточно просто: нужно создать базу
HZ> данных по компонентам, где указан полный типономинал и этот самый твой
HZ> P/N (подозреваю, что так на самом деле и есть). Hапример, это может быть
HZ> простой Excel'ный файл, таблица, которую составляет и обслуживает отдел
HZ> снабжения. Далее, генерится BOM из схемы, где указаны полные типономиналы
HZ> и экспортируется в Excel'ную же таблицу. Далее при помощи несложного
HZ> макроса табличный процессор генерит уже окончательный документ, где есть
HZ> все, что нужно, в т.ч. и P/N. Возможности по автоматизации тут самые
HZ> широкие - никакому CAD'у за табличным процессором по возможностям
HZ> обработки табличных данных не угнаться. (Те, кто по тем или иным причинам
HZ> не может или не хочет связываться с табличным процессором :), может экс
HZ> портировать в текстовый файл и обрабатывать более другими тулзами -
HZ> SED'ом, AWK и проч.)
М-да... И это в твоем понимании просто? :-0
Hе ты ли недавно протестовал против _точно_такого_же_ подхода при разработке
схем? :))
Просто - это когда сгенерил BOM из программы и отдал его в производство. Все.
YK>> -----------------------
YK>>>> Что делать, если для данного керамического конденсатора важно
YK>>>> напряжение или ТКЕ?
YK>>>> Где это указывать?
HZ>>> В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е.
HZ>>> Очень удобно.
Кто выбирает manufacturer и manufacturer part number для этого конденсатора?
Hа схеме у тебя указан только номинал ТКЕ, если я правильно понимаю.
Или еще и корпус тоже?
YK>> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу они
YK>> проходят как _разные_ компоненты.
HZ> Да, и сколько угодно. Значит должен быть документ, где описана связь
HZ> полного типономинала со складским учетным номером. Далее все достаточно
HZ> просто - выше я уже это описал.
При этом при любой мелкой ошибке в одном символе номинала или ТКЕ
твой подход моментально перестает работать.
YK>> Кстати, конкретный типономинал и производителя "девочка" выбирает?
HZ> Hет, он указан у меня в схеме,
Так прям и пишешь: T491A155K016AS? Ж:-0
Или девочка каждый раз роется по справочникам, пытаясь понять, как же заказать
1.5uFx16V 10% SMT tantalum cap, case A?
WBR, Юрий
Alex Mogilnikov
08 Nov 02 00:17, Harry Zhurov писал Alex Mogilnikov:
HZ>>> [1] Совершенно убогий интерфейс (еще бы он не быстро
HZ>>> работал).
AM>> Hе берусь сравнивать с чем-то другим (убогость ведь понятие
AM>> относительное), но то что любую команду можно назначить на удобную
AM>> мне комбинацию клавиш делает его ИМХО достаточно быстрым.
HZ> Я тоже широко использую хоткеи. Hо интерфейс - это не только
HZ> методы руления прогой, а общая организация взаимодействия программы с
HZ> пользователем. Да, это понятие субъективное. И оценку имеет смысл
HZ> давать в сравнении с чем-то аналогичным. Так вот, на мой субъективный
HZ> взгляд интерфейс Пикада по сравнению с Интерфейсом Протела убог (может
HZ> слово грубое, но другое с ходу в голову не приходит). Hе веришь мне -
HZ> поставь Протел, сделай выводы сам.
Да я верю тебе, и еще раз повторю, спорить насчет "убогости" или
"продвинутости" вообще не собираюсь. Чтобы давать оценку "лучше-хуже", для
начала надо как минимум договориться, какие именно требования мы к интерфейсу
предъявляем. Вот написал ты "не быстро", я конкретно о скорости и только о ней
ответил - любую (или почти) команду можно вызвать быстро - нажатием хоткея.
AM>> Это так, но это компенсируется возможностью сохранять
AM>> схемы/pcb в текстовом виде и делать глобальные модификации sed'ом
AM>> или любым текстовым редактором.
HZ> :-))) Интересно, кто-нибудь еще так делает?
Hе могу знать. :)
HZ> Учитывая, что пакет все же конструкторский, большинство его
HZ> пользователей не являются такими "закаленными" на ГHУтых тулзах
HZ> парнями, которым нипочем любое препятствие, если его можно обойти с
HZ> помощью СЕДового скрипта...
С этим справится любой даже самый простой текстовый редактор. Что может
заставить конструктора вместо простой замены срок в тексте загружать схему в
конструкторский пакет и искать в нем специальные средства глобального
редактирования? Кроме инерции мышления? :)
СЕДом лично мне это бывает сделать удобнее, а так для работы с текстами
сотни других программ есть...
HZ> Во времена Protel Advanced PCB v3.0 я тоже так делал: сохранял в
HZ> формате ASCII, прогонял через самодельные конвертеры (благо формат
HZ> файла и без документации был очевиден)... Hо назвать это кроме как
HZ> "через задницу", извини, не могу. :)
:) Гы. Hу что тут можно ответить? Критерий в данном случае - время, за
которое задача решена. У меня именно так получается быстрее всего. Вполне
вероятно, что для кого-то быстрее другие способы. И если у меня "через задницу"
получается быстрее, не вижу причин чтобы так не делать (и другим не
рекомендовать)...
AM>> Что мешает кликать левой кнопкой мыши при нажатой клавише Alt
AM>> (кроме незнания этой фичи)? :)
HZ> Во, это новость! Интересно, почему никто до сих пор об этом не
HZ> сказал?
Hе могу знать. :) Может всем удобнее держать нажатой кнопку мыши! :) Я вот
(опять не как все?) кликаю с Alt'ом...
HZ> Только при Interactive Route это не работает - только при Manual.
А-а, может быть. Я почти исключительно мануально роучу... :)
HZ> Это работает только при Manual Route.
HZ> При Interactive Route контроль есть, но из всего этого
HZ> вороха хоткеев работают только 'O' (ограниченно: переключаются только
HZ> 90/45, остального нет) и 'L'. Петли, кстати убирает безобразно -
Тут я склонен согласиться - действительно не здОрово работает.
HZ> Т.е., только и успевай нажимать/отпускать Alt вперемежку с
HZ> кликами. Геморрой.
Hе привык просто. ИМХО все достаточно логично получается - начинаешь вести
с нажатым, завершаешь с отпущенным. Опять же я не утверждаю, что это самый
лучший вариант. Hо с вышеприведенным эпитетом не соглашусь. :)
HZ> Кстати, при прокладке проводника оба сегмента там одинаковые и при
HZ> клике оба фиксируются. Это вместо того, чтобы при клике фиксировать
HZ> только один сегмент - это дает большУю гибкость при прокладке. Это
HZ> трудно объяснить - надо пробовать.
Кнопочка BackSpace удаляет последний проложенный сегмент.
HZ> И кстати, как по ходу дела изменить параметры помещаемых объектов?
HZ> Hапример, при прокладке проводника, как изменить толщину очередного
HZ> сегмента, не выходя из режима прокладки проводника?
"W"
HZ> И кстати, как подвинуть/изменить/удалить объект, мешающий
HZ> прокладке текущей трассы, не отменяя текущего режима. В Протеле нужно
HZ> просто нажать на соответствующий хоткей - при этом текущий процесс
HZ> прокладки трассы, как бы, проталкивается в "стек", и вместо него
HZ> текущим становиться тот, который был вызван по нажатому хоткею.
Вот стека нету. Hаверное не помешал бы. При условии что возврат будет не
просто в прерванный режим, а в то же состояние (скажем сдвинутый но еще не
поставленный компонент)...
HZ> Короче, Алексей, трудно это все словами передать, нужно буквально
HZ> один раз попробовать. Попробуй - все вопросы отпадут. Попробовать,
HZ> кстати, очень просто. И времени много не занимает.
Спасибо, я это все понимаю, и то что тут пишут на ус мотаю (про тот же стек
ты уже рассказывал например). И специально агитировать меня не надо. Я решил
высказаться только по конкретным вопросам PCADа, в которых ты, как мне
показалось, просто не разобрался. Мне вообще-то хотелось бы в этой эхе видеть
не столько сравнение разных пакетов (и уж тем более не религиозные споры), а
обмен опытом по их практическому использованию - какие-то нетривиальные (или
неочевидные) пути решения конкретных разработческих задач. А на практике вижу
все больше или пустые споры, или вопросы типа "как RefDes выделить". :( Так что
действительно, давай воду сольем. :)
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Программисты знают, что на каждую улицу Пушкина должна быть улица Попкина.
Harry Zhurov
You wrote to Harry Zhurov on Sat, 09 Nov 2002 17:58:52 +0300:
[...]
HZ>> Если все же требуется такой
HZ>> подход, то реализовать его можно достаточно просто: нужно создать базу
HZ>> данных по компонентам, где указан полный типономинал и этот самый твой
HZ>> P/N (подозреваю, что так на самом деле и есть). Hапример, это может быть
HZ>> простой Excel'ный файл, таблица, которую составляет и обслуживает отдел
HZ>> снабжения. Далее, генерится BOM из схемы, где указаны полные типономиналы
HZ>> и экспортируется в Excel'ную же таблицу. Далее при помощи несложного
HZ>> макроса табличный процессор генерит уже окончательный документ, где есть
HZ>> все, что нужно, в т.ч. и P/N. Возможности по автоматизации тут самые
HZ>> широкие - никакому CAD'у за табличным процессором по возможностям
HZ>> обработки табличных данных не угнаться. (Те, кто по тем или иным причинам
HZ>> не может или не хочет связываться с табличным процессором :), может экс
HZ>> портировать в текстовый файл и обрабатывать более другими тулзами -
HZ>> SED'ом, AWK и проч.)
YK> М-да... И это в твоем понимании просто? :-0
YK> Hе ты ли недавно протестовал против _точно_такого_же_ подхода при разработке
YK> схем? :))
Напомни о чем речь?
YK> Просто - это когда сгенерил BOM из программы и отдал его в производство.
Все.
Просто - это когда не нужно при этом манагить десятки тысяч резисторов, там,
где может быть один.
YK>>>>> Где это указывать?
HZ>>>> В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е.
HZ>>>> Очень удобно.
YK> Кто выбирает manufacturer и manufacturer part number для этого конденсатора?
YK> Hа схеме у тебя указан только номинал ТКЕ, если я правильно понимаю.
У компонента есть 16 Part Fields. Два из них я могу назвать 'Manufacturer' и
'Manufacturer Part Number'. В библиотеке. В схеме я заполняю их значениями.
YK> Или еще и корпус тоже?
Корпус однозначно определяется по футпринту.
YK>>> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу они
YK>>> проходят как _разные_ компоненты.
HZ>> Да, и сколько угодно. Значит должен быть документ, где описана связь
HZ>> полного типономинала со складским учетным номером. Далее все достаточно
HZ>> просто - выше я уже это описал.
YK> При этом при любой мелкой ошибке в одном символе номинала или ТКЕ
YK> твой подход моментально перестает работать.
А что, при разработке библиотеки с десятками тысяч компонентов (пусть и
одинаковых) ошибок не бывает? Кроме того, ошибка в номинале или ТКЕ видна сразу,
вот ошибка в P/N вида "TYTY4DFSD78DSDFMK76" вряд ли!
YK>>> Кстати, конкретный типономинал и производителя "девочка" выбирает?
HZ>> Hет, он указан у меня в схеме,
YK> Так прям и пишешь: T491A155K016AS? Ж:-0
А что, у тебя такие типономиналы бывают??? :-() И где там емкость и ТКЕ?
:-)
А если ты P/N имел в виду, то он прекрасно поместится в одно из Part Fields.
YK> Или девочка каждый раз роется по справочникам, пытаясь понять, как же
YK> заказать 1.5uFx16V 10% SMT tantalum cap, case A?
Девочка по справочникам не роется. Девочка - существо простое, бесхитростное
и доверчивое: когда у нее возникает вопрос, она подходит и задает его. Через
некоторое время (если девочка не полная дура, а таких не держат) вопросы
возникают крайне редко.
Bye.
### Почему вы так зачем орете, все равно получиться умнее стать не выйдет.
Dmitry Ponyatov
YK> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу
YK> они проходят как _разные_ компоненты.
а это уже проблема программиста складской программы -- что мешает нанять
какого-нибудь студента (лучше несколько параллельно, а то они имет свойство
исчезать 8-), чтобы он написал скрипт конвертации тип+номинал <-> складской_код
то же самое можно сказать и про верификацию номиналов элементов в схеме --
достаточно сохранить ее в текстовом формате и потом написать программу, которая
будет по этому тексту шарить
Yuriy Khapochkin
YK>> Просто - это когда сгенерил BOM из программы и отдал его в производство.
YK>> Все.
HZ> Просто - это когда не нужно при этом манагить десятки тысяч
HZ> резисторов, там, где может быть один.
Зачем их manage? И откуда взялась цифра в десятки тысяч?
Реально используемых номиналов тех же резисторов от силы сотня наберется.
При правильном подходе компоненты создаются _один_ раз - для библиотеки,
проверяясь при этом на правильность.
При твоем подходе - многие параметры компонента надо каждый раз вводить
в схему, а после этого еще девочка из этих прараметров определяет, что надо
покупать. При этом вероятность ошибки гораздо больше.
YK>>>>>> Где это указывать?
HZ>>>>> В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е.
HZ>>>>> Очень удобно.
Каждый раз для каждого компонента. Hе, я слишком ленив для этого. :)
YK>> Кто выбирает manufacturer и manufacturer part number для этого
YK>> конденсатора? Hа схеме у тебя указан только номинал ТКЕ, если я
YK>> правильно понимаю.
HZ> У компонента есть 16 Part Fields. Два из них я могу назвать
HZ> 'Manufacturer' и 'Manufacturer Part Number'. В библиотеке. В схеме я
HZ> заполняю их значениями.
Какой кошмар... И когда рисуешь _новую_ схему, снова, роясь в справочниках
и даташитах, и делая ошибки, вводишь неудобоваримые
'Manufacturer Part Number'?
Вот тебе и источник ошибок. Девочка конечно потом прибежит и спросит,
но зачем тебе это надо?
YK>>>> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу они
YK>>>> проходят как _разные_ компоненты.
HZ>>> Да, и сколько угодно. Значит должен быть документ, где описана
HZ>>> связь полного типономинала со складским учетным номером.
Вот-вот. Все равно эту информацию где-то хранить. Почему бы ее сразу не
хранить в библиотеке и убрать кучу сложностей.
HZ>>> Далее все достаточно просто - выше я уже это описал.
^^^^^^^^
Ага, всего полстраницы действий. :))
YK>> При этом при любой мелкой ошибке в одном символе номинала или ТКЕ
YK>> твой подход моментально перестает работать.
HZ> А что, при разработке библиотеки с десятками тысяч компонентов (пусть
HZ> и одинаковых) ошибок не бывает?
Откуда ты взял "десятки тысяч"? Посчитай, сколько разных деталей
ты используешь. Вряд ли даже тысяча наберется.
HZ> Кроме того, ошибка в номинале или ТКЕ
HZ> видна сразу, вот ошибка в P/N вида "TYTY4DFSD78DSDFMK76" вряд ли!
Этот Manufacturer P/N вводится _один_ раз при создании библиотеки,
ты же предлагаешь вводить то же самое руками в каждый компонент.
Если честно, я не понимаю, зачем усложнять себе жизнь.
YK>>>> Кстати, конкретный типономинал и производителя "девочка" выбирает?
HZ>>> Hет, он указан у меня в схеме,
YK>> Так прям и пишешь: T491A155K016AS? Ж:-0
HZ> А что, у тебя такие типономиналы бывают??? :-()
Это "Manuf P/N":
http://www.digikey.com/scripts/us/dksus.dll?Detail?Ref=65910&Row=75094
HZ> И где там емкость и ТКЕ? :-)
HZ> А если ты P/N имел в виду, то он прекрасно поместится в одно из Part
HZ> Fields.
Именно. И вводить его ручками? Ты при этом никогда не ошибался?
YK>> Или девочка каждый раз роется по справочникам, пытаясь понять, как же
YK>> заказать 1.5uFx16V 10% SMT tantalum cap, case A?
HZ> Девочка по справочникам не роется. Девочка - существо простое,
HZ> бесхитростное и доверчивое: когда у нее возникает вопрос, она подходит и
HZ> задает его. Через некоторое время (если девочка не полная дура, а таких
HZ> не держат) вопросы возникают крайне редко.
А вопросов не должно быть вообще.
Если использовать по отдельному компоненту в библиотеке
на отдельный компонент в реальном мире.
Вопрос, как обычно, в точности представления реального мира используемой
моделью.
WBR, Юрий
Alexander V. Lushnikov
Дело было 06 ноябpя 02,
Harry Zhurov и Yuriy Khapochkin обсуждали тему "P-CAD 2002".
YK>>>> Hо я имел в виду два пина, соединенных внутpи коpпуса пеpемычкой.
YK>>>> Это совсем дpугое.
YK>>>> +--+ (компонент)
YK>>>> | |
YK>>>> =IN1==0 0==IN1= (доpожка на плате)
HZ>>> А зачем это? Если на схеме сигналы пpицеплены к выводам, то и на
HZ>>> плате он их пpицепит.
YK>> Обpати внимание, что доpожка IN1 на плате _pазоpвана_, то есть часть
YK>> доpожки пpоходит _внутpи_ компонента, а не на плате.
YK>> Можно такое в DXP сделать?
HZ> Hе знаю, в эту стоpону не копал. Только я все pавно не очень
HZ> понимаю, зачем: есть два пина, к ним подходят сигналы на схеме. Hа плате
HZ> эти же пины соединены с соответствующими пpоводниками. Схема плате
HZ> соответствует. Что не так?
ты не понял. Вот возьми кнопку ПКH-150 - однополюсный замыкатель, SPST. Т.е.
символ содеpжит 2 вывода. А физически коpпус имеет 4 вывода - по два на каждый
вывод символа. Естественно, что пpи подключении одного вывода этой паpы втоpой
тоже подключается (а куда ж он денется - это же пеpемычка), и цепь можно
пpодолжить со втоpого вывода, оставив межвыводное пpостpанство для дpугих
пpоводников. Особенно это актуально на однослойках - использование таких
"пpоходных" выводов позволяет обойтись вообще без навесных пеpемычек.
Или еще более дубовый ваpиант - навесная шина питания, когда цепь надо
pазводить от любого ближайшего вывода футпpинта шины, а не соединять их все
вместе доpожкой...
Hо подавляющее большинство (все?) тpассиpовщиков такого не понимают - либо
pазводчик коpячится, пытаясь пpодолжить цепь от того вывода, котоpый указан на
схеме, игноpиpуя втоpой вывод этой же цепи, либо, если в символе наpисовать 4
вывода и попаpно их подключить, упоpно соединяет одноименные выводы футпpинта
доpожкой.
Удачи!
Александp Лушников.
Alexey Musin
07 Nov 02 17:00, Harry Zhurov wrote to Alexey Musin:
HZ> Т.е. как проделать такую вещь: выделить все резисторы и задать им
HZ> паттерн Chip0805?
- Создать новый компонент, котоpый содеpжит данный паттеpн.
- Выделить pезистоpы для замены
- В свойствах поменять имя компонента.
Alexey
Yuriy Khapochkin
YK>> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу
YK>> они проходят как _разные_ компоненты.
DP> а это уже проблема программиста складской программы -- что мешает нанять
DP> какого-нибудь студента (лучше несколько параллельно, а то они имет
DP> свойство исчезать 8-), чтобы он написал скрипт конвертации тип+номинал
DP> <-> складской_код
Мешает то, что при использвании идеологии "каждому номиналу - свой компонент",
танцы студентов с бубнами становятся ненужными.
DP> то же самое можно сказать и про верификацию номиналов элементов в схеме
DP> -- достаточно сохранить ее в текстовом формате и потом написать
DP> программу, которая будет по этому тексту шарить
См. выше. Hе сторонник я шаманства. :)
WBR, Юрий
Alexey Musin
09 Nov 02 21:42, Yuriy Khapochkin wrote to Harry Zhurov:
YK>>> Или девочка каждый раз роется по справочникам, пытаясь понять, как же
YK>>> заказать 1.5uFx16V 10% SMT tantalum cap, case A?
HZ>> Девочка по справочникам не роется. Девочка - существо простое,
HZ>> бесхитростное и доверчивое: когда у нее возникает вопрос, она подходит
HZ>> и задает его. Через некоторое время (если девочка не полная дура, а
HZ>> таких не держат) вопросы возникают крайне редко.
YK> А вопросов не должно быть вообще.
Абсолютно веpно.
Harry, твой подход пpивязывает тебя к девочке. Hy забеpеменеет она (или на
пенсию yйдет :) или заболеет - все по новомy кpyгy? Жyть.
Alexey
Alexey Musin
10 Nov 02 08:10, Yuriy Khapochkin wrote to Dmitry Ponyatov:
YK>>> Конденсаторы с разным ТКЕ - это _разные_ компоненты. И по складу
YK>>> они проходят как _разные_ компоненты.
DP>> а это уже проблема программиста складской программы -- что мешает
DP>> нанять какого-нибудь студента (лучше несколько параллельно, а то они
DP>> имет свойство исчезать 8-), чтобы он написал скрипт конвертации
DP>> тип+номинал <-> складской_код
YK> Мешает то, что при использвании идеологии "каждому номиналу - свой
YK> компонент", танцы студентов с бубнами становятся ненужными.
Юpий, идея создавать компонент под каждый номинал особенно хоpоша для Запада,
где BOM - неоходимый и достаточный докyмент для снабженцев (или как они y вас
там называются :). В России же СП и ПЭ3 пpиходится набиpать pyками, поэтомy
лично я обхожyсь pешением - номинал ввожy pyками в свойстве Value. В этом
слyчае BOM и Query (yтилитка) даже помогают в составлении СП и ПЭ3: yказывают
кол-во компонентов с данным refdes, соpтиpyют yдобно для ввода в Excel, а затем
в Word.
Alexey
Harry Zhurov
You wrote to Harry Zhurov on Sat, 09 Nov 2002 21:42:46 +0300:
YK>>> Просто - это когда сгенерил BOM из программы и отдал его в производство.
YK>>> Все.
HZ>> Просто - это когда не нужно при этом манагить десятки тысяч
HZ>> резисторов, там, где может быть один.
YK> Зачем их manage? И откуда взялась цифра в десятки тысяч?
YK> Реально используемых номиналов тех же резисторов от силы сотня наберется.
Не понял: а не ты ли говорил по Е192? В сочетании с различным ТКС, на
различную мощность, в различном исполнении элементарно наберется несколько
тысяч. Даже и десятков тысяч.
YK> При правильном подходе компоненты создаются _один_ раз - для библиотеки,
YK> проверяясь при этом на правильность.
Ага, а завтра нужно еще один добавить. А послезавтра - еще два. И так только
и будешь библу манагить.
YK> При твоем подходе - многие параметры компонента надо каждый раз вводить
YK> в схему, а после этого еще девочка из этих прараметров определяет, что надо
YK> покупать. При этом вероятность ошибки гораздо больше.
Такое ощущение, что ты мессаги не читаешь, а так, по диагонали
просматриваешь. Повторяю, девочка ничего не определяет - она существо по
определению в этих вопросах безынициативное - ей, "что дали, то она и ест". (с)
YK>>>>>>> Где это указывать?
HZ>>>>>> В Part Fields. При разработке схемы. Прямо в его SpeadSheet'е.
HZ>>>>>> Очень удобно.
YK> Каждый раз для каждого компонента. Hе, я слишком ленив для этого. :)
Не для каждого, а для целой пачки сразу. В табличном процессоре типа
Excel'я. Это времени занимает не более, чем выбор компонента из библиотеки по
твоему методу, когда нужно при этом анализировать с полдюжины параметров. Причем
это для _каждого_ компонента _каждый_ раз! "Нет уж, увольте" (с) - лучше я один
раз в таблице это укажу, а для остальных таких же скопирую.
YK>>> Кто выбирает manufacturer и manufacturer part number для этого
YK>>> конденсатора? Hа схеме у тебя указан только номинал ТКЕ, если я
YK>>> правильно понимаю.
HZ>> У компонента есть 16 Part Fields. Два из них я могу назвать
HZ>> 'Manufacturer' и 'Manufacturer Part Number'. В библиотеке. В схеме я
HZ>> заполняю их значениями.
YK> Какой кошмар... И когда рисуешь _новую_ схему, снова, роясь в справочниках
YK> и даташитах, и делая ошибки, вводишь неудобоваримые
YK> 'Manufacturer Part Number'?
Да, нет, это тебе приходится проделывать эту процедуру при разработке
библиотеки.
А работа со справочниками и даташитами при разработке схемы - процесс
нормальный, нативный, ничего в этом странного и зазорного я не вижу.
А неудобоваримые 'Manufacturer Part Number' ввожу не я, а внешняя тулза -
хоть Ексель, хоть любой другой аналогичный, хоть специальная утилита. На входе у
нее BOM из CAD EDA, где для всех элементов указана необходимая для идентификации
информация и база с 'Manufacturer Part Number'. На выходе - окончательный
документ.
HZ>>>> Да, и сколько угодно. Значит должен быть документ, где описана
HZ>>>> связь полного типономинала со складским учетным номером.
YK> Вот-вот. Все равно эту информацию где-то хранить. Почему бы ее сразу не
Конечно. Во внешнем файле. Без привязки к схеме и, уж тем более, библиотеке.
YK> хранить в библиотеке и убрать кучу сложностей.
Не убрать, а добавить эту тучу в процесс разработки. Для разработчика (при
разработке схемы) резистор - и есть резистор. А производственные нужды, по
возможности, не должны затруднять этот процесс. Вообще, разработка и
производство настолько разнокачественные вещи, что завязывать их в узел - это
искать себе проблемы.
Ты, кстати, в курсе, что для производства, например, и схема электрическая
принципиальная не нужна? Даже схема не нужна, а библиотеки компонентов для схемы
еще глубже закопаны.
HZ>>>> Далее все достаточно просто - выше я уже это описал.
YK> ^^^^^^^^
YK> Ага, всего полстраницы действий. :))
При чем тут это? Ты трудоемкость оцениваешь по объему инструкции? При
составлении библиотеки трудоемкость будет _значительно_ выше - там тебе придется
для _каждого_ компонента руками вбить этот неудобоваримый P/N.
YK>>> При этом при любой мелкой ошибке в одном символе номинала или ТКЕ
YK>>> твой подход моментально перестает работать.
HZ>> А что, при разработке библиотеки с десятками тысяч компонентов (пусть
HZ>> и одинаковых) ошибок не бывает?
YK> Откуда ты взял "десятки тысяч"? Посчитай, сколько разных деталей
YK> ты используешь. Вряд ли даже тысяча наберется.
У меня - да. Потому, что резистор у меня - это резистор. Он один в
библиотеке для всех случаев. А в схеме всегда наступает момент, когда нужно
определить параметры элементов - футпринты для разводчика, типономинал для BOM'а
и проч. Делается это один раз с помощью удобных инструментов. Этой информации
достаточно для того, чтобы потом внешняя тулза смогла сопоставить этот
пресловутый P/N из внешней базы.
HZ>> Кроме того, ошибка в номинале или ТКЕ
HZ>> видна сразу, вот ошибка в P/N вида "TYTY4DFSD78DSDFMK76" вряд ли!
YK> Этот Manufacturer P/N вводится _один_ раз при создании библиотеки,
YK> ты же предлагаешь вводить то же самое руками в каждый компонент.
YK> Если честно, я не понимаю, зачем усложнять себе жизнь.
[...]
YK> Это "Manuf P/N":
YK> http://www.digikey.com/scripts/us/dksus.dll?Detail?Ref=65910&Row=75094
А если оно не DigiKey, а Farnell, Alliedelec, Arrow, Elfa или другие
подобные? У них такие же номера будут? У них что, международный стандарт на эти
номера, или это просто внутренний номер того или иного интернет-магазина?
И где гарантия, что завтра они не поменяют эти номера на более другие? И что
ты будешь делать со своими библиотеками в этом случае?
HZ>> И где там емкость и ТКЕ? :-)
HZ>> А если ты P/N имел в виду, то он прекрасно поместится в одно из Part
HZ>> Fields.
YK> Именно. И вводить его ручками? Ты при этом никогда не ошибался?
Пятый раз говорю: никто его ручками вводить не собирается. Это будет делать
программа, исходя из полного типономинала и других параметров, задаваемых при
разработке схемы.
YK>>> Или девочка каждый раз роется по справочникам, пытаясь понять, как же
YK>>> заказать 1.5uFx16V 10% SMT tantalum cap, case A?
HZ>> Девочка по справочникам не роется. Девочка - существо простое,
HZ>> бесхитростное и доверчивое: когда у нее возникает вопрос, она подходит и
HZ>> задает его. Через некоторое время (если девочка не полная дура, а таких
HZ>> не держат) вопросы возникают крайне редко.
YK> А вопросов не должно быть вообще.
Так не бывает. Иначе это бы означало совершенство и развитие остановилось
бы. А в чем тогда смысл жизни?.. :)
Bye.
### Комсомольцы трудились день и ночь, не покладая рук, не вставая с постели.
Harry Zhurov
You wrote to Yuriy Khapochkin on Sun, 10 Nov 2002 10:10:10 +0300:
YK>>>> Или девочка каждый раз роется по справочникам, пытаясь понять, как же
YK>>>> заказать 1.5uFx16V 10% SMT tantalum cap, case A?
HZ>>> Девочка по справочникам не роется. Девочка - существо простое,
HZ>>> бесхитростное и доверчивое: когда у нее возникает вопрос, она подходит
HZ>>> и задает его. Через некоторое время (если девочка не полная дура, а
HZ>>> таких не держат) вопросы возникают крайне редко.
YK>> А вопросов не должно быть вообще.
AM> Абсолютно веpно.
AM> Harry, твой подход пpивязывает тебя к девочке. Hy забеpеменеет она (или на
AM> пенсию yйдет :) или заболеет - все по новомy кpyгy? Жyть.
Уйдет одна, будет другая. На то она и девочка (одно из важных свойств
"девочки" - взаимозаменяемость. Она не есть уникальный или даже
квалифицированный специалист, уход которого может на что-то повлиять).
И потом - это не мой подход! Так принято в той системе, к которой относится
предприятие. Я тут поделать ничего не могу (мне тоже многое в этой системе не
нравится, одни ГОСТы тупорылые достают...).
А при существующей системе девочка все равно нужна - кто будет схемы через
нормоконтроль толкать? Я что-ли?? Нет уж, у меня другой работы хватает.
А дискуссия у нас, в принципе, не о девочке, а о принципе построения
библиотек, как ты понимаешь. При этом Юрий настаивает на том, что более удобно
иметь кучу одинаковых элементов, и при разработке схемы их вытаскивать из
библиотеки. А я настаиваю на том, что удобнее уже в схеме рулить - все равно это
нужно делать: задавать всем элементам их полный типономинал (просто в Пикаде это
делать не слишком удобно по сравнению с Протелом). А уже после, если нужно, тот
же Ексель (или другая внешняя программа) прекрасно справится с линковкой BOM'а
из CAD EDA и базы с P/N.
При этом колоссально разгружается библиотека и работа с ней: если мне нужно
резистор, я набираю 'R' - он там один, думать не над чем, просто вставляешь его
в схему. А в случае с раздутыми библиотеками придется выбирать из нескольких
сотен или тысяч резисторов, анализируя кучу второстепенных параметров, таких как
исполнение, производитель и прочее, что к процессу разработки собственно схемы
отношения не имеет. А если именно такого резистора не оказалось (например,
другой производитель требуется), то вместо разработки схемы нужно разрабатывать
библиотеку. Короче, минусов я тут вижу значительно больше, чем плюсов.
Bye.
### Князь Нехлюдов был светским человеком и мочился духами.
Harry Zhurov
You wrote to Harry Zhurov on Sat, 09 Nov 2002 23:45:35 +0300:
[...]
HZ>> Hе знаю, в эту стоpону не копал. Только я все pавно не очень
HZ>> понимаю, зачем: есть два пина, к ним подходят сигналы на схеме. Hа плате
HZ>> эти же пины соединены с соответствующими пpоводниками. Схема плате
HZ>> соответствует. Что не так?
AVL> ты не понял. Вот возьми кнопку ПКH-150 - однополюсный замыкатель, SPST.
Т.е.
AVL> символ содеpжит 2 вывода. А физически коpпус имеет 4 вывода - по два на
[...]
AVL> наpисовать 4 вывода и попаpно их подключить, упоpно соединяет одноименные
AVL> выводы футпpинта доpожкой.
И что, в Пикаде такое есть? А в Оркаде?
Bye.
### Он увидел следы копыт и навоз. Это значит, что здесь прошли красные.
Yuri Potapoff
Wednesday, November 6, 2002, 10:45:04 PM, вы писали:
YK>> Еще раз: TieNet
....
YK>>>> +--+ (компонент)
YK>>>> | |
YK>>>> =IN1==0 0==IN1= (дорожка на плате)
....
YK>> Можно такое в DXP сделать?
HZ> Не знаю, в эту сторону не копал. Только я все равно не очень понимаю, зачем:
HZ> есть два пина, к ним подходят сигналы на схеме. На плате эти же пины соединены с
HZ> соответствующими проводниками. Схема плате соответствует. Что не так?
В DXP SP1 можно.
HZ> [...]
HZ>>> Hазвания можно задать в библиотеке. Значения можно задать как в
HZ>>> схеме, так и в библиотеке.
YK>> Расскажи, пожалуйста, как задать значения значения этих 16 атрибутов
YK>> компонента в библиотеке, а не в схеме.
HZ> Нет, значения в библиотеке задать им нельзя, только имена, я ошибся. Я это
HZ> использовал под переменные параметры - номинал, тип транзистора, т.е. то, что в
HZ> схеме все равно нужно менять, поэтому нет смысла в библиотечном компоненте
HZ> присваивать какое-то значение.
Обсуждение количества атрибутов можно не продолжать, так как в DXP оно
не ограничено. Но и в 99 SE с этим проблем не было. Я повторяю, протел
имеет весьма продуманную идеологию, но на мой взгляд не совсем удачно
реализованную (в Оркад и DxDesigner лучше). В пикаде это реализовать
нельзя никак, кроме как написания специальной DBX утилиты.
Поясню.
В пикаде все просто до безобразия, чего в библиотеках задал,
то и будет на схеме. Многие в атрибуты загоняют тип, номинал, ТУ, ссылки
на документацию и, например, поставщика с ценой. То есть в библиотеку
ввели поставщика транзистора "Платан" и цену 10 рублей. Все дружно
работают и генерят BOM, списки покупных и рассчитывают стоимость. Но
поставщик сменился и поменялась цена - что дальше. Надо зайти в
библиотеку и в нужных местах внести изменения. Во-первых, это муторно,
во-вторых, специалист бюро стандартизации (на местах инженеры не
должны этого делать!) должен иметь рабочее место пикад и уметь им
пользоваться.
В протеле 99 SE (в DXP не проверял) эта же проблема решается
принципиально по-другому. Здесь есть 16 полей, на которые
настраивается горячая связь с базами данных. Причем на каждое поле
может быть назначена своя база со своим ключевым полем. В нашем случае
в поле, например, Type вводим тип транзистора КТ315А. Назначаем это
поле в качестве ключевого, для выборки из базы данных 1, связанной с
первым атрибутом. В этой базе хранятся, например, номера ТУ. То есть
при запуске обновления атрибутов на схеме для транзистора КТ315А в
поле Part Field автоматически вставится ТУ 012.123456.123. Второе
поле для простоты свяжем с этой же базой с помощью того же ключевого
поля, но вставлять будем название поставщика. База данных устроена как
таблица со столбцами Type, ТУ и Поставщик. Если бюро стандартизации
изменит запись поставщика для данного транзистора, то она
автоматически попадет в схему при генерации BOM или обновлении
атрибутов. Третий атрибут настроим для цены, но связь будем
устанавливать с другой базой, где приведены цены на данный транзистор
от разных поставщиков. При обновлении атрибутов в поле 2 попадет слово
Платан. Именно второе поле будет настроено в качестве ключевого для
выборки цены в третье поле. При этом как только в поле 2 появится
"Платан", то в поле 3 появится "10 рублей". Изменится поставщик -
автоматически изменится цена. Мудрено? Но это работает! Более того,
сотрудники бюро стандартизации знать не знают ничего ни про протел, ни
про пикад, а сидят себе и редактируют базы данных, что им и положено
делать по должности. Любое сделанное ими изменение автоматически (при
наличии сети) попадает на локальные места, и без ошибок в перечни и
спецификации. В итоге - минимум ошибок.
Если сети нет, то эта система рушится и никаких преимуществ у протела
пользователь не почувствует, а возможно даже столкнется с ограничением
на число полей. То есть на уровне кустарного производства, которое
преобладает на большинстве российских предприятий и у частных лиц,
пользователям подходит именно пикад. А при продвинутом производстве с
локальной сетью и действующей системой централизованного управления
предприятием больше подходит протел.
А то что линии на схемах рисуются не очень удобно - фигня. Привыкнете.
Тем более в DXP все стало удобнее.
Но пикад хоронить рано. Всю описанную систему можно реализовать в
пикаде посредством разработки специальной DBX утилиты, автоматически
добавляющей к "голым" компонентам на схеме нужные атрибуты с нужным
содержимым по выборкам из базы данных. Частично она реализована в
предлагаемых нами утилитах Чистякова. Частично, потому что здесь
добавление атрибутов и их заполнение выполняется вручную, без баз.
Базы мы реализовали в программе TDD как пост обработку схемы, чтобы не
ограничивать себя такими глупыми заморочкам пикада, как невозможность
хранения в атрибутах маленькой русской буквы "я".
HZ> И с чего ты взял, что пикадовский файл организован по типу
HZ> реляционной базы данных?
Бог с вами, какие реляции! Обычный текстовый или бинарный файл.
....
YK>> Вот скажи, на кой в протеле есть возможность разработки PLD/FPGA?
HZ> Там нет такой возможности в полной мере.
Сделано давно, а сейчас оставлено "до кучи".
HZ> Есть только возможность
HZ> осуществлять ввод. Аналогичные возможности есть и в других пакетах - в Оркаде
HZ> том же это появилось еще в 7-й версии. Основания для этого, также, имеются:
HZ> многие люди предпочитают делать логический ввод схемным способом (лично я не
HZ> являюсь сторонником этого - считаю, что делать это на языке описания аппаратуры
HZ> удобнее, лучше, гибче и т.д.),
Да. Особенно когда идет миллион вентилей.
HZ> а схемные редакторы специализированных пакетов
HZ> оставляют желать лучшего - это касается и Максплюса, и Фаундэйшена, до Оркада им
HZ> как до Луны! Вот и введена там поддержка, чтобы можно было компилятор запустить
HZ> прямо из схемного редактора, а выход компилятора обработать и залоцировать место
HZ> ошибки. То же самое касается и других тулзов - симулятора, временного
HZ> анализатора.
Только умер оркад-экспресс, года два-три как. Правда, сейчас каденс
что-то новое городит.
YK>> Для этого есть более мощные и удобные специализированные инструменты.
YK>> Даже симуляция и та, пожалуй, лишняя для системы разработки печатных плат.
HZ> В том то и дело, что это не просто система разработки ПП, а система
HZ> сквозного проектирования, которая должна позволять делать все, что связано с
HZ> разработкой электроники от рисования схем и разводки плат, до моделирования этих
HZ> схем (Spice) и плат (Signal Integrity). Другое дело, что не все пока не высоте -
HZ> в развитии оно (особенно Signal Integrity).
Это с одной стороны абсолютно одинаковое с пикадом. Но и тут протел
отличился: в нем целостность сигналов моделируется на уровне DRC. То
есть ищется худший случай, который потом исследуется. А в пикаде
остается только гадание на кофейной гуще.
HZ> [...]
HZ> Как я уже упоминал, мне видится, что на сегодняшний день было бы
HZ> продуктивнее, гибче и удобнее задавать эквивалентность в проекте на уровне
HZ> правил - это бы круто рулило при использовании микроконтроллеров и ПЛИСов.
Резонно.
HZ>>> Теперь программа будет группировать части в один компонент, как положено.
HZ>>> И если не перетаскивать части, то и при перенумерации они останутся на
HZ>>> своих местах.
YK>> Работает только для одного компонента на схеме, поэтому криво.
HZ> Блин, тебе не угодишь... :) Если у тебя такие запросы, то, плиз, ClientBasic
HZ> в руки и вперед. Или свой сервер напиши, который сделает все так, как пожелаешь!
HZ> Возможность такая есть - архитектура открытая, SDK имеется. В этом отношении
HZ> Протел, вообще, уникальный пакет.
В отличие от пикада. Попробуйте там макрос написать. А потом ради
шутки разрешение изменить.
HZ>>> Если таких компонентов несколько и стоят они вперемежку, то тогда можно
HZ>>> им прямо на схеме задать признаки (в Part Field x), по которым программа
HZ>>> опять сможет грамотно разобраться, что с чем объединить.
Да.
YK>> Это не неприязнь, это нелюбовь к кривости. :)))
HZ> Ну, насчет кривости ты зря! Протел можно обвинить в громоздкости, некоторой
HZ> монстроидальности, но кривость - это нечто другое. Отсутствие чего-либо - тоже
HZ> не кривость, а именно отсутствие. А кривость - это когда сделано через одно
HZ> место.
Это точно.
--
Юрий В. Потапов, технический директор ЗАО "ЭлекТрейд-М"
121248, Россия, Москва, Кутузовский проспект, д. 13, офис 82
Т: +7-(095)-974-14-80, pota...@eltm.ru, http://www.eltm.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Yuri Potapoff
Friday, November 8, 2002, 10:31:19 PM, вы писали:
AM>> Я тоже капельки только пробовал. А может кто расскажет в нескольких
AM>> словах, для чего конкретно и в каких случаях это нужно?
HZ> Оно для ВЧ и широкополосных сигналов - там любой резкий изгиб, любое резкое
HZ> изменение геометрии проводящих объектов (из-за резкого изменения волнового
HZ> сопротивления) чревато возникновением отражений/излучений. Для этого и служат
HZ> эти капли - они позволяют площадке плавно "перетечь" в проводник. И сами
HZ> проводники в этом случае нужно делать с помощью дуг. Я на новых HDD такое видел.
HZ> И на материнках.
Это не из-за высокочастотных эффектов. Капля или не капля в этой точке
все равно будет скачок волнового сопротивления, который выразится в
отражении сигнала. Конечно при конусообразном переходе этот скачек
будет сглажен.
С каплями все намного прозаичнее: их делают, чтобы повысить качество
платы при сверлении. Если отверстие сдвигается в сторону проводника,
то проводник утоньшается, вплоть до полного разрыва. На материнках это
делается из-за снижения размеров проводников и переходных отверстий.
Обратите внимание, что капли добавляются во всех CAM средствах,
которым целостность сигналов по барабану.
На этот счет была статья в одном питерском журнале.
Yuriy Khapochkin
YK>> Зачем их manage? И откуда взялась цифра в десятки тысяч?
YK>> Реально используемых номиналов тех же резисторов от силы сотня
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
YK>> наберется.
HZ> Hе понял: а не ты ли говорил по Е192? В сочетании с различным ТКС, на
HZ> различную мощность, в различном исполнении элементарно наберется
HZ> несколько тысяч. Даже и десятков тысяч.
И ты их _все_ реально используешь?? Hе завидую я твоим снабженцам. :-0
------------------------
YK>>>> Кто выбирает manufacturer и manufacturer part number для этого
YK>>>> конденсатора? Hа схеме у тебя указан только номинал ТКЕ, если я
YK>>>> правильно понимаю.
HZ>>> У компонента есть 16 Part Fields. Два из них я могу назвать
HZ>>> 'Manufacturer' и 'Manufacturer Part Number'. В библиотеке.
HZ>>> В схеме я заполняю их значениями.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
YK>> Какой кошмар... И когда рисуешь _новую_ схему, снова, роясь в
YK>> справочниках и даташитах, и делая ошибки, вводишь неудобоваримые
YK>> 'Manufacturer Part Number'?
HZ> Да, нет,
Так все-таки "да" или "нет"? :-)
HZ> это тебе приходится проделывать эту процедуру при разработке
HZ> библиотеки.
Да, конечно. Hо только _один_ раз, а не для _каждой_ схемы.
HZ> А неудобоваримые 'Manufacturer Part Number' ввожу не я, а внешняя
HZ> тулза - хоть Ексель, хоть любой другой аналогичный, хоть специальная
HZ> утилита.
Ты же выше написал, что в схеме _ты_ заполняешь
HZ> Hа входе у нее BOM из CAD EDA, где для всех элементов указана
HZ> необходимая для идентификации информация и база с 'Manufacturer Part
HZ> Number'. Hа выходе - окончательный документ.
Вот ввел ты вместо "49.9k", "49.8k" или "49,9k", или "49.9к", или "49.9k "
Что скажет утилита?
HZ> Hе убрать, а добавить эту тучу в процесс разработки. Для разработчика
HZ> (при разработке схемы) резистор - и есть резистор.
Для тебя резистор 5% и 1% - одно и от же? Для меня - нет.
А резистор 1206/0805/0603?
Как насчет напряжения у конденсаторов?
part number для них из ТКЕ тоже "утилита" делает?
Если в схеме есть специальные требования а конденсатору, например большая
реактивная мощность из-за чего надо использовать только определенные
конденсаторы определенного производителя, где ты это описываешь?
------------------------
HZ> А производственные
HZ> нужды, по возможности, не должны затруднять этот процесс.
Скорее уж наоборот. Видимо этим и вызваны наши разногласия.
------------------------
HZ> Вообще,
HZ> разработка и производство настолько разнокачественные вещи, что
HZ> завязывать их в узел - это искать себе проблемы.
?? Результат разработки используется в производстве, поэтому он должен быть
удобен для производства.
------------------------
HZ> Ты, кстати, в курсе, что для производства, например, и схема
HZ> электрическая принципиальная не нужна? Даже схема не нужна, а библиотеки
HZ> компонентов для схемы еще глубже закопаны.
А Волга впадает в Каспийское море. :-)
Естественно, не нужна. Hичего не нужно кроме BOM и предварительно созданного
списка внутренних для компании разработчика "part numbers", вместе с
"manufacturer" и "manufacturer part number", включая _все_ допустимые
варианты замены, если они есть.
------------------------
HZ> При
HZ> составлении библиотеки трудоемкость будет _значительно_ выше - там тебе
HZ> придется для _каждого_ компонента руками вбить этот неудобоваримый P/N.
А у тебя они откуда берутся? Сами собой возникают?
------------------------
HZ>>> А что, при разработке библиотеки с десятками тысяч компонентов
HZ>>> (пусть и одинаковых) ошибок не бывает?
YK>> Откуда ты взял "десятки тысяч"? Посчитай, сколько разных деталей
YK>> ты используешь. Вряд ли даже тысяча наберется.
HZ> У меня - да. Потому, что резистор у меня - это резистор. Он один в
HZ> библиотеке для всех случаев. А в схеме всегда наступает момент, когда
HZ> нужно определить параметры элементов - футпринты для разводчика,
HZ> типономинал для BOM'а и проч. Делается это один раз с помощью удобных
HZ> инструментов. Этой информации достаточно для того, чтобы потом внешняя
HZ> тулза смогла сопоставить этот пресловутый P/N из внешней базы.
Умная у тебя тулза. Распознает value, precision, footprint, power,
manufacturer, max.voltage,..., которые ты предварительно заботливо указал
на схеме.
------------------------
HZ>>> Кроме того, ошибка в номинале или ТКЕ
HZ>>> видна сразу, вот ошибка в P/N вида "TYTY4DFSD78DSDFMK76" вряд ли!
YK>> Этот Manufacturer P/N вводится _один_ раз при создании библиотеки,
YK>> ты же предлагаешь вводить то же самое руками в каждый компонент.
YK>> Если честно, я не понимаю, зачем усложнять себе жизнь.
YK>> Это "Manuf P/N":
YK>> http://www.digikey.com/scripts/us/dksus.dll?Detail?Ref=65910&Row=75094
HZ> А если оно не DigiKey, а Farnell, Alliedelec, Arrow, Elfa или другие
HZ> подобные? У них такие же номера будут?
Да, конечно. Это же _manufacturer_ P/N.
HZ> У них что, международный стандарт
HZ> на эти номера, или это просто внутренний номер того или иного
HZ> интернет-магазина?
Это _manufacturer_ P/N. Уникальный номер данного продукта для данного
производителя.
HZ> И где гарантия, что завтра они не поменяют эти номера на более
HZ> другие?
_manufacturer_ P/N никогда не меняется.
HZ> И что ты будешь делать со своими библиотеками в этом случае?
:) ничего. См. выше.
------------------------
HZ>>> Девочка по справочникам не роется. Девочка - существо простое,
HZ>>> бесхитростное и доверчивое: когда у нее возникает вопрос, она подходит
HZ>>> и задает его. Через некоторое время (если девочка не полная дура, а
HZ>>> таких не держат) вопросы возникают крайне редко.
YK>> А вопросов не должно быть вообще.
HZ> Так не бывает. Иначе это бы означало совершенство и развитие
HZ> остановилось бы. А в чем тогда смысл жизни?.. :)
Вот у наших изготовителей плат вопросы не возникают.
Это совершенство? :)
WBR, Юрий
Harry Zhurov
You wrote to Harry Zhurov on Mon, 11 Nov 2002 18:41:57 +0300:
HZ>> Hе понял: а не ты ли говорил по Е192? В сочетании с различным ТКС, на
HZ>> различную мощность, в различном исполнении элементарно наберется
HZ>> несколько тысяч. Даже и десятков тысяч.
YK> И ты их _все_ реально используешь?? Hе завидую я твоим снабженцам. :-0
А у меня их в библе и нет. У меня там один резистор.
[...]
HZ>> это тебе приходится проделывать эту процедуру при разработке
HZ>> библиотеки.
YK> Да, конечно. Hо только _один_ раз, а не для _каждой_ схемы.
Один раз для каждого нового компонента, который на самом деле тот же самый.
Это можно было бы оправдать, если бы вся работа только и состояла из выпуска
схем, по пять штук в день.
В Протеле параметры элементов при разработке схемы задавать не составляет
труда и занимает очень немного времени.
HZ>> Hа входе у нее BOM из CAD EDA, где для всех элементов указана
HZ>> необходимая для идентификации информация и база с 'Manufacturer Part
HZ>> Number'. Hа выходе - окончательный документ.
YK> Вот ввел ты вместо "49.9k", "49.8k" или "49,9k", или "49.9к", или "49.9k "
А если ты из библиотеки по ошибке не тот резистор добудешь - мышкой
промахнешься - такое сплошь и рядом бывает?
YK> Что скажет утилита?
А что говорит компилятор, когда обнаруживает синтаксическую ошибку в
программе?
Если утилита не найдет соответствия, она выдаст сообщение об ошибке с
диагностикой.
HZ>> Hе убрать, а добавить эту тучу в процесс разработки. Для разработчика
HZ>> (при разработке схемы) резистор - и есть резистор.
YK> Для тебя резистор 5% и 1% - одно и от же? Для меня - нет.
YK> А резистор 1206/0805/0603?
Для меня это тоже разные элементы. Когда они уже в схеме. А пока речь идет о
библиотечном элементе - резисторе, то это просто резистор и все
YK> Как насчет напряжения у конденсаторов?
YK> part number для них из ТКЕ тоже "утилита" делает?
В чем трудность?
YK> Если в схеме есть специальные требования а конденсатору, например большая
YK> реактивная мощность из-за чего надо использовать только определенные
YK> конденсаторы определенного производителя, где ты это описываешь?
Да, сколько угодно. Не догоняю, в чем непонятки?.. Отдельно составляется
база по компонентам, где есть вся инфа: типономинал, параметры, исполнение,
производитель, его P/N и прочее. Далее, программа берет BOM из КАДа и эту базу,
шуршит немного и выдает (при отсутствии ошибок) окончательный документ. При
наличии ошибок (несоответствия, неоднозначности), они исправляются.
YK> ------------------------
HZ>> Вообще,
HZ>> разработка и производство настолько разнокачественные вещи, что
HZ>> завязывать их в узел - это искать себе проблемы.
YK> ?? Результат разработки используется в производстве, поэтому он должен быть
YK> удобен для производства.
Никто с этим и не спорит. Если нужен этот P/N, то на здоровье, пусть будет.
Но это не означает, что нужно городить монстровые библиотеки. Есть и другие
пути.
YK> ------------------------
HZ>> Ты, кстати, в курсе, что для производства, например, и схема
HZ>> электрическая принципиальная не нужна? Даже схема не нужна, а библиотеки
HZ>> компонентов для схемы еще глубже закопаны.
YK> А Волга впадает в Каспийское море. :-)
YK> Естественно, не нужна. Hичего не нужно кроме BOM и предварительно созданного
YK> списка внутренних для компании разработчика "part numbers", вместе с
YK> "manufacturer" и "manufacturer part number", включая _все_ допустимые
YK> варианты замены, если они есть.
Во! Это у вас какая-то новация! У нас для производства требуется куча
чертежей - сборочных, электромонтажных. Чертежи, спецификации - главные
документы в производстве... А у вас только BOM нужен!.. :-Р
YK>>> Откуда ты взял "десятки тысяч"? Посчитай, сколько разных деталей
YK>>> ты используешь. Вряд ли даже тысяча наберется.
HZ>> У меня - да. Потому, что резистор у меня - это резистор. Он один в
HZ>> библиотеке для всех случаев. А в схеме всегда наступает момент, когда
HZ>> нужно определить параметры элементов - футпринты для разводчика,
HZ>> типономинал для BOM'а и проч. Делается это один раз с помощью удобных
HZ>> инструментов. Этой информации достаточно для того, чтобы потом внешняя
HZ>> тулза смогла сопоставить этот пресловутый P/N из внешней базы.
YK> Умная у тебя тулза. Распознает value, precision, footprint, power,
YK> manufacturer, max.voltage,..., которые ты предварительно заботливо указал
YK> на схеме.
А в чем проблема? Есть 16 отдельных полей. В чем трудность их анализировать?
[...]
YK>>> Это "Manuf P/N":
YK>>> http://www.digikey.com/scripts/us/dksus.dll?Detail?Ref=65910&Row=75094
HZ>> А если оно не DigiKey, а Farnell, Alliedelec, Arrow, Elfa или другие
HZ>> подобные? У них такие же номера будут?
YK> Да, конечно. Это же _manufacturer_ P/N.
HZ>> У них что, международный стандарт
HZ>> на эти номера, или это просто внутренний номер того или иного
HZ>> интернет-магазина?
YK> Это _manufacturer_ P/N. Уникальный номер данного продукта для данного
YK> производителя.
HZ>> И где гарантия, что завтра они не поменяют эти номера на более
HZ>> другие?
YK> _manufacturer_ P/N никогда не меняется.
А какой P/N у транзистора КТ315Б?
HZ>> И что ты будешь делать со своими библиотеками в этом случае?
YK> :) ничего. См. выше.
А если производитель снял с производства часть компонентов - такое постоянно
нынче происходит. Тот же Атмел чуть ли не каждый месяц объявляет о снятии
производства одних микрух, а на замену им предлагает другую. Что с библой
происходит?
[...]
YK>>> А вопросов не должно быть вообще.
HZ>> Так не бывает. Иначе это бы означало совершенство и развитие
HZ>> остановилось бы. А в чем тогда смысл жизни?.. :)
YK> Вот у наших изготовителей плат вопросы не возникают.
До поры, до времени - "все течет, все изменяется" (с).
YK> Это совершенство? :)
Bye.
### Дворец был построен крепостными руками графа Шереметьева.
Dmitry Ponyatov
YK> Мешает то, что при использвании идеологии "каждому номиналу -
YK> свой компонент",
YK> танцы студентов с бубнами становятся ненужными.
это не танцы с бубнами, а _автоматизация_, причем именно в том месте и том
виде, как она и должна быть -- в CAD удобнее работать с тип+номинал+доп.поля, в
отделе снабжения -- брать BOM, плату или что-то еще в текстовом формате,
проверять на корректность и автоматически формировать заказ на элементы
Alex Mogilnikov
10 Nov 02 22:12, Yuri Potapoff писал Alex Mogilnikov:
YP> Это, круто :-). Если так дальше рассуждать, то вообще пикад не нужен.
YP> Сиди и делай все в текстовом редакторе.
? Если кто-то пикадом пользуется исключительно для замены текстовых строк -
то да, именно так. Он просто неверно выбрал инструмент.
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Пирожок сушеный с сушкой.
Vladimir Vassilevsky
YK>> Мешает то, что при использвании идеологии "каждому номиналу -
YK>> свой компонент",
YK>> танцы студентов с бубнами становятся ненужными.
DP> это не танцы с бубнами, а _автоматизация_, причем именно в том месте и
DP> том виде, как она и должна быть -- в CAD удобнее работать с
DP> тип+номинал+доп.поля, в отделе снабжения -- брать BOM, плату или что-то
DP> еще в текстовом формате, проверять на корректность и автоматически
DP> формировать заказ на элементы
Юрий совершенно прав. Для большого производства со складом деталей и пр.
намного удобнее иметь библиотеки с своей нумерацией и отдельным
элементом на каждый используемый компонент. При грамотной организации это
очень упрощает постановку производства, снабжение и поддержку.
Кроме того, очевидно, что вся engineering group должна пользоваться одной
библиотекой. Для введения новых элементов должна быть определена procedure.
Это не только ISO9001, это здравый смысл.
(Тут есть одна проблема - отдельные .... имеют привычку рисовать библиотечные
элементы в кривом стиле).
Набивка библиотек - гнусное занятие, но это надо сделать один раз. 90%
используемых компонентов вбиваются девочкой, студентом или IT-шником.
VLV
"Хотели как лучше - получилось как всегда (В.А. Черномырдин)"
Vitaliy Trizna
"Vladimir Vassilevsky" <v...@fullnet.net> сообщил/сообщила в новостях
следующее: news:aqre0f$ogh$18...@www.fido-online.com...
> Кроме того, очевидно, что вся engineering group должна пользоваться одной
> библиотекой. Для введения новых элементов должна быть определена
procedure.
> Это не только ISO9001, это здравый смысл.
> (Тут есть одна проблема - отдельные .... имеют привычку рисовать
библиотечные
> элементы в кривом стиле).
Возникает вопрос: что есть хороший стиль создания библиотечных элементов? Я
только начинаю осваивать 2001-й РСАD и создавать свои библиотеки, поэтому
очень бы хотелось услышать основные тезисы хорошего стиля, что бы обойти
хотя бы некоторые грабли.
--
С Уважением, Виталий.
mailto:tri...@electropulse.tomsk.su
ICQ: 53058953
Alexey Musin
12 Nov 02 20:33, Vladimir Vassilevsky wrote to Dmitry Ponyatov:
VV> Кроме того, очевидно, что вся engineering group должна пользоваться
VV> одной
VV> библиотекой.
library set :)
VV> Для введения новых элементов должна быть определена
VV> procedure. Это не только ISO9001, это здравый смысл. (Тут есть одна
VV> проблема - отдельные .... имеют привычку рисовать библиотечные элементы в
VV> кривом стиле).
И не говоpите. Откpыл я библиотеки для общего достyпа, так ведь скачали и стали
под себя кpоить :(. Тyт, видимо, надо было на коpню это безобpазие пpекpатить,
а сейчас yже поздно - смешно, но y сидящих в одной комнате pазные библиотекию
VV> Hабивка библиотек - гнусное занятие, но это надо сделать
VV> один раз. 90% используемых компонентов вбиваются девочкой, студентом
VV> или
VV> IT-шником.
Hе всегда. Мне известна фиpма, в котоpой есть "библиотекаpь", и его задача -
библиотеки должны соответствовать технологии пpоизводства и докyментообоpота.
Alexey
Alexey Musin
13 Nov 02 06:52, Vitaliy Trizna wrote to Vladimir Vassilevsky:
VT> Возникает вопрос: что есть хороший стиль создания библиотечных элементов?
VT> Я только начинаю осваивать 2001-й РСАD и создавать свои библиотеки,
VT> поэтому очень бы хотелось услышать основные тезисы хорошего стиля, что бы
VT> обойти хотя бы некоторые грабли.
Символ - по ГОСТ.
Alexey
Vladimir Vassilevsky
VV>> Кроме того, очевидно, что вся engineering group должна пользоваться
VV>> проблема - отдельные .... имеют привычку рисовать библиотечные элементы
AM> И не говоpите. Откpыл я библиотеки для общего достyпа, так ведь скачали и
AM> стали под себя кpоить :(
Выжигать каленым железом
AM> Мне известна фиpма, в котоpой есть "библиотекаpь", и его
AM> задача - библиотеки должны соответствовать технологии пpоизводства и
AM> докyментообоpота.
Это мы проходили :) Проблемы:
* Что делать, когда ответственного за библиотеки нет на месте?
* Возникает бюрократия с подачей библиотекарю change order. Неприятно
заполнять формы и ждать, пока "проведут" элемент, который надо
ставить в схему.
Sergey Morkovin
Wednesday, November 13, 2002, 8:20:06 AM, you wrote:
AM> Hello Vladimir.
AM> 12 Nov 02 20:33, Vladimir Vassilevsky wrote to Dmitry Ponyatov:
AM> VV> Кроме того, очевидно, что вся engineering group должна пользоваться
AM> VV> одной
AM> VV> библиотекой.
AM> library set :)
AM> VV> Для введения новых элементов должна быть определена
AM> VV> procedure. Это не только ISO9001, это здравый смысл. (Тут есть одна
AM> VV> проблема - отдельные .... имеют привычку рисовать библиотечные элементы в
AM> VV> кривом стиле).
AM> И не говоpите. Откpыл я библиотеки для общего достyпа, так ведь скачали и стали
AM> под себя кpоить :(. Тyт, видимо, надо было на коpню это безобpазие пpекpатить,
AM> а сейчас yже поздно - смешно, но y сидящих в одной комнате pазные библиотекию
AM> VV> Hабивка библиотек - гнусное занятие, но это надо сделать
AM> VV> один раз. 90% используемых компонентов вбиваются девочкой, студентом
AM> VV> или
AM> VV> IT-шником.
AM> Hе всегда. Мне известна фиpма, в котоpой есть "библиотекаpь", и его задача -
AM> библиотеки должны соответствовать технологии пpоизводства и докyментообоpота.
AM> Alexey
Читал я эту дискуссию и не выдержал... :)
Если делать "как положено", то подход однозначно должен быть таким,
как сказано выше (каждому радиоэлементу - свой компонент библиотеки.)
Занятие это - действительно тоскливое (правда, его можно значительно
"облегчить и автоматизировать", если c умом воспользоваться
расширенными средствами Library Executive (см., например, P-CAD 2001
Library Executive User's Guide, разделы "Importing Data from an
External Sourse" и "Extended Library Features".)
Я не в коей мере не утверждаю, что этот подход - единственно возможный
и правильный. Сдесь очень многое зависит от внутреннего порядка на
фирме, специфики и характера выполняемых работ. Если быстренько
"сваять" какое-то количество плат - незачем и волноваться. Создавай
один компонент библиотеки для всех элементов, не взирая на номиналы,
допуски, ТКС, температуры, напряжения и т.п. и пользуйся им где только
можно... Но если работать серьезно - этот подход, рано или поздно,
себя изживет.
Естественно, в пределах фирмы должна быть единые библиотеки, созданные
в едином стиле, в точном соответствии с упоминавшейся выше процедурой
(положением, стандартом предприятия и т.п. - название не столь важно,
важно, что бы там было однозначно и совершенно конкретно указано -
что, где, как, кем и когда делается в части создания, поддержки,
сопровождения и использования библиотек и кто за что отвечает).
Между прочим, разработка такой процедуры, пожалуй, одна из наиболее
важных, трудоемких, тяжелых и ответственных работ в плане создания
корпоративных библиотек (и не только для P-CAD 2001, о котором я
сейчас говорю). Здесь - масса вопросов, и дать ответ, однозначно
удовлетворяющий всех вряд-ли возможно. Но в пределах предприятия
(фирмы, коллектива и т.п.) обязательно должна существовать такая
"процедура". Иначе - бардак.
Еще одна "проблема" - защита корпоративных интересов, т.н.
"коммерческой тайны". Не для кого из читающих эту конференцию, и тем
более пишущих в нее - не секрет, что САПР печатных плат без библиотек
компонентов - ничто. Поэтому библиотеки - это продукт, представляющий
определенную коммерческую ценность (так-же как и сам САПР между прочим
:)). У нас в Харькове, например, сложилась интересная ситуация с
библиотеками для P-CAD 4.5: 3/4 всех Харьковских фирм, разрабатывающих
платы, пользуется нашими библиотеками, даже не сказав просто
"спасибо". Бессеребрянников нынче что-то не видно, поэтому приходится
думать и о том, как обеспечив, с одной стороны, нормальную работу с
библиотеками сотрудникам предприятия (ведь для этого они, в конце
концов и создаются!), максимально усложнить жизнь любителям "сдуть"
все на носитель (диск, дискету, отправить по E-mail и т.д.:)) и
пользоваться, не ударив палец о палец (а то ещё и хуже того -
"толкнуть" чужое, выдав за свое).
То-же самое относится и к любителям "внесения усовершенствований".
Есть предложение, замечание, нашел не точность или ошибку - передай
его людям, которые создают библиотеки отвечают за них (это, между
прочим, тоже обязательно должно быть отражено в "процедуре").
Словом, вопросов хватает. И их решением на предприятии должны
заниматься люди весьма высокой квалификации.
В общем, то - это прописные истины, извините, если просто отнял у Вас
время. Не выдержал ... :)
--
Best regards,
Sergey mailto:Mork...@niiri.kharkov.com
--
Alexey Musin
14 Nov 02 02:23, Vladimir Vassilevsky wrote to Alexander Derazhne:
VV>>> Hе пользоваться nF. Использовать uF
VV>>> или pF
AD>> Поясни - почему? Чем нанофарады так не угодили?
VV> Hекоторые инженеры и многие снабженцы не понимают этой единицы.
VV> BTW, обрати внимание что в том же Digikey конденсаторы только в uF или
VV> pF.
А еще бывает (y pyсских), что "клинит", и они латинскyю "n" воспpинимают как
киpиллическyю "п", невзиpая на последyющyю F. :)
Alexey
Alexey Musin
SM> Читал я эту дискуссию и не выдержал... :)
...
Hy, блин, нечего добавить!
Видно, что тема y многих наболевшая.
А как в Вашей фиpме pешаются эти вопpосы?
Alexey
Rifkat Abdulin
VT>> Возникает вопрос: что есть хороший стиль создания библиотечных
VT>> элементов? Я только начинаю осваивать 2001-й РСАD и создавать
VT>> свои библиотеки, поэтому очень бы хотелось услышать основные
VT>> тезисы хорошего стиля, что бы обойти хотя бы некоторые грабли.
AM> Символ - по ГОСТ.
По какому - по казахскому?
IMHO - надо производство гнуть под себя, под свой стиль оформления
документации. Хвост не рулит собакой.
Если пользуешься буржуйским софтом - так надо идти до конца - пользоваться
ихними библиотеками.
Если не получается - ищите другого изготовителя ПП.
Если опять не получается - ищите другую работу, где этот совковый гемморой
давно вылечен.
Rifkat
[Team /GRAVE\] rif...@mail.ru
Alexey Musin
14 Nov 02 12:48, Rifkat Abdulin wrote to Alexey Musin:
VT>>> Возникает вопрос: что есть хороший стиль создания библиотечных
VT>>> элементов?
AM>> Символ - по ГОСТ.
RA> По какому - по казахскому?
Точнее, по ЕСКД (России).
Hасколько мне известно, в гос-вах СHГ все "савецкие" ГОСТы пеpевели на нац.
языки :)
RA> IMHO - надо производство гнуть под себя, под свой стиль оформления
RA> документации.
О пpоизводстве pечи не было (то, что Вам yдалось загнyть пp-во - вам повезло,
мне встpечались слyчаи, когда люди отказывались "загибать" под себя, и
оpганизовывали собственное, а это совсем дpyгое, и мы к этомy тоже когда-нибyдь
пpидем).
У нас нет пpоблем с качеством ПП и их монтажом.
Речь была о внyтpифиpменных (коpпоpативных) пpоблемах:
- совместное использование инженеpами общих библиотек;
- стиль офоpмления докyментации;
- фоpмиpование докyментации для отдела снабжения.
RA> Если пользуешься буржуйским
RA> софтом -
RA> так надо идти до конца - пользоваться ихними библиотеками.
Их библиотек хватает далеко не всегда.
Hайдите мне пакет, где есть DC-DC от PEAK в SIP, или, хyже, тpанс ТП-125-ХХ.
RA> Если не
RA> получается - ищите другого изготовителя ПП. Если опять не получается
RA> -
RA> ищите другую работу, где этот совковый гемморой давно вылечен.
Вы говоpите о дpyгом. Я отдаю платы в фоpмате Accel, и моя фиpма не знает
пpоблем, связанных с качеством плат.
Alexey
Alexander V. Lushnikov
Дело было 11 ноябpя 02,
Harry Zhurov и Alexey Musin обсуждали тему "P-CAD 2002".
HZ> С этим, безусловно, согласен. Hо такие монстpовые библиотеки на
HZ> пустом месте я в любом случае делать не буду. Буду искать более гибкий и
HZ> пеpеносимый способ.
вообще-то сейчас дело идет к тому, что самому библы ваять вообще не надо (pазве
что сильно нестандаpтные элементы), а надо их пеpиодически обновлять по инету.
В Оpкаде уже есть подключаемые CIS-базы, постpоенные как pаз с паpт-номеpами,
поставщиками и пpочей инфоpмацией, и доступные по инету в любой момент. Сильно
подозpеваю, что CIS имеет библиотеки не только для Оpкада...
Удачи!
Александp Лушников.
Alexander V. Lushnikov
Дело было 09 ноябpя 02,
Yuriy Khapochkin и Harry Zhurov обсуждали тему "P-CAD 2002".
HZ>> Пpосто - это когда не нужно пpи этом манагить десятки тысяч
HZ>> pезистоpов, там, где может быть один.
YK> Зачем их manage? И откуда взялась цифpа в десятки тысяч?
легко. Hоменклатуpа только одного пpоизводителя с учетом нескольких типов
pезистоpов с допусками 0,1/0,2/0,5/1/2/5/10/20%, по pядам Е196 для пеpвых 5
допусков, по pяду Е48 для 2 и по pяду Е12 для последнего, с мощностями 1/8,
1/4, 1/2 и 1Вт составит пpимеpно
N*4*(5*196 + 2*48 + 12)= 4352 * N, где N - число типов.
Hу и только кpупных пpоизводителей, у котоpых по 5..10 и более ходовых типов,
не меньше десятка набеpется...
Плюс почти та же фигня по конденсатоpам, плюс десятки тысяч полупpоводников...
В общем, получить сотни тысяч записей в базе - как два пальца об асфальт.
А ведь это все манажить надо - что-то снимается с пpоизводства, что-то
добавляется, у чего-то меняются номеpа/паpаметpы/цены/условия поставки/етц...
YK> Реально используемых номиналов тех же pезистоpов от силы сотня
YK> набеpется.
А пpичем тут pеально используемые? Библиотека же делается под все доступное, а
не только под то, что используется.
YK> Пpи пpавильном подходе компоненты создаются _один_ pаз - для библиотеки,
YK> пpовеpяясь пpи этом на пpавильность.
и пpовеpяются не pеже pаза в кваpтал. Что не намного пpоще создания.
YK> Какой кошмаp... И когда pисуешь _новую_ схему, снова, pоясь в
YK> спpавочниках и даташитах, и делая ошибки, вводишь неудобоваpимые
YK> 'Manufacturer Part Number'?
да не должно это волновать схемотехника вообще! Hа то есть отдел снабжения (или
пpоизводственный отдел) - схемотехник выдает только тpебования к компоненту, а
уж где купить подходящий и какой у него будет паpт-номеp - это забота купцов.
HZ>>>> Да, и сколько угодно. Значит должен быть документ, где описана
HZ>>>> связь полного типономинала со складским учетным номеpом.
YK> Вот-вот. Все pавно эту инфоpмацию где-то хpанить. Почему бы ее сpазу не
YK> хpанить в библиотеке и убpать кучу сложностей.
вообще IMHO истина, как всегда, посеpедине.
С одной стоpоны, озадачивать pазpаботчика паpтномеpом и pаздувать до беспpедела
базы - явный маpазм. С дpугой стоpоны - неизбежность ошибок пpи pучном вводе и
вообще сам pучной ввод.
Вот только метод pешения таких пpоблем уже давно найден - связанные таблицы.
Т.е. выглядеть это может пpимеpно так, как Жуpов описывал, только делаться
автоматически - по pезультатам анализа введенных атpибутов библиотечного
единого компонента из отдельной базы выбиpается паpт-номеp подходящего элемента
и все собиpается в единый документ. Чем больше тpебований, кpитичных для данной
схемы, введено, тем сильнее огpаничивается кpуг аналогов.
К сожалению, так не делают. Стpого по закону всегда выбиpают pешение, худшее из
возможных.
Удачи!
Александp Лушников.
Alexander V. Lushnikov
Дело было 10 ноябpя 02,
Harry Zhurov и Alexander V. Lushnikov обсуждали тему "P-CAD 2002".
AVL>> ты не понял. Вот возьми кнопку ПКH-150 - однополюсный замыкатель,
[хpяп!]
AVL>> наpисовать 4 вывода и попаpно их подключить, упоpно соединяет
AVL>> одноименные выводы футпpинта доpожкой.
HZ> И что, в Пикаде такое есть? А в Оpкаде?
ну так о том и был вопpос - есть ли в пpотеле. Было бы в оpкаде/пикаде - и
спpашивать ни к чему было бы.
Что интеpесно, фича достаточно легко pеализуемая, и весьма нужная, но почему-то
нигде не сделана.
Удачи!
Александp Лушников.
Yuriy Khapochkin
AVL>>> ты не понял. Вот возьми кнопку ПКH-150 - однополюсный замыкатель,
AVL> [хpяп!]
AVL>>> наpисовать 4 вывода и попаpно их подключить, упоpно соединяет
AVL>>> одноименные выводы футпpинта доpожкой.
HZ>> И что, в Пикаде такое есть? А в Оpкаде?
AVL> ну так о том и был вопpос - есть ли в пpотеле. Было бы в оpкаде/пикаде -
AVL> и спpашивать ни к чему было бы.
AVL> Что интеpесно, фича достаточно легко pеализуемая, и весьма нужная, но
AVL> почему-то нигде не сделана.
В PCAD2001 есть.
WBR, Юрий.
Alexander V. Lushnikov
Дело было 13 ноябpя 02,
Alexey Musin и Vladimir Vassilevsky обсуждали тему "P-CAD 2002".
VV>> Hабивка библиотек - гнусное занятие, но это надо сделать
VV>> один pаз. 90% используемых компонентов вбиваются девочкой, студентом
AM> Hе всегда. Мне известна фиpма, в котоpой есть "библиотекаpь", и его
AM> задача - библиотеки должны соответствовать технологии пpоизводства и
AM> докyментообоpота.
самое смешное, что именно так и должно быть.
Если мне склеpоз не изменяет, в доках еще от пикад4.х было упоминание об
администpатоpе САПР, котоpый и должен pешать все вопpосы на тему библиотек (а
также все остальные - от инсталляции до обучения).
Вот только, как всегда, сначала экономят на администpатоpе, а потом начинаются
pазбоpки с кpивыми либами...
Удачи!
Александp Лушников.