1. Откройте новый проект и запустите Partlister - увидите стандартный набор:
# QTY Part Number Description Value Ref Designator
это и есть стандартно используемые данные для BOM.
Вы же создаете уже не BOM, а несколько иной документ.
2. Тоже самое, посмотрите стандартный файл настроек скаута - в нем аннотации на символах размещаются только на определенных символах форматки и Композитных
3. Возьмите, и где там спец. проверка для ALT_SYMBOLS? Допускаю что строчку внесения в нетлист данного атрибута добавили с появлением такого свойства в Allegro, но не предусмотрели, что его значение может содержать знаки запрещенные для всех других атрибутов. Те кто пользуется данным атрибутом просто внесли исправление в свой конфиг. файл и забыли об этой "проблеме", т.к. стандартными конфигами как правило пользуются только начинающие пользователи.
4. Не допускаете что обычно просто используют для того чтобы при общении например по телефону указать другому человеку "посмотри на лист такой-то в такую-то область" и не более того?
5. Да, виноват, забыл. Действительно есть вариант с графой зона, но только сколько я ни смотрел присланные мне перечни\спецификации из других компаний (а их много), во всех если и есть эта графа, то девственно чистая.

PS. Что касается скаута, то была информация что его хотят полностью переделать.

1. Т.е. Вы хотите подойти к делу формально, говорите, что если я чего-то поправил в конфиге для бома, то это уже и не бом? Думаю, большинство (к которому Вы так любите апеллировать) с Вами тут не согласится. Даже в менторовском хелпе есть раздел о том, как настроить бом, и от этого он не перестает оставаться бомом.
2. Да-да. Команды аннотации зон для компонентов и пинов закомментированы. Я ж говорю: замануха.
3. Сорри, неточно выразился. Самой проверки в чистом виде нет. Но свойство-то передается, оно указано в разделе AttPassList. И при передаче оно генерит эту несчастную ошибку. А вот, Ваше утверждение о том, что "кто пользуется данным атрибутом просто внесли исправление" говорит как минимум о том, что это не тестировалось. А как максимум - это мой случай, мне не удалось без посторонней помощи это исправить, ибо это нифига не тривиально, с учетом отсутствия какого-либо хелпа на эту тему. Все это говорит о качестве.
4. Ух! А по емейлу, значит, мне уже нельзя сказать соседу, куда ему смотреть? Информацию из схемы в компьютере может считать только человек, но не компьютер?
5. Ну опять же, разговоры о большинстве. И они были бы обоснованы, если бы ментор не предлагал кучу доп. возможностей, которыми пользуется меньшинство, при этом их не тестируя.


О май гад. Это будет, наверно, последний гвоздь в крышку гроба.


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

3. Я же нашел данную информацию через документацию и knowledge database - стандартный набор которым пользуются офиц. пользователи.
4. Наступили на больной мазоль - как было бы проще мне работать если бы все офиц. пользователи общались со мной исключительно по почте. Открою Вам глаза - 99% вообще не имеют доступа к интернет (ибо секретность). Да и телефон на раб месте это тоже зачастую роскошь - общение выглядит следующим образом:
- звонок: вопрос
- ответ :сделайте на компе то то и то
- ответ: щас сбегаю до компа ....



Никто не считает это ересью. Просто то что Вам так важно, другими не используется. Соответственно и не тестируется, и не исправляется.

Ну почему сразу порицание? У меня Ваши старания вызывают сочувствие например... Все пытаетесь что-то сделать, а не получается. Мне правда в 90% случаев непонятно зачем Вам это надо сделать и как это помогает в работе и ускоряет процесс проектирования.

Ок, по пунктам 1, 2, 5 - иппон?
3. Knowlеgde base - это прекрасно. А что Вы скажете на то, что в этой части конфиг не меняется на протяжении уже нескольких лет? Проще записать все в эту base, и пусть кому надо рыскает по ней. Хотите сказать, что эта маленькая проблемка, и ей некогда\невыгодно заниматься? И занимаются только действительно важными проблемами? Это все хорошо, только поймите, что для каждого юзера свои проблемы гораздо важнее общих проблем ментора. То, как ментор классифицирует багу и какой ей дадут приоритет, ровно ничего не меняет для конечного юзера: ему надо тут и сейчас сдать проект. Поставьте себя на место юзера, что бы Вы сделали в такой ситауции, когда потрачено уйма времени на переход, и в конце не удается получить документацию в том же виде, что была до перехода? Что сказать начальству? Себе?
4. Дык и я почти такой же. У меня только почта есть. Но суть не меняется: имеем схему в электронном виде, но считать из нее информацию можем только глазами. Это 21 век, между прочим.


Вот спасибо, пожалели беднягу...
Очень полезно иметь зоны в перечне. Особенно при ремонте и регулировке. Поступает сообщение: "Сгорел R123, не работает канал XYZ". Открываем перечень, видим имя резистора, говорим складу, чтобы приготовили новый. Тут же открываем схему, по зоне находим его и проверяем, что это за резистор, на что он влияет и т.д. При этом неважно в каком виде схема и перечень, на бумаге или в эл. виде. Т.е. физически Вы можете сидеть за своим компом, а можете бегать с комплектом КД по цехам или вообще в командировке.

Вы никак не поймете одного, чтобы что-то было сделано, нужно чтобы кто-то из пользователей запустил весь этот бюрократический процесс внесения изменений:
- создал SR
- по нему создали DR
- внесли изменения в ПО согласно требованиям DR
В вашем случае НИКТО не сподобился на это.

По поводу перехода 2005->2007. Офиц. пользователи при возникновении проблем обращаются непосредственно в support и быстро решают возникшие проблемы.
Кроме того менторовцы создали как документы по вопросам миграции, так и спец. форумы где пользователи обмениваются как опытом миграции, так и полезными скриптами, автоматизирующими такой переход.



Если схема в электронном виде, то найти нужный элемент можно без какого-либо привлечения аннотаций - по времени как минимум это одно и тоже



А зачем вообще тогда лезть в Перечень, если можно просто открыть схему в эл. виде, нажать find и увидеть перед собой нужный резистор, на котором и прочитать его имя.
Только для случая "бумага+произвольная нумерация на схеме" ваш способ действительно дает некоторый выигрыш. Проблема в том что как было уже сказано 99% у нас используют нумерацию по схеме и тогда выигрыша уже практически никакого.

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


А аллегро тупо открывает старую версию файла pcb в новой версии САПР. Возникает информационное сообщение об этом и на сем мучения пользователя заканичваются. За 15 лет использования этот механизм не сглючил у меня ни разу. Чувствуете разницу? Никаких форумов, никаких скриптов, техподдержки и др. Две секунды и готово.


Ну я ж говорю: чтобы не зависеть от того, в каком виде документация. Разве не очевидно, что это полезно?

При чем здесь политика\этика? Есть просто важные вопросы и не важные. "Если я не использовал какой-то атрибут или у меня в моем конфиг. файле изначально стояло правило что можно использовать скобки, то это что означает что я должен был перебрать все возможные варианты при бета тестировании?" - этот вопрос задаст вам любой добровольный бета тестировщик. Каждый из них проверяет в основном только функции им используемые в своем процессе работы + новые функции которые заинтересовали.
Хотите глубоко тестировать, пожалуйста - купите DxD и станьте бета тестировщиком, тогда "ваши" функции наверняка станут полностью работоспособными. Возможно даже Вы все протестируете (в силу своего понимания возможного варианта перебора), но надолго ли Вас хватит в каждом релизе проводить такое тестирование.



Так ExpeditonPCB (или DC\DV) также без проблем открывает старые релизы за те же 15 лет.
А проекты DxD2007 также без проблем открываются в новых релизах в течении 5 лет.
И это происходит во всех программах где не было коренного изменение внутренней базы построения системы.
Процесс DxD2005-->2007 не даром называется "Миграцией", а не просто открытие проекта в новой версии софта.
Чтобы далеко не ходить посмотрите на "оркадчиков" - насколько легко у них происходит миграция из Layout в новый релиз (Allegro)?



Полезно, не означает что обязательно нужно.

Специально, сейчас задал вопрос одному очень дотошному пользователю - они перед переходом всячески тестируют новый релиз, и только потом если все нормально (по их маршруту работы) ставят его у всех в компании. При выявлении ошибок они создают SR для исправления. Кроме того они дописывают дополнительные функции, которые им необходимы.
Его ответ по зонам - "Нет, в перечень из СхЭ мы не выводим графу "Зона". Нам это просто не надо".
Т.е. Вам в данном случае не повезло, если бы они работали по вашему маршруту, то эта проблема была бы давно выявлена и устранена.

Скажите, пожалуйста, годами висящее в базе знаний решение проблемы (копеечное) - это не повод уже таки внести это решение в релиз?


Имея такие примеры, это никого не вдохновляет. Прискорбно.


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


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


И что? Тогда уж будьте до конца принципиальны, попросите этого пользователя ввести SR на тему удаления из софта аннотации по зонам.

точнее на 99%

vitan плиз объясни для чего это нужно ???

Спешл фо ю: http://electronix.ru/forum/index.php?showt...t&p=1086434

С чего вы взяли что там висит SR-DR

Там всего лишь вопрос "Как задать альтернативные символы для Allegro" и ответ как  Using_the_Alternate_Footprint_Attribute_with_Allegro.pdf ( 38.62 килобайт ) Кол-во скачиваний: 1273


Если бы пользователь сформулировал SR приблизительно так как Вы : "В стандартном файле конфигурации отсутствуют настройки для правильного использования атрибута ALT_SYMBOLS", тогда бы появился бы и DR, а затем исправление в релизе.



Можно конечно попробовать.

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

Спасибо за файлик. Но почитайте его: где упоминание про проверку для ANY?


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


Вот и посмотрим. Уверен, что это должно натолкнуться на непонимание со стороны менеджеров, т.к. тупо урезается функциональность. И тогда, возможно, начнется-таки разбирательство. Мда...

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


Посмотрите внимательно в описание:
вместо правки проверки ANY
предлагается добавление строчки
CHKVAL _NAME_CHK PKG ALT_SYMBOLS ERR 0 "A-Z0-9_-()" "" 1 79

Предложенное мной решение с ANY было сделано методом "научного тыка", до того как я нашел выложенный вариант из базы знаний.



В менторе работает более 5000 человек. Чтобы управлять процессом и контролировать, что сделал каждый, введена определенная последовательность работы с применением базы обращений, задач и т.п.



Естественно SR не будет выглядеть так как вы написали. Для того чтобы сформировался DR нужно чтобы в SR содержалось описание того что софт работает не так как написано в документации и это было выявлено\подтверждено на тестовом примере. Поэтому в SR написано что скаут формирует Non-Common Property, которые не обрабатывает Partlister? поэтому нужно поменять скаут (для получения common property) или поменять Partlister (чтобы он читал Non-Common Property).

Что-то мне это напоминает:

- Кто сшил костюм?
- Мы!
- Кто это мы?
- Специализация у нас узкая: один пришивает карман, другой – проймочку, один – рукав. Я лично пришиваю пуговицы. К пуговицам претензии есть?
- К пуговицам претензий нет. Пришиты насмерть, не оторвешь. Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?!
А. Райкин, «Ателье»
http://www.youtube.com/watch?v=2wxL3DYen5g

Моё ощущение, что предыдущие версии DxD (до 2007) продумывались как целостный продукт и создавались специалистами не только в программировании, но и в предметной области.
Современный же DxD (после 2007) компилируется манагерами из набора фич для достижения заявленного функционального наполнения. Отсюда и все бесконечно обсуждаемые нескладухи. Но это видимо требование времени, современного ведения бизнеса.