This is topic Пересчет канала OUTPUT при потере/восстановлении связи с модулями вывода in forum Общие вопросы / Common questions at Форум TRACE MODE: техническая поддержка.
Как с наименьшими телодвижениями (создание вспомогательной программы и т.п.) обойти ситуацию когда имеет место потеря связи с модулем вывода а запись нового значения в канал происходит в этот момент. Т.к. при восстановлении связи RTM не передаст команду для модуля, поскольку значение осталось неизменным. Долбить постоянно в 39-й атрибут что ли? Ведь OUTPUT отрабатывается только при изменении значения и соответственно достоверность у него меняется по изменению значения. Или у Вас как всегда есть некие нюансы которые в Хелпе не освещены?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
При записи нового значения в канал OUT он пытается передать это значение приемнику. Если связь с устройством некачественная и полученное(!) в ответ сообщение не соответствует ожидаемому по протоколу подтверждению, то канал OUT будет повторять свои попытки (через заданный таймаут) до тех пор, пока связь не восстановится и он не получит от приемника необходимое подтверждение.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Не повторяет посылку! Если значение было записано в момент потери связи. Т.е. в канал записали значение, если связи нет, то выставляется недостоверность и при восстановлении связи на модуль нет посылки, т.к. посылка была в момент нарушения связи и, как Вы говорите протоколом предусмотрено подтверждение от модуля, которого не было обнаружено и через таймаут все отвалилось. После чего связь восстановилась, а посылок в порт нету, пока либо в 39-й атрибут не запишешь либо не обновишь значение в канале. Проверьте у себя на живом оборудовании. Если было бы все ок не писали бы мы об этом, а ситуация имеет место. Конечно она не безвыходная, но гемор определенный вызывает!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Прошу прощения за неточность формулировки предыдущего поста (см. отредактированный пост).
В случае, если связь с устройством отсутствует (в ответ на 2 попытки послать команду не получено ни одного байта), канал OUT теряет активность. Сделано это мотивированно, т.к. далеко не всегда повторение команды через неопределенный промежуток времени (после восстановления связи) может оказаться допустимым. Поэтому, с нашей точки зрения, управление повторной передачей допустимых команд после восстановления связи вполне оправдано. Отменить указанный режим можно введением в файл *.cnf ключа HNRDSLOW=OFF
Posted by Grigorovskih (Участник № / Member № 1915) on :
Мы согласны что не зачем каналу быть активным, если связь восстановиться неизвестно когда, но это почему то реализовано у вас только для OUTPUT. INPUT оживает сам. Если мы используем ключ HNRDSLOW=OFF, то это будет для всех OUTPUT каналов узла? Как это повлияет на нагрузку (ресурсы ПК, ресурсы порта) если посылки будут уходить с почетной регулярностью. Может сделать "контрольный" канал, и ориентироваться по нему, и рассылать отработку в 39 атрибуты каналов связанных с модулем? Мы и спрашиваем может есть реальный опыт реализации - как лутше это сделать, а не пробовать и не экспериментировать, чтоб не напороться на "грабли".
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Задача мониторинга фактически универсальна для всех систем: получение данных с динамическими характеристиками, адекватными процессу. И опасности для самого процесса мониторинг не представляет. Задача управления в разных системах решается по разному. И, как уже было сказано, в ряде случаев неадеватное решение может представлять опасность для процесса. Поэтому ограничение коснулось именно каналов OUT. 2. Ключ HNRDSLOW=OFF отменяет блокировку для всех каналов OUT, связанных с приемниками. На ресурсах ПК это практически не скажется. Загрузка COM-порта увеличится и, следовательно, для других устройств, подключенных к этому COM-порту, реактивность обмена может ухудшиться. 3. На практике реальная производительность COM-порта в значительной степени определяется не управлением, а мониторингом. Поэтому контроль наличия связи с каждым отдельным устройством, подключенным к COM-порту, и соответствующее управление обменом с ним (выключение/включение соответствующих каналов и, при необходимости (!) повторение команд управления) - задача, решаемая программным образом индивидуально в рамках каждого проекта.
При обмене по сети, когда существует системная диагностика связей по каждому IP-адресу, прерывание трафика и его восстановление при восстановлении связи осуществляется автоматически.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Спасибо за консультацию Ещё вопрос: этот ключ будет действителен для Embedded RTM под WinCE для WinPac-а?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да, будет действителен.
Posted by Grigorovskih (Участник № / Member № 1915) on :
И снова Здравствуйте!
Проверили работу узла как под RTM так и под embedded RTM, с указанным Вами ключом. Выяснили следующее: 1. При потере связи с модулями вывода МРВ не выставляет в каналах OUTPUT связанных с соответствующими источниками/приемниками (модулями вывода) признак аппаратной недостоверности. 2. При восстановлении связи с соответствующими источниками/приемниками (модулями вывода) система передает значение в канал, в случае если его значение стало отличным от того которое было до разрыва связи. Без указанного ключа такой реакции мы не наблюдаем.
Теперь вопрос: то что описано первым пунктом сверху это так и есть, или надо еще какой либо ключ чтобы канал OUTPUT обновлялся "самостоятельно" не только при восстановлении связи (п.2) но и при её потере (п.1)?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В каналах OUTPUT, связанных с соответствующими приемниками (модулями вывода), выставляется недостоверность после неудачной попытки передачи значения приемнику. Если в период отсутствия связи с УСО через канал OUT будет осуществлена попытка передачи значения (если значение канала изменилось или взведен атрибут EXEC (39))? каналу будет выставлена недостоверность. Автоматически (без осуществления попытки передачи значения) канал OUT "не обнаружит" отсутствия связи с УСО.
Автоматическая передача старого значения при восстановлении связи при введении ключа HNRDSLOW=OFF системными средствами невозможна. Можно только средствами прикладной программы контролировать наличие связи каналом INPUT и после восстановления связи принудительно взводить атрибуты атрибут EXEC (39) нужным каналам OUT.
Posted by Grigorovskih (Участник № / Member № 1915) on :
все понятно, тогда для полного счатья надо использовать вотчдог
