Занимательные задачи, №35, Использование инструкций перехода. Опции

[Sergei Troizky]

В заголовке опечатка. Это- Задача №36.

Задача не требует для ответа написания какого-либо кода.
Вначале- пара цитат.

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

Согласен, что использовать переход в основной программе, если без него можно обойтись, плохо.

Не будем обсуждать, что именно гласит на этот счет теория, и почему.
Задание. Назовите, применительно именно к ПЛК:
а) Практические причины, почему инструкций перехода лучше избегать.
В том числе, конкретно для серии FX, если, на ваш взгляд, такая специфика существует.
б) Случаи, когда инструкции перехода полезны.
В том числе, конкретно для серии FX, если, на ваш взгляд, такая специфика существует.
в) Случаи, когда без инструкций перехода не обойтись. Если такие случаи вообще существуют.
Уточнение: в вопросах речь именно об инструкциях перехода, а не о вызове подпрограмм.
Ясно, что ответы будут в определенной мере субъективными и, возможно, неполными.
Соображения просуммируем, закрывая задачу.

Вопрос к inntele, по цитате.
Почему только "в основной программе"?

Реплика по теме, не связанная с заданием:
Вопреки не только теории, но и практическим ограничениям,
компилятор GX IEC Developer использует переходы напропалую, при компиляции каждого IF.
Поправьте, если неправ, но именно так мне показалось, из недолгого с ним знакомства.
И это при том, что в LD каждый rung по определению- структура IF ELSE.

Сообщение отредактировал Sergei Troizky - 16.03.2014 - 02:32

[inntele]

Вопрос к inntele, по цитате.
Почему только "в основной программе"?

Я неясно выразил то, что хотел донести этой фразой.
Инструкции перехода вообще следует применять крайне аккуратно во всей программе, а, по возможности, стараться и вовсе избегать их применения. По отношению же к основной (головной) программе это особенно важно: помимо проблем с превышением времени скана, к которым способны привести переходы "назад" и перекрещенные переходы, бездумное использование данных команд способно повлечь потерю читабельности программы. В тех же случаях, когда без этих команд не обойтись, просто необходимо прибегать к нехитрым правилам, быть осмотрительным и предварительно прокручивать программный код в голове.

Реплика по теме, не связанная с заданием:
Вопреки не только теории, но и практическим ограничениям,
компилятор GX IEC Developer использует переходы напропалую, при компиляции каждого IF.
Поправьте, если неправ, но именно так мне показалось, из недолгого с ним знакомства.
И это при том, что в LD каждый rung по определению- структура IF ELSE.

Это не так.

[ivgtrk]

(#36)
а) ну во первых, как уже говорилось - это влияет на читабельность самой программы. Во вторых, действительно, необходимо внимательно контролировать их применение и достаточно точно представлять, как эти конструкции будут работать. Ибо в некоторых ситуациях, с использованием переходов (касательно ПЛК), могут возникнуть ошибки.
Само по себе, применение условных переходов позволяет писать некие программы, которые "могут принимать решения", на основании тех или иных входящих условий. В этом, пожалуй, и заключается основаная суть применения переходов. В ПЛК же, имеется масса, скажем так, более "наглядных" способов это осуществить, не прибегая к CJ.

б) особых таких случаев на первый взгляд не вижу. Ну разве что возможность пропуска частей программы, возможность дублирования выходов... Но опять же, все это упирается в грамотную реализацию переходов в программе.

в) если такие случаи и есть, то я покамест с такими ситуациями не сталкивался. Если провести параллель с другими яз. программирования, то да, встречались ситуации, где без перехода не обойтись, и то(!) - это скорее "псевдо"- необходимость, дабы не увеличивать код, прибегая к различным уловкам и т.п.

И это при том, что в LD каждый rung по определению- структура IF ELSE.

Хм... Если это так, то невижу логики такого подхода.

Конструкция IF [условие] если TRUE, то
- CASE 1;
ELSE (если FALSE)
- CASE 2;
END IF

тоже является инструкцией условного перехода по событию, однако, сама форма представления ее, явно более понятна, чем "прыжки" по программе инструкциями CALL, GOTO, ну и CJ (ПЛК). Конечно это справедливо для тех случаев, когда в тело (CASE) включена некая последовательность явно описанных команд, а не ссылка (читай - переход) в некую область основной программы.

Кстати, это навело меня на еще одну, не менее интересную мысль. Касательно инструкций FOR-NEXT, именно применительно к ПЛК, т.к. сама по себе выполняемая программа в нем циклична. Вот здесь уже напрашивается некий компромисс, между возможностью применения этой комбинации, что безусловно задерживает основной цикл программы, или же возложить команды, которые находятся внутри FOR-NEXT на обработку самой "цикличной" программы ПЛК. Но все зависит от потребностей, конечно.

Сообщение отредактировал ivgtrk - 17.03.2014 - 06:19

[m_by]

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

[ivgtrk]

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

а) верно! причем имеются еще некоторые дополнительные нюансы, связанные, например, с применением таймеров в "перепрыгнутом" куске программы.
б) и в) :

В ПЛК же, имеется масса, скажем так, более "наглядных" способов это осуществить, не прибегая к CJ.

Например, ничто не мешает вынести "тяжелые куски" вычислений в отдельный POU, и вызывать его при необходимости.

(развиваю мысль )

[Sergei Troizky]

Реплика по теме, не связанная с заданием:
Вопреки не только теории, но и практическим ограничениям,
компилятор GX IEC Developer использует переходы напропалую, при компиляции каждого IF.
Поправьте, если неправ, но именно так мне показалось, из недолгого с ним знакомства.
И это при том, что в LD каждый rung по определению- структура IF ELSE.

Это не так.

А как же вот это? http://www.melsec.ru/forum/index.php?showt...&#entry5666
Сообщения №3 и №6.

[Sergei Troizky]

... ничто не мешает вынести "тяжелые куски" вычислений в отдельный POU, и вызывать его при необходимости.

В откомпилированном IL, это и будет означать либо подпрограмму, либо обход фрагмента программы путем CJP. То же самое и применительно к IF-ELSE, либо IF-CASE-...
Вопрос в задаче не относился к языкам высокого уровня.

Сообщение отредактировал Sergei Troizky - 21.03.2014 - 08:18

[inntele]

Реплика по теме, не связанная с заданием:
Вопреки не только теории, но и практическим ограничениям,
компилятор GX IEC Developer использует переходы напропалую, при компиляции каждого IF.
Поправьте, если неправ, но именно так мне показалось, из недолгого с ним знакомства.
И это при том, что в LD каждый rung по определению- структура IF ELSE.

Это не так.

А как же вот это? http://www.melsec.ru/forum/index.php?showt...&#entry5666
Сообщения №3 и №6.

Не сразу понял, что речь шла об ST, которым принципиально не пользуюсь.
В этом плане могу заметить следующее:
1) Точно так же, как лингвальный перевод с одного языка, которым пользуются люди для общения между собой, на другой сильно зависит от ментальности и квалификации переводчика, так и результат компиляции с языка, далекого от языка ПЛК, на язык, понятный контроллеру, целиком и полностью зависит от программиста, который этот компилятор прописал. Тот кто писал, очевидно полагал, что способ компиляции, реализованный им, суперский, не обращая при этом внимание на издержки, связанные с реализованным им способом.
2) В ветке шло обсуждение проблем с компиляцией структур языка ST в очень старой версии GX IEC Developer v7.01. За истекшее время вышло несколько новых версий, последняя из выпущенных v7.04. Техника компиляции во вновь вышедших версиях, как правило, отличается от предшествующих, в чем можно убедиться , если зайти в меню Extras-Options-Project Options-Code Generation. Так что, возможно, "косяк" компилятора, который обсуждался вами в топике, уже не актуален.

Самое лучшее - владеть языком оригинала/писать в синтаксисе контроллера. Тогда промежуточное звено со своими "тараканами" в голове не будет мешать правильно доносить мысли.

Сообщение отредактировал inntele - 21.03.2014 - 08:52

[ivgtrk]

... ничто не мешает вынести "тяжелые куски" вычислений в отдельный POU, и вызывать его при необходимости.

В откомпилированном IL, это и будет означать либо подпрограмму, либо обход фрагмента программы путем CJP.

И тем не менее, это является один из подходов к разбиению основной программы на выполняемые по условию части.
В вопросе (видимо) не рассматривается, как именно компилятор реализует обход, а имелось в виду явное применение CJ программистом.

Сообщение отредактировал ivgtrk - 22.03.2014 - 07:19

[Sergei Troizky]

Выскажу свои соображения.
Инструкции перехода демонизировать не стоит.
Будь они слишком вредны, нашли бы способ вообще обойтись без них.
Разумеется, злоупотреблять ими не стоит, но так можно сказать о чем угодно.

Соображения об ухудшении читабельности программы мне кажутся несостоятельными. Не отказываемся же мы из этих соображений от подпрограмм, хотя вызов подпрограммы и возврат из нее- те же самые переходы, к тому же последний не содержит явно указанного адреса.
Для читабельности гораздо важнее общая структура программы и тщательное комментирование, особенно нестандартных приемов и неочевидной логики в работе оборудования.

Суммируя плюсы и минусы переходов:

Переходы назад- единственный, кроме FOR-NEXT, способ реализовать програмно любые виды циклов внутри скана.
Однако, слишком массивные либо слишком многопроходные циклы удлиняют скан, вплоть до срабатывания сторожевого таймера и остановки ПЛК.

Переходы вперед- способ обхода ненужного в данный момент фрагмента программы, для сокращения времени скана, либо для полного его исключения из выполняемой логики (напр. в силу конфигурации конкретного оборудования с универсальной программой).
Это- альтернативный способ организовать POU, наряду с подпрограммами.

При обходе фрагмента программы, последний не выполняется, что может вызвать затруднения с диагностикой при мониторинге.
Однако, эта проблема существует при любой технике программирования, где фрагмент кода может не выполняться непрерывно. А именно- подпрограммы, включая прерывания, и состояния STL.

Напоследок, небольшой экскурс на тему переходов, но отойдя от ПЛК
(не претендуя на полноту и академическую строгость).
Согласно теории, для алгоритмической полноты языка программирования, наличие в нем инструкций перехода необязательно.
На уровне кода микропроцессора, команды перехода сбивают работу кэша (конвеерной памяти), снижая тем самым производительность.
В хорошо структурированных языках высокого уровня, использование переходов считается излишним. Спешу добавить, что IL/LD к таковым никак не относится.

Сообщение отредактировал Sergei Troizky - 26.03.2014 - 06:30

[ivgtrk]

Соображения об ухудшении читабельности программы мне кажутся несостоятельными. ...

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

Переходы вперед- способ обхода ненужного в данный момент фрагмента программы, для сокращения времени скана, либо для полного его исключения из выполняемой логики (напр. в силу конфигурации конкретного оборудования с универсальной программой).
Это- альтернативный способ организовать POU, наряду с подпрограммами.

Пожалуй, это единственный пример целесообразного применения переходов (в данном случае, с ПЛК).

На уровне кода микропроцессора, команды перехода сбивают работу кэша (конвеерной памяти), снижая тем самым производительность.

Отнюдь, не всегда.

В хорошо структурированных языках высокого уровня, использование переходов считается излишним. Спешу добавить, что IL/LD к таковым никак не относится.

Совершенно верно.