ошибки в примерах ...

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

.... то что примеры не работают можно списать на несовпадение таргетов, настройки компиляторов, файрволлов, свои кривые руки и оборванные провода в разъемах ..... но анализ кода примера после решения проблемы и "вьезжания в тему" приводит к мысли что он вообще не должен работать ......

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

... мне становиться страшно от мысли что софтина самого плк написана в том же стиле что и примеры применения (((((

ИМХО Вы много ожидаете от примеров. Не могу говорить про примеры Овен. Но мои собственные примеры явно обладают мистическим свойством портится со временем.:rolleyes:
Взять хотя бы пример со светофором из штатной документации CoDeSys. Его переделывали три раза три разных человека! Всякий раз самым тщательным образом все проверяя, каждый шаг, каждую мелочь. Все было понятно и работало 200% :) . Но проходит год, новый человек начинает делать это пример и обнаруживает что он не работоспособен, крив, непонятен и написан полным идиотом :mad: . Он переделывает этот пример, доводит все до совершенства :) . Через год ситуация в точности повторяется :mad: . Поэтому я лично давно бросил детально разбирать примеры в любых документах любых фирм. Хорошо если при взгляде по диагонали получиться позаимствовать базовую идею, но не более того.

Может быть Вы можете поправить пример и выложить свой вариант? Однако дело это не благодарное и могу поспорить, что найдется куча людей, у которых он не заработает. Спасибо не скажет никто (99%), а материть будут (это 100%)…

Кхм, кто спорит что в программах бывают ошибки. Однако хотелось бы уточнить, где действительно ошибка и что за пример с сокетами?

W3S_RCV: (* Прием из сокета*)
rcv_buf_cnt_tmp:=SysSockRecv(sock_acc,rcv_snd_buf+ rcv_bytes_cnt,1024,SOCKET_MSG_OOB);


IF rcv_buf_cnt_tmp<>16#FFFFFFFF THEN
rcv_bytes_cnt:=rcv_buf_cnt_tmp+rcv_bytes_cnt;
ELSE
IF rcv_buf_cnt_tmp=0 THEN
RETURN;
END_IF
END_IF
full_get(in:=(rcv_bytes_cnt>0) ,pt:=t#500ms); (* Ждем 200 мс на всякий случай*)


... ну например, что вы имели ввиду в ветке ELSE , выполняя проверку на ноль переменной, которая заведомо = -1 ? return каким образом выполняется???

кстати, по докам функция чтения возвращает результат DINT а не DWORD ... разница не велика, но читабельность программ ухудшается и очень станно что компилятор не ругается на такую подмену...
про то что функции возращают не нули а FF -ы все уже привыкли ))))

а как отнесутся ваши лицензиаты к распространению подобного кода на вашем форуме? ведь использование сокетов позволяет вытаскивать из ПЛК значительные объемы переменных с весьма приличной скоростью и уменьшает востребованность контроллеров с литерой "М"

Ясно, это просто кусок не исполняемого кода, который остался от другого алгоритма. Ну если Вы считаете это ошибкой, пусть так и будет. Я спорить не буду, но придержусь иного мнения. Поскольку код не закрыт - предлагаю выкладывать все свои исправления.
Насчет DINT и DWORD не совсем к нам претензия...

Не понятно в чем проблема лицензий M,L и примера web сервера. Примерно как теплое и мягкое сравнивать.
Вы наверное имели 3SSoftware - наших Лицензиаров - мы лицензиаты. Маленький скромный писанный на коленке пример не может конкурировать с web визуализацией.

Ребзы, вы не обижайтесь! Огребать недовольство пользователей - это судьба тех. поддержки, сам в таком же положении поэтому знаю не по наслышке )))
Все ж понимают что ПЛК как объект купли-продажи возникает только когда выполнена разработка, без программы он никому не нужен. Ваш контроллер уникален по набору железных вкусняшек и цене, поэтому хочется его использовать. И использовать в применениях, мягко говоря не тривиальных для ПЛК. Типовые цели пользования ПЛК понятны и давно описаны, и под них есть более гладкие контроллеры.... скажем Сименс Пур ... и просто и дешево и .... Сименс )))) та задача, которую пытаюсь двигать решается набором Compact-RIO от National Instruments c плисом в ядре и циклом в микросекундах ... стоимость которой, особенно сегодня, заоблачна. Вроде, получается с несущественными потерями поднять на ПЛК, но для этого приходиться лезть в области программирования ранее не копанные .... ну не занимался я никогда обменом с помощью юзернета ))) поэтому ошибки и малейшие неточности в примерах гробят много времени. Вот, например, в теме про пример Веб сервера появилось уточнение, что в ИЕ он не работает ( 80% пользователей - ИЕ! ), а ведь теме даже не месяц!!! ... и вот ситуация : начинаешь новую тему - ищешь инфу - о! заботливый саппрорт выложил пример, здорово! скачиваешь его, и .... не работает, почему? не совпал таргет? нет нужной библиотеки? сработал файрволл? программная ошибка? поврежден порт хаба? несовместимость с установленным броузером??? да только для того чтобы определить круг возможных проблем уже надо быть докой )))
... да лан ))) проблема решилась, пример подправили ))) значит работаем дружно и в нужном направлении )))
А проблем с примером веб сервера и лицензиями M L нет, я имел в виду другое .... сделав функциональный блок с сокетом и dll на компьютере можно перегонять любые объемы данных из ( в ) ПЛК обходя ограничения версии L ( которые на самом деле жесткие, когда нужны вещественные переменные )

По стандарту МЭК DWORD – это строка из 32 бит, c которой можно делать только логические операции и работать с отдельными битами (адресуется номером бита через точку после имени переменной). Математические вычисления делать с этим типом нельзя, для этого есть UDINT. Но на практике оказалось, что очень уж часто надо и то и другое. С точки зрения процессора эти типы не отличаются. Показалось разумным не забивать голову прикладным программистом этими тонкостями, не усложнять им жизнь, заставляя делать явные преобразования. На данный случай в CoDeSys сделано послабление. Потери данных при таком преобразовании не происходит, поэтому нет смысла пугать людей (не всем понятными) предупреждениями. Бесспорно, лучше использовать типы данных, не смешивая их предназначение. Однако при разработке CoDeSys есть цель сделать инструмент простым в освоении. В этом ключе данное послабление есть плюс.

Понятно, что всякими хитрыми приемами можно обходить ограничения. Не для кого это не секрет. Можно и ПЛК вообще не покупать, а слепить самому на базе IPC чипа. Кто-то любит проковыривать дырки гвоздем (как говорила моя покойная бабушка 'вдовий метод'), другие предпочитают купить сверло. Есть свобода выбора. Это еще один плюс для ПЛК Овен.

Дмитрий Артюховский, расскажите пожалуйста про конечный результат - оно работает? Я сейчас пытаюсь сделать нечто подобное через модем, но пока успехи невелики. В данном примере меня смущают не мелкие погрешности (уже привык :) ), а то, что SysLibSocket работает не так, как того ожидаешь (у Овна вообще все библиотеки с "национальными особенностями" - классический пример SysLibTime - вместо добавления доп. ф-ции SetTime сделали сами знаете что).

Сокеты вообще-то работают так (в POSIX системах, т.е. в UNIX/Linux, откуда они родом, а также в Windows, где они скопированы "1 в 1"):
socket();
bind(); Задаем IP-адрес (редко) и порт (всегда).
listen(); Задаем ограничение на число соединений, ожидаем соединения.
accept(); Создается дубликат сокета, однако они не равноценны - дубликат уже соединен (ESTABLISHED), а исходный сокет ждет следующего соединения (LISTEN).
Теперь дубликат используется для обмена данными - read()/write()/send()/recv() и затем соединение закрывается - сlose(). Для распараллеливания это обычно делается в дочернем процессе или thread. А основная программа возвращается к listen().

У Овена сразу создается несколько сокетов, слушающих один порт (в других реализациях это ошибка!). Что делает listen() - непонятно, но он не сообщает о поступившем соединении. А accept(), похоже, вообще нет. В результате о том, что соединение установлено, можно узнать только по возврату recv(). Также, по тексту примера, соединение и не закрывается. Как сокет возвращается вновь в состояние LISTEN? По таймауту? По закрытию клиентом? А если он не закроет (может для этого и 3 сокета)? У меня по Ethernet вроде работает, но иногда выдает ахинею, как будто склеиваются несколько ответов, может как раз из-за нечеткой фиксации конца транзакции?

Также, на мой взгляд, пример расточителен по ресурсам процессора. Зачем повсюду искать "спецтег" <OWEN> для подстановки переменных - это же ПЛК, а не ПК (как любит говорить техподдержка :)). Постоянно перезагружать страницу для обновления все равно неразумно - для этого есть AJAX. Также странно реализована SymLib - если бы вместо ф-ций Read/Write можно было бы получить адрес по имени, то a) это можно было бы делать один раз и б) легко можно было бы передать массив (а сейчас только по элементам?).

0. Господин Петров тут подробно всё объяснил с библиотеками. Вот поотрубал бы все библиотеки - и проблем бы не было. А то, почему у Вас штаны не уставного цвета?! Другие производители, видимо обжёгшись на техподдержке, обрубают всё под корень.

1. Некоторые особенности ПЛК (а именно отсутствие пары Гб ОЗУ) и нежелание использовать heap для динамического выделения (т.к.) фрагментируется память, а ПЛК должен работать годами (это не винда) и привели к "особенностям". listen - просто заглушка. Как и accept. 1 сокет - 1 соединение. Полный контроль за ресурсами.
А закрывается либо вызовом функции close, либо по таймауту, либо по желанию 2-го участника соединения. Какие ещё бывают варианты?

Если в буфере сокета, к примеру, 3 ответа, то при чтении они и будут выданы один за другим. Какие между ними должны быть разделители?

И ещё дочерних процессов хочется - это в оборудование классом за 2000$, пожалуйста.

2. SymLib - А указатель на озу в возвращаемой структуре Вы не заметили? Возьмите его, сохраните и используйте!

3) "легко можно было бы передать массив (а сейчас только по элементам?)" - напишите коллективную петицию в CoDeSys пожалуйста, чтобы они каждый элемент массива не объявляли отдельной строкой в символьном файле. Будем очень благодарны.
И заодно поинтересуйтесь, на каком из ПЛК есть вообще доступ к символам.

AJAX — это не самостоятельная технология, а концепция использования нескольких смежных технологий. AJAX базируется на двух основных принципах:

* использование технологии динамического обращения к серверу «на лету», без перезагрузки всей страницы полностью, например:

* с использованием XMLHttpRequest (основной метод);
* через динамическое создание дочерних фреймов;
* через динамическое создание тега <script>.

* использование DHTML для динамического изменения содержания страницы;
И ЭТО:confused: вы назваете разумной альтернативой вместо перезагрузки малюсенькой страницы.


Люди, критиковать - самое простое. Понять почему так сделано - уже труднее. А самое трудное - участвовать в разработке.
ПЛК состоялся как прибор и обсуждать его особенности бессмысленно. Никто не пойдёт на из изменения (тем более что это не ошибки), используется уже слишком много кода, чтобы менять что-либо.

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

* через динамическое создание тега <script>.

* использование DHTML для динамического изменения содержания страницы;
И ЭТО:confused: вы назваете разумной альтернативой вместо перезагрузки малюсенькой страницы.


Люди, критиковать - самое простое. Понять почему так сделано - уже труднее. А самое трудное - участвовать в разработке.
ПЛК состоялся как прибор и обсуждать его особенности бессмысленно. Никто не пойдёт на из изменения (тем более что это не ошибки), используется уже слишком много кода, чтобы менять что-либо.

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

* использование DHTML для динамического изменения содержания страницы;
И ЭТО:confused: вы назваете разумной альтернативой вместо перезагрузки малюсенькой страницы.


Люди, критиковать - самое простое. Понять почему так сделано - уже труднее. А самое трудное - участвовать в разработке.
ПЛК состоялся как прибор и обсуждать его особенности бессмысленно. Никто не пойдёт на из изменения (тем более что это не ошибки), используется уже слишком много кода, чтобы менять что-либо.

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

работает, но в текущем варианте программы соединение закрывается после каждого обмена, похоже тайм аутом, и поэтому в С программе для очередной посылки вновь устанавливаю соединение:


pSocket = new CClientSocket(this);
pSocket->Create();
pSocket->Connect(m_sAdr, m_port);
pSocket->Send("HELLO_PLC", 9);
- выполняется при создании окна и установлении связи


pSocket->Connect(m_sAdr, m_port);
pSocket->Send( "SOUND", 5 );
- при каждой посылке данных



... да еще режим сокета в плк ставлю другой:

SysSockIoctl(sock_acc,SOCKET_FIONREAD,ADR(param_ct rl));



Владислав! Да мы собственно не критикуем, а пытаемся выяснить как это работает! Документация весьма скудная, а попытки притащить знания из других платформ натыкаются на факт, что в ПЛК100 функции реализованы не совсем так, как в аналогичных системах. Понятно что особенности реализации неизбежны, но хотелось бы иметь список этих особенностей )))) .... замечательно что есть форум, на котором почти всегда можно получить исчерпывающий и быстрый ответ, но хотелось чтоб эти ответы систематизировались и объединились в один документ.


А по новым разработкам: хочу внешние прерывания с откликом в микросекунды, ШИМ внутри полупериода сети с привязкой к нулю и съемный носитель памяти для архивов и настроек. В идеале наличие быстрого шинного интерфейса, с соответствующими модулями ввода - вывода. МДВВ через 485 хорошо, но медленно.

20 мкс прерывание уже в 110.
ШИМ - для таких целей частотник - куда более правильное решение. ПЛК должен руководить "плотником", а не его рукой, забивающей гвозди. ШИМ такого уровня - уже аппаратное решение, если хочется точности и стабильности. Один узел детектирования нуля с ФАПЧ и устойчивостью к шумам - сложное устройство.
Шинная архитектура интенсивно разрабатывается. Есть обнадёживающие результаты.

Продираем глаза и ищем в примере HTTPRequst - нашли - прекрасно - вот вам и AJAX. Реально перегружается только param.txt.
На мой взгляд тоже расточительно по ресурсам процессора использовать ОВЕН ПЛК в качестве сервера удаленного доступа и web сервера. Можно купить обычный комп поставить туда SP RTE и дополнителные платы ввода-вывода. За какие - то смешные - 3-5тыс евро у вас нагрузка на процессор упадет до 1-2 процентов.

Понятно, что это должен быть аппаратный модуль. Частотник это хорошо, но для систем, аналогичных "умному дому" хочется иметь простенький диммер! Все шим модули овена заточены под печки, а как хочется порегулировать яркость лампочки ))) Есть еще коллекторные двигатели, которыми удобно управлять одним симистором. Можно говорить что связка простенький ПЧ + асинх.двигатель по цене не много выше коллекторника... и что шуметь симистор с КД будет изрядно, это так, но потребительские свойства привода с КД все-таки выше чем простые ПЧ. Чтобы дойти до параметров коллекторного двигателя нужен хотя бы бездатчиковый вектор, а не просто U/f, пусть и с подьемами характеристики. Да и выводов контроллера займеться намного больше. Может быть реализовать такой шим в качестве внешнего модуля с 485 интерфейсом, в части применений это решит задачу.


.... увидел платки подключения выводов к контроллеру и согласования с ТТЛ!!! оч. здорово, и нужно - побег покупать!!!

Филоненко Владислав, ну почему Вы в ответ на вполне конкретные вопросы и замечания все время начинаете считать чужие гигабайты, гигагерцы и килобаксы? "Вот поотрубал бы все библиотеки..." - это Ваше право. Вы (фирма "Овен"), как производитель можете выбрать любую линию поведения в диапазоне от "потребитель всегда прав" до "вас много, а я один". Но только от этого будет зависеть объем продаж :). Поэтому Вы и библиотеки не отрубаете, и ПЛК продаете за 7000р., а не за $7000, а вовсе не по особой доброте души. Так надо спасибо говорить пользователям, которые находят ошибки или ухитряются пользоваться некоторыми возможностями без нормальной документации. Причем большая часть замечаний вовсе не требует цеплять в ПЛК новый процессор или "2 ГБ ОЗУ" - речь идет о достаточно безболезненной коррекции ПО. И не я выкладывал на форум пример Веб-сервера и др...

Указатель в ReadValueTag - это адрес ПОЛЬЗОВАТЕЛЬСКОГО буфера. Сохранять и использовать его бессмысленно. Речь шла об адресе переменной в программе. Насчет массивов - если x: array [0..100] of dword и adr(x[0])=20000, то разве не будет adr(x[1])=20004 и т.д. Вопрос - как узнать adr(x[0]) по имени "x".

AJAX работает в броузере, он ничего особенного не требует на сервере. Наоборот, его использование НЕ ТРЕБУЕТ парсить 100кБ текста в поисках волшебного слова ОВЕН. И да, он уже используется в примере для графика. А то, что нормальный TCP/IP и небольшой HTML сервер при правильной реализации вполне по силу ПЛК доказывает пример ADSL-модемов - вряд ли эти штуки за 600р. имеют большую вычислительную мощность, чем ПЛК.

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

Вопросы выглядят несколько иначе. Вспоминается обсуждение на abok. Начали с "какая гадость эта ваша заливная рыба..." а оказалось человек в коробочке 10х15х10 кабель найти не мог. 3 дня искал. Ложки нашли, но заголовок месяца 3 висел в топе. Помогать и отвечать на вопросы я никогда не отказываюсь.

Про сокеты - Есть кусок памяти под 20 сокетов. Он 1 раз в жизни ПЛК выделяется. И что бы не делать - память не фрагментируется, как при динамическом выделении.
Про ответ - т.е. каждый раз, когда надо опросить сервер - открывать сокет? Web-брайзер, с динамическим числом пользователей - очень специфическая задача. Да и то с 3-х компьютеров 1 ПЛК с 1 выделенным сокетом прекрасно можно опрашивать. Проверяли.
Описанная Вами модель хороша для больших операционок. 1 сокет - 1 поток.
В ПЛК нет большой операционки, т.к. она много потребляет ресурсов, даже с RT-расширениями.

Про символы уточню. Указатель там, по памяти, возвращался.

Про символы - т.к. ПЛК поддерживает online change, и адреса переменных при этом могут сместится - мы перестраховались и запретили доступ к физ. адресу параметра.
Если давать доступ - программист на CoDeSys должен отслеживать события online change - это сложно. :D
Т.к. у нас в стране документацию читают только в самом крайнем случае :mad: под дулом пистолета :eek: , а последствия ошибки в данном случае могут быть катастрофическими.
Мы и убрали указатель.

Ответ не принимается. В документации, которую никто не читает :), сказано следующее:
"Attention: Online Change might change the contents on addresses. Please regard this when using pointers on addresses !"
Т. е. <b>"online change" вообще несовместимо с использованием указателей!</b>. А т. к. использовать SymLib (и SysLibFile, SysFibSockets, ...) без указателей все равно не получится, то мы ничего не теряем.
Пугать катастрофическими последствиями не стоит, поскольку, надеюсь, идиотов, регулярно делающих "online change" на работающем объекте, среди пользователей Овена нет.

А насчет отслеживания события "online change" - хорошая мысль. Продолжение исполнения программы со середины после изменения во многих случаях неприемлимо даже безотносительно к указателям. Надо будет вставить сложную ;) программу "init_required:=TRUE;" в обработчик события, если оно действительно поддерживается.

alex1963, не путайте тёплое с мягким. Указатель сейчас в SymLib передаётся только на пользовательский буфер, и если этот указатель всегда перед отдачей инициализируется как pbuf:=ADR(My_BUF); то ничего страшного не произойдёт, т.к. даже при смене кода ADR(My_BUF) всегда будет иметь правильное значение.
А вот если хранить в массиве заранее считанные адреса переменных - тогда капец.

А что Вы там такое монструозное ваяете, что нужен доступ через символы и с индексацией?

О, Господи! А в SysLibFile, SysFibSockets тоже указатели инициализировать непосредственно перед использованием? Впрочем, следите за каждым указателем, если Вам это нравится, а по мне проще обойтись без "online change", или программный reset после него не забывать делать, или обработчик события (см. выше).

Ну какой "капец"? Ну не будет работать после "online change", программист увидет, сделает reset. Кстати, пример Веб-сервера после "online change" благополучно виснет :). И что, других глупых ошибок мало делается, после которых "капец"? И сам СoDeSys не у кого ни разу не сбоил при заливке программы (наверное, только у меня это случается :))?

А передавать массивы нужно, что в этом такого? Даже в уже упомянутом примере Веб-сервера нужен массив для графика. Выкрутились отдельными переменными - но это демо, там всего 6 точек. А если 100?

А Вы сделайте наоборот.
Выделите массив с известным именем, а это имя и вставляете в спец-тег с индексом на конце.
Имя массива(массивов) известно, так что функция ADR будет работать. А далее, зная индекс и размер элемента - вуаля - искомый указатель.

Массивы можно определять динамически - главное стандартизировать имена