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

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

Нет, всё правильно у нас реализована событийная модель обмена, и клиент и сервер могут отправлять сообщения в произвольный момент времени, ожидая ответа или нет.


Да, версия ПО именно 0.2.24, эта версия последняя что публиковалась в этом топике, если я ничего не пропустил... А где взять последнюю?

Часть проекта во вложении

1. Последнюю версию ПО можно запросить в нашей техподдержке + она должна появится на сайте.
2. Обязанность клиента (в терминологии стека ТСP) поддерживать соединение, постоянно передавая пакеты, иначе сработает таймаут.
3. Таймауты на повтор пакетов у Вас великоваты - 3 секунды - поставьте 1.
3а. Таймаут должен отсчитываться во всех состояниях с установленным соединением.
4. В программе ожидается определённое количество байт и считываются только они - если придёт лишний - он никогда не будет считан и буфера закончатся Правильно - всегда считывать все данные из сокета до момента возврата нуля в ответе SySSockRecv(). Иначе будет вышеописаное.
5. По задачам - за 1 цикл ПЛК способен выполнить только 1 задачу, даже если ещё 20 уже заждались очереди. Т.о. если я правильно расшифровал текстовые поля в описании задач - (лучше бы проект .pro прислали чтобы не мучится), то у Вас множество задач по событиям (т.е. возможно каждый цикл будут вызываться) и MainTask в режиме свободного вызова (крайне не рекомендую на CoDeSys 2 Embedded, ведёт себя непредсказуемо).
При такой конфигурации период вызова MainTask не определён. Попробуйте вычленить коммуникационную часть и с учётом рекомендаций 3 и 4 проверить в монопольной задаче.

[_Pavel_]

Владислав, спасибо за ответ!

1. Последнюю версию ПО можно запросить в нашей техподдержке + она должна появится на сайте.

Хорошо, попробую запросить.

Обязанность клиента (в терминологии стека ТСP) поддерживать соединение, постоянно передавая пакеты, иначе сработает таймаут.

Да, я это знаю. Только у нас это немного не так реализовано: при подключении клиента сервер начинает посылать раз в секунду специальные пакеты (PulsePacket), на которые клиент сразу же отвечает. Если сервер не получит хотя бы один из этих пакетов в течении определённого времени (20 сек), он закроет сокет.

3. Таймауты на повтор пакетов у Вас великоваты - 3 секунды - поставьте 1.
3а. Таймаут должен отсчитываться во всех состояниях с установленным соединением.

Таймаут в 3 секунды здесь задан как раз для контроля Pulse-пакетов от сервера, если в течении 3-х секунд мы не получили от сервера Pulse-пакет или вообще чего-нибудь, то мы закрываем сокет и переподключаемся.

4. В программе ожидается определённое количество байт и считываются только они - если придёт лишний - он никогда не будет считан и буфера закончатся Правильно - всегда считывать все данные из сокета до момента возврата нуля в ответе SySSockRecv(). Иначе будет вышеописаное.

Не совсем так: чтение происходит в несколько этапов:
1. Читаем шапку пакета (4 байта) в которой мы должны распознать принадлежность пакета и считать его размер. (это заложено в нашем протоколе)
2. Запускаем процедуру обработки пакета, которая считывает из сокета определённое количество байт, указанное в шапке, далее идёт разбор пакета и выполнение определённых действий.
3. Далее мы повторяем вышеописанные действия, проверяя нет ли ещё данных в сокете. Завершаем цикл при выполнении одного из условий: чтение сокета вернуло 0, либо кончилось количество попыток. Может быть в этом и есть ошибка: я должен обязательно дочитать все данные до 0... Я ограничил количество попыток 5-ю, дабы потенциально не раздувать время цикла.

5. По задачам - за 1 цикл ПЛК способен выполнить только 1 задачу, даже если ещё 20 уже заждались очереди. Т.о. если я правильно расшифровал текстовые поля в описании задач - (лучше бы проект .pro прислали чтобы не мучится), то у Вас множество задач по событиям (т.е. возможно каждый цикл будут вызываться) и MainTask в режиме свободного вызова (крайне не рекомендую на CoDeSys 2 Embedded, ведёт себя непредсказуемо).

Да, событийных задач довольно много: срабатывание каждого дискретного входа ПЛК, задний фронт. Одна циклическая задачка 3 раза в секунду. Но, относительно времени цикла ПЛК ( не более 0,7 - 1,2 мс судя по модулю статистики), эти события ооочень редки,а выполняются они ооочень быстро, поэтому при временных расчётах ими вообще можно пренебречь. То есть ситуация когда событийные задачки будут вызываться каждый цикл абсолютно исключена. Т.о. коммуникационная часть выполняется максимально часто. Т.е. насколько я понял в моём случае нужно ставить минимальное время цикла в ноль.

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

Есть ли лог снифера?
Чтобы мне погонять программу - нужен проект (можно по почте прислать), т.к. экспортный файл импортируется с ошибками.
И ответная часть - сервер на ПК.

[_Pavel_]

Пробовал посмотреть: может какая ошибка сокета появляется с помощью ФБ SysSockGetLastError, но он почему-то bDONE никогда не бывает TRUE. Правильно я применяю этот ФБ?

SysSockGetLastError(bEnable := TRUE, diSocket := udiSocketHnd);
IF SysSockGetLastError.bDone THEN
dwSockLastError := MAX( dwSockLastError, SysSockGetLastError.dwLastError); SysSockGetLastError(bEnable := FALSE);
END_IF;

Программу могу выслать, но вот серверную часть... Вы её врядли сможете запустить, т.к. она запускается из под DOSа весьма не тривиальным способом. Сниффера под dosом нет. Претензий к серверной части у меня нет, она давно уже отлажена и работает. Причём штатно она ворочает довольно большими объёмами строковой информации.

Отмечаю ещё один интересный факт: наш протокол предусматривает отправку сообщений серверу о событиях, происходящих на контроллере, а также ответные сообщения на команды сервера. Так вот если я эти сообщения передаю отдельными пакетами (~40 байт) в разных циклах то проблема с "умиранием" SysSockSend на контроллере появляется гораздо позже, чем если я склеиваю несколько этих событий в один пакет (200 - 500 байт) и вызываю SysSockSend. Такое ощущение, что я переполняю некий буфер у сокета и он из этого состояния не может выйти без переподключения.

Ещё раз формулирую проблему: при интенсивном обмене данными через сокеты возникает такой момент когда SysSockSend корректно возвращает количество переданных байт, но реально сервер их не получает, при этом SysSockRecv корректно получает данные. Помогает закрытие-открытие сокета на контроллере: обмен тутже восстанавливается.

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

1. SysSockGetLastError не поддержана
2. буфера разного размера в разном количестве, маленьких больше. => что то не дочитывается.
3. Лог можно снять используя хаб и другой комп.
4. Ну и прошивку выложу на всякий, не факт что она на тестовых ПЛК запустится, но можно попробовать.

[_Pavel_]

Попробовал этот же код на ПЛК150, проблемы с SysSockSend не наблюдал, при аналогичном тесте соединение живёт, однако если при дальнейшем очень интенсивном обмене 150-ый вообще уходит в ребут

[_Pavel_]

2. буфера разного размера в разном количестве, маленьких больше. => что то не дочитывается.

проверял эту гипотезу, оставлял чтение сокета до нуля - не помогло.

4. Ну и прошивку выложу на всякий, не факт что она на тестовых ПЛК запустится, но можно попробовать.

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

[Звучный Телефонист]

Однозначно, 150-й работает исправнее. Попробуйте прошивку. Должна помочь.

[_Pavel_]

Когда можно будет сделать заказ обновлённый контроллер?

[Николаев Андрей]

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