Фичи и баги OWEN Logic

[Dimensy]

А какая размерность у этой величины - [s*s] = [s^2] ?
Это же некорректненько

результатом UDINT_TO_TIME(nDelay_s) будет nDelay_s в миллисекундах
умножаем nDelay_s мс на 1000 мс получаем nDelay_s в секундах

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

Думаю, что и так было бы корректно tDelay := nDelay_s * T#1000ms;, но и это компилятор не пропускает.

здесь получаем выражение udint * time, вот компилятор и ругается

[FPavel]

Наверное, всё же не соглашусь...
[ms]*[ms]=[ms^2], т.е. размерность не соблюдается

Попытаюсь показать ошибку в Ваших рассуждениях.
А как быть, если на первую задачу отводится T1 := t#1s, а на вторую задачу в k := 7 раз больше.
Как вычислить интервал времени T2?

[mva2204]

Спасибо. Странная конечно реализация. Думал что полноценная симуляция.

[kondor3000]

Наверное, всё же не соглашусь...
[ms]*[ms]=[ms^2], т.е. размерность не соблюдается

Попытаюсь показать ошибку в Ваших рассуждениях.

TIME в миллисекундах должен быть, для конвертации целое число секунд надо привести к ms, умножив на 1000 и только после этого конвертировать.
Никаких секунд в квадрате тут нет, только ms.
Можете сделать обратную конвертацию, например t#5s, при конвертации получите целое 5000 ms, а разделив на целое 1000, получите целое 5 секунд.
Компилятор же ругался, когда конвертированное время пытались умножить на целую 1000, то есть не соблюдали типы переменных, что и подтвердил 2 ваш скрин.
Удивительно, как простейшие вещи надо ещё доказывать, вроде и люди неглупые. Даже в моих примерах, которые вы вроде смотрели, в каждом ФБ есть приведение к ms.

[FPavel]

TIME в миллисекундах должен быть, для конвертации целое число секунд надо привести к ms, умножив на 1000 и только после этого конвертировать.
Никаких секунд в квадрате тут нет, только ms.
Можете сделать обратную конвертацию, например t#5s, при конвертации получите целое 5000 ms, а разделив на целое 1000, получите целое 5 секунд.
Компилятор же ругался, когда конвертированное время пытались умножить на целую 1000, то есть не соблюдали типы переменных, что и подтвердил 2 ваш скрин.
Удивительно, как простейшие вещи надо ещё доказывать, вроде и люди неглупые. Даже в моих примерах, которые вы вроде смотрели, в каждом ФБ есть приведение к ms.

Делаю последнюю попытку показать, что операция над типами корректна
[TIME] * [ANY_INT] = [TIME]

Чуть выше уже приводил краткую справку на реализацию в CODESYS 3.5
https://owen.ru/forum/showthread.php...l=1#post479204

А сейчас сошлюсь на ГОСТ Р МЭК 61131-3—2016, который (цитирую из предисловия к этому документу):

4 Настоящий стандарт идентичен международному стандарту МЭК 61131-3:2013 «Контроллеры программируемые. Часть 3. Языки программирования (IEC 61131-3:2013, «Programmable controllers — Part 3: Programming languages», IDT).

https://files.stroyinf.ru/Data2/1/42...4293755016.pdf

Открываю "6.6.2.5.11 Функции даты и продолжительности времен" (с. 83)
Т.к. интересует заголовок и строки внизу таблицы, то на скрине "вырежу" среднюю часть таблицы.
Видно, что в строке 10a описана функция умножения MUL и её представление в выражениях в виде одного символа "*"
Функция (операция) умножения выполняется над двумя аргументами типов [TIME] и [ANY_INT] результатом которого является значение типа [TIME].
таблица.png
Т.е. реализация в Owen Logic неправильная 100%. Это - баг.

Вполне приму объяснение, что с момента внедрения в Owen Logic языка ST прошло несколько лет и пользователями написано много программ, часть из которых передана заказчикам в виде исходников - поэтому, чтобы не ломать совместимость с наработками, найденный баг исправляться не будет.

[Aviator_VZh]

В ПР205, в отличии от ПР200, при изменении значения поля ввода и нажатии SEL, переход на следующее поле ввода происходит без сохранения значения. Есть планы исправить?

[RV9WFJ]

Не факт что так правильнее. Я бы как есть оставил.

[Aviator_VZh]

Не факт что так правильнее. Я бы как есть оставил.

Я не говорю о правильности. Я говорю об единообразии.

[Aviator_VZh]

Об этом баге известно? Исправления ждать?

https://disk.yandex.com/i/FRGZzU0DLWjsTw

[Aviator_VZh]

Не факт что так правильнее. Я бы как есть оставил.

По поводу правильно.

Считаю абсолютно правильной логику, реализованную в ПР200.

Нажатие SEL подтверждает ввод с переходом к редактированию следующего поля.
Нажатие ОК подтверждает ввод с выходом из режима редактирования.
Нажатие ESC отменяет ввод с выходом из режима редактирования.

Режим редактирования одной переменной без перехода к редактированию другой нужен ОБЯЗАТЕЛЬНО!