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

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

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

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

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

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

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

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Код:

---

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

---

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

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

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

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


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

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

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

Код:

---

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

---

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

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

Цитата:

---

Сообщение от Филоненко Владислав

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

---

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

Цитата:

---

Сообщение от Филоненко Владислав

Вещь обыденная, но отлажена ли она? А утечка в Вашей программе есть, и каждый раз по 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.

---

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

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

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