This is topic OPC и отработка канала "однократно" in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.


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

Posted by Поляков Илья (Участник № / Member № 3358) on :
 
Ситуация1

Исходные данные:


Машина1: Удаленный ПК с Lectus Modbus OPC, один тэг. Время обновления тэга - не обновлять.
Lectus забирает данные с контроллера.

Машина2: АРМ с TM6.06.02 с тестовым проектом ONCE. Один тэг на OPC, ASYNC\DEVICE.

Между Машина1 и Машина2 - TCP\IP.

Задача проекта - инициировать с машины2 однократное получение тэга Lectusом (который на Машине1) с контроллера, и отправку
полученного значения на Машину2.

Lectus настроен так, что самостоятельно, без запроса данные с контроллера не кэширует. Только в момент прихода запроса с Машины2
получает число от контроллера.


В ТМ реализуется путем выставления 38 атрибута канала в "однократно" на этапе конфигурации, и затем установки 3 атрибута
в 0 каждый раз, когда требуется получить данные.


Иногда работает нормально, иногда данные не приходят на атрибут IN канала (все это в пределах одной сессии, т.е.
профайлер не выключаем, просто делаем серию попыток. Из них часть удачные, часть неудачные).


LECTUS считывает с контроллера данные при каждом запросе от ТМ, это видно по встроенной в него мониторилке. Т.е. каждый раз, когда
дергаем канал за 3 атрибут, LECTUS получает данные с контроллера, и это видно по изменению данных и времени обновления.

Ответные пакеты по TCP от LECTUSа приходят всегда на машину2 (смотрели BWMETERom на портах отведенных под OPC, адреса
портов вычисляли netstat -a).


Ситуация2

Исходные данные:

Те же, что и в ситуации1, но на машине2 проект CYCLE.

Задача проекта - та же, что и в ситуации1

Настройки Lectusa - как в ситуации1.


В ТМ реализуется путем выставления 38 атрибута канала в "сек", а 5 атрибута в 5, на этапе конфигурации. Т.е. отработка канала идет в 5 сек цикле.


Иногда работает нормально, иногда данные не проходят на атрибут R канала (все это в пределах одной сессии, как в ситуации1).

На IN данные от OPC приходят всегда, в каждом цикле.


Основное отличие ситуации 1 от ситуации 2:

В ситуации1 данные иногда вообще не приходят на IN. Данные получаем путем ручного дерганья 3 атрибута, при настройках цикла канала стоит "однократный".

В ситуации2 данные всегда приходят на IN, но не всегда передаются на R. Данные получаем путем циклической отработки канала с периодом в 5 секунд.

Других отличий нет.

Требуется гарантированное получение данных (при условии исправности канала, живого Lectusa и пр.) в ситуации1. СитуациЯ2 выявлена в результате поисков
причин ненадежной работы в ситуации1.

Складывается впечатление, что в ситуации1 TM не всегда дожидается ответа от OPC и отпадает по какому-то таймауту.
В ситуации2 поведение TM объяснить не можем.

Добавлю, что в обоих ситуациях недостоверность канала никогда не появляется, по крайней мере это не видно в "компонентах" в профайлере.

Проекты отправлены на hotline.

P.S. Вся затея состоит в том, чтобы максимально снизить трафик в большом проекте, ибо данные между машиной1 и контроллером передаем по GPRS.
При использовании циклического опроса OPC-сервером контроллера транспортная задержка на участке составляет 25-30 сек, при том, что 95 процентов
данных не требуется получать постоянно, но необходимо почти все по команде оператора.
Ну и экономия траффика не на последнем месте.
 
Posted by Поляков Илья (Участник № / Member № 3358) on :
 
Добавлю еще одно наблюдение:

В ситуации1, как в случае удачного приема значения, так и в случае неудачного приема, наблюдаем шесть пакетов данных по ТCP

Машина2 в Машина1
Машина2 от Машина1
Машина2 в Машина1
Машина2 от Машина1
Машина2 в Машина1
Машина2 от Машина1

Пакеты присутствуют при каждой попытке получения данных, т.е. вариант с потерей пакетов в сети отпадает.

Пакеты наблюдаем на портах занятых под OPC на машине2.

Изменение приоритета потоков Прием TCP, отправка TCP, TCP\IP с DEFAULT на HIGHEST иногда приводит
к значительному увеличению количества нормально принятых значений от OPC (но как оказалось не всегда).
 
Posted by Поляков Илья (Участник № / Member № 3358) on :
 
Эксперименты продолжаются...

После изменения времени цикла монитора с 0,055*10 до 0,055*100 прием данных стал устойчивым, т.е. каждый раз, как только инициируем получение данных через OPC путем дерганья за 3 атрибут канала прикрученного к OPC, мы эти данные получаем (спустя некоторое время, порядка 1-2 сек).

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

Но теперь возникает вопрос, а если транспортная задержка будет составлять 10 сек (чисто теоретически), то потребуется увеличить время цикла монитора до 200*0,055?

Есть идея ставить исполнение канала в основном цикле (т.е. не однократно, а например 1 цикл) и оставить время цикла монитора 10*0,055с, но включать канал 3 атрибутом только на время отправки запроса+получение данных, а в остальное время держать его выключеным.
Как определить момент прихода данных от OPC в канал?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Ошибка с периодом однократно есть в релизе 6.06.2. Это уже поправлено, будет доступно в ближайшем релизе.

Если данные пришли новые, то можно по 45 атрибуту. Если данные не изменились, то определить окончание обмена довольно проблематично.
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2