В тему. А что мешает сразу на вкладке приборы присвоить всем датчикам ААД тип,а потом уже из раздела тот же ИПР изменить?

Вот по поводу CID хотелось бы, чтобы в PPROG работала сквозная нумерация не для прибора целиком, а для выбранных ШС. 

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

Далее, по поводу типов извещателей и их соответствия: ну дымовые и тепловые пожарные извещатели никак логически не могут быть отнесены к охранным (дли ИП и ДИП34А в КДЛ типы адресный дымовой и адресный тепловой на пример) - вполне логично автоматически для них выставлять тип шлейфа "Пожарный" в С2000М, равно как к примеру тот же ИК - охранный.

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

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

Я приведу дргой пример. Вы берёте на обслуживание объект где предварительно надо восстановить сигнализацию и в частности заменить ПКУ. Где в таколм случае брать конфигурацию?
Хотя само по себе определять тип датчика на уровне ПКУ, как это делает Рубикон или Рубеж не особо много смысла, максимум отличить пожарные датчики от охранных. А вот хранить конфигурацию во всех приборах (или хотя-бы части) на линии RS485 как у кажется Paradox, уже другое дело.

Систем много и все они разные, у одной так сделано у другой сяк, а у Болида эдак. Это их подход, а с учётом "так исторически сложилось" сделать иначе уже проблема.

по вопросу "показать ... наладчика" - подобных встречалось не мало, вернее объектов после подобных. Ну и это был лишь как частный случай приведен. А ситуации бывают разные, в том числе и с преобразованием конфигов бывает загвоздка. и прочии ситуации, когда удобнее считать конфу со смонтированной системы, 
Ну и сама стадия наладки, вы в пульте зашиваете каждый извещатель, задавая ему тип вручную - это время. Хорошо если действительно в упроге сделали автоматическое определение типа извещателя и сделают выгрузку с головы в тот же кдл, чтобы хотя бы в КДЛ не выставлять эти типы. Но гемора с С2000М это не уменьшает. А если у вас в системе 500 извещателей и 1000 выходов? Вы в любом случае задаете адрес каждому извещателю, далее вы всеравно в С2000М выставляете тип каждому извещателю (а это можно сделать по сути при программировании адресов - автоматическим определением типа), далее хорошо если автоматом кдл всетаки сделали определение типа (но я пока еще не успел потестить, надо будет попробовать как время будет), но если опять таки прийдется выставлять вручную - здрасти приехали )))  А можно хотябы - задал адреса, ткнул кнопку и они автоматом определились в С2000М по типам.
вдобавок в С2000М еще и реле мы выставляем для кдл вручную. А если этоо еще десяток Сигналов - работы меньше не становится (разве что реле определены уже), мало того, что в сигналах выставляем типы шлейфов, так и в С2000М еще повторяем процедуру (опять же облегчит если реализуют все-таки с С2000М выгрузку в приборы).

А чем Вас не устраивает значение "по умолчанию" для типа ШС в ПКУ?

 Налетов Константин , по сути в том же PProg-е сделать кнопку со считыванием характеристик системы не такая и проблема, вопрос больше в подходе и во времени для реализации. Кода там на пару сотен строк максимум выйдет (считать инфу с интерфейса в цикле с опросом приборов и выставить в конфиге значения в соответствии с бд. бд по соответствию типов вполне можно допилить. для универсальных входов - тип по умолчанию определить).
Другое дело, что у них между версиями постоянно даже различия критичные в совместимости имеются, им даже пришлось специальный пункт по конвертированию между версиями конфигов сделать на повышение версий - это говорит о том, что структуры как таковой у них не определено, каждая новая версия делается либо практически с нуля, либо непонять как ( а вернее даже сами прошивки делаются с недостатками в архитектуре, приводящими к таким последствиям ). ведь по сути старые типы извещателей и прочих устройств не меняются - ничего не мешает поддержку старых конфигов в новых версиях вести 1:1 при грамотном подходе (тут хотелось бы знать что этому мешает). смысл менять в новой версии структуру всего конфига - я лично не вижу (можете не плеват с ожидаемой критикой "да что вы понимаете", я сам микроконтроллеры программирую и как там что устроено вполне понимаю с разных сторон, на данном этапе занимаюсь разработкой для ESP32, хоть и не в промышленном масштабе). Если не отвлекаться на прочие задачи - с тестами за 2-3 неделек можно вполне реализовать, сложностей не вижу (тесты тут 90% времени и займут с отладкой). Другой вопрос сколько у них задач на программере висит, потому как тот же сириус еще сырой и есть у людей нарекания по слухам.

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

значение по умолчанию - тем, что при работе с Орион про у них вообще чудеса случаются - корявые показания (а иногда вообще отсутствие показаний) АЦП, сообщения, не соответствующие назначению, неверное значение типа входа в С2000КДЛ, и так далее. Хорошо было бы, если бы "По умолчанию" все типы нормально работали. В КДЛ выставлять тип в любом случае необходимо.

Ну КДЛ более или менее выставляет сам типы зон.

Новоселов ВА, пожалуй соглашусь с Вами. Я тоже считаю, что некий параметр, в данном конкретном случае это тип входа, должен устанавливаться единожды. Для болидовских приборов и их структуры всей системы логичнее и удобнее всего делать это именно в приборах, например КДЛ. Там наладчик определяет для заданного адреса все параметры. В этом случае в ПКУ настройки типа входа не должно быть в принципе, т.к. всё это уже задано в приборе. Если ПКУ для корректной работы требуются индивидуальные параметры входа, то пускай он их подгружает в момент инициализации и хранит в ОЗУ. ИМХО это логично.

Каким? Поясните пожалуйста.

  Заданные в С2000М типы шлейфов никак не влияют на запрос измерений (АЦП) из АРМ "Орион Про". Тип шлейфа С2000М влияет только на доступные команды управления, функцию "отключения" и формирование сигнала "Пожар2", более ни на что. Типы "адресно-аналоговый дымовой" и "адресно-аналоговый тепловой" идентичны "пожарному", поэтому всем автоматическим пожарным извещателям можно задавать тип "пожарный". Тип "по умолчанию" идентичен "охранному".  В более ранних версиях С2000М (2.хх) все перечисленные типы не отличались, поэтому тип "по умолчанию" годился для любого охранного или пожарного извещателя (кроме ИПР, которому для получения сигнала "Пожар2" требовалось задать тип "ручной пуск" (сейчас он называется "пожарный ручной"), когда данный сигнал не формировался блоком С2000-КДЛ).
  По PProg. Сейчас PProg не знает форматов конфигураций приборов, кроме С2000М и С2000, поэтому не сможет считать типы шлейфов из С2000-КДЛ, Сигналов и других блоков. Наиболее реалистичный путь - сделать в PProg загрузку типов шлейфов из хорошо формализованного файла с конфигурацией прибора в формате XML.  Для чтения  конфигураций из приборов потребуется включить в PProg функции UProg, а это не одну кнопку добавить.
 

Ильин Сергей, многолетняя практика показывает, что разница бывает, вероятно зависит еще от версий прошивок - этого не проверял и нет времени вникать. Бывают и показания дробные типа 0,ХХ на разных извещателях (кажись на дипах такое проявлялось, сейчас нет возможности уточнить) показывает в орионе, и прочую подобную ахинею, и это не выдумка. То, что периодически техподдержка сама не понимает что происходит, полагаясь на "как оно должно работать" - это другой вопрос. В отрыве от темы - чего стоит только ответ от специалиста при удаленном подключении "мы сами незнаем как оно так у вас работает", частный случай, не в критику но в понимание, что багов и проблем море на самом деле и у служб порой недостаточно чегото (времени/возможностей/прочего - тут мне неизвестно и я не намерен судить, я не за суд, я за развитие) для вылавливания всех глюков. И у меня вопрос не в том что "могут/не могут сейчас", а в том, чтобы в конце концов за столько лет существования подобный функционал осуществился, ведь все стремятся к развитию и улучшению качеств - неужели в болиде останется всё "как на коленке"?
"включить функцию" - это использовать хедер с функцией из ппрога? или у вас там всё на столько сложно, что функциональное программирование не используется в подобном направлении совместном с ооп? А если по сути:
1) вариант углубленный: жмем кнопку, получаем там всякие WM_COMMAND (а если там у вас еще всё продвинетей - так и функцию сама ide с шаблона закинет типа onButtonPressed, давненько для венды в продвинутых ide не писал), делаем в цикле опрос приборов, каждому прибору делаем опрос извещателей, получаем от извещателя через прибор его тип - записываем предустановленное значение в значение в конфиге
2) вариант попроще: жмем кнопку, получаем WM_COMMAND, запускаем опрос приборов в цикле, считываем с прибора конфиг, с конфига берем нужные значения.

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

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

Новоселов ВА, 
Но есть одно маааленькое примечание - всё, что обсуждается здесь, касается исключительно наладчиков систем. А на труд наладчиков и заказчикам, и производителю начихать. Для одного важно чтобы всё работало, а второму важно чтобы больше продавалось. Поэтому какие либо улучшения юзабилити софта (Uprog, PProg, АБД и др.) это  жест доброй воли разработчика, типа "нате Вам косточку, грызите её и не вякайте".

P.S. Сорри за тон изложения.

Во-первых, в КДЛ можно одним нажатием расставить типы извещателей по умолчанию.
Во-вторых, можно настроить один шлейф и скопировать один или все его параметры через список или диапазон адресов.
Если сгорел пульт, вы теряете логику работы системы и разделы - адресация и типы в дискретных приборах, а не как в Рубеже.
Что касается отображение в АРМе значений запылённости (если я верно понял), то должно пройти время пока сбор статистики опросит все извещатели по кругу.