Это не причина использовать 64 разрядную оболочку. Надо смотреть, что контроллер поддерживает. Вот овен 64 разряд не поддерживает, хотя и 10ка виндовс.Цитата:
Сообщение от Yakut
Вид для печати
Это не причина использовать 64 разрядную оболочку. Надо смотреть, что контроллер поддерживает. Вот овен 64 разряд не поддерживает, хотя и 10ка виндовс.Цитата:
Сообщение от Yakut
Ну да, скорее всего 3.07. Тогда нужен 3.5.17, на сайте написано. У них на сайте вроде и 32 и 64 есть
премного благодарен.Цитата:
Сообщение от Sergey361
Неужели нельзя в той же странице где контроллер оставить кодесис 17 пака...а то зашёл человек 1 раз посмотреть и столько всяких кривостей слёту...это так филосовия..
Вот овеновцы красавцы, всё по уму делают и упорядоченно и обновляют актуальную информацию.
Буду удалять и новый качать ставить...
Удалять не обязательно, главное нужный ярлык запустить
Ага, и таргеты для 3.002 и выше
Благодарю, коллеги!:o
Заработало, увидел.
Теперь нет какого-то плагина, загружать не может, мигать контроллер не может, искать дополнительные модули не может.
СПК210: иногда мигает экран, в логе только это:
Что бы это значило(как починить)?Код:IECVisualization Visu_PRG: Creating Client successful for Extern-ID: 27400 Returned IEC-ID: 1
IECVisualization Visu_PRG: Creating Client for Extern-ID: 27400
Получается ГУЙ перезапускается, а причина то где????
================================================== ======================
Эти сообщения - это по ходу дела я подключался, сразу после промаргивания.
Тогда про промаргивание вообще никакой информации!
Куда копать?
См. п. 2 в новых функциях:Цитата:
Сообщение от pt200
https://owen.ru/forum/showthread.php...l=1#post459353
CS скорее всего криво всталЦитата:
Сообщение от Yakut
я б сказал что может встать криво, но тут бывают дамы...а так да, вы правы на все 100%Цитата:
Сообщение от Sergey361
решается вопрос очень просто - пишется в техпомощь, они кидают вот такой ссыль https://disk.yandex.ru/d/_0QeJfOfyoxt6g, с него качаем и устанавливаем. Всё работает.
Проект пустышка внизу - модули нашлись, всё влилось и никаких ошибок.
Допустимо ли переиспользование экземпляра OCL.MB_SerialRequest с другими параметрами(чего там внутри понакручено)?
т.е. он "отстрелялся"(xDone или xError) и снова в бой с другими параметрами?
Допустимо.Цитата:
Сообщение от pt200
Совсем недавно демонстрировали это на вебинаре:
https://owen.ru/media/video/webinar_170625
OCL.MB_SerialRequest: Допустимо ли стартовать новый запрос одновременно с окончанием предыдущего, а то чтото дрябленько запросы сыпятся на 115200(~9мс между ответом и новым запросом(смотрю на шине)(main_task: Freewhiling(на глаз порядка 1000Гц))?
т.е. он "отстрелялся"(xDone или xError) = TRUE и тоже уже xExecute := TRUE(с новыми параметрами) в этом же цикле?
PS Кстати а шаблон пустого проекта под СПК210 откуда берется(из таргета?), а то в коммуникационном контроллере дефолтная задача на 50Гц* из коробки как то не очень, из за этого достаточно долго не мог поднять связь(таймауты сыпались).
*если не память не подводит
Шаблоны проектов для наших контроллеров устанавливаются одновременно с пакетом наших таргет-файлов.Цитата:
PS Кстати а шаблон пустого проекта под СПК210 откуда берется(из таргета?), а то в коммуникационном контроллере дефолтная задача на 50Гц* из коробки как то не очень, из за этого достаточно долго не мог поднять связь(таймауты сыпались).
*если не память не подводит
Цель библиотеки OCL - предоставить пользователю:Цитата:
Сообщение от pt200
- расширенный функционал, которого нет в стандартных компонентах CODESYS (например, поддержку функции 20 Read File Record, режима Modbus RTU over TCP и т. д.);
- возможность полностью настраивать и контролировать обмен в своем коде.
Библиотека не является средством "ускорения" обмена; ее ФБ являются асинхронными, и выполнение каждого из них происходит в течение нескольких циклов задачи контроллера.
Предложенный вами подход технически возможен, но может нарушить ожидаемую работу блоков, поэтому он не относится к рекомендуемым.
Добрый день. Какая настройка отвечает за понимание компилятором, что переменная .var является глобальной из списка глобальных переменных и позволяет не писать каждый раз GVL.var?
Спасибо.
Прагма в фигурных скобках, удалите ее, и сможете обращаться к переменным напрямую...Цитата:
Сообщение от mf_
Спасибо, Михаил!Цитата:
Сообщение от МихаилГл
Здравствуйте. Некоторое время назад понадобилось мне установить Кодесис 3.5 СП18 для контроллера другого производителя. Теперь при каждом запуске проектов для СПК на Кодесис 3.5 СП17 у меня выскакивает окно с предложением обновить библиотеки. Версию СП18 я давно удалил с компьютера, но окошко при каждом запуске проектов все равно появляется.
Можно как-то удалить из системы библиотеки последней версии из списка?
Вложение 84664
Все версии 4.2 и 4.3 прекрасно работают и в SP17.3, удалять не обязательно, можете просто не обновлять.Цитата:
Сообщение от Карбофос
Мало того 4.2 и 4.3 в некоторых случаях работают корректнее 4.1
Ну это как раз понятно, просто надоело это окошко. А вот обновлять опасаюсь - не хотелось бы получить неведомые глюки...Цитата:
Сообщение от kondor3000
Убираете галочку "проверять обновления" в этом окне, и жмете "ок". Перед "ок" проверить, что все стоит в "не обновлять". И больше на этом ПК данное окошко для данного проекта не выскочит, если не удалять вспомогательные файлы...Цитата:
Сообщение от Карбофос
Для проекта автоматизации вентиляции здания нужен каскадный регулятор температуры, вычисляющий уставки для PID нагрева и PID охлаждения по датчикам в притоке и в помещении
на Codesys 3.5 с таким проектом опыта не было
в основном автоматизацией вентиляции занимался на Siemens Desigo Xworks
там для данной задачи есть функциональный блок CAS_CTR
есть ли подобный функциональный блок в Codesys 3.5?
OCL.UNM_SerialRequest:
1) можно опубликовать список проверок по которым вылетает WRONG_PARAMETER?
2) Допустимо ли переиспользование экземпляра с другими параметрами(чего там внутри понакручено)?
P.S. А какие есть еще варианты работы с СОМ портом?
1) WRONG_PARAMETER прокидывается из внутренних ФБ COM.Read и COM.Write из библиотеки CAA SerialCom, используемых внутри OCL.UNM_SerialRequest.Цитата:
Сообщение от pt200
В документации CODESYS не приведён список ситуаций, в которых возвращается эта ошибка, но типовой случай - передача некорректного хэндла на вход hCom.
2) Допустимо.
Другие варианты - библиотека CAA SerialCom или SysCom.
А точно больше ни откуда WRONG_PARAMETER вылезти не может(так как я в приемном буфере вижу корректный ответ(т.е. отправлено и принято), но вместо Done выставляется Error)?Цитата:
Сообщение от Евгений Кислов
Я описал, как устроена библиотека.Цитата:
Сообщение от pt200
Вылезти может что и откуда угодно.
Например, при неосторожной работе с массивами/указателями можно залезть в ту область памяти, в которой хранится eError и совершенно случайно записать туда 12.
А нет нормальной документации по COM.Read (не описание интерфейса(даже на оф сайте :mad:), а углубленного)?
1) Я правильно понимаю что eError 5001: time out это для нее "нормальный" режим работы/использования(т.к. редко известен обьем ожидаемых данных)?
2) Что будет при таймаут = 0, а при = 1(как выгребать синхронно все данные из FIFO порта)?
А есть более низкий уровень работы с портами(file.read?)?
Насколько я помню - udiTimeOut касается не обмена как такового, а выполнения блока в принципе.Цитата:
Сообщение от pt200
Я обычно оставляю для него значение 0, чтобы "выгребать все данные".
Я бы сказал, что для блока нормально возвращать xDone при szSize = 0 (хотели считать что-нибудь из буфера COM-порта, а там ничего нет).
В рамках операционной системы - безусловно. Но ни здесь, ни на support консультации по этому вопросу ждать не стоит.Цитата:
А есть более низкий уровень работы с портами(file.read?)?
Подразумевается, что клиент приобретает ПЛК с CODESYS, чтобы получить более высокий уровень абстракции для своего прикладного ПО, а не спускаться на уровень системных вызовов.
А вот про этот момент можно поподробнее(т.е. udiTimeOut = 0 - это не ждать / сразу вернуть что есть в буфере(xDone + szSize))?Цитата:
Сообщение от Евгений Кислов
P.S. еще бы xExecute не "моргать" и вообще нормально было бы
Цитата:
Сообщение от pt200
udiTimeOut = 0 - это ждать столько, сколько придется
Если вы ставите udiTimeOut = 100, а блок не сможет за 100 мкс вычитать весь буфер COM-порта (по тем или иным причинам) - то тогда случится .xError и .eError = TIME_OUT
Тогда можно еще раз для дурачков: как же пользоваться этим "более высоким уровнем абстракций" за который уплочено?Цитата:
Сообщение от Евгений Кислов
Задача стандартная(запрос):
0) почистил приемный буфер от всякого мусора(очень желательно)
1) отправил буфер с данными
2) в течении какого то времени принимаешь/получаешь данные кусками и пытаешся собрать из этого пакет(и если получилось, то не ждешь до упора).
PS Нет ли нормального примера, а не детсадовского из 3х коробочек на FBD?
так понимаю, нет возможности остановить timeout если пакет весь пришел и не дожидаться его окончания? впрочем это мало где есть, мне так кажется.
0) Это сделают за вас (если речь о буфере UART).Цитата:
Сообщение от pt200
1, 2) https://ftp.owen.ru/CoDeSys3/11_Docu...cols_v.3.0.pdf (6.5.4)
Например - использовать уже упомянутый UNM_SerialRequest.Цитата:
Тогда можно еще раз для дурачков: как же пользоваться этим "более высоким уровнем абстракций" за который уплочено?
Касательно вашей проблемы с WRONG_PARAMETER - техподдержка (support@owen.ru) с радостью вам поможет, как только вы пришлете минимальный проект, в котором ее можно повторить, и пошаговую инструкцию, как это сделать.
Прошу помочь, пока ждём контроллер, начал делать проект, и проверять его на эмуляторе, но столкнулся вот с этим паролем
Где-то я нашел что надо найти файл и снять комментарий с строки,но это не помогло, нет папки с названием эмулируемого контроллера
Вложение 84841
Добрый день.Цитата:
Сообщение от Fusa
https://owen.ru/forum/showthread.php...l=1#post401060
Не помогает,файлы удалил,один из них постоянно появляется опять после перезагрузки контроллера
и пробую подключится, опять просил логин и пароль (вроде я даже при установке не создавал пользователя вообще)Вложение 84848 Вложение 84849 Вложение 84850
Напишите завтра утром мне в телеграм (см. в подписи), пожалуйста.Цитата:
Сообщение от Fusa
Пока таким "костылем" пользуюсь:Цитата:
Сообщение от Евгений Кислов
Все таки хотелось бы с COM.Read разобраться, как она работает:Код:IF(REQ.xDone OR (REQ.xError AND (REQ.uiResponseSize > 0))) THEN
1) xExecute := TRUE и udiTimeOut = 0 и она начинает складывать принятые данные в буфер(добавляя каждый раз в конец) и инкрементируя размер szSize?
2) а когда мне надо будет тормознуть "нажимаем" xAbort(кстати он мгновенного действия или надо будет дожидаться подтверждения)?
По переднему фронту xExecute происходит однократная вычитка всего того, что накопилось в буфере COM-порта. После этого буфер автоматически очищается.Цитата:
1) xExecute := TRUE и udiTimeOut = 0 и она начинает складывать принятые данные в буфер(добавляя каждый раз в конец) и инкрементируя размер szSize?
"Добавлять каждый раз в конец и инкрементировать szSize" - это задача того, кто вызывает COM.Read.
В документе из прошлого поста всё это показано.
После ответа на 1) должно быть понятно, что в реальной жизни у вас не будет поводов для "торможения".Цитата:
2) а когда мне надо будет тормознуть "нажимаем" xAbort(кстати он мгновенного действия или надо будет дожидаться подтверждения)?
Теперь понятно: т.е. это "не блокирующая" фукция("ReadAllFromBuffer"), гарантированно завершающаяся максимально быстро и не ждущая больше ни чего, а таймаут прикрутили больше "для мебели"(ну и мне по мозгам "поездить" :))Цитата:
Сообщение от Евгений Кислов