Switch-технология. Программирование задач логического управления.

[gtfox]

С MATLAB и PLC Link фишка в том...

Ну давайте по порядку.
Модель объекта получили : 1) аналитически
2) по диф урвнениям
3) по переходной хар-ке в Систем идентификейшн
Это хорошо
Пробуем разные регуляторы: четкие, нечеткие.
Настроили, отладили. Это хорошо
Регуляторная часть работает
Дальше нужно еще написать логическую часть, систему аварий, архивов, интерфейс пользователя
и прикрутить это к сгенерированному коду, который как бы должен быть читаемым и понимаемым...
Допускаю, что логическую часть можно хорошо сделать в Стейтфлоу, но остальное без программирования трудно представить.

Причем тут прерывания? Уже существуют ПЛК под CoDeSys Control c несколькими процессорами и физически параллельными вычислениями в МЭК языках. ОС РВ уже норма для ПЛК. Фон Нейманы освоили бригадный метод

Согласен с Вами. Но разговор начался с вопроса о переходе в 2 состояния одновременно, и на форуме Овен . На сколько мне известно у Овена пока нет бригады Фон Нейманов . Предлагаю закрыть "параллельную" тему.

В современных ПЛК широко применяется реальная многозадачность. Она сильно упрощает жизнь. Механизмы мьютексов, событий и исключений придуманы не зря. Синхронизация процессов не такое простое дело. Если отказаться от нормальной многозадачности, сделать шаг назад в эволюции ПЛК, то такой простой механизм синхронизации будет исправно работать.

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

Параллельные ветви SFC никак не решают проблемы РВ. И switch тут тоже ничем не помогает.
Используя менеджер задач CoDeSys, сделаем циклические задачи с разными приоритетами и временами цикла. 5 движений мышкой и проблема надежно решена. Все системные проблемы решает планировщик рантайм. Этим не должен ломать голову прикладной программист.

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

Как?

на быстрый вход ПЛК вешаем событийную задачу с высшим приоритетом.
Она мгновенно останавливает цикл и делает то, что должна: Вырубает оборудование, пишет аварию в журнал.

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

Я на учебных курсах по программированию ПЛК показываю свич технологию. Хотелось бы дать четкие критерии, когда ее стоит применять, а когда нет. Вы можете описать недостатки switch технологии и задачи, для которых она не подходит?

Попробую.
На счет плюсов и применяемости написано в шапке темы. Там всего много, и никто не читает. Я ее отредактирую оставлю только самое самое...

От меня: "когда ее стоит применять, а когда нет?" - применять только для алгоритмизации (для задач логического управления), причем правильным будет рисовать графы состояний вместе с технологом на этапе обсуждения ТЗ или "как это все должно работать". Потом нарисовать в visio, расставить переменные, получить код алгоритмической части. (либо можно обойтись без visio, рисовать сразу в SFC)
Применительно к FBD минусом можно считать накладные расходы на память и кол-во блоков (в Овен Лоджике нет мультиплексоров Адрес=Int, Вх/Вых=Int, есть только Адрес=Bool, Вх/Вых=Int, пришлось делать свои Int/Int). Пример реализации в картинках.
Применительно к ST минусом можно считать: программа в текстовом виде (кому минус, кому плюс ), нет визуальной динамики (решается визуализацией кодесис)
Применительно к SFC: ограниченная графика; не конвертирует в ST. (хочу возможности графики Stasteflow )

См. тут. http://reflex-language.narod.ru/arti...nd-S-STenh.pdf
С Рефлексом все четко. Весь необходимый функционал есть в рантайме. Нужно ввести в ST несколько ключевых. Вполне реально написать плагин и получим поддержку Рефлекса в CoDeSys.

По этой статье:
1) это только предложение изменений, причем 2009 года. (воз и ныне там )
2) "PROC" и "STATE" - это полный функциональный аналог "CASE" и "N:"
3) "START" и "STOP" - это полный функциональный аналог состояния "Начало" (см. картинку гафа автомата )
4) "ERROR" - это полный функциональный аналог состояния "Авария" (см. картинку гафа автомата )
5) "TIMEOUT" - T_Zaver_progr :TON:=(PT:=T#10m); (*Время Завершения программы прогрева*)
Вывод: эти изменения не нужны.

По Рефлексу:
1) в ST код не генерит
2) кто будет писать плагин. У меня нет квалификации для его написания
К чему я это все: MetaAuto конвертер уже делает то что необходимо. Если бы были средства использования рефлекса то не появился бы конвертер.

Обсуждая подобные темы в ветке по CoDeSys возникает законный вопрос: что из предлагаемого имело бы смысл поддержать в данном комплексе?

Нормальную графику SFC, это графический язык, должен радовать глаз . Адекватный конвертер в ST.

Со свичем не так очевидно. Добавили UML диаграммы в CoDeSys Professional Edition. Автоматный подход реализован графически, изящно, живой обратной связью при отладке. Никаких конвертеров и промежуточных ST или C кодов. Что плохо?

Все просто великолепно!
Еще из первого поста

См. CoDeSys Professional Edition.

посмотрел английскую пдф-ку, полез на сайт, информацию не нашел, пол часа тыкался по меню и ссылкам.
В пдф-ке есть
Product name Order code
CoDeSys UML 602003
из чего ясно что за деньги...
Вопросы:
1) Где взять CoDeSys Professional Edition
2) Сколько стоит
3) Есть ли Training(Free) версия