NAP OPC ICP CON

[ЧесноковИА]

АРМ оператора подключен к ПЛК ICP через Ethernet ModBus TCP IP, на АРМ Genesis и NAP OPC версии 2.6

АСУ расширили добавили два АРМ на Intouch, наблюдаем следующий эффект периодически NAP OPC сервер выдает отрицательные значения аналоговых параметров, для некоторых параметров очень большие значения (я так понял это в зависимости от типа данных int или word).
обслуживающий персонал говорит что это из за частых опросов ПЛК.

Вопрос что делать ???
1. Сменить OPC Сервер на новую версию ??
2. Пробывали модбас сервер ввода-вывода интач связь вообще неустойчивая с ICP, SCADAPACK при этом опрашивается нормально.
3. Пробывали изменить период опроса снижали до 10 сек, не помогает
4. Есть ли у ПЛК ICP ограничение по опрашивающим его серверам по Ethernet - кол-во серверов, период опроса и т.п. ???
Поделитесь опотом !

[Никита]

Первый ответ - попробовать оптимизировать программу ПЛК. Чем программировали, что заливали, какие функции? 10 секунд - это очень много даже для ICP, возможен косяк в прикладном ПО контроллера. Может быть и в самих библиотеках обмена проблема

[ЧесноковИА]

да мы его не программировали, просто вывели параметры с этого ПЛК на новые АРМ, в рамках ПНР это сделали по просьбе Заказчика. ПЛК был существующий в него никто не лазил.

[Никита]

Тогда немного не понял проблемы. Получается, что контроллер стоит с той же прошивкой и крутится тот же OPC-сервер в одном экземпляре, а когда на OPC-сервер по сети повесили второе АРМ - получаете непонятные данные? Данные такие дает сам OPC-сервер и на той машине, на которой он крутится и на той, которую поставили дополнительно? А если отключить лишние АРМы? Вообще немного поподробнее про структуру верха расскажите.

[CHANt]

Сталкивался со схожей ситуацией. САУ ГТУ была реализована на WinCon8000, получала данные от контроллера газотурбинного двигателя по ModbusRTU и со своего полевого оборудования. С САУ шла передача данных Modbus TCP на панельный компьютер местного щита САУ с Genesis32 (ОРС Iconics) и на верхний уровень в КРУГ2000 через NAPOPCDA. Все переменные типа Word.
При запуске ГТУ, после выхода с холодной прокрутки на малый газ, на 40-120 секунд переставали обновляться данные в КРУГ 2000, NAPOPCDA просто не получал данные с WinCon. По мере выхода ГТД на полный газ связь восстанавливалась.
К сожалению программа САУ в среде ISAGraf, нам была недоступна, и деталей касающихся ICP не знаю. Пытались применить Матриконовский ОРС-сервер, вообще происходил отвал обмена минут на 5-10 при пуске ГТУ. Временно, ситуацию решили путем обмена КРУГ2000 с Genesis32. Мое мнение - с обменом данных не справлялся WinCon8000 (ОС - WinCE). На данный момент ГТУ не работает, так как не смог изготовить нормальный редуктор "Киров-Энергомаш", и соответственно проблема не устранена.

[Михайло]

Автору темы: Наверное где-то в системе старший бит слова интерпретируется как знак. И при переполнении регистра (которое происходит редко) значения становятся отрицательными. Нужно сменить тип данных на unsigned word или integer. ИМХО.

[abbat81]

АРМ оператора подключен к ПЛК ICP через Ethernet ModBus TCP IP, на АРМ Genesis и NAP OPC версии 2.6

АСУ расширили добавили два АРМ на Intouch, наблюдаем следующий эффект периодически NAP OPC сервер выдает отрицательные значения аналоговых параметров, для некоторых параметров очень большие значения (я так понял это в зависимости от типа данных int или word).
обслуживающий персонал говорит что это из за частых опросов ПЛК.

Вопрос что делать ???

Раз Вы говорите, что АРМ Genesis, до ввода в эксплуатацию двух дополнительных АРМ работал нормально, сделать можно следующее:
Перепривязать Интачевские АРМ- ы не к контроллеру а непосредственно к OPC серверу на АРМ Genesis, проблема отпадет сама собой.

[MuadDib]

Присоединяюсь к вопросу Никиты: нужно написать подробнее о структуре "верха". Кроме того, уточните пожалуйста:
1. Точный тип контроллера ICP. Тип ПО на нем (таргет ISaGRAF, экзешник собственного изготовления и т.п.)
2. Где конкретно снижали период опроса до 10 сек? (NAPOPC, Intouch, Genesis)?
3. Производится ли в вашей системе запись данных по Modbus TCP (передача данных в регистры контроллера)? Если да, то как часто и с какого из АРМ?

[ЧесноковИА]

Контроллер I-8437 ISaGRAF 3.46
NAP OPC/* Version : 2.22 /* Date : May-9-2006
OPC сервер установлен на каждом АРМе
период опроса снижал в Intouch, в OPC сервере такого параметра по моему не было.
Запись данных в ПЛК не производиться
Со слов обслуживающего персонала - "Сам зашитый в контроллер проект высылать смысла нет, там просто сконфигурированы каналы ввода-вывода. Кроме того, исходников у нас вообще нет, по-моему."

[Никита]

OPC сервер установлен на каждом АРМе

Не самое лучшее решение - сами-то пробовали одновременно по нескольким телефонам разговаривать :) - контроллер оказывается в такой же ситуации.
Вариант - оставить один OPC-сервер, остальные берут от него данные по сети (с DCOM и брандмауэрами, если есть, придется повеселиться) - здесь все зависит от "талантов" сервера, либо, как предлагал abbat81 использовать, в качестве промежуточного, OPC-сервер, имеющийся в Genesis, что в общем-то то же самое, суть - снизить количество обращений к контроллеру от OPC-серверов

[CHANt]

В NAPOPC есть возможность менять таймаут, в настройках устройства. В закромах сохранились рекомендации.

[MuadDib]

Контроллер I-8437 с таргетом ISaGRAF 3.46 производства ICP DAS поддерживает (по фирменной документации) 4 одновременных соединения с мастерами Modbus TCP. В вашем случае было 3, меньше заявленного.
Конечно, ситуация с одновременным опросом одного контроллера несколькими мастерами далека от оптимальной, но в принципе должно было работать, тем более что вы устанавливали очень большой период опроса... По крайней мере, у нас в некоторых случаях в процессе отладки системы ряд контроллеров опрашивался одновременно 2 мастерами, и ничего подобного не происходило.

Лучше всего, как уже писал Никита, отказаться от нескольких ОРС серверов. Но если такой конфиг необходим, придется основательно поковыряться.

Возможным источником проблемы может быть превышение числа запрашиваемых регистров. По документации, с контроллера нельзя запрашивать более 255 бит (для битовых регистров) и более 120 слов (для остальных типов регистров) в одной транзакции Модбас. То есть, если в конфигурации ОРС-сервера существует, например, ряд регистров начиная с нулевого, и заканчивая 149-м, получаемые операцией 0x03, OPC-сервер может сделать в соответствии с протоколом Модбас один запрос следующего содержания:
"Команда 0х03, регистр 0, количество регистров 150"
...ожидая получить в ответ в одном фрейме Модбас 150 слов, содержащих значение всех этих регистров
У OPC-сервера Модбас обычно существует настройка такой оптимизации запросов - предельное количество запрашиваемых подряд регистров. Если в ваших новых OPC-серверах этот параметр превышает 120 слов, могут быть труднопредсказуемые проблемы. (Если не ошибаюсь, на скриншоте в посте CHANt этот параметр установлен в 122)

Таким образом рекомендации следующие.
1. Проверить описанную выше настройку ОРС. Если не помогает, попробуйте следующее.
2. Выясните, включение каких конкретно ОРС-серверов вызывает сбой обмена. Допустим, сервер на машине с Genesis - это №1, два новых - №2 и №3. Когда работает только №1, очевидно, проблема не наблюдается. Но при каком минимальном числе включенных серверов проблема появляется? Если, скажем, глюк возникает при включении одного только №2 (№1 и №3 отключены), то проблема однозначно в конфигурации №2.
3. Если и это ничего не дает, возможен глюк ОРС-сервера. Попробуйте ОРС-сервер другого производителя. Очень хорошо зарекомендовал себя сервер KEPware OPC с набором драйверов под протоколы Modicon. Софтина не бесплатная, но в демо-режиме можно непрерывно работать 2 часа - достаточно чтобы определить, повторится глюк или нет.
4. Наконец, не исключен глюк таргета ISaGRAF (в терминологии ICP - драйвер ISaGRAF). Выясните, какая версия драйвера у вас (подключаемся к СОМ1 контроллера, запускаем фирменную терминальную программу, включаем контроллер с подключенной перемычкой Init, выполняем следующую команду: isa *p= . Последняя версия на данный момент 4.12, в ней могли быть пофиксены какие то глюки, связанные с реализацией Modbus TCP Slave. Однако при отсутствии проекта Isagraf обновлять придется на свой страх и риск. У меня проект при обновлении драйвера не повреждался ни разу, но 100% гарантию его сохранности дать не могу.

2 CHANt
Таймаут в настройках ОРС-сервера означает предельное время ожидания ответа слейва на запрос мастера. Сбой при слишком малом таймауте выражается в отсутствии данных, а не в их искажении (мастер выставляет признак недостоверности ОРС-переменных, просто не дождавшись ответа слейва). С другой стороны, каких только косяков в ПО не бывает...