Обновленный ПЛК110?

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

Предполагается, что перемычка при штатной эксплуатации не потребуется.

Дмитрий, проектик и серверную часть пришлите, погоняем.

[tsda]

Так как подключение по Modbus TCP через конфигуратор для моей задачи не подходит, попробовал запустить на контроллере Modbus TCP сервер. С прошивкой 0.42, после старта контроллер судя по всем признакам сразу переходит в режим постоянного перезапуска. Перепролошился на 0.43. После старта ПЛК один раз перегружается и выходит в стоп. "Колбасится" перестал. Как найти причину такого поведения ПЛК не знаю, так как связь с контроллером сразу пропадает, он сам перезапускается и в нём очищается память. С таким мазахизмом я еще не сталкивался, хотя работаю с CODESYS c 2012 года. Тестовый проект до этого запускал на разных контроллерах других фирм. Нигде проблем не было. На всякий случай версия под PLCWinNT. Можно проверить, там все работает. Единственное различие: в версии для ПЛК исправлена в IP_CONTROL2 строка IF SysSockConnect(socket, ADR(sockaddr), SIZEOF(sockaddr)) THEN на IF BOOL_TO_DINT(SysSockConnect(socket, ADR(sockaddr), SIZEOF(sockaddr))) > -1 THEN
Может быть кто нибудь, сможет мне объяснить, что происходит или выложит пример работающего Modbus TCP.

PLCWinNT_MB_TCP_SERVER.rar
ПЛК110_MB_TCP_SERVER.zip

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

Сокет надо сразу ставить в неблокирующий режим. Пример тут где-то лежал.
А у Вас блокирующий, вот через 4 секунды ожидания связи ПЛК и сбрасывается по Watchdog.

[tsda]

Сокет надо сразу ставить в неблокирующий режим. Пример тут где-то лежал.
А у Вас блокирующий, вот через 4 секунды ожидания связи ПЛК и сбрасывается по Watchdog.

Честно говоря я ничего не понял. Непонятная отсылка на какой то непонятный пример, который тут где то лежит. Мне кажется корректный ответ может заинтересовать многих. Если Вы знаете как легко решить проблему, почему нельзя пример подправить и выложить для всеобщего использования, тем более он полностью сделан на библиотеке OSCAT и не содержит ничего лишнего. Судя по поиску в форуме такая тема обсуждается уже несколько лет и всегда заканчивается "У меня получилось и Вам желаю. Пишите в личку".
Вопрос второй. Почему контролер по Watchdog вместо того, чтобы перейти в СТОП уходит автоматически на перезагрузку и сбрасывает память. Если в контроллере есть загрузочный проект, он как я понял, запускается и еще четыре секунды после перезагрузки успевает поработать. А если ПЛК у меня не на столе, я отлаживаю проект на объекте и к нему подключено реальное оборудование? Если это один из видов исключения, исполнение программы должно остановиться и заблокироваться. Так себя в общем то и ведут контроллеры на CODESYS других производителей и даже СПК вашего производства. От меня может потребоваться ручной сброс программы или перезагрузка, но уходить на автоматическую перезагрузку и при этом сбрасывать память, чтобы я не смог найти причину ошибки .
Честно говоря, я с таким поведением ПЛК за 25 лет работы еще не сталкивался. Можно запатентовать.

[Дмитрий Артюховский]

для TSDA - перед вызовом Accept для сервера, либо Connect для клиента, сокет нужно перевести в неблокирующийся режим -

RES := SysSockSetOption( SOCK, SOCKET_SOL, SOCK_NBIO, 0, 0 ); (* ÏÅÐÅÂÅÑÒ&# 200; ÑÎÊÅÒ Â ÍÅÁËÎÊÈÐ&# 211;ÞÙÈÉÑß ÐÅÆÈÌ *)

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

По второму вопросу - пока вы отлаживаете проект - не делайте загрузочный образ, тогда при собаке вы получите остановку ПЛК (но память конечно все равно слетит), если проект отлаженный - то собака - способ выйти из случайной ошибки алгоритма и восстановить работоспособность установки. циклическая перезагрузка - грубая ошибка программиста и вряд ли это нужно патентовать )))

а примера не было, было только упоминание о данном факте, без описания ужасов связанных с блокирующимися режимами в концепции ПЛК

[_Pavel_]

Вот лог сниффера с проблемой большого (>255 bytes) пакета.
101.71 - PLC110-30-24L с последней прошивкой.
101.111 - Сервер под Win
Один пакт (№8 в сниффере, 9.0972) проходит нормально
следующий большой не проходит и далее все пакеты не идут.

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

Хм. PLC посылает аск на сегмент 1 и свой сегмент №13
И в ответ получает аск на сегмент 13 (правильно) и сегмент от ПК №17???

Т.к. 17-1=16> размера окна (3 или 4 пакета), то он естественно пишет в ответ предыдущие сегменты не получены.
Причем этих пакетов в сети не наблюдается.
Тут ПК уже 28 сегмент шлёт и понеслось.
Что-то тут не так.

Проектик и ПО для ПК то можно увидеть?

P.S. И где тут пакеты больше 255 байт?

[Дмитрий Артюховский]

во вложении кусок кода сервера
RCV_SND_BUF[ 4 ] = 22 - метка "длинного" пакета, если его длина 255 ( пробовал и 220 - тоже глухо ) - то детектор не срабатывает, ставишь длину пакета 200 - проходит... остальные пакеты короче - 100 и 60 байт проходят

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

во вложении кусок кода сервера

(* размер буфера должен быть не менее чем в 4 раза больше чем MSS - типовое значение 8192 *) - Это откуда? Размер буфера MTU+40, MTU=1500. Все что больше - благие пожелания.
А MSS=MTU-40

Окно размером с буфер. Так что даже чтение по 1536 не имеет смысла


IF RCV_SND_BUF[ 4 ] = 22 THEN
DET22 := DET22 + 1;
END_IF
Метка то есть, а где в сети пакеты больше 255 байт?
Самый большой пакет 65 байт?!
А передача вообще по 10 байт данных, т.е. тоже мало.

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

во вложении кусок кода сервера

Попробуйте не задавать размер буферов.
И будут ли передаваться пакеты по 202 и 203 байта?