Lectus + >10 Овенов

Дорогие форумчане, может, кто сталкивался с такой проблемой - при опросе через Lectus Modbus OPC большого количества контроллеров по Modbus TCP возникают периодические проблемы с качеством связи с контроллерами.
Более подробно: Есть 13 контроллеров, объединенных на свитче в сеть, каждый из них - modbus slave. Из каждого необходимо считывать порядка 20 параметров в режиме modbus RTU. При включении принудительного опроса всех контроллеров у некоторых из них качество переменных - плохое. При нажатии кнопки Refresh все становится отлично, и данные опять считываются, до очередного сбоя. Под сбоем я понимаю неответ контроллера на очередной запрос Lectus - судя по логам Lectus, в определенный момент сервер посылает запрос контроллеру, и в течение 10-ти секунд не получает на него ответ.
Непонятное кроется прежде всего в том, что когда в конфигурации Lectus всего, допустим, 5 контроллеров - все работает стабильно и четко, без каких-либо сбоев. По мере увеличения числа опрашиваемых контроллеров все чаще возникают ошибки. разработчики Lectus ссылаются на то, что Овен не отвечает на запросы.
Вот и не знаю, как быть и кого винить. Если у кого была похожая проблема, прошу поделиться решением.

Цитата:

---

Сообщение от drbril

Вот и не знаю, как быть и кого винить. Если у кого была похожая проблема, прошу поделиться решением.

---

Просим прощения, что оставляем пока без ответа. Необходимо разобраться в ситуации. Скажите какая у Вас прошивка у ПЛК?

Был опыт установки около сотни плк с lectus-ом вроде никаких проблем замечено не было. Единственное были проблемы с временем опроса. Попробуйте установить период опроса побольше. в scada и в самом lectus.

Версии прошивок либо 2.02, либо 2.03, сейчас точно не скажу.
Я ставил в Lectus время ожидания ответа порядка 20 секунд - не помогает. С временем опроса тоже колдовал. Дело в том, что проект недорогой, и SCADA отсутствует, поэтому Lectus используется и в качестве регистратора аварийных сообщений - он пишет значения непосредственно в базу данных. А для этого нужно вести постоянный опрос всех переменных, причем достаточно часто.
Хотелось бы отследить все передаваемые пакеты с помощью, например, PortMon, но связь организована по TCP. Не подскажите, может существуют какие-либо утилиты для этих целей?
P.S. Кстати, такие проблемы со связью у меня наблюдаются на трех объектах, везде стоит чуть больше десятка контроллеров.

Есть пакет pcap - сниффер пакетов ethernet. Если режим командной строки не удобен скачайте ethereal - надстройки над ним c GUI

Спасибо, уже нашел сниффер WireShark - очень удобная штука, да еще и Modbus TCP понимает сам.
Так вот выяснилось следующее(прилагаю еще скриншот лога, т.к. файл специфического формата, надо смотреть этим wireshark'ом).
все идет отлично, осуществляется обмен, пока в 116 строке сетевая карта компьютера не посылает broadcast запрос на поиск выключенного в данный момент контроллера с 12-м IP-адресом. А потом почему-то следует почти 10-секундная пауза, сопровождающаяся только служебными пакетами CISCO.
Я не знаю TCP протокола, но подозреваю, что далее остальные контроллеры посылают компьетеру запросы на завершение соединения(строки 124, 126, 128, 132, 134, 136, 138) - там взведен флаг FIN.
Ну и далее в строках 140, 143, 146... идут пакеты с флагом RESET.

Соответственно есть вопрос к разработчикам ОВЕН - возможна ли ситуация, что контроллеры завершают обмен по таймауту?
Можно ли в прошивке поставить таймаут, скажем, минуту?

P.S. Сначала думал, что дело в циске, что задержки из-за нее. Но потом снял логи на другом объекте - там обычный свитч D-Link - ситуация такая же, задержка порядка 10-ти секунд.

1. Таймаут есть у самого соединения ТСР в соответствии со стандартом. 2. Даже если данные не идут, при установленном соединении клиент и сервер должны обмениваться пакетами без данных для подтверждения активности соединения.
3. Иногда даже на TCP могут быть обрывы, клиент ДОЛЖЕН в этом случае произвести реконнект (что у Вас делает Лектус при нажатии кнопки Refresh). Попробуйте настроить Лектус на автоматический реконект.

Владислав, этот реконнект в Лектусе есть, он в итоге восстанавливает соединение, но не быстро. Я уже сам запутался в логике его работы, у них каждую неделю новая версия выходит сейчас. На сегодня главный вопрос у меня такой - почему в канале возникают задержки порядка 10 секунд? Это наблюдается не только в сети на базе CISCO, но и в обычной, построенной на одном свитче. И на это время прерываются посылки всех пакетов TCP, в том числе и служебных. А переменные хочется опрашивать хотя бы раз в 2-3 секунды.

При тестировании у нас ни при связи с ПК, ни при связи между 2 ПЛК задержек не возникало. Причину без анализа всей системы установить трудно. У вас там какой-нибудь "дикий"сервер кучу UDP broadcast пакетов не шлёт?

на самом деле ситуация следующая - после прохождения ARP пакета(определить MAC адрес по IP-шнику) для узла, который в данный момент недоступен, наблюдается зависание сети, секунд на 10, после чего контроллеры начинают более-менее дружно ресетить TCP соединение. Если же узел доступен, то он отвечает, и никакой задержки не происходит.
получается что после ARP пакета контроллеры начинают выдерживать таймаут?
судя по логам офисной сети(почти 80% траффика - ARP) из-за неотвеченных ARP-пакетов задержек не происходит

т.е. если кто-то пытается послать ARP к выключенному компьютеру, и рядом стоит контроллер - он тормозит?
Если так - у меня на стенде подобного не происходило, хотя он (контроллер) в общефирменной сети и там куча таких мёртвых ARP запросов ходит.

да, в офисной сети, один контроллер у меня тоже работает без проблем. в проблемной сети 12-13 контроллеров и комп диспетчеризации. посмотрите скрин лога, который ранее выкладывал drbril, проходит пакет 116, дальше идут сервисные пакеты циски, но такая ситуация поторяется и в другой такой же сети, но с простым хабом. после пакетов циски, примерно через 10сек, в пакете 124 стоит флажок FIN, я так понимаю, завершение сессии TCP. и дальше несколько контроллеров посылают такие же пакеты(адр компа - 192.168.1.20). а потом, начиная с пакета 140 идут пакеты с флажками RST, видимо перезапуск соединения.
во время этих "перетрубаций" лектусу и плохеет

Из лога следует, что после броадкаста на 12 IP лектус посылает ASK на 11 контроллер и всё. На ASK ПЛК логично не отвечает и все контроллеры №3,4,5,6,7,8,9 - через таймаут выдают FIN. 11 контроллер выдаёт FIN через 12 сек после последнего к нему обращения и самым последним, что логично, т.к. он последним получил ликвидный пакет от лектуса. Другие контроллеры получили ответы ASK видимо раньше и соотв. раньше послали FIN.
Т.о. разрыв соединения со стороны сервера (ПЛК) произошёл из-за отсутствия активности клиента в течении 12 сек.
ARP, ИМХО, не причём.
Сервер сам инициировать обмен не может.
Считать ли таймаут на разрыв 12 сек маленьким - не знаю, для системы реального времени - возможно нужно и меньше ставить

действительно, ARP не виноват, повнимательнее посмотрел логи лектуса - выделенный участок на скрине, отправляется пачка пакетов, и судя по логу, приходят с большой задержкой, хотя в логах Wireshark никакой задержки нет - контроллеры отвечают сразу
спасибо за помощь

Вложение 802

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