Отработка деления на 0

[Nortmn]

Возник вопрос, как осуществить отработку контроллером(Siemens S7-300) ошибки при делении числа на 0 ?

[Jackson]

Элементарно. Не допускать деления на ноль.
Перед делением проверить, не равен ли знаменатель нулю.

[Nortmn]

Отличный совет 10/10

Отправлено спустя 2 минуты 8 секунд:
Вопрос состоит не в том "как не допускать деление на 0", а как такие ошибки отрабатывать, какие OB для этого подходят и тп?

[SMax]

0001.png

Отправлено спустя 3 минуты 47 секунд:

0002.png

[Jackson]

Вопрос состоит не в том "как не допускать деление на 0", а как такие ошибки отрабатывать

Тоже логично. Но если не допускать, то и обрабатывать не надо.
Кое-где с меня даже требовали в документации представить доказательства того, что такие ошибки в программе отсутствуют (деление на ноль, бесконечный цикл, условный переход на несуществующую метку и т.п.). В итоге программа была написана так, что там совсем не было ни одного деления, цикла и перехода.

[Sergy6661]

В итоге программа была написана так, что там совсем не было ни одного деления, цикла и перехода.

И это таки идеальный вариант и если без циклов и деления довольно грустно бывает, то безусловные переходы это абсолютное зло.
Я вот не заморачиваюсь проблемой деления на 0, т.к просто стараюсь не допускать его, но что будет с ПЛК S7-300? Перейдет в стоп?

[Romcheg]

Обычно у вычислителя есть регламент по этому поводу. Вон, у Сименса выше привели значения флагов.
Я когда свой движок вычислителя для FBD делал, то заложил штатные ситуации со значениями, например - деление на ноль дает в результате бесконечное значение (INF, причем как положительное может быть, так и отрицательное), которое можно алгоритмически контролировать. Это как раз делается для того, чтобы не словить критическую ошибку, которая остановит работу вычислителя.
Как это контролировать: до вычисления, или постфактум - это уже дело программиста-прикладника, но, сам движок вычислителя дает гарантию, что процесс не остановится при таких ситуациях.

[Jackson]

но, сам движок вычислителя дает гарантию, что процесс не остановится при таких ситуациях.

А почему, если процесс не остановится - это правильно? Процесс пойдёт дальше с некорректным значением и один RND знает к чему это может привести в установке в целом - так? В приведённом примере - с до упора большим или малым значением. То есть цифра должна была получиться равная, к примеру, 2, а получилась 65535, и к примеру это расчётная дозировка химиката в какой-то установке. На выходе получится вместо лёгкого раствора адов концентрат, который должен был, к примеру, слегка ароматизировать воздух, но в итоге всех убьёт. Resident Evil, часть первая. Так?

Поэтому, если контроллер с ошибкой исполнения программы уходит в СТОП - вот это как раз правильно. А Производитель позаботился не о том чтобы процесс не остановился, а о том чтобы персонал смог узнать причину остановки. Уже задача программиста - не допустить этого - а не контроллера.

Если не ошибаюсь, это нормативное требование - чтобы система при внутренних ошибках ушла в безопасное состояние до выяснения.

Автор об этом всём и не спрашивал. Он спросил

как осуществить отработку контроллером(Siemens S7-300) ошибки при делении числа на 0 ?

И ответ здесь только один: это уже сделано в самом контроллере его производителем, и ответили как сделано. А что с этой ошибкой потом делать - это уже совсем другая история.

Отправлено спустя 16 минут 8 секунд:

И это таки идеальный вариант и если без циклов и деления довольно грустно бывает

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

Отправлено спустя 8 минут 32 секунды:
Кстати, по опыту, панель Weintek при ошибке деления на 0 в скрипте не останавливается - просто скрипт прерывается. Системными переменными можно увидеть, что скрипт был прерван, но причина не будет показана - негде. В формах та же ситуация - форма показывает некорректное значение вместо требуемого. Но панелька Weintek - это и не контроллер, она ничем не управляет а только картинки показывает.

[Никита]

А почему, если процесс не остановится- это правильно?

А потому, что это проблема программиста. В каких-то случаях наоборот, может быть важнее продолжение выполнения других задач. Проблема требует ручного разрешения.
Вот не могу сказать за процессоры Siemens, но на Intel, начиная с рождения x86 линейки (может и раньше, но я не застал) деление на ноль вызывало прерывание, причем немаскируемое (вызов нельзя запретить), для которого можно было написать свой обработчик и корректно обработать ситуацию, а можно отдать на откуп операционной системе - тогда программа завершалась и управление возвращалось ОС.
Здесь может быть такая же ситуация - обрубается процесс, а все остальное продолжает жить, причем этот же процесс, скорее всего, можно на следующем цикле запустить и повторно. Увы, по симатикам такой же литературы, как по x86 и ARM нет.
Так и тут в общем-то. Возможность отловить есть, стало быть и решай сам, а как по умолчанию себя поведет система - так поэкспериментировать проще, чем рассуждать, даже на штатном симуляторе)
А вот по сути вопроса - отловить это на 300й серии, увы, не подскажу.

А если он оказался равным нулю - уже от задачи зависит, что с этим делать.

Не нулю и не равным. По уму надо делать проверку на то, что величина делителя по модулю больше некоторой малой величины, которая больше машинной погрешности.

то безусловные переходы это абсолютное зло

Для работы с языками высокого уровня. Но стоит спуститься чуть ниже... Второе, что делает процессор после сброса - переход на адрес начала программы. Кстати, таблица прерываний устроена также- по адресам, соответствующим номеру лежат джампы на обработчики:)
А вообще это мы уже обсуждали - никакие проверки на языке высокого уровня ничего не гарантируют. Они лишь перекладывают ответственность с того, кто разрабатывает прикладное ПО на того, кто разрабатывал компилятор. Впрочем и на ассемблере, после появления разных фич типа предсказания переходов, оптимизации конвейеров и многопоточности с многоядерностью уже ничего гарантировать нельзя...

[Jackson]

Проблема требует ручного разрешения.

Вот именно. Известные мне ПЛК в этом случае уходят в СТОП. Но S7-300 не в их числе (конкретно этот вопрос про него мне неизвестен). Да чего спорить - в документации Сименса написано, что будет в этом случае.

Вот не могу сказать за процессоры Siemens, но на Intel,

Дело не в процессоре. Дело в ПЛК как законченном изделии. В нём есть ОС и она этим занимается, у пользовательской программы нет туда доступа, кроме системных регистров. Ибо не нужно, потому что

правильный контроллер, как я Выше писал, при делении на 0 должен уйти в СТОП и тогда никакая обработка уже не поможет - программа не выполняется

.

[stesl]

Не задавался конкретно этим вопросом. Однако у Сименс общая идеология такая - при возникновении любой ошибки происходит прерывание и вызывается определённый ОВ. Понятно что нет ОВ под каждую ситуацию - ситуации сгруппированы. Ошибка связи - один ОВ, модуля - другой. По выполнения программы тоже есть ОВ. Если нужного ОВ в тексте нет, вот тогда ПЛК в стоп.
Поэтому просто в Степ напишите деление на 0 и запустите на симуляторе. И сразу станет ясно. Думаю, что затребует ОВ 122 и уйдет в стоп.

Поэтому крайне плохо программировать соответствующие ОВ пустыми.

[SMax]

По выполнения программы тоже есть ОВ. Если нужного ОВ в тексте нет, вот тогда ПЛК в стоп.

S7 300 при делении на 0, OB не вызывает и в стоп не уходит. Выставляет только статусные биты.

[+] Организационный блок ошибок программирования (OB121)

001.png

[stesl]

OB не вызывает

А если не вызывает, то о чем эта таблица? )
Да, я сказал 122 наобум. Возможно и 121

[SMax]

А если не вызывает, то о чем эта таблица?

О том что там нет ошибки деления на 0.

[stesl]

О том что там нет ошибки деления на 0.

Ну как то печально ) Флаги эти - только слышал о их наличии, никогда не использовал. Так по факту то что произойдет? Поделит на ноль? ) Или откажется делить?

[SMax]

Проверял с типом INT, при делении на 0 - на выходе 0

[Sergy6661]

Проверял с типом INT, при делении на 0 - на выходе 0

А вот с Real уже интереснее.

Division_Null.jpg

[SMax]

В классике с REAL какое-то свое представление некорректного вещественного числа.
(контроллер реальный CPU 315 2DP, не симулятор)

001.png

[Looker]

В классике с REAL какое-то свое представление некорректного вещественного числа.

См. IEEE 754.

• формат чисел с плавающей точкой: мантисса, экспонента (показатель), знак числа;

• представление положительного и отрицательного нуля, положительной и отрицательной бесконечностей, а также нечисла́ (англ. Not-a-Number, NaN);

• методы, используемые для преобразования числа при выполнении математических операций;

• исключительные ситуации: деление на ноль, переполнение, потеря значимости, работа с денормализованными числами и другие;

• операции: арифметические и другие.

[SMax]

Да, с NaN все понятно, но там: +1.#IOe+000
Этот же выход в CFC представляется как: #e+INF