Тема / Topic: Пересчет канала OUTPUT при потере/восстановлении связи с модулями вывода
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Здравствуйте Господа!
Как с наименьшими телодвижениями (создание вспомогательной программы и т.п.) обойти ситуацию когда имеет место потеря связи с модулем вывода а запись нового значения в канал происходит в этот момент. Т.к. при восстановлении связи RTM не передаст команду для модуля, поскольку значение осталось неизменным. Долбить постоянно в 39-й атрибут что ли? Ведь OUTPUT отрабатывается только при изменении значения и соответственно достоверность у него меняется по изменению значения. Или у Вас как всегда есть некие нюансы которые в Хелпе не освещены?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
При записи нового значения в канал OUT он пытается передать это значение приемнику. Если связь с устройством некачественная и полученное(!) в ответ сообщение не соответствует ожидаемому по протоколу подтверждению, то канал OUT будет повторять свои попытки (через заданный таймаут) до тех пор, пока связь не восстановится и он не получит от приемника необходимое подтверждение.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Не повторяет посылку! Если значение было записано в момент потери связи. Т.е. в канал записали значение, если связи нет, то выставляется недостоверность и при восстановлении связи на модуль нет посылки, т.к. посылка была в момент нарушения связи и, как Вы говорите протоколом предусмотрено подтверждение от модуля, которого не было обнаружено и через таймаут все отвалилось. После чего связь восстановилась, а посылок в порт нету, пока либо в 39-й атрибут не запишешь либо не обновишь значение в канале. Проверьте у себя на живом оборудовании. Если было бы все ок не писали бы мы об этом, а ситуация имеет место. Конечно она не безвыходная, но гемор определенный вызывает!
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Прошу прощения за неточность формулировки предыдущего поста (см. отредактированный пост).
В случае, если связь с устройством отсутствует (в ответ на 2 попытки послать команду не получено ни одного байта), канал OUT теряет активность. Сделано это мотивированно, т.к. далеко не всегда повторение команды через неопределенный промежуток времени (после восстановления связи) может оказаться допустимым. Поэтому, с нашей точки зрения, управление повторной передачей допустимых команд после восстановления связи вполне оправдано. Отменить указанный режим можно введением в файл *.cnf ключа HNRDSLOW=OFF
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Мы согласны что не зачем каналу быть активным, если связь восстановиться неизвестно когда, но это почему то реализовано у вас только для OUTPUT. INPUT оживает сам. Если мы используем ключ HNRDSLOW=OFF, то это будет для всех OUTPUT каналов узла? Как это повлияет на нагрузку (ресурсы ПК, ресурсы порта) если посылки будут уходить с почетной регулярностью. Может сделать "контрольный" канал, и ориентироваться по нему, и рассылать отработку в 39 атрибуты каналов связанных с модулем? Мы и спрашиваем может есть реальный опыт реализации - как лутше это сделать, а не пробовать и не экспериментировать, чтоб не напороться на "грабли".
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Задача мониторинга фактически универсальна для всех систем: получение данных с динамическими характеристиками, адекватными процессу. И опасности для самого процесса мониторинг не представляет. Задача управления в разных системах решается по разному. И, как уже было сказано, в ряде случаев неадеватное решение может представлять опасность для процесса. Поэтому ограничение коснулось именно каналов OUT. 2. Ключ HNRDSLOW=OFF отменяет блокировку для всех каналов OUT, связанных с приемниками. На ресурсах ПК это практически не скажется. Загрузка COM-порта увеличится и, следовательно, для других устройств, подключенных к этому COM-порту, реактивность обмена может ухудшиться. 3. На практике реальная производительность COM-порта в значительной степени определяется не управлением, а мониторингом. Поэтому контроль наличия связи с каждым отдельным устройством, подключенным к COM-порту, и соответствующее управление обменом с ним (выключение/включение соответствующих каналов и, при необходимости (!) повторение команд управления) - задача, решаемая программным образом индивидуально в рамках каждого проекта.
При обмене по сети, когда существует системная диагностика связей по каждому IP-адресу, прерывание трафика и его восстановление при восстановлении связи осуществляется автоматически.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Спасибо за консультацию Ещё вопрос: этот ключ будет действителен для Embedded RTM под WinCE для WinPac-а?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
И снова Здравствуйте!
Проверили работу узла как под RTM так и под embedded RTM, с указанным Вами ключом. Выяснили следующее: 1. При потере связи с модулями вывода МРВ не выставляет в каналах OUTPUT связанных с соответствующими источниками/приемниками (модулями вывода) признак аппаратной недостоверности. 2. При восстановлении связи с соответствующими источниками/приемниками (модулями вывода) система передает значение в канал, в случае если его значение стало отличным от того которое было до разрыва связи. Без указанного ключа такой реакции мы не наблюдаем.
Теперь вопрос: то что описано первым пунктом сверху это так и есть, или надо еще какой либо ключ чтобы канал OUTPUT обновлялся "самостоятельно" не только при восстановлении связи (п.2) но и при её потере (п.1)?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
В каналах OUTPUT, связанных с соответствующими приемниками (модулями вывода), выставляется недостоверность после неудачной попытки передачи значения приемнику. Если в период отсутствия связи с УСО через канал OUT будет осуществлена попытка передачи значения (если значение канала изменилось или взведен атрибут EXEC (39))? каналу будет выставлена недостоверность. Автоматически (без осуществления попытки передачи значения) канал OUT "не обнаружит" отсутствия связи с УСО.
Автоматическая передача старого значения при восстановлении связи при введении ключа HNRDSLOW=OFF системными средствами невозможна. Можно только средствами прикладной программы контролировать наличие связи каналом INPUT и после восстановления связи принудительно взводить атрибуты атрибут EXEC (39) нужным каналам OUT.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
Printer-friendly view of this topic
