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

[Yury Evgenev]

Увидел пометку о возможности программирования ПЛК110 под CDS3.
Это обозначает полный переход ПЛК110 под CDS 3? или как то будет реализована возможность выбора?
Очень не нравиться работа с библиотеками в CDS3 для ПЛК304 - ужасно.
Конфигуратор в CDS2.3 гораздо приятнее.

Развейте мои страхи. Ядро CDS3 встроено в чип ПЛК или насажено поверх Linux как в ПЛК304?

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

Возвращаемся в эфир.
ПЛК110 новый сейчас будет на платформе CODESYS 2. В дальнейшем, как тенденцию, планируем переводить на CODESYS 3. Он уже будет, с большой вероятностью, с Linux. Но для пользователя это будет оставаться так-же не сильно заметно.
По состоянию дел на данный момент.
Открытые продажи приборов начнутся уже на следующей неделе.
Но, к сожалению, модификации появятся не все и не сразу.
ПЛК110-24.30.Р-М. С них мы начнем.
ПЛК110-24.60.К-М. Планируются к концу октября.
Остальные - позже.
В первых числах октября проведем вебинар, на котором расскажем что да как. В чем отличия и пр. Следите за новостями.

[_Pavel_]

Товарищи, подскажите пожалуйста:
Тестирую обмен данными через сокеты на новом ПЛК110. Скорость работы с сокетами конечно ломовая по сравнению с ПЛК150. Делаю такой тест: с компьютера-сервера посылаю команды (36 байт) контроллеру-клиенту в непрерывном цикле, на которые контроллер отвечает пакетами по 239 байт. Min время цикла ПЛК = 2 мс. Вызовы SysSockSend и SysSockRecv разнесены по разным циклам и чередуются (при наличии пакета для передачи). Когда количество таких циклов превышает 18 (т.е. передано более примерно 4кБ данных), прекращается передача данных со стороны контроллера, при этом функция SysSockSend корректно возвращает количество переданных байт, но сервер ничего не видит. При этом данные от сервера до контроллера доходят. Далее, через 20 сек. сервер закрывает соединение и после переподключения контроллера передача данных возобновляется. В связи с этим у меня вопрос: правильно я понимаю, что в моём случае происходит переполнение буфера отправки сокета? Почему передача не восстанавливается за 20 секунд таймаута? С какой максимальной скоростью ПЛК110 способен передавать данные через сокеты?

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

Хотелось бы посмотреть на программу, удалённо ничего сказать не могу. Та же связь по GetWay генерирует значительно больший трафик чем в описанном тесте и такого поведения не наблюдается.
P.S.

с компьютера-сервера посылаю команды (36 байт) контроллеру-клиенту

- клиент и сервер не перепутаны местами в описании?
P.P.S. Какая версия ПО? - если 0.2.24 - то тестирование на 0.2.24 не имеет смысла, т.к. с тех пор проведен огромный комплекс работ по тестированию, отладке и настройке ПО.

[_Pavel_]

- клиент и сервер не перепутаны местами в описании?

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

P.P.S. Какая версия ПО? - если 0.2.24 - то тестирование на 0.2.24 не имеет смысла

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

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

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

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


Да, версия ПО именно 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 корректно получает данные. Помогает закрытие-открытие сокета на контроллере: обмен тутже восстанавливается.

[_Pavel_]

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