Может быть, кому-то будет интересно. Разбор работы функций библиотеки. Описание пока не закончено, но планирую доделать его в ближайшем будущем. Хотелось бы выслушать комментарии и прочие замечания-предложения.
Вид для печати
Может быть, кому-то будет интересно. Разбор работы функций библиотеки. Описание пока не закончено, но планирую доделать его в ближайшем будущем. Хотелось бы выслушать комментарии и прочие замечания-предложения.
Любителям конструкций BOOL_TO_DINT(SysLibSocketFunction()) посвящается..:D
Молодец, классно! Думаю Владислав должен прокомментировать сие..
Самое печальное то, что эту инфу нужно собирать по крупицам по форуму, что усложняет вход новичков и вызывает отторжение у некоторых.
Самое печальное - это то, что подобное, мягко выражаясь, безобразие тиражируется из прошивки в прошивку. При том, что косяки (нет. правильнее КОСЯКИ) видны невооружённым взглядом.
Ау! Владислав!!! Хоть бы спасибо сказали за проделанную работу?
ЗЫ. Большинство этих косяков исправляется элементарно даже в обычном HEX-редакторе, безо всяких исходников. И этот тяжёлый труд в "Овене" не смогли осилить за десяток лет?
Да, кстати, все свои выводы по функциям библиотеки могу подтвердить мелкими программками на CoDeSys.
Чтобы не быть голословным, приведу пример для проверки правильности выводов по первой функции. Ну, где "ошибко":
Вложение 39592
Окно telnet-сервера:
Вложение 39587
Упс?
ЗЗЫ. Описание закончено.
Ещё одна ошибка работы сокетов. Возьмём для примера самую простую программу:
Как Вы думаете, что произойдёт при соединении с этим сервером? Правильный ответ - ничего хорошего. Данные через SysSockRecv не принимаются, ПЛК через примерно 5 секунд после установки соединения уходит в reboot (видимо, по тайм-ауту соединения). Если закомментировать строку с установкой блокирующего режима, то данные через SysSockRecv принимаются, но если в сокет ничего не посылать, то соединение закроется по тайм-ауту (хотя бы без reboot'а - и то хорошо) и повторно с ним соединиться уже не получится.Цитата:
VAR
tcp_adr: SOCKADDRESS;
diSocket: DINT := SOCKET_INVALID;
diParam: DINT := 0;
recv_buf: STRING[250];
res: DINT;
resIoctl: DINT;
first_run: BOOL := TRUE;
counter: DWORD;
END_VAR
IF first_run THEN
diSocket := SysSockCreate(SOCKET_AF_INET, SOCKET_STREAM, SOCKET_IPPROTO_TCP);
resIoctl := SysSockIoctl(diSocket, SOCKET_FIONBIO, ADR(diParam)); (* Включаем блокирующий режим - diParam<>1 *)
tcp_adr.sin_family := SOCKET_AF_INET;
tcp_adr.sin_addr := 16#C0A80135;
tcp_adr.sin_port := 23;
SysSockBind(diSocket, ADR(tcp_adr), SIZEOF(tcp_adr));
SysSockListen(diSocket, 1);
first_run := FALSE;
END_IF
res := SysSockRecv(diSocket, ADR(recv_buf), SIZEOF(recv_buf), 0);
counter := counter +1; (* просто счётчик. посмотреть, работает ли программа *)
Обнаружил я это при изучении неблокирующего режима. Выяснилось, что сокеты работают по умолчанию в неблокирующем режиме, а при попытке его отключения видим то, что видим.
В дальнейшем попробую разобраться, почему это происходит.
Вот это заклинание переводит ПЛК110 М02 в неблокирующий режим
А зачем Вам вообще блокирующий режим?Код:SysSockSetOption( handle, SOCKET_SOL, 16#1014, 0, 0 );
Какой у Вас ПЛК?
замечательное видео разбора полётов с сокетами на примере кодесис 3. отлично описано различие блокирующего и неблокирующего режимов. станет понятно, почему у вас срабатывает ватчдог при работе указанного сервера в блокирующем режиме
https://www.youtube.com/watch?v=ThVLXygHnnU&t=29s
ну есть же поясняющий пример работы с сокетами от S3Software, известны особенности овеновской разработки с булями, но сперва же мастерят код собственного изготовления, а потом жалуются что не работает чегойто
Как уже выше писалось, только ради самопиара поднимает тему в верх списка, чтоб больше народу увидело какой он молодец, дизасемблировал закрытую библиотеку
ЗЫ бибку я тоже выкладывал, повторно загружать не буду
ЗЫЫ ссылка на бибку
Почему бы и не молодец? Народ вот уже лет 10 пытается добиться от производителя вменяемой документации по не самой немаловажной библиотеке. А ещё лучше вменяемой работы этой библиотеки. И? Результат-то где? Ваш example демонстрирует только то, что встроенными функциями пользоваться невозможно. О чём, собственно, я и веду речь.
Да. За "особенности овеновской разработки с булями" отдельное спасибо. Поржал от души.
ЗЫ. "Бибку" тоже хрен где найдёшь. С сайта она уже давно не грузится. А жаль. Хотелось посмотреть..
Хорошее видео. Ничего нового из него не узнал, но спасибо.
Вачдог отключен. Собственно, поэтому я и не ожидал reboot'а. Видимо, я неправильно понимаю смысл этой галочки.
Вложение 39671
Вы правы в том, что с момента подключения и до перезагрузки ПЛК Counter уже не считает. Только ещё раз уточню - данные в сокет тоже не принимаются. Вообще. Т.е. блокирующий режим работы полностью неработоспособен.
И, согласитесь, сокеты работают по умолчанию в неблокирующем режиме. Что несколько расходится с их стандартным поведением. И с документацией.
1. Ради Вашей безопасности Вы никак не можете отключить аппаратный WatchDog. Только програмный.
2. Да, на старой линейке ПЛК блокирующий режим 100% неработоспособен. На новой он работает 5 секунд до ватчдога. Успеет произойти обмен - программа проживёт еще 5 секунд :D Системы реального времени и блокирующие функции несовместимы от слова совсем.
3. Сокеты на embedded реализации ну никак не могут 100% соответствовать стандарту, Вы небось на linux/Windows ориентируетесь? Особенности известны, примеры есть, на ОШИБКИ мы оперативно реагируем. Так что не надо паники!
Да я не паникую. Я разбираюсь в том, как работает ваша техника. Недавно (уже упоминал) убил полтора месяца на то, за что в принципе даже не брался бы, зная то, что знаю сейчас. Хочу вот уберечь других программистов от повторения моих ошибок.
ЗЫ. В оперативность реагирования, простите, не верю. Как и в то, что ошибки бережно сохраняются в новых прошивках для сохранения совместимости с ранее написанным для ПЛК софтом. По мне так нормальной реакцией была бы новая прошивка с правильно функционирующей библиотекой и объявление о том, что обновление прошивки не рекомендуется тем-то и тем-то по таким-то причинам. Вместо этого мы годами читаем на форуме о том, как правильно делать BOOL_TO_DINT при полном отсутствии документации.
Пять раз Владислава спросили про документацию. Пять раз он не ответил:)
Озвучили. Только смысл ответа от меня ускользает. Что значит "никто не будет их "исправлять"? Это почему? Некому? Давайте я исправлю?
И почему "исправлять" в кавычках? Т.е. вас вот это все устраивает? Всех всё устраивает? Один я никак не врублюсь в "особенности овеновской разработки с булями" (с) ?
Ладно бы всё это касалось древних приборов, давно ушедших в прошлое. Так ведь нет - половина производимых сегодня ПЛК идёт с такими вот "особенностями" (с).
ЗЫ. Есть ещё один вариант выхода из положения. Выпускайте 2 прошивки - одну для любителей мазохизма, вторую - соответствующую документации.
Как я понял, пока единственная реакция со стороны "Овена" - это забота о том, как бы я не получил излишнее количество самопиара.:D
Ну, да я не гордый. Повторю вкратце выводы здесь.
Для всех ПЛК с прошивкой 2.17.0 из 25 функций библиотеки SysLibSockets:
Функции, возвращающие свой аргумент (не скажу, что это ненормально, но применять их в проектах только для ПЛК "Овен" смысла нет):
- SysSockHtonl
- SysSockHtons
- SysSockNtohl
- SysSockNtohs
Полностью неработоспособные функции:
- SysSockAccept
- SysSockGetHostByName
- SysSockGetHostName
- SysSockGetLastError
- SysSockGetOption
- SysSockInetAddr
- SysSockInetNtoa
- SysSockSelect
- SysSockSetIPAddress
- SysSockSetOption
- SysSockShutdown
Работают, но не так, как заявлено в документации:
- SysSockClose - возвращает TRUE вместо FALSE и наоборот;
- SysSockConnect - возвращает всегда FALSE;
- SysSockIoctl - расхождение с документацией, причём разное для разных команд;
- SysSockListen - возвращает всегда FALSE. Примечание: BOOL_TO_DINT от результата возвращает всегда 0.
Работают как заявлено в документации:
- SysSockBind
- SysSockCreate
- SysSockRecv
- SysSockRecvFrom
- SysSockSend
- SysSockSendTo
Вывод то какой? Если что, у меня два плк100 между собой в быки-коровы играли по Ethernet, им ни чего не мешает, неужто потому что яичек нет?
а зачем, еще раз повторяю не пользуюсь я всеми функциями, которые Вы забраковали как не рабочие, тех которые работают вполне достаточно для обмена информацией. ПЛК программируется для конкретных задач, а не поддерживать весь функционал стека на всякий случай
А вы можете хоть 50 раз повторять. Вы не пользуетесь нерабочими функциями, потому что они нерабочие. ;) (Интересен ещё вопрос, а как вы догадались, что они нерабочие и сколько ушло на это понимание времени?) И вопрос отнюдь не в полной или неполной поддержке сетевого функционала. Вопрос в том, что всё это никак не отражено в документации.
ЗЫ. Попробую попроще объяснить. Я покупаю ПЛК отнюдь не подвального изготовления, читаю всю прилагающуюся к нему документацию, пишу (опираясь на эту документацию) программу и... ну да - программа не работает. Это нормально?
А я попробую тогда в открытую сказать, раз не поняли намека: плохому танцору ... => ищите подсказку в предыдущих постах
Рад за ваши танцорские умения. Развивайте талант и дальше...
PS. Уважаемые модераторы! (здесь же бывают модераторы?) Конечно, товарищ capzap обладает невероятными талантами - великолепный танцор и обладатель чёрного пояса по программированию без правил (уверен, что он может заставить играть в "быки и коровы" хоть арифмометры "Феликс"), но я не уверен в том, что эти яркие достоинства дают ему право нарушать правила форума. Нет?
Овену надо было поступить с SysLibSockets также, как SysLibCom. Сделать дополнительную библиотеку ( или библиотеки ) с функциональными блоками ( например TcpClient, TcpServer, UdpClient и т.д. ), снабдить все это описанием и примерами. И разработчикам было бы проще и матов на форуме было бы меньше.
ComService насколько я знаю, разработка пользователя а не овеновское предложение, просто это удобно, но какой смысл что то предлагать с сокетами, когда есть http://www.owen.ru/forum/showthread....l=1#post291852 вложение от КДС, остается переделать преобразование типов в нужных местах и всё, все мои примеры которые я на форуме выкладывал написаны через этот код
Я не знаю чья именно разработка ComService.lib, но сейчас она входит в "стандартный набор" библиотек, который можно скачать с сайта owen.ru.
Я не настаиваю на создании дополнительных библиотек для сокетов. Просто с ними тоже было бы удобно, и скрыло бы некоторые нюансы реализации сокетов в ПЛК Овен. И разработчикам на стороне клиента, и техподдержке на стороне производителя было бы удобней.
TcpUdpLib этим и занимается, сама бибка открытая, поправить в двух-трех местах и Вы в шоколаде
так то он и код свой выкладывал, который не похож на то что я показал и тоже не рабочий, может дело не в бибке
ПЛК - это важный компонент промышленной автоматики.
Понимаете, одно дело когда используешь библиотеки скачанные с официального сайта, например отсюда
https://www.owen.ru/product/programm...er_oven_plk110
и другое когда используешь код, который кто-то выложил на форуме. Вы же в Овене не работаете.