У всех состояний есть приоритет. Как "Запрос" оказался на одном уровне или выше с "Пожаром" я в недоумении. 
Хотя сейчас вспоминаю и вроде бы в больших системах такое было и мы не задумывались о "высоком", а просто перепрошивали мешающие неисправные КПБшки.
И к разговору у сценариях, не знаю, кто что читал, давайте не будем этим оперировать, а если считывать с шлейфа только разрешающее условие "Пожар", то блокирующие действительно должны быть по боку. Но это как-то не по Фэн-Шую что ли.

На самом деле не пульт, а КДЛ переводит систему в состояние «пожар», это именно КДЛ принимая от АУ «уровень», и при превышении, как раз КДЛ принимает (источник события) решение, и отправляет событие «пожар» в пульт. Но если возникает ситуация, при которой КДЛ «заклинивает» на:

Соответственно нет ответа на "Запрос" и пульт в ступоре. А если ответа нет, то на «нет», и ничего не происходит. А к этому ещё и «глюк» пульта по соседнему разделу.
Причём подобное уже где-то было…

Производитель то что нибудь скажет?
По моему это серьезная проблема..

У Производителя выходные так-то, если просто забыть, что это неофициальный форум.

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

Состояние "ЗАПРОС..." в разделе означает, что С2000М не закончил опрос состояний входящих в него элементов, состояния не всех элементов раздела получены. После включения С2000М состояние "ЗАПРОС..." должно уйти, когда он опросит все приборы. Если этого не происходит - это серьёзная ошибка, которую нужно обязательно исправлять.
 "ЗАПРОС..." (состояние неизвестно) имеет приоритет ниже "ПОЖАРА", но если неизвестное состояние не позволяет определить, по какому условию нужно включить реле - управление откладывается до тех пор, пока требуемые состояния не станут известны. Такая логика сделана, в первую очередь,  для корректной работы программ АСПТ и сценариев, включающих условия блокировки пуска, чтобы предотвратить включение реле при неизвестном состоянии условия блокировки. Реле  может включиться по первому, самому приоритетному условию программы или сценария, например, для программ 1 - 8 - при "Пожар2" или при ручном пуске, так как в этом случае наличие неизвестных состояний не влияет на условие пуска.
Необходимо избавиться от "застревания" состояния "ЗАПРОС...". Возможные причины данной ошибки:
1. Со стороны С2000М - если в настройках RS-232 выставлен режим "ПИ/РЕЗЕРВ". В этом режиме С2000М имеет проблемы с запросом состояний. Его нужно изменить на любой другой (например, "КОМПЬЮТЕР", если  С2000М работает с АРМ). Если же необходим именно этот устаревший режим - прошу обратиться в техподдержку для получения обновления версии.
2. Со стороны С2000-КДЛ. Данная проблема была в случае, если в раздел С2000М включен вход контроля концевого выключателя рабочего или исходного положения С2000-СП4, и в конфигурации С2000-КДЛ контроль этим входом отключен. Решается обновлением версии С2000-КДЛ.
3. Если указанные причины не подходят, то потребуется обратиться в техподдержку. Нужны следующие данные: информация, какой элемент(ы) системы находится в состоянии "ЗАПРОС...", конфигурации С2000М и С2000-КДЛ, версии приборов. Для поиска элемента в состоянии "ЗАПРОС..." потребуется пароль с правами управления разделами, с помощью которого нужно на С2000М найти раздел с состоянием "ЗАПРОС...", войти в него клавишей "ввод", найти и выписать элементы с состоянием "ЗАПРОС..." (адрес прибора и номер входа или выхода). Для более детальной диагностики может потребоваться снять лог команд с линии RS-485 между С2000М и С2000-КДЛ специальной программой (потребуются компьютер и преобразователь интерфейсов для подключения к линии RS-485).

Ой, а пользуясь случаем, можно эту самую "специальную" программу? :) Это же не PKUEventReader, а что-то более низкоуровневое и realtime. Очень иногда пригодилась бы при поиске глюков.

Это уже интереснее..
Можно поподробнее про эту программу?
Это типа сниффера  с декодером?

Можно подробнее.
Служебный диагностический софт. Для распространения среди пользователей не предназначен.
В поиске типичных пользовательских глюков бесполезен.

Глюки точно пользовательские?

Глюки встречающиеся у пользователей системы в болишнстве случаев...
Ну то есть это не поможет пользователям в поиске и устранении ошибок абсолютно никак. И не требуется вообще в 99.99% возникающих ситуаций.

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

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

И все же. Можно выложить программу?

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