Философский вопрос…
Выходы ПЛК можно включать/выключать в разных шагах, при этом будут активироваться/деактивироваться некие механизмы и 'нечто' делать сами (как бы аппаратно определенные действия). Это нормально? Это связано с маркерами? Вероятно, да.
Теперь допустим, мы хотим этим 'нечто' управлять с контроллера более детально. Вместо сущности 'переменная' введем сущность работа или 'действие', которое можно точно также включать/выключать в разных шагах. В МЭК SFC примитивным действием может быть переключение логической переменной (имя BOOL переменной можно в лоб писать вместо имени МЭК действия), но мы имеем замечательную возможность наполнить действие чем-либо более программно сложным. Есть ли большая разница между включением/выключением по маркерам переменных и действий? Практически никакой.
Действия МЭК – это довольно самостоятельные сущности, их можно запускать и останавливать, как и некие внешние устройства. Маркер же действительно ходит по шагам и управляет МЭК действиями, как директор фирмы разными отделами и их работами. Сотрудники не должны все бросать, если директор ушел.
При этом подходе, глядя на SFC схему мы не должны брать в голову, что делается внутри каждого действия. Этого SFC схема не описывает. Она активирует и деактивирует действия в нужных шагах, в нужное время. Ключевым является 'шаг-условие-переход'. Действия (переменные) – это только инструмент исполнения решений SFC.
2Игорь Петров
Да,я понимаю о чем вы говорите. И с практически (а может и полностью) с Вами согласен. Просто меня смущает следующее: Я начал активно примять SFC в своих проектах после того, как начал копатьсяв теме конечных автоматов, диаграмм состояний и т.д. Т.е. для меня SFC на сегодняшний день это компромисс между своими старыми решениями в области программирования прикладных программ ПЛК (причем не только в среде Codesys, но и массе МЭК-экзотики) и пока еще не освоенной (по крайней мере на том уровне,чтобы можно было применять в коммерческих проектах) switch-технологии. Т.е. я пытаюсь при помощи SFC создать некую структуру (не знаю корректно ли нызывать ее автоматом) с заданным и определенным количеством состояний, чтобы исключить неоднозначность как на программном уровне, так и на уровне документирования\сопровождения\модернизации проекта. Все чаще приходится работать над проектами совместно с кем-то, очень трудно разбираться в чужом коде, тем более когда решения скажем, мягко, "не тривиальны". Вот и пытаюсь выработать некий "стандард" (хотя бы в рамках своей фирмы) для написания\сопровождения плк-программ.
Потому меня и смущает эта неоднозачность с МЭК-дейсвиями. Но будем разбираться, копать дальше:-)
для этого появился конвертер http://www.owen.ru/forum/showthread....4646#post74646