Вид для печати
Убираете галочку "проверять обновления" в этом окне, и жмете "ок". Перед "ок" проверить, что все стоит в "не обновлять". И больше на этом ПК данное окошко для данного проекта не выскочит, если не удалять вспомогательные файлы...Цитата:
Сообщение от Карбофос
Для проекта автоматизации вентиляции здания нужен каскадный регулятор температуры, вычисляющий уставки для 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