Ещё одна особенность, на мой взгляд явный косячок.
Два экрана. С первого на второй переход осуществляется по УДЕРЖАНИЮ клавиши "ОК". Со второго на первый НАЖАТИЕМ клавиши ОК.
За переходом с первого экрана на второй сразу же следует переход обратно (пользователь не успел отдёрнуть палец). Что на мой взгляд явно не корректно.
События не должны генерироваться одно за другим без отпускания клавиши, либо менять свою последовательность!
Пример https://yadi.sk/d/WpnvUuYE3JW63U
Умный человек - с лёгкостью решает любые проблемы. Мудрый - их не создаёт.
https://vk.com/a.matica
Проект: https://yadi.sk/d/RYz75Xlz3JW6Ns
Умный человек - с лёгкостью решает любые проблемы. Мудрый - их не создаёт.
https://vk.com/a.matica
В продолжение - в окне просмотра в любом случае выход с плавающей запятой показывается как булевский со значениями 0 или 1. На рисунке - создал макрос и сразу ему выход обозвал "с плавающей запятой", не присоединяя его до этого никуда. Все равно показывает его как булевский.
Снимок.PNG
P.S. На рисунке очень полезный макрос LinTrafo - перерисовал из CoDeSys библиотеки Util.lib - масштабирование входного значения к выходному. Жалко, что его нет в библиотеке онлайн-макросов
Там что, тоже не защищаются от деления на "0"? А если InMax=InMin? Интересно что будет в этом случае на ПР? Потому что имелись случаи, в библиотеке PL/M например, что если делитель "0"- программа зависает (jmp на себя). Ну правильно, нельзя же делить на "0",... но и зависать нельзя. Симулятор в таком случае выдает "бесконечность", а вот что выдает процессор ПР -интересно, и что происходит с бесконечностью при дальнейшей арифметике с нею.
Последний раз редактировалось Серёга Букашкин; 27.05.2017 в 19:34.
Да, но это сказано про целочисленное деление, а про fDiv ни чего не сказано. Для целочисленного вроде бы и логично если так как сказано, но в симуляторе при делении на "0" дает "0", и это напрягает. Так что на самом деле? Я не проверял на ПР, а на симуляторе дает "0", что не соответствует описанию ОЛ.
Последний раз редактировалось Серёга Букашкин; 27.05.2017 в 19:56.
Проверил на живой ПР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 не проверяется.
Последний раз редактировалось Мамонов Михаил; 28.05.2017 в 00:05.
Как раз 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 - как то странно..