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

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

SysLibSockets сделана максимально (насколько это возможно для ПЛК) по образу и подобию сокетов в Windows (www.msdn.com).

перегружаются циклически при вставленном в RS debug порт кабеле - при большой разнице между потенциалами земель (а с компьютерами это регулярная болезнь) и ПЛК до 2008 года, когда в верхней плате не было опторазвязки, отмечались случаи перезагрузок ПЛК, а также отгорания 232 портов на компьютерах, особенно при включении "на ходу". Для справки - 232 не Plug&Play интерфейс.
В таких случаях мне помогало заземление корпуса компьютера или работа исключительно по Ethernet, а при перепрошивке - отключения аналоговых входов, т.к. они гальванически связаны с портом Debug 232.

З.Ы. Все же хотелось бы взглянуть на Ваш проект.

[0xBA0BAB]

если речь про мой проект - да ради бога. проект в процессе.

ух намучался я с ним... елки-палки... никак не отлажу. постоянно перезагружается. начниаешь пошагово делать - вроде все нормально, а потом - хлоп и на ровном месте валится.
обратил еще внимание, что он несколько раз циклически перезагрузится, а потом нормально вроде работать начинает. в принципе, не перезагружается циклически, если кабель эзернета выдернуть на время перезагрузки. загрузочного проекта нет никакого.
версии как всегда - 2.10.4 в контроллере, соответствующие таргеты в кодесисе.
В debug.txt продолжает писать что-то про power...

[0xBA0BAB]

обратил внимание, что если ничего не трогать, контроллер без загрузочного проекта перезагружается раз 5-7, а потом вроде как работает...

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

Странно, что ПЛК работает-то.
Это не ПК, тут нет гектаров памяти и гигагерцовых процессоров.
Тут есть 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, качайте, пробуйте, на первый взгляд вполне работоспособно.

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

В четвертой вкладке есть пункт Events.
Там и старт, и стоп и reset. Вот к reset и привязывайтесь.