Я не думаю, что неподготовленный пользователь полезет менять то, в чем не понимает.
Для неподготовленных - четко указано, где и что писать.
Подготовленные пользователи, наоборот, могут оптимизировать этот "скелет" так, чтобы он более четко соответствовал решаемой задаче.
В "модели поведения" основная идея в том, что по интерфейсу ФБ можно быстро понять как этот ФБ работает:
- работа по уровню, или по переднему фронту;
- есть ли возможность прервать работу блока;
- есть ли возможность ограничить время цикла блока;
- есть ли возможность задать таймаут работы блока;
А решаемую при помощи этого ФБ задачу программист реализует сам, накладывая решение на "скелет".
Обратите внимание на п.3 списка выше.
Есть модель поведения, которая позволяет ограничить время, которое ФБ потратит в 1 цикле ПЛК, после чего отложит выполнение на следующий цикл ПЛК (это модели поведения с буквами TL в названии (например, ETrigTl)).
Т.е. если есть предпосылки для того, что работа ФБ будет сильно увеличивать время цикла ПЛК, нужно будет просто использовать соответствующую модель поведения, и сама модель позаботиться о том, чтобы отложить выполнение при достижении ограничения.
Пользователю лишь останется написать код так, чтобы при следующем вызове выполнение продолжилось с того же места, на котором было прервано в предыдущем цикле.
Я постараюсь выделить время и подготовить пару примеров "из жизни" для того, чтобы ближе познакомить новичков с моделями поведения и их использованием в проектах.
В данном случае не вижу преимуществ в передаче структуры в функцию и ФБ.
Заменив переменные ФБ на структуру мы обяжем пользователя работать со структурой в его программе (мониторить xDone, xBusy, изменять xExecute), что на CFC совсем не очевидно.
По итогу результат будет тем же, но
новичков это отпугнет.