Поляков Илья
Active Forum Member / Активный участник форума
Участник № / Member № 3358
отправлено / posted
Ситуация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 процентов данных не требуется получать постоянно, но необходимо почти все по команде оператора. Ну и экономия траффика не на последнем месте.
Сообщения / Posts 68 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Поляков Илья
Active Forum Member / Активный участник форума
Участник № / Member № 3358
отправлено / posted
Добавлю еще одно наблюдение:
В ситуации1, как в случае удачного приема значения, так и в случае неудачного приема, наблюдаем шесть пакетов данных по ТCP
Машина2 в Машина1 Машина2 от Машина1 Машина2 в Машина1 Машина2 от Машина1 Машина2 в Машина1 Машина2 от Машина1
Пакеты присутствуют при каждой попытке получения данных, т.е. вариант с потерей пакетов в сети отпадает.
Пакеты наблюдаем на портах занятых под OPC на машине2.
Изменение приоритета потоков Прием TCP, отправка TCP, TCP\IP с DEFAULT на HIGHEST иногда приводит к значительному увеличению количества нормально принятых значений от OPC (но как оказалось не всегда).
Сообщения / Posts 68 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Поляков Илья
Active Forum Member / Активный участник форума
Участник № / Member № 3358
отправлено / posted
Эксперименты продолжаются...
После изменения времени цикла монитора с 0,055*10 до 0,055*100 прием данных стал устойчивым, т.е. каждый раз, как только инициируем получение данных через OPC путем дерганья за 3 атрибут канала прикрученного к OPC, мы эти данные получаем (спустя некоторое время, порядка 1-2 сек).
Т.е. видимо МРВ не всегда мог дождаться получения данных за время цикла, это и было причиной потерь.
Но теперь возникает вопрос, а если транспортная задержка будет составлять 10 сек (чисто теоретически), то потребуется увеличить время цикла монитора до 200*0,055?
Есть идея ставить исполнение канала в основном цикле (т.е. не однократно, а например 1 цикл) и оставить время цикла монитора 10*0,055с, но включать канал 3 атрибутом только на время отправки запроса+получение данных, а в остальное время держать его выключеным. Как определить момент прихода данных от OPC в канал?
Сообщения / Posts 68 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Ошибка с периодом однократно есть в релизе 6.06.2. Это уже поправлено, будет доступно в ближайшем релизе.
Если данные пришли новые, то можно по 45 атрибуту. Если данные не изменились, то определить окончание обмена довольно проблематично.
Сообщения / Posts 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
