This is topic Проблема ТМ6 при работе по ОРС с AllenBradley in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/35/t/000345.html

Posted by kip (Участник № / Member № 6280) on :
 
Добрый день,

Вресия ТМ6 - 6.090 (последняя).

Обнаружена проблема остановки коммуникаций по ОРС между МРВ1 и ОРС-сервером AllenBradley (АВ).
В процессе работы ОРС-сервер АВ может иногда не отвечать на запросы при выполнении сложных задач. Это описано в его документации и это абсолютно штатный режим.

Согласно трассировке сети, после запуска МРВ успешно посылает ОРС-запросы ровно до того момента, когда ОРС-сервер АВ один раз рвет соединение (на запрос МРВ TCP:ACK приходит пакет TCP:RST).

После этого МРВ не возобновляет попыток опросить ОСР-сервер АВ вплоть до перезапуска МРВ.

Уважаемая разработка. Есть ли какой-либо способ решения проблемы, а именно как заставить ТМ6 периодически проводить опрос ОРС-сервера без останова-запуска проекта?

Всего наилучшего,
Сергей.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Существует диагностическая переменная @e_OPC, которая позволяет как диагностировать процесс обмена с OPC-серверами (в режиме INPUT), так и принудительно реинициализировать обмен (в режиме OUT) (см.соответствующий раздел справочной системы).
Обнаружив отказ OPC-интерфейса, Вы можете программно реинициализовать его.
 
Posted by kip (Участник № / Member № 6280) on :
 
Отлично, можно привести пошаговую инструкцию по использованию этой переменной в проекте?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Канал, связанный с переменной @e_OPC типа Input, возвращает код ошибки.
Программа должна анализировать этот код с некоторым временным фильтром выдавать исполнительную команду в анал, связанный с переменной @e_OPC типа OUT.
 
Posted by kip (Участник № / Member № 6280) on :
 
Спасибо, начинаю понимать, как реализовать перезапуск, но во встроенной справке не очень много информации.
К МРВ подключено 4 ОРС сервера. " из них проблемные.

Переменная @e_OPC привязана к каналу с типом FLOAT (тип FLOAT получился автоматически при перетаскивании перменной из И-П в Каналы).


Какие биты мне анализировать для проверки работы с оперделенными ОРС-серверами?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Можно открыть СВОЙСТВА канала FLOAT и изменить его тип на HEX16.
Каждому OPC-серверу соответствует в папке узла файл конфигурирования *.cnf. В имени файла присутствует индекс OPC-сервера в узле.
По этим индексам и следует идентифицировать результат диагностики (номера битов).
 
Posted by kip (Участник № / Member № 6280) on :
 
В нашем случае каждому ОРС-серверу соответствует 2 *.cnf файла с разными переменными внутри.

Например PROJ_0_opc0.cnf и PROJ_0_opc1.cnf соответствуют 1-ve серверу RSLinx.

Как я понимаю, мне нужно будет анализировать либо 0-й либо 1-й бит для определения доступности данного сервера по ОРС?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Именно так.
 
Posted by kip (Участник № / Member № 6280) on :
 
Спасибо. Тема закрыта.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2