Lectus + >10 Овенов

[Ушаков Николай]

да, в офисной сети, один контроллер у меня тоже работает без проблем. в проблемной сети 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 никакой задержки нет - контроллеры отвечают сразу
спасибо за помощь

log_lectus.JPG

[asutp]

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