Не удается установить связь по TCP-сокету из ПЛК-150 :(

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

Странно, что ПЛК работает-то.
Это не ПК, тут нет гектаров памяти и гигагерцовых процессоров.
Тут есть watchdog, и если кусок программы работает слишком долго - ПЛК должен перегрузится.
Вопросы по программе:
1. Зачем Вы ДИНАМИЧЕСКИ выделяете куски памяти по 64кБайта? При этом кода для освобождения её при перезаливке новой программы нет.
2. В программе множество обращений по указателю, прямого доступа к памяти, ее копирования и т.п. Тут простор для опечаток. Рекомендую пошагово пройти по программе и проверить ликвидность всех указателей и адресов.
3. При чтении 65кБайт из сокета, функция может возвратить максимум 1,5кБайта, размер 1 посылки. Т.к. запрос бывает и длиннее - его надо собрать из 1 или нескольких пакетов. Хотя бы чтением из сокета до победного конца.

[0xBA0BAB]

Странно, что ПЛК работает-то.

Меня это удивляет не меньше Вашего

Это не ПК, тут нет гектаров памяти и гигагерцовых процессоров.
Тут есть watchdog, и если кусок программы работает слишком долго - ПЛК должен перегрузится.

Это мне известно. Что до сторожевой собаки, то период программы довольно велик, 50мс, и изменение этого параметра на циклическую перезагрузку никак не влияет. Повторю, контроллер перезагружается сам несколько раз в отсутствии загрузочного проекта.

Вопросы по программе:
1. Зачем Вы ДИНАМИЧЕСКИ выделяете куски памяти по 64кБайта?

Если посмотреть внимательно, то реально кусок памяти выделяется один раз. Ну или в нештатных ситуациях - очищается и снова выделяется.

При этом кода для освобождения её при перезаливке новой программы нет.

Я заинтригован... И как отловить момент перезаливки?

2. В программе множество обращений по указателю, прямого доступа к памяти, ее копирования и т.п. Тут простор для опечаток.

Вполне рядовая практика, коль на то пошло... Некоторые вещи гораздо удобнее (и часто гораздо эффективнее) делаются через динамическую память. Как аргумент - примите такое утверждение: другой кусок проекта полностью написан с динамической памятью, используются односвязные списки довольно больших размеров, проблем с утечкой никаких.

Рекомендую пошагово пройти по программе и проверить ликвидность всех указателей и адресов.

В том-то и дело, что все, что было возможно - уже отлажено, а то, что не получилось отладить - не получается по причине непонятных перезагрузок контроллера. Ну грубо говоря, заливаю программу в пустой контроллер. Программа в состоянии "стоп", не запущена. Если ничего не делать, то примерно через 10 секунд происходит перезагрузка контроллера (программа с момента заливки даже не запускалась ни разу!). Если иногда все-таки удается прошагать ее немного, то в самых безобидных местах (где никаких обращений к динамической памяти нету) контроллер перезагружается; а в самых опасных местах порой проходит на отлично, и успеваю убедиться, что нарушений при обращении к памяти нет.
Напомню, я просто пытался адаптировать под свои нужды пример с этого форума. Там, кстати, в оригинале встречается даже такой перл:

SysMemMove(rcv_snd_buf,ADR(header),LEN(header));
(* header имеет тип STRING *)

3. При чтении 65кБайт из сокета, функция может возвратить максимум 1,5кБайта, размер 1 посылки.

Ох как не зря эту тему подняли... Кто бы мог подумать о таком ограничении? Всего лишь полторы недели потребовалось, чтобы догадаться о нем... Жаль, но эта информация припоздала, догадался уже об этом ограничении... То-то я думал, почему отправка идет только по 1536 байт...

Т.к. запрос бывает и длиннее - его надо собрать из 1 или нескольких пакетов. Хотя бы чтением из сокета до победного конца.

Это нам известно, спасибо.

[0xBA0BAB]

Хм... Начало работать гораздо стабильнее, стоило только избавиться от SymLib.lib... Не идеально, но проблем стало меньше. Надеюсь, теперь получится хоть поотлаживать.
Мне SymLib ни к чему в проекте, другой кусок формирует файлы, которые как-то надо забрать с контроллера, так что мне только выдавать файлы...

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

Я заинтригован... И как отловить момент перезаливки? -

Есть события, к которым можно привязаться.


Вполне рядовая практика, коль на то пошло... Некоторые вещи гораздо удобнее (и часто гораздо эффективнее) делаются через динамическую память. Как аргумент - примите такое утверждение: другой кусок проекта полностью написан с динамической памятью, используются односвязные списки довольно больших размеров, проблем с утечкой никаких.

Вещь обыденная, но отлажена ли она? А утечка в Вашей программе есть, и каждый раз по 64*3 кБайта.

Напомню, я просто пытался адаптировать под свои нужды пример с этого форума. Там, кстати, в оригинале встречается даже такой перл:

SysMemMove(rcv_snd_buf,ADR(header),LEN(header));
(* header имеет тип STRING *)

И где тут перл?

Про перезагрузки без программы - такое возможно, если у Вас в сети очень большое число пакетов данных. ПЛК пытается их все обработать и срабатывает Watchdog.
В версии 2.10.7 введена доп. защита от этого и перезагрузки убраны.
Однако, отсутствие перезагрузки не означает, что проблемы нет. Если ПЛК из-за перегрузки не сможет обработать все пакеты, то необработанные будут потеряны.
Мы рекомендуем размещать ПЛК всегда в отдельном сегменте сети и ограничивать поток широковещательных UDP и ICMP пакетов в этом сегменте.

[0xBA0BAB]

Есть события, к которым можно привязаться.

Ладно, пойдем длинным путем. Где можно узнать, что это за события?

Вещь обыденная, но отлажена ли она? А утечка в Вашей программе есть, и каждый раз по 64*3 кБайта.

Вы что-то путаете. В каждом FB-блоке память выделяется ОДИН раз.

SysMemMove(rcv_snd_buf,ADR(header),LEN(header));
(* header имеет тип STRING *)

И где тут перл?

Перл в том, что один участок памяти выделен динамически, а другой - статически, и потому надо не SysMemMove, а SysMemCpy. Хотя бы потому, что дальше в программе вроде как снова идет обращение к строке header. Может, ничего и не будет, но это явно не является признаком хорошего тона. Тем паче что операция копирования здесь просится логически, плюс она быстрее, чем операция перемещения. Если, конечно, после перемещения что-то в старом участке затирается. Хотя, Вам, как разработчику, вероятно, виднее...

В версии 2.10.7 введена доп. защита от этого и перезагрузки убраны.

Там реально версия 2.10.7, а то magirus писал, что под видом 2.10.7 качается 2.10.5, которая реально 2.10.4? Я проверял - ссылка и вправду указывает на 2.10.5...
upd: А, пардон, сейчас вроде исправленная, два дня назад проверял - была кривая.

Однако, отсутствие перезагрузки не означает, что проблемы нет. Если ПЛК из-за перегрузки не сможет обработать все пакеты, то необработанные будут потеряны.
Мы рекомендуем размещать ПЛК всегда в отдельном сегменте сети и ограничивать поток широковещательных UDP и ICMP пакетов в этом сегменте.

Про перезагрузки без программы - такое возможно, если у Вас в сети очень большое число пакетов данных. ПЛК пытается их все обработать и срабатывает Watchdog.

О как... Что ж, буду знать, спасибо.

[0xBA0BAB]

Фух. Попробовал прошивку 2.10.7. Ну наконец-то хоть пошагово все прогнать можно стало... А то вообще проблема была - пара шагов - и ребут. Magirus, качайте, пробуйте, на первый взгляд вполне работоспособно.