Монограф

[gtfox]

Поясните, пожалуйста. Не понял.

Рисуем программу на SFC в редакторе CoDeSys, сохраняем.
Если выделить, скопировать эту программу и вставить в редактор SFC STEP7 (IEC Developer, ISaGRAF), то ничего не выйдет, форматы хранения и описания графических языков в разных средах разные. А вот программы на текстовых языках переносятся и работают без глобальных проблем.

разработчики SWITCH-технологии далеки от автоматизации

Да, но если откинуть ненужное то вполне применимо. пример ST и FBD в шапке http://www.owen.ru/forum/showthread.php?t=11839

Люди, знающие реле и пускатели, сделают те же вещи быстрее и эффективнее

Да, но при усложнении задачи, увеличении размера программы становится сложнее ее писать, отлаживать, и тем более для "посторонних" людей это вообще может стать невозможным. Т.е. тиражируемость, модернизация, повторное использование отдельных частей при таком подходе будут очень сложными.
По общей идеологии можно тут почитатьhttp://is.ifmo.ru/works/open_doc/ , но там много :)
Либо начало этой http://is.ifmo.ru/download/1minute.pdf статьи, там 1 листик.

По пониманию конкретной реализации по моему хватит этих картинок

[+] Картинки

Переменные ST.JPG

Автомат ST.jpg

ТЕКСТ ST.jpg

[gtfox]

[+] Картинки. Продолжение...

Нотация графов переходов.png

Автомат для FBD.jpg

Коментарии поближе FBD.jpg

[Михайло]

А вот программы на текстовых языках переносятся и работают без глобальных проблем.

Теперь понял. Не очень-то и нужная функция.

По пониманию конкретной реализации по моему хватит этих картинок

Ну вроде в целом понятно. На языке LD аналог программ будет изящнее. Но это для тех, кто умеет в нем работать.

И как всегда: задачи, которые рассматриваются в примерах - не очень удобно решать в SFC, так как слишком много переходов и мало состояний.
Я как инженер применяю функциональные блоки для обработки аварийных ситуаций:
Если авария, то запустить функциональный блок "Авария" (где обнулить состояние и произвести прочие действия).
Какой смысл усложнять все и рисовать кучу одинаковых переходов на графе?

[Михайло]

Редко полностью вся программа представляется на языке SFC. Это очень специфичный язык, который ЛУЧШЕ подходит для написания последовательностных процессов, то есть когда группа некоторых действий (выходов) активируется последовательно друг за другом по некоторому закону. Кстати, SFC очень удобен для управления навигацией по экранам панели.
Главные недостатки SFC:
1. Встречается не в каждой среде разработки
2. А если и встречается, то очень неудобен и жрет много ресурсов контроллера (Сименс)
3. ХУЖЕ подходит для параллельных процессов, когда группа действий (выходов) активируется одновременно и, как правило, независимо или слабозависимо. (В этом случае лучше подходят LD/FBD/IL.)
Чтобы обойти эти недостатки SFC, я разбиваю всю программу на несколько блоков, каждый из которых реализую на одном из языков. Лично я использую только LD и SFC. Так как SFC в инструментарии Сименса, можно сказать, отсутствует, то я реализую алгоритм SFC на языке LD. Да, алгоритм SFC легко "перегнать" на язык LD!

Разбиение программы на блоки осуществляется следующим образом:
1. Нужно составить перечень входов и выходов всей программы (входы и выходы контроллера + входы и выходы с сетевых интерфейсов HMI и других устройств)
2. Анализ выходов. У нас стоит задача - сократить этот список входов и выходов, чтобы облегчить себе программирование. Поэтому анализируем каждый выход на предмет простоты алгоритма его включения-выключения. Например, лампа HL1 загорается, когда включено реле K1 (движение) - реальный претендент на вылет из списка. Для каждого из этих выходов уже готов кусок программы и про них можно забыть.
3. Очень часто системы автоматизации могут работать в нескольких режимах (автоматический, полуавтоматический, ручной). Работа в ручном режиме может сильно отличаться от работы в автоматическом режиме, поэтому есть смысл написать эти алгоритмы в разных блоках программы. Эти блоки имеют, как правило, одинаковые списки выходов, которыми они управляют. Наша задача - проанализировать, относится ли выход к этим блокам или он работает независимо от режима работы системы. Если выход не зависит от режима работы установки, то его нужно поместить в некоторый общий блок программы.
4. Иногда требуется иметь блок "режим ожидания" - этот блок активен, пока неактивны блоки "автомат" и "ручной".
5. При переключении режимов (автомат/ручной) обычно необходимо сбрасывать все выхода, которые были включены в предыдущем режиме. Поэтому создается блок "Сброс". Этот блок вызывается однократно по фронту/спаду переключателя режимов.
6. Если автоматического и ручного режимов нет, то нужно действовать следующим образом: оставшийся перечень выходов пытаться разбить на две и более независимых групп. Такие группы могут образовать отдельный блок SFC или LD. Решать уже по ситуации, какой из языков применить.
7. Разработку структуры программы можно считать завершенной, как только все выходы программы оказались в том или ином блоке.

Сам процесс рисования графа достаточно интуитивный. Я рисую его карандашом на бумажке, активно при этом пользуюсь ластиком. Самое главное - нарисовать скелет графа, то есть нарисовать кружочки и соединить стрелками. Каждый кружочек (вершина, шаг) должен получить определенный смысл и напротив его должно быть некоторое действие, то есть поведение автомата. Смысл придает вершине статус состояния. Например, в графе тележки нет ничего лишнего - 5 вершин-состояний - "тележка стоит", "тележка едет вперед медленно", "тележка едет вперед быстро", "тележка едет назад медленно", "тележка едет назад быстро".
В сложных графах часто следует в начале графа подумать об отводе (возврате) механизмов в исходное положение. Отвод в исходное положение - это последовательность шагов в самом начале общей последовательности, начиная, как правило, с вершины S0. Суть отвода состоит в проверке, находится ли каждый исполнительный механизм в исходном положении и если не находится - то механизм отводится в исходное положение. (Естественно, что отвод делается в такой последовательности, чтобы механизмы не столкнулись.) Только после завершения этого процесса, объект управления и система управления приходят в исходное положение и можно начинать некоторый цикл технологического процесса. После каждого технологического цикла (который обычно совпадает с циклом последовательности графа) механизмы должны оказываться в исходном положении.
<...>
Потом, когда скелет графа нарисован, добавлены все действия и условия переходов - боремся с гонкой состояний и гонкой переходов.

[CHANt]

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

А что в CoDeSys ST компилировать, после внесения изменений, не нужно? Так как и МЭКовские графические языки и IL правятся на ходу, на ПНР это очень важно и именно этим они и привлекают в практической работе деградировавших коллег :D
А холивар на тему какой язык лучше, сюда - viewtopic.php?f=35&t=1923
Мое же мнение - автоматный подход приучает проектировать программу, а с соблюдением той же нотации SWITCH, еще и получать вполне понятный графический алгоритм. Который ох как помогает на наладке.
Лично мне часто приходится "править" граф именно в визио, коллеги звонят и просят помочь с изменениями, а под рукой на работе только визио - а по графу, набросать в аське какие строчки и как изменить, трехсекундное дело.
Как пример - вот сегодня правил по ходу ПНР:

Безымянный.jpg

Граф перегоняю в IL, и не считаю это зазорным. а вполне нормальным - на ST мне бы пришлось "миллион" раз котельную отключить...
Так что - не так важен язык программирования, как важна сама нотация. Применяете SWITCH - замечательно! Я также, но, в своей версии, как и например К.В. Вавилов (чьи работы на http://is.ifmo.ru Вы видели). Но и SWITCH и его варианты, не единственно возможный подход. Именно об этом в этой теме мы и делились.

[gtfox]

Какой смысл усложнять все и рисовать кучу одинаковых переходов на графе?

Для перехода в аварию используется групповое состояние и одна линия перехода. Если требуется знать в каком именно состоянии произошел сбой, рисуем линии переходов из каждого состояния в аварию, а на дуге запоминаем номер состояния. Может это и не оптимальный вариант...

ST компилировать

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

Так что - не так важен язык программирования, как важна сама нотация

Согласен.