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

Здравствуйте!

Никак не получается установить коннект из ПЛК-150 к ПК. Вот код:

CASE step OF
0:
sock:=SysSockCreate( SOCKET_AF_INET, SOCKET_STREAM, SOCKET_IPPROTO_TCP);

sock_adr.sin_addr:=16#6C01A8C0; {192.168.1.108 - IP ПК}
sock_adr.sin_family:=SOCKET_AF_INET;
sock_adr.sin_port:=5001;

sc := SysSockConnect( sock, ADR( sock_adr ), SIZEOF( sock_adr ) ); {sc = -1}

step:=1;

1:
tmr(IN:=start_TON,PT:=t#5s);
IF NOT start_TON THEN
start_TON:=TRUE;
END_IF
IF tmr.Q THEN
my_buf[0] := 5;
res:=SysSockSend(sock, ADR( my_buf ), SIZEOF( my_buf ), SOCKET_MSG_OOB );
start_TON:=FALSE;
END_IF
END_CASE

IP ПЛК - 192.168.1.205
Со стороны ПК пишу на Delphi 7 использую TServerSocket и уверен, что всё правильно.
Что я делаю не правильно?

с сокетами ни когда не пробывал ...

Но зачем такой тюнинг в зоопарке??? есть более простые способы конекта с плк ...
или со стороны ПК не форточки?

А остальные пляски, типа бинд кто делать будет?

SysSockConnect - возвращает -1 - значит ошибка.

Сам разобрался. Основные проблемы были со стороны ПК.

По ответам:

K.I.V.: Со стороны ПК будет многпоточный TCP-сервер. Под форточкой или нет - пОфигу.

Филоненко Владислав: Типа Бинд оказался не при делах. Без него всё работает.

Есть некий "стандарт" установления соединения и если у Вас так удачно совпали дефолтные установки и Bind не понадобился - это не значит, что в сл. раз все заработает.

Здравствуйте, многоуважаемые! Попробовал пример веб-сервера для ПЛК150I-M. Не хочет, зараза! Перезагружается! Прошивка 2.10.4, как пишет PLCInfo (хотя программа перепрошивки вроде должна лить 2.10.5, судя по заголовку). Максимум чего я добился - ответа "Cannot open this file" в браузере, когда в контроллере не было файлов. Залил весь контент, запрашиваю http://<ip>/index.html - и контроллер начинает перезагружаться. Причем циклически, хотя загрузочного проекта нет...
А в debug.txt пишет

Цитата:

---

2009.11. 9 17:13:11 # 17 E Power is recovered too late!

---

Причем здесь power?!
Характерно, что со всеми другими проектами запускается на ура...

Пришлите ваш проект, к-й так себя ведет, лог и дебаг txt, лог гипертерминала и файлы таргета из каталога C:\CoDeSys\Имя вашего ПЛК\

Цитата:

---

Не хочет, зараза! Перезагружается! Прошивка 2.10.4, как пишет PLCInfo (хотя программа перепрошивки вроде должна лить 2.10.5, судя по заголовку). Максимум чего я добился - ответа "Cannot open this file" в браузере, когда в контроллере не было файлов. Залил весь контент, запрашиваю http://<ip>/index.html - и контроллер начинает перезагружаться. Причем циклически, хотя загрузочного проекта нет...

---

точь в точь мои танцы с бубнами....
http://www.owen.ru/forum/showthread.php?t=6183
скачал прошивку 2.10.7 в архиве 2.10.5 которая на поверку оказалась 2.10.4
залил в контроллер и понеслась
ЗЫ может на сайте ссылки поправите?

Не знаю насчет прошивки, пока выяснил следующее: жалобы на питание возникали, вероятно, из-за непонятных токов между интерфейсами, контроллер был одновременно подключен к ПК через RS232 и к хабу, как только в определенные моменты стал выдергивать один кабель, циклическая перезагрузка прекратилась. Теперь только по ethernet, правда, все равно очень странно себя ведет, перезагружается очень часто, но тут я связываю пока вот с чем:
1. Кривой пример сервера, не отслеживается переполнение буфера, выход за пределы выделенной памяти и т.п.
2. Очень-очень интересная библиотека SysLibSockets, про которую не единожды сказано, что за более подробной документацией - пожалте к справке ОС, которую я пока нигде не сумел отыскать. Так вот решительно непонятно, чего такого должны возвращать эти веселые функции. Попробовал сразу поставить контроль на возвращаемые значения - программа постоянно переходит в состояние ошибки, т.к. результаты возвращаются вроде как аварийные. Убрал контроль - не смотря на аварийные результаты, все заработало.
Однако если при перезагрузке контроллера ethernet-кабель включен в контроллер, начинается циклическая перезагрузка. Стоит выдернуть кабель и дождаться, когда загорится "работа" - тогда вроде все стабильно, включаешь кабель - и погнали работать более-менее.
Сдается мне, что просто в определенный момент сокет действительно не открывается, и дальнейший bind просто рушит программу. Однако совершенно не понятно, как же анализировать результат, возвращаемый функциями из SysLibSocket. Они ВСЕГДА возвращают аварийные значения, а работают, по видимому, когда нравится.

magirus, так я не понял, после скачки прошивки "понеслась" - это значит "все заработало нормально" или "начались танцы с бубном"? И действительно, у меня аналогичное подозрение, что косяк на самом деле с прошивкой. Граждане разработчики! Потрудитесь если уж не выложить современные прошивки, то хотя бы уж исправить всю эту свистопляску с номерами версий!

начались танцы с бубном.
у меня сейчас два контроллера
причем с самописной программой, (небольшой) без использования веб сервера, но с прошивкой 2.10.4 перегружаются циклически при вставленном в RS debug порт кабеле
кстати идея Ваша на счет эзернета, попробую перепрошить через эзернет, залив прошивку на диск....

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 и привязывайтесь.

Цитата:

---

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

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

---

Не совсем понял, вы имеете в виду "Системные события" и события before_reset, after_reset? Хм. Они действительно срабатывают при online-change (сиречь при перезаливке)?

Цитата:

---

Magirus, качайте, пробуйте

---

я дома с ФТП слил и перезалил прошивку, перегрузы прекратились.... , на работе перекрыт ФТП, (уж в целях какой безопасности, не знаю....)

Цитата:

---

Сообщение от magirus

на работе перекрыт ФТП, (уж в целях какой безопасности, не знаю....)

---

а не на одном ли предприятии мы с Вами работаем?... В стальном сердце страны?

именно эти события.
но я настоятельно рекомендую использовать статическую память.

Вопрос по некорректной работе библиотеки SisLibSockets.
Имеется скачанный с сайта пример реализации Клиент-Сервер для TCP соединения. Написан для контроллера Win NT .Работает прекрасно между двумя компами.Также можно тестить на одном компьютере,обращаясь клиентом к своему же адресу.
Попытка перенести пример на ПЛК100КМ с прошивкой 2.10.7 оказалась неудачной. После замены библиотеки SysLibSockets на аналогичную для ПЛК и замены целевой платформы на ПЛК100, сервер перестал включаться и клиент не цепляется. Пока удалось обнаружить , что при обращении к SisSockListen, ответ
всегда FALSE. Возможно и другие функции библиотеки работают с ошибками? Как работать с библиотекой , время на эксперименты утекает рекой...Видимо ПЛК100 не адаптирован к данной библиотеке или наоборот ? Прошу посоветовать, как перенастроить пример под ПЛК100.

Цитата:

---

Сообщение от Евгений_Томск

SisSockListen, ответ всегда FALSE. Возможно и другие функции библиотеки работают с ошибками?

---

Увы, это ее нормальное поведение, она всегда возвращает FALSE, даже если все успешно. Остальные функции так же не любят информировать программиста об успешности или неуспешности своего выполнения. :mad:
Более того, эти функции по-разному отвечают в режиме эмуляции и в контроллере, обратите на это внимание.

Дело в том, что в рамках концепции ПЛК - жесткий контроль за ресурсами классический подход, когда Вы функцией listen получаете доп. сокет при установлении соединения - не работает. 1 соединение-1 сокет, не больше и не меньше.
Соответственно создаете сокет и дальше просто ждете, когда начнут приходить данные (или сами начинаете передавать). Анализируя ответ функций чтения/записи и код посл. ошибки Вы и можете определить, есть соединение или нет.
Такой подход гарантирует, что вне зависимости от числа входящих соединений у Вас всегда для каждого требуемого сервиса будет нужное число сокетов.

Уточните, пожалуйста: listen просто не нужна (можно не вызывать, все будет работать и без нее), или ее нужно вызывать в любом случае, и просто игнорировать ее результат?

рекомендую вызывать. так будет совместимость с режимом симуляции.