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) версия

[gtfox]

Шапка темы изменена

[Игорь Петров]

Professional Edition относится к V3. Подготовлю по нему отдельную тему. Аналогично CoDeSys Application Composer. Он растет из идей ООП, далековато от этой темы.

Предлагаю закрыть "параллельную" тему.

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

Многозадачные примеры? Однозадачные трудней придумать. 2 светофора = 2 задачи... Климатическая камера: Архивация на диск – отдельная низкоприоритетная задача с циклом 1 минута (кстати, свич на ST). Синхронизация встроенных часов - циклическая задача 1 час. Опорос кнопок режимов – высокий приоритет цикл 20 мс. Подготовка данных для графиков – фоновая задача. Все работает параллельно.
Запись строки на USB флешку делается 1 функцией. В нашем контроллере (на чипе Beck) она иногда (с износом флешки чаще) задумывается надолго. Пускай себе, другие задачи это не тормозит. Как тут ‘по старинке’? Только внешним самописецем.

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

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

Она срабатывает и ударяет кувалдой по всей технологии. В программе получается ход конем, который никак не описан в исходной диаграмме. Так?

По Рефлексу:
1. Плагин есть кому написать. Была бы материальная необходимость.
2. Зачем ему генерировать ST код? Генерировать надо машинный код и никому не показывать. Отладка в онлайне должна идти в самом Рефлексе. Если я запустил пошаговое выполнение или точки останова, то наблюдать я должен работу Рефлекса, а не ST.
Обязательно нужна не только конвертация в текст, но и обратная связь из работающего ПЛК в диаграмму. О какой наглядности можно говорить, если проектируем диаграмму, а в онлайне смотрим в текст?

SFC: ... не конвертирует в ST

Полноценный МЭК SFC предполагает, что всю полезную работу выполняют действия. В программе есть неявный массив действий, десятки или сотни. Говорить ‘выполнение шагов’ вообще не корректно. Исполнитель SFC моментом просматривает все активные шаги и меняет действиям флажки активности и таймеры. На этом ‘выполнение’ шагов заканчивается. Далее внутри исполнителя SFC сидит ядро маленькой операционной системы. Она запускает все активные действия (квази)параллельно. Действиями могут быть либо подпрограммы, либо переменные, либо выходы ПЛК. Задачи последовательностного логического и временного управления решаются на ‘чистом МЭК SFC’ в лоб, без применения других МЭК языков. Рисуем SFC диаграмму и она сразу оживает и работает. В онлайне шикарно просматривается работа шагов и действий. ИМХО нагляднее некуда.

Не понимаю если без visio сразу рисуем в SFC, то зачем потом конвертировать ST?

[gtfox]

Professional Edition относится к V3. Подготовлю по нему отдельную тему. Аналогично CoDeSys Application Composer. Он растет из идей ООП, далековато от этой темы.

1) Не нашел тему про CoDeSys Application Composer ни на форуме owen ни на 3s-software
2) так и не понял:
2.1) Где взять CoDeSys Professional Edition
2.2) Сколько стоит
2.3) Есть ли Training(Free) версия, для энтузиастов
3) Можно ли в Professional Edition использовать UML в качестве "исполняемого языка алгоритмизации", или он там только для нужд ООП?

Многозадачные примеры? Однозадачные трудней придумать. 2 светофора = 2 задачи... Климатическая камера: Архивация на диск – отдельная низкоприоритетная задача с циклом 1 минута (кстати, свич на ST). Синхронизация встроенных часов - циклическая задача 1 час. Опорос кнопок режимов – высокий приоритет цикл 20 мс. Подготовка данных для графиков – фоновая задача. Все работает параллельно.
Запись строки на USB флешку делается 1 функцией. В нашем контроллере (на чипе Beck) она иногда (с износом флешки чаще) задумывается надолго. Пускай себе, другие задачи это не тормозит. Как тут ‘по старинке’? Только внешним самописецем.

Благодарю за примеры. Я надеялся увидеть пример реального проекта (куска проекта), но и за это благодарен.
Из приведенных примеров к задачам логического управления относятся только светофоры, и каждый из них выполняется в одной задаче...
У Вас были примеры, где Вы алгоритм (условно "Светофора") разбивали на задачи?

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

например, можно вот так, 2 стр., внизу. (см. картинку)
вместо "Контроль кнопки стоп" рисуем весь автомат, который будет работать паралельно...
будет полнота функционирования но меньше наглядности

Она срабатывает и ударяет кувалдой по всей технологии. В программе получается ход конем, который никак не описан в исходной диаграмме. Так?

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

По Рефлексу:
1. Плагин есть кому написать. Была бы материальная необходимость.
2. Зачем ему генерировать ST код? Генерировать надо машинный код и никому не показывать. Отладка в онлайне должна идти в самом Рефлексе. Если я запустил пошаговое выполнение или точки останова, то наблюдать я должен работу Рефлекса, а не ST.
Обязательно нужна не только конвертация в текст, но и обратная связь из работающего ПЛК в диаграмму. О какой наглядности можно говорить, если проектируем диаграмму, а в онлайне смотрим в текст?

1) По Рефлексу: когда Вы его упомянули в первый раз, я его спутал с ДРАКОНОМ, графическим языком программирования. Потом выяснилось, что Рефлекс мало чем отличается от ST.
2) ДРАКОН также генерирует исходные тексты на разных языках программирования, но их реализация базируется на операторе GOTO

Полноценный МЭК SFC предполагает, что всю полезную работу выполняют действия. В программе есть неявный массив действий, десятки или сотни. Говорить ‘выполнение шагов’ вообще не корректно. Исполнитель SFC моментом просматривает все активные шаги и меняет действиям флажки активности и таймеры. На этом ‘выполнение’ шагов заканчивается. Далее внутри исполнителя SFC сидит ядро маленькой операционной системы. Она запускает все активные действия (квази)параллельно. Действиями могут быть либо подпрограммы, либо переменные, либо выходы ПЛК. Задачи последовательностного логического и временного управления решаются на ‘чистом МЭК SFC’ в лоб, без применения других МЭК языков. Рисуем SFC диаграмму и она сразу оживает и работает. В онлайне шикарно просматривается работа шагов и действий. ИМХО нагляднее некуда.

Согласен... если у него появится нормальная графика (пример stateflow)

Не понимаю если без visio сразу рисуем в SFC, то зачем потом конвертировать ST?

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

PS
долго отсутствовал по рабочим причинам