Фичи и баги OWEN Logic

[wal79]

Нужен проект ,а не видео

Чтобы разобраться, да, нужен проект. Но видео всегда очень наглядно описывает проблему. Так что, если люди предпочитают описывать проблему посредством видео - мы только за. :-)

[Project M]

Ещё одна особенность, на мой взгляд явный косячок.

Два экрана. С первого на второй переход осуществляется по УДЕРЖАНИЮ клавиши "ОК". Со второго на первый НАЖАТИЕМ клавиши ОК.
За переходом с первого экрана на второй сразу же следует переход обратно (пользователь не успел отдёрнуть палец). Что на мой взгляд явно не корректно.
События не должны генерироваться одно за другим без отпускания клавиши, либо менять свою последовательность!

Пример https://yadi.sk/d/WpnvUuYE3JW63U

[Project M]

Чтобы разобраться, да, нужен проект. Но видео всегда очень наглядно описывает проблему. Так что, если люди предпочитают описывать проблему посредством видео - мы только за. :-)

Проект: https://yadi.sk/d/RYz75Xlz3JW6Ns

[Мамонов Михаил]

Да, замечание принимаю... Будем устранять.

В продолжение - в окне просмотра в любом случае выход с плавающей запятой показывается как булевский со значениями 0 или 1. На рисунке - создал макрос и сразу ему выход обозвал "с плавающей запятой", не присоединяя его до этого никуда. Все равно показывает его как булевский.

Снимок.PNG

P.S. На рисунке очень полезный макрос LinTrafo - перерисовал из CoDeSys библиотеки Util.lib - масштабирование входного значения к выходному. Жалко, что его нет в библиотеке онлайн-макросов

[Серёга Букашкин]

На рисунке очень полезный макрос - перерисовал из CoDeSys библиотеки Util.lib - масштабирование входного значения к выходному. Жалко, что его нет в библиотеке онлайн-макросов

Там что, тоже не защищаются от деления на "0"? А если InMax=InMin? Интересно что будет в этом случае на ПР? Потому что имелись случаи, в библиотеке PL/M например, что если делитель "0"- программа зависает (jmp на себя). Ну правильно, нельзя же делить на "0",... но и зависать нельзя. Симулятор в таком случае выдает "бесконечность", а вот что выдает процессор ПР -интересно, и что происходит с бесконечностью при дальнейшей арифметике с нею.

[Владимир Ситников]

Симулятор в таком случае выдает "бесконечность", а вот что выдает процессор ПР -интересно.

В документации ОЛ сказано, что

При делении на 0 на выходе элемента будет значение 0хFFFFFFFF.

[Серёга Букашкин]

В документации ОЛ сказано, что

Да, но это сказано про целочисленное деление, а про fDiv ни чего не сказано. Для целочисленного вроде бы и логично если так как сказано, но в симуляторе при делении на "0" дает "0", и это напрягает. Так что на самом деле? Я не проверял на ПР, а на симуляторе дает "0", что не соответствует описанию ОЛ.

[Мамонов Михаил]

Проверил на живой ПР200: fDiv 0/0=0. Ничего не зависает.

По исходнику из CoDeSys - когда-то очень давно (лет 8 назад) скопировал из Util.lib себе в проект - нужна была только эта функция. Там тоже деление на ноль не проверялось. Вот:
K := (OUT_MAX - OUT_MIN) / (IN_MAX - IN_MIN);
IF (IN <= IN_MIN) THEN
LIN_TRAFO_FUN := OUT_MIN;
END_IF;
IF ((IN > IN_MIN) AND (IN < IN_MAX)) THEN
LIN_TRAFO_FUN := OUT_MIN + K * (IN - IN_MIN);
END_IF;
IF (IN >= IN_MAX) THEN
LIN_TRAFO_FUN := OUT_MAX;
END_IF;
Поскольку IN_MIN,IN_MAX,OUT_MIN,OUT_MAX у меня всегда задавались константой при программировании - никогда на деление на ноль не нарывался.
Сейчас глянул в Util.lib, котрорая вместе с текущей версией CoDeSys поставилась - там вообще все по другому, и деление на ноль проверяется, и выход ошибки появился..

Нашел еще - такой макрос уже на форуме пробегал, только для ПР114 - http://www.owen.ru/forum/showthread....l=1#post123611. Там тоже деление на 0 не проверяется.

[Серёга Букашкин]

Проверил на живой ПР200: fDiv 0/0=0. Ничего не зависает.

Как раз 0/0=0 проверять не надо, это и в симуляторе так. Интересен вариант чистого деления на ноль, например 100/0 для float и для целочисленных. Результат может оказаться разным и удивить. Уже то, что имеем противоречие показаний в симуляторе с описанием ОЛ при делении на "0" напрягает.

[Мамонов Михаил]

Проверил:
INT 100/0 в симуляторе =0, в живом контроллере =4294967295 (если ограничить вывод на экран в 3 знака, то покажет 999)
FLOAT 100/0 в симуляторе пишет "бесконечность", в живом контроллере 999999,9

Проверял через вывод на экран, кол-во знаков переменной ставил максимальное (11 для INT и 7 для FLOAT)
Ну результат как бы закономерный - живой контроллер пытается взять максимально большое число для данного типа, с эти можно согласиться при отсутствии в нем системы контроля таких ошибок, симулятор с FLOAT ведет себя тоже правильно, а вот с INT - как то странно..