Вид для печати
результатом UDINT_TO_TIME(nDelay_s) будет nDelay_s в миллисекундахЦитата:
Сообщение от FPavel
умножаем nDelay_s мс на 1000 мс получаем nDelay_s в секундах
здесь получаем выражение udint * time, вот компилятор и ругаетсяЦитата:
Переставляя скобки смог преобразовать и получить код, сейчас пойду дальше по выполнению работы, но всё же это - БАГ компилятора.
Думаю, что и так было бы корректно tDelay := nDelay_s * T#1000ms;, но и это компилятор не пропускает.
Наверное, всё же не соглашусь...
[ms]*[ms]=[ms^2], т.е. размерность не соблюдается
Попытаюсь показать ошибку в Ваших рассуждениях.
А как быть, если на первую задачу отводится T1 := t#1s, а на вторую задачу в k := 7 раз больше.
Как вычислить интервал времени T2?
Спасибо. Странная конечно реализация. Думал что полноценная симуляция.
TIME в миллисекундах должен быть, для конвертации целое число секунд надо привести к ms, умножив на 1000 и только после этого конвертировать.Цитата:
Сообщение от FPavel
Никаких секунд в квадрате тут нет, только ms.
Можете сделать обратную конвертацию, например t#5s, при конвертации получите целое 5000 ms, а разделив на целое 1000, получите целое 5 секунд.
Компилятор же ругался, когда конвертированное время пытались умножить на целую 1000, то есть не соблюдали типы переменных, что и подтвердил 2 ваш скрин.
Удивительно, как простейшие вещи надо ещё доказывать, вроде и люди неглупые. Даже в моих примерах, которые вы вроде смотрели, в каждом ФБ есть приведение к ms.
Делаю последнюю попытку показать, что операция над типами корректнаЦитата:
Сообщение от kondor3000
[TIME] * [ANY_INT] = [TIME]
Чуть выше уже приводил краткую справку на реализацию в CODESYS 3.5
https://owen.ru/forum/showthread.php...l=1#post479204
А сейчас сошлюсь на ГОСТ Р МЭК 61131-3—2016, который (цитирую из предисловия к этому документу):
https://files.stroyinf.ru/Data2/1/42...4293755016.pdfЦитата:
4 Настоящий стандарт идентичен международному стандарту МЭК 61131-3:2013 «Контроллеры программируемые. Часть 3. Языки программирования (IEC 61131-3:2013, «Programmable controllers — Part 3: Programming languages», IDT).
Открываю "6.6.2.5.11 Функции даты и продолжительности времен" (с. 83)
Т.к. интересует заголовок и строки внизу таблицы, то на скрине "вырежу" среднюю часть таблицы.
Видно, что в строке 10a описана функция умножения MUL и её представление в выражениях в виде одного символа "*"
Функция (операция) умножения выполняется над двумя аргументами типов [TIME] и [ANY_INT] результатом которого является значение типа [TIME].
Вложение 87863
Т.е. реализация в Owen Logic неправильная 100%. Это - баг.
Вполне приму объяснение, что с момента внедрения в Owen Logic языка ST прошло несколько лет и пользователями написано много программ, часть из которых передана заказчикам в виде исходников - поэтому, чтобы не ломать совместимость с наработками, найденный баг исправляться не будет.
В ПР205, в отличии от ПР200, при изменении значения поля ввода и нажатии SEL, переход на следующее поле ввода происходит без сохранения значения. Есть планы исправить?
Не факт что так правильнее. Я бы как есть оставил.
Я не говорю о правильности. Я говорю об единообразии.Цитата:
Сообщение от RV9WFJ
Об этом баге известно? Исправления ждать?
https://disk.yandex.com/i/FRGZzU0DLWjsTw
https://youtu.be/AHf8IQvf_io
По поводу правильно.Цитата:
Сообщение от RV9WFJ
Считаю абсолютно правильной логику, реализованную в ПР200.
Нажатие SEL подтверждает ввод с переходом к редактированию следующего поля.
Нажатие ОК подтверждает ввод с выходом из режима редактирования.
Нажатие ESC отменяет ввод с выходом из режима редактирования.
Режим редактирования одной переменной без перехода к редактированию другой нужен ОБЯЗАТЕЛЬНО!