Как работает шаг SFC, написанный на SFC?

[Yegor]

Бвахахахаха жесткач. Смарите пацаны чё натворить можно:

sfc_wtf.png

Открываем стандарт, 2.6.5 Rules of evolution

Evolutions of the active states of steps shall take place along the directed links when caused by the clearing of one or more transitions.

Очевидно, с позиции внешнего автомата данное правило нарушается. Ну а с позиции внутреннего автомата нарушается 2.6.3 Transitions:

A transition represents the condition whereby control passes from one or more steps preceding the transition to one or more successor steps along the corresponding directed link

В результате внешний автомат получает два (минимум) активных шага вопреки условию перехода, а внутренний автомат остаётся без активности. А всё почему? Да потому что кто-то позволил писать в это поле что попало:

sfc_transition_to_outer.png

... и почему-то сделали так, что шаги автоматов всей иерархии оказываются в одной области имён. Хм, а я знаю почему: потому что шаги включаются в область имён вышестоящего POU как самостоятельные имена. Если бы разработчики компилятора не поленились и ввели бы отдельные структуры для каждого автомата или не рассматривали шаги как именованную единицу компиляции, такой фигни бы не было.

Выходит, что с кодесисом надо очень чётко разделять вопросы «как работает» и «как формально описывается». Я бы сказал, что переход маркера из автомата в автомат в рамках стандарта рассматривать вообще нет смысла — это не допускается определениями переходов и порядка вычисления. При этом правила не запрещают вкладывание SFC в SFC и напоминают, что даже при соблюдении всех правил возможно сформулировать в принципе нефункционирующий и/или самоблокирующийся автомат, только среда исполнения должна считать возникновение такой ситуации ошибкой:

The application of the rules given in this subclause cannot prevent the formulation of “unsafe” SFCs, such as the one shown in figure 18 a), which may exhibit uncontrolled proliferation of tokens. Likewise, the application of these rules cannot prevent the formulation of “unreachable” SFCs, such as the one shown in figure 18 b), which may exhibit “locked up” behavior. The programmable controller system shall treat the existence of such conditions as errors as defined in 1.5.1.

Проект прилагается к посту. Для воспроизведения проблемы открыть визуализацию и воспользоваться кнопками: один раз Next outer, три раза Next inner.

[rapucha]

У меня претензии, если есть, то скорее к стандарту --- конструкция из вложенных SFC функционирует недостаточно очевидно, а кларификаций никаких нет.

Еще на SFC можно нарисовать action. Думаю, там меня тоже ждут открытия ))

[Валенок]

Да потому что кто-то позволил писать в это поле что попало:

Классический goto из внутреннего цикла.

Смарите пацаны чё натворить можно

Можно еще сделать goto внутрь )))

Видимо среда считает что кому-то это нужно. Типа пока маркеры не слиплись, одного еще можно отравить домой.

В action - такие goto нормально заблокированы. Но все равно накосячили с локализацией имен.

Зачем мусолить косяки разработчиков. Косяк не есть предмет для РЭ, о косяке нужно предупредить "вне перехода переходить запрещено, сетку на разделителе прокакали". А дальше - сами.

[Yegor]

Видимо среда считает что кому-то это нужно.

Не уверен насчёт «считает». Сдаётся мне, такие возможности не задумывались. Просто все шаги в одну кучу сваливаются. Вот сообщение, которое выдаёт всю костыльную сущность компилятора:

duplicate.png

Надо будет в третьем кодесисе попробовать.

[petera]

Не уверен насчёт «считает». Сдаётся мне, такие возможности не задумывались. Просто все шаги в одну кучу сваливаются. Вот сообщение, которое выдаёт всю костыльную сущность компилятора:

duplicate.png

Надо будет в третьем кодесисе попробовать.

Это не ошибка компилятора.
Имя шага тоже переменная (тип BOOL). Только не явная.
Захват-1.png
Она доступна даже из вне POU, в вызывающей программе,например, можно узнать какой шаг внутри программы STC активный.
Или ее можно было использовать в Вашем примере с размножением маркеров, для того, чтобы их "склеить".
Или вот например
Захват-2.png
В моем случае маркеры параллельных ветвей "склеятся" после выполнения шага "OSTANOV"

[Yegor]

Это не ошибка компилятора.
Имя шага тоже переменная (тип BOOL). Только не явная.

Да, я ещё вчера сказал, что «шаги включаются в область имён вышестоящего POU как самостоятельные имена». Прошу обратить особое внимание на текст сообщения компилятора: «Duplicate step name». И указывает это сообщение на шаг, а не на явно объявленную переменную типа INT. В корректной реализации с «неявными» переменными должно быть либо другое сообщение, либо декорирование имён шагов целиком (приписывание всяких прочерков и т.п. примерно как это описано в вашем источнике).

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