PartLister, не выводит поля компонентов Опции

[Volkov]

EE7.9.2
не выводит поля non-common property. Есть способ, как заставить Part Lister вывести те поля компонентов, которые мне нужны для формирования перечня элементов?

[vitan]

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

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

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

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

[fill]

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

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

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

4. Дык и я почти такой же. У меня только почта есть. Но суть не меняется: имеем схему в электронном виде, но считать из нее информацию можем только глазами. Это 21 век, между прочим.

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

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

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

[vitan]

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

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

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

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

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

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

[fill]

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

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

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

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

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

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

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

[vitan]

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

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

Так ExpeditonPCB (или DC\DV) также без проблем открывает старые релизы за те же 15 лет.

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

Процесс DxD2005-->2007 не даром называется "Миграцией", а не просто открытие проекта в новой версии софта.
Чтобы далеко не ходить посмотрите на "оркадчиков" - насколько легко у них происходит миграция из Layout в новый релиз (Allegro)?

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

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

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

Его ответ по зонам - "Нет, в перечень из СхЭ мы не выводим графу "Зона". Нам это просто не надо".

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

[fill]

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

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

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


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

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

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

[vitan]

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

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

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

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

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

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

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

[fill]

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

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

Спасибо за файлик. Но почитайте его: где упоминание про проверку для 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).

[vitan]

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

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