Модели поведения в CODESYS 2.3

[capzap]

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

ЗЫ прочитал, в доках используется REPEAT почему используете WHILE

[Осинский Алексей]

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

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

В "модели поведения" основная идея в том, что по интерфейсу ФБ можно быстро понять как этот ФБ работает:

1. работа по уровню, или по переднему фронту;
2. есть ли возможность прервать работу блока;
3. есть ли возможность ограничить время цикла блока;
4. есть ли возможность задать таймаут работы блока;

А решаемую при помощи этого ФБ задачу программист реализует сам, накладывая решение на "скелет".

Обратите внимание на п.3 списка выше.
Есть модель поведения, которая позволяет ограничить время, которое ФБ потратит в 1 цикле ПЛК, после чего отложит выполнение на следующий цикл ПЛК (это модели поведения с буквами TL в названии (например, ETrigTl)).
Т.е. если есть предпосылки для того, что работа ФБ будет сильно увеличивать время цикла ПЛК, нужно будет просто использовать соответствующую модель поведения, и сама модель позаботиться о том, чтобы отложить выполнение при достижении ограничения.
Пользователю лишь останется написать код так, чтобы при следующем вызове выполнение продолжилось с того же места, на котором было прервано в предыдущем цикле.

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

все локальные переменные оформить в UDT структуру

В данном случае не вижу преимуществ в передаче структуры в функцию и ФБ.
Заменив переменные ФБ на структуру мы обяжем пользователя работать со структурой в его программе (мониторить xDone, xBusy, изменять xExecute), что на CFC совсем не очевидно.
По итогу результат будет тем же, но

подавать на вход функции через указатель

новичков это отпугнет.

[Салихов Ильдар]

В "модели поведения" основная идея в том, что по интерфейсу ФБ можно быстро понять как этот ФБ работает:

1. работа по уровню, или по переднему фронту;
2. есть ли возможность прервать работу блока;
3. есть ли возможность ограничить время цикла блока;
4. есть ли возможность задать таймаут работы блока;

А можно небольшое объяснение?
По пунктам 2,3,4 какое то понимание есть, а вот по 1 пункту... Понятно как это работает, непонятно как применить. В каких случаях следует использовать логику по уровню, а в каких по фронту?

Спасибо.

[Осинский Алексей]

А можно небольшое объяснение?
По пунктам 2,3,4 какое то понимание есть, а вот по 1 пункту... Понятно как это работает, непонятно как применить. В каких случаях следует использовать логику по уровню, а в каких по фронту?

Спасибо.

Не так давно этот документ был переведен на русский язык (доступен по ссылке).

Не смотрели документ по ссылке выше?

Если вкратце, то

• ФБ с работой "по уровню" выполняет некую задачу до тех пор, пока на входе xEnable присутствует высокий уровень сигнала (например, утюг, поддерживает температуру до тех пор, пока включен в розетку);
• ФБ с работой "по фронту" начинает выполнение некой задачи по переднему фронту сигнала xExecute и до тех пор, пока задача не будет выполнена (например, стиральная машина: программу выбрали, кнопку нажали, закончит стирку - пропищит).

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

[Осинский Алексей]

ЗЫ прочитал, в доках используется REPEAT почему используете WHILE

Мы не используем цикл REPEAT т.к. его использование ухудшает читабельность программы:
чтобы понять до каких пор будет выполняться цикл нужно пролистать до конца цикла и только потом станет понятно условие выхода.

Цикл WHILE лишен этого недостатка: условие выхода становится понятным уже на 1й строке.

[capzap]

Мы не используем цикл REPEAT т.к. его использование ухудшает читабельность программы:
чтобы понять до каких пор будет выполняться цикл нужно пролистать до конца цикла и только потом станет понятно условие выхода.

Цикл WHILE лишен этого недостатка: условие выхода становится понятным уже на 1й строке.

не совсем так, переменную мы найдем в while в начале блока, а в repeat в конце блока, а условие выхода нужно искать в теле обоих циклов и чтоб быть уверенным что оно несколько раз не изменяется, в каждом случае надо пролистывать от начала и до конца блока, между ними лишь одна разница repeat один раз но выполниться

[Осинский Алексей]

не совсем так, переменную мы найдем в while в начале блока, а в repeat в конце блока, а условие выхода нужно искать в теле обоих циклов и чтоб быть уверенным что оно несколько раз не изменяется, в каждом случае надо пролистывать от начала и до конца блока, между ними лишь одна разница repeat один раз но выполниться

Мы не используем (за исключением редких случаев) прерывание цикла при помощи CONTINUE и EXIT т.к. это ухудшает читабельность кода (п. 6.5.2 PLCopen Coding Guidelines):
пробежавшись глазами по телу цикла легко пропустить такой оператор, и сидеть, недоумевая, над программой, в попытках понять, почему этот конкретный участок кода не выполняется.
А спустя какое-то время увидеть, что перед ним стоял оператор EXIT.

В большинстве случаев, тело цикла можно переписать так, чтобы обойтись без этих операторов.

UPD: Из тех же соображений избегаем использования RETURN.