CODESYS V3.5. Вопросы и ответы

[МихаилГл]

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

Убираете галочку "проверять обновления" в этом окне, и жмете "ок". Перед "ок" проверить, что все стоит в "не обновлять". И больше на этом ПК данное окошко для данного проекта не выскочит, если не удалять вспомогательные файлы...

[Vladimir Zhuravlev]

Для проекта автоматизации вентиляции здания нужен каскадный регулятор температуры, вычисляющий уставки для PID нагрева и PID охлаждения по датчикам в притоке и в помещении
на Codesys 3.5 с таким проектом опыта не было
в основном автоматизацией вентиляции занимался на Siemens Desigo Xworks
там для данной задачи есть функциональный блок CAS_CTR

есть ли подобный функциональный блок в Codesys 3.5?

[pt200]

OCL.UNM_SerialRequest:
1) можно опубликовать список проверок по которым вылетает WRONG_PARAMETER?
2) Допустимо ли переиспользование экземпляра с другими параметрами(чего там внутри понакручено)?

P.S. А какие есть еще варианты работы с СОМ портом?

[Евгений Кислов]

OCL.UNM_SerialRequest:
1) можно опубликовать список проверок по которым вылетает WRONG_PARAMETER?
2) Допустимо ли переиспользование экземпляра с другими параметрами(чего там внутри понакручено)?

P.S. А какие есть еще варианты работы с СОМ портом?

1) WRONG_PARAMETER прокидывается из внутренних ФБ COM.Read и COM.Write из библиотеки CAA SerialCom, используемых внутри OCL.UNM_SerialRequest.
В документации CODESYS не приведён список ситуаций, в которых возвращается эта ошибка, но типовой случай - передача некорректного хэндла на вход hCom.

2) Допустимо.

Другие варианты - библиотека CAA SerialCom или SysCom.

[pt200]

1) WRONG_PARAMETER прокидывается из внутренних ФБ COM.Read и COM.Write из библиотеки CAA SerialCom, используемых внутри OCL.UNM_SerialRequest.
В документации CODESYS не приведён список ситуаций, в которых возвращается эта ошибка, но типовой случай - передача некорректного хэндла на вход hCom.

А точно больше ни откуда WRONG_PARAMETER вылезти не может(так как я в приемном буфере вижу корректный ответ(т.е. отправлено и принято), но вместо Done выставляется Error)?

[Евгений Кислов]

А точно больше ни откуда WRONG_PARAMETER вылезти не может(так как я в приемном буфере вижу корректный ответ(т.е. отправлено и принято), но вместо Done выставляется Error)?

Я описал, как устроена библиотека.
Вылезти может что и откуда угодно.
Например, при неосторожной работе с массивами/указателями можно залезть в ту область памяти, в которой хранится eError и совершенно случайно записать туда 12.

[pt200]

А нет нормальной документации по COM.Read (не описание интерфейса(даже на оф сайте ), а углубленного)?
1) Я правильно понимаю что eError 5001: time out это для нее "нормальный" режим работы/использования(т.к. редко известен обьем ожидаемых данных)?
2) Что будет при таймаут = 0, а при = 1(как выгребать синхронно все данные из FIFO порта)?

А есть более низкий уровень работы с портами(file.read?)?

[Евгений Кислов]

А нет нормальной документации по COM.Read (не описание интерфейса(даже на оф сайте ), а углубленного)?
1) Я правильно понимаю что eError 5001: time out это для нее "нормальный" режим работы/использования(т.к. редко известен обьем ожидаемых данных)?
2) Что будет при таймаут = 0, а при = 1(как выгребать синхронно все данные из FIFO порта)?

А есть более низкий уровень работы с портами(file.read?)?

Насколько я помню - udiTimeOut касается не обмена как такового, а выполнения блока в принципе.
Я обычно оставляю для него значение 0, чтобы "выгребать все данные".
Я бы сказал, что для блока нормально возвращать xDone при szSize = 0 (хотели считать что-нибудь из буфера COM-порта, а там ничего нет).

А есть более низкий уровень работы с портами(file.read?)?

В рамках операционной системы - безусловно. Но ни здесь, ни на support консультации по этому вопросу ждать не стоит.
Подразумевается, что клиент приобретает ПЛК с CODESYS, чтобы получить более высокий уровень абстракции для своего прикладного ПО, а не спускаться на уровень системных вызовов.

[pt200]

udiTimeOut .... Я обычно оставляю для него значение 0, чтобы "выгребать все данные"....

А вот про этот момент можно поподробнее(т.е. udiTimeOut = 0 - это не ждать / сразу вернуть что есть в буфере(xDone + szSize))?

P.S. еще бы xExecute не "моргать" и вообще нормально было бы

[Евгений Кислов]

А вот про этот момент можно поподробнее(т.е. udiTimeOut = 0 - это не ждать / сразу вернуть что есть в буфере(xDone + szSize))?

udiTimeOut = 0 - это ждать столько, сколько придется

Если вы ставите udiTimeOut = 100, а блок не сможет за 100 мкс вычитать весь буфер COM-порта (по тем или иным причинам) - то тогда случится .xError и .eError = TIME_OUT