тогда получается, что это одна электрическая цепь? с разными псевдонимами? А зачем DxD допускает несколько имен одной цепи?

от себя хочется добавить, что в DxD я обнаружил 2 вида шин: 1) - условно назовем их "разнородными" - им (шинам) даются имена в setup и прописывается содержимое, которое совершенно не привязано к имени шины. Впоследствии в эту шину можно добавлять сигналы через setup.
2) - "однородные", их имена однозначно определяют содержимое, например имя шины AD[0:31] - сигналы AD0, AD1, ... AD30, AD31. Если дать это имя при рисовании шины через properties, то такая шина не фигурирует в setup и ей не может быть впоследствии назначен псевдоним, например "BUS" и добавлены еще сигналы, например RD, WR.
хотя обходной путь есть - вручную создать в setup BUS, в ее содержимое прописать все, что надо, а на схеме переименовать шину AD[0:31] в BUS. Но это неудобно.

Ну а если назначить шине при ее рисовании простое имя без цифирек - то это получается, что шина вырождается в простой wire, хотя выглядит как шина. Мне это кажется нелогичным. Да и неравноправность шин прописанных заранее в setup и непрописанных - тоже нелогична.
было бы удобнее, если бы шины, именованные при рисовании попадали автоматом в stup/bus contents c именем и содержимым, данными при рисовании, с возможностью редактирования в setup. Тогда неравноправность шин исчезла бы.

кстати, из неудобств работы с шиной - при подключении безымянной net к шине и при выводе net из шины она (net) получает первое попавшееся имя из содержимого шины, было бы удобнее автоматом вызывать диалог выбора имени этой net, как это происходит при ПКМ / Rip Nets .

И еще - к старому спору о различимости больших и маленьких букв в properties. Напомню - там они различаются. То есть Part Name и part name - это РАЗНЫЕ атрибуты. А вот в именах шин BUS и bus - одно и то же. Опять нелогично. То есть имена то разные, и в списке шин есть и BUS и bus, только содержимое у них автоматически одинаковое.

**************************************
Из выходящего за рамки понимания:
имется учебный проект DxPADS_2007WS, когда-то любезно выложенный fill-ом. Так вот, после загрузки проекта в DxD открытие листов (их там 8) происходит от 4 до 14 секунд (14 секунд - 2 лист). При этом загрузка процессора практически нулевая, памяти 2GB. Хотел записать это безобразие на видео через camtasia, однако тут обнаружился парадокс: при запущеной камтасии листы грузятся ГОРАЗДО быстрее, например злополучный 2 лист не больше 3-4 секунд. От размера окна/разрешения экрана не зависит, включение/выключение антивируса не влияет. Придется записать это на глюки...

+1000 - очень нужно. И в плюс к этому - чтобы все подведенные цепи, именованные заранее, или переименованные потом в то, чего не было в bus contents, тоже автоматом добавлялись в Bus Contents - ИМХО его назначение чисто информационное в идеале должно быть. И, согласен, вообще непонятно, зачем иметь возможность подключать к одному сигналу шины кучу цепей с разными именами... Если и где-то надо (когда фича есть, это лучше, чем ее нет), так наверное крайне редко, хорошо бы, если бы это было запрятано, да еще и предупреждение выскакивало - типа "а вы точно уверены?"... Пока же bus contents запрятан почти так, как символы или pdb - отдельный файл, требующий апдейта после внесения изменений туда, и, думаю, надежды на все это около нуля.

Не, не первое попавшееся... А следующее из списка bus contents после той, которую дали в предыдущий раз. Т.е. все по кругу пробегает. В общем-то удобно вполне, если принцип понять...

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

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

1. Bus Contents прежде всего служит для организации всего процесса - сначала определяем что входит в состав шины и затем уже выбираем при рисовании в схеме. Т.е. исключаем фактор ошибочного набора, например в схеме ввели название двум отрезкам цепи RAO и RA0 которые не сильно отличаются визуально в схеме и подключили их к шине, которая автоматически их добавила в Bus Contents (это вы хотите) в итоге получим две цепи вместо одной и попробуйте потом отловите такую ошибку в сотнях цепей составляющих такую шину.
2. Процессом назначения имен можно управлять [attachment=33750:Rip_Nets.7z]
3. Например два человека рисуют каждый свою подсхему при этом один и тотже сигнал используется в обеих подсхемах но выполняет разную роль и поэтому ему дали разное имя в этих подсхемах - закоротили его через шину и все, имена в подсхемах остались без изменений и отражают логику работы, а цепь стала единой. В противном случае пришлось бы в какой-то из подсхем менять имя цепи.
4. Интересный момент для поборника ГОСТ - Вы его выполняете? А ведь при использовании критикуемой вами возможности можно и выполнить
Кстати если использовать знак | то имя итоговой "сборной" цепи останется не сборным (т.е в данном примере будет просто CLK).
5. Указанный проект DxPADS_2007WS у меня открывается как все остальные (быстро) поэтому ищите проблему на своем компе.

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

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

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

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

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

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

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

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

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




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

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

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

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


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

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

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


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



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

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

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

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

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


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

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

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

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

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

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