"Зависание" modbus TCP ПЛК 110-60

[Ангелина]

Добрый день! Имеется ПЛК 110-60. Реализована передача данных ПЛК (master) - Lectus (slave), Modbus TCP. В случае, когда Lectus не отвечает, ПЛК выдает ошибку 84 (Last error) и перестает обращаться к Lectus. "Work mode" - "By command". Помогает только перезагрузка ПЛК.
В чем может быть причина? Как победить это "зависание" Modbus TCP?
Всех с наступающим! :)

[Филоненко Владислав]

А команды посылаете?

[krollcbas]

Ангелина, всегда в подобных ситуациях стоит обращать внимание на детали.
Например:
Как проложен кабель?
Какая марка кабеля?
Метраж?
Как обжат?

Стоит вынести ПЛК временно из того места где он стоит и соединить с чем-то еще, например Modbus Pool или какой-то другой OPC.
Возникает ощущение, что опрос идет с большим количеством ошибок. Драйвер ПЛК уверен имеет какой-то лимит на "неответы"
Попробуйте для выяснения причины что-то менять местами, вычленять проблему.
Проект стоит выложить, приложить скрин с ПЛК браузер о сетевых соединениях.

Чтобы устранить причину ее надо сначала найти.

[Филоненко Владислав]

И самое главное лог снифера прикладывать. Там будет видно кто запрашивает а кто не отвечает и есть ли соединение

[Ангелина]

Спасибо большое за ответы!
Команды посылаю.
К сожалению, проект и скрин ПЛК-браузера сейчас скинуть не могу. Новогодние каникулы, всё на работе. Позже обязательно прикреплю!
По поводу кабеля.. Конфигурация проекта такова: ПЛК, Панель оператора, модуль МВ110 на 8 аналоговых входов. Модуль подключен к ПЛК по RS-485. ПЛК master, модуль slave. Сначала при опросе модуля также возникала подобная проблема. Если опрос модуля единожды возвращался тайм-аутом, то опрос модуля прекращался вовсе. Посадили на RS-485 "шпиона" и увидели, что ПЛК просто ничего не отправляет, хотя команда на отправку есть. Эту проблему решила программным путем. Такие же изменения внесла и в код программы где осуществляется опрос по TCP, но это не помогло. По Ethernet с ПЛК также общается панель оператора. Связь между панелью и ПЛК работает стабильно. Была мысль, что мешает панель. Попробовала поменять порт по которому ПЛК общается с OPC. Не помогло.
Я понимаю, что без кода и скринов посоветовать мне что-то сложно. Как говорится "пальцем в небо". После праздников подготовлю все необходимое и прикреплю!
С Новым Годом! :)

[Филоненко Владислав]

По зависанию обмена - при обнаружении проблемы залогиньтесь на контроллер, остановите программу и пользуясь снифером и PLC Configuration вручную поотправляйте команды.

[Ангелина]

По аналогии нужно смотреть, если панель общается с плк по периодичному опросу, то зачем заставлять плк работать по команде а не по времени?
Команда на отправку данных ПЛК выдается с определенным периодом. По сути, никакой разницы нет. Т.е. можно считать, что передача работает по времени, просто это реализуется программным путем.


Ангелина, всегда в подобных ситуациях стоит обращать внимание на детали.
Например:
Как проложен кабель?
Какая марка кабеля?
Метраж?
Как обжат?

Стоит вынести ПЛК временно из того места где он стоит и соединить с чем-то еще, например Modbus Pool или какой-то другой OPC.
Возникает ощущение, что опрос идет с большим количеством ошибок. Драйвер ПЛК уверен имеет какой-то лимит на "неответы"
Попробуйте для выяснения причины что-то менять местами, вычленять проблему.
Проект стоит выложить, приложить скрин с ПЛК браузер о сетевых соединениях.

Чтобы устранить причину ее надо сначала найти.

Конфигурация ПЛК:
46610
46611
46612

Листинг программы (ConnectAndSend) (часть программы, отвечающая за отправку данных):

(* Минимальное время цикла ПЛК 10 мс *)

TimConnect := TimConnect + 1;

CASE ConnectCykl OF
0:
IF (MMDDFromArch <> 0) OR (HHMMFromArch <> 0) THEN
TimConnect := 0;
ConnectCykl := 1;
END_IF

1:
(* Вырезала кусок кода. Заполнение массива на отправку. *)

RStart := 255;
StrO_u:=255;
MLerr:=0;
TimConnect:=0;
ConnectCykl:=2;

2:
IF (TimConnect >= 1300) THEN
ptw := ADR(StrI);
ptw^ := 65535;
RStart := 255;
StrI_u := 255;
MLerr:=0;
StrIDone := FALSE;
ConnectCykl:= 3;
TimConnect := 0;
END_IF

3:
IF NOT(StrIDone) THEN
ptw := ADR(StrI);
IF (ptw^ <> 65535) THEN
StrIDone := TRUE;
END_IF
END_IF

IF (StrIDone) THEN
ConnectCykl:= 4;
TimConnect := 0;
ELSE
IF (TimConnect >= 1000) THEN
ConnectCykl := 0;
TimConnect := 0;
END_IF
END_IF

4:
IF (TimConnect >= 100) THEN
ConnectCykl := 5;
TimConnect := 0;
END_IF

5:
ptwi := ADR(StrI) + 16;
IF (idSent = ptwi^) THEN
ptwi := ADR(StrI) + 6;
IF (ptwi^ > 0) THEN
IF (ptwi^ > (cur_hour * 100 + cur_min)) THEN
IF ((ptwi^ - (cur_hour * 100 + cur_min)) > 2) THEN
ptwi := ADR(StrI);
Par1 := ptwi^;
ptwi := ptwi + 2;
Par2 := ptwi^;
ptwi := ptwi + 2;
Par3 := ptwi^;
ptwi := ptwi + 2;
Par4 := 30;
Par5 := ptwi^ / 100;
Par6 := ptwi^ MOD 100;
SetDateTime();
END_IF
IF (((cur_hour * 100 + cur_min) - ptwi^) > 2) THEN
ptwi := ADR(StrI);
Par1 := ptwi^;
ptwi := ptwi + 2;
Par2 := ptwi^;
ptwi := ptwi + 2;
Par3 := ptwi^;
ptwi := ptwi+2;
Par4 := 30;
Par5 := ptwi^ / 100;
Par6 := ptwi^ MOD 100;
SetDateTime();
END_IF
END_IF
END_IF
ConnectCykl:=6;
TimConnect:=0;
ELSE
ConnectCykl := 7;
TimConnect := 0;
END_IF

6:
MMDDFromArch := 0;
HHMMFromArch := 0;
(* Вырезала кусок кода. Обнуление массива на отправку. *)
ConnectCykl := 7;
TimConnect := 0;

7:
IF (TimConnect >= 100) THEN
ConnectCykl := 0;
TimConnect := 0;
END_IF

END_CASE

[Валенок]

п2... 13сек ....п3 - норм ?

[Ангелина]

п2... 13сек ....п3 - норм ?

Да. Это ожидание перед отправкой команды на считывание с OPC. Считываем специальный регистр с OPC, который говорит об успешной (или нет) записи полученных данных в БД. Эта задержка связана с загруженностью OPC сервера и большим количеством запрос в БД. 13 секунд вполне достаточно для считывания корректного признака. В общем это внутренние особенности организации передачи данных и это нормально.

[Филоненко Владислав]

Ок. Сокет через конфигурацию. Может он сам как-то переоткрывается (и коряво) при отсутствии запросов за такой период ? Не знаю, но допускаю. Можно проверить на большей частоте. Например 1..2 сек.

Если ОПС не держит соединение (посылкой/ответом на keepalive пакеты), то в течении 5-6 секунд ПЛК производит реконект к ОПС.
В общем нужен лог снифера

[Ангелина]

Ок. Сокет через конфигурацию. Может он сам как-то переоткрывается (и коряво) при отсутствии запросов за такой период ? Не знаю, но допускаю. Можно проверить на большей частоте. Например 1..2 сек.

Вы имеете ввиду эту настройку?
46616
Если да, до без не опрос вообще не работает. Возможно, порт можно определять и открывать по другому, но я пока не знаю как. Просто в основном работаю с другими ПЛК. С ОВЕНом работаю впервые.


Если ОПС не держит соединение (посылкой/ответом на keepalive пакеты), то в течении 5-6 секунд ПЛК производит реконект к ОПС.
В общем нужен лог снифера

Поняла. Как согласуют отладочные работы, запущу снифер и прикреплю лог.

Просто IT-шники смотрели на стороне нашего сервера. Запросы от ПЛК не приходили, а команда ПЛК на отправку подавалась согласно алгоритму.

[Филоненко Владислав]

Вы имеете ввиду эту настройку?
46616
Если да, до без не опрос вообще не работает. Возможно, порт можно определять и открывать по другому, но я пока не знаю как. Просто в основном работаю с другими ПЛК. С ОВЕНом работаю впервые.



Поняла. Как согласуют отладочные работы, запущу снифер и прикреплю лог.

Просто IT-шники смотрели на стороне нашего сервера. Запросы от ПЛК не приходили, а команда ПЛК на отправку подавалась согласно алгоритму.

И ручками проверьте, подавая команды при остановленной программе

[Ангелина]

Чем обоснуете что команда - подавалась ? Пока на уровне - "мамой клянусь, да" За пределами картинок много чего может быть.

Вы меня, конечно, извините, но если я сижу в режиме «Онлайн» и вижу, как в управляющих регистрах (в данном случае – RStart, StrO_u и StrI_u в зависимости от того, что сейчас инициируется (запись или чтение) появляется значение 0x00FF, то я берусь утверждать, что команда все-таки подается. Если у вас есть какие-либо другие способы проверки того, что команда ПЛК на отправку подается, прошу поделиться ими со мной.

Дополнение:
Есть четкая логика программы, есть кейсы. Я вижу, как происходит переход из кейса в кейс. Все работает исправно ровно до того момента, как один из запросов к OPC возвращается тайм-аутом. Дальше всё - ступор по обращению к OPC. Но переход по кейсам осуществляется, управляющий сигнал подается. Если бы имело место быть зависание программы - происходил бы перезапуск ПЛК. Стоит учесть, что этот же самый код исправно работает при передаче по интерфейсу RS-232.


И ручками проверьте, подавая команды при остановленной программе

Да, я проверю. Лог прикреплю. Спасибо!

[Ангелина]

Да да, спасибо. Увидела, что не тот лог прикрепила. Исправлю.