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

[gtfox]

Не спорьте, уровень сложности конвертера это от незнания как визио готовить.
Кстати конвертер можно встроить в визио как надстройку, причём можно скачать с микрософта инструменты для создания надстроек.

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

1) Этот конвертер создавался как универсальное средство. Он создает XML описание автомата которое можно использовать где (и как) угодно. После, руками, создаются шаблоны преобразования XML описания автомата в любой язык программирования. Для этого там применяются синтаксический и лексический анализаторы, +парсеры.

2) Я, в этом всем, всего лишь отредактировал шаблон под язык ST.

3) Благодарю за примеры. Давно хотел увидеть что-то конкретное. Если не использовать синтаксические и лексические анализаторы, то Ваш вариант реализации вполне привлекателен.
т.к. конвертер уже работает, приоритет создания VBA-аналога уменьшится...

Еще вопрос: откуда эти макросы? я так понял это "САПР"? Самописный?

[BETEP]

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

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

тот кто делал заготовку для визио и конвертер, просто дал имена фигурам и метку в данных фигуры, но не догадался сделать полноценные фигуры с данными пользователя, тогда вместо текста квадратиков и линий можно было-бы использовать коннекторы с кучей строк для описания кучи условий перехода. Прямоугольники состояний и групп то-же нужно было наделить пользовательскими данными. Добавить данные можно и к листу, и вообще подготовить листы для подпрограмм. и даже вполне возможно отображать нужные данные из ОРС сервера, что-бы с тормозами лицезреть процесс работы в контроллере.

Если правильно определить структуру и типы листов, подготовить шейпы с нужными полями для данных, появится возможность рисования сложных алгоритмов и их нормального читаемого оформления и печати. Можно ведь использовать принятые принципы оформления, титульный лист, содержание, граф организации программы, текст графа (как перечни в схемах) листы с подпрограммами графа в виде графов и.т.п.
Скрипты в предыдущем посте выдают результат немного похожий на конвертер в ST, Перебирают листы, на нужных листах находят нужные фигуры, цепляют из них данные, сортируют, считают и выдают текст. некоторые функции реагируют на событие при подсоединении коннектора к точке и цепляют данные от того к кому прицепились.
обрабатывать файл визио или его XML версию неблагодарное занятие, обрабатывать данные фигур в самом визио намного проще.

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

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

[gtfox]

Параллельные шаги нужны для.. реальных проектов, которые несколько сложнее светофора.

up

благодарю за развернутый ответ

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

"Паралельные" бывают только физические процессы, а вычислительные - последовательные, хоть вы и видите в SFC 2 одновременно работающих состояния.

Хм. В стандарте МЭК такого требования нет. Кроме состояний в SFC еще есть и действия. Они способны работать параллельно, независимо от состояний . Исполнитель SFC имеет полное право вешать их на разные процессы. В многоядерных системах будет физически параллельно.

"Если 2 физических процесса происходят одновременно, то для их описания используются 2 автомата, которые запускаются по изменению 1 логической переменной. Если нужно одному подождать - смотрим за номером состояния другого..

Значит параллелизм в автоматном подходе есть. Он выражается гиперавтоматом. В нем реализуется простейший механизм синхронизации задач (автоматов). Его приходится самостоятельно кодировать в прикладной программе, вместо того чтобы использовать готовые механизмы ОС.

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

Допустим, иногда внутри этого цикла делаются некоторые громоздкие вычисления или блокирующая запись на флеш диск и др. В итоге, наш цикл подзастревает допустим на 1-2 секунды. Еще есть аварийный вход. По его изменению реакция обязана происходить, например, за 1 мс. Решение: на быстрый вход ПЛК вешаем событийную задачу с высшим приоритетом. Она мгновенно останавливает цикл и делает то, что должна. Нигде никакого лишнего кода писать не приходится. Для программирования напрягли 0.5 извилины.
Автоматный подход очень полезная штука. Раздражают только попытки подать его как универсальную ‘суперкувалду’.

Есть много других замечательных подходов. Например, событийные, процесс ориентированные...

Помните, мы обсуждали инструмент PLC Link? Он интегрирует CoDeSys в MATLAB Simulink с непосредственным выполнением в ПЛК и визуальной отладкой. Это было нужно для математически сложных задач, типа динамического управления лопастями генераторов. Тема получила развитие. Теперь в MATLAB появился PLC Coder. Жалко, нет случая попробовать.

[gtfox]

Хм. В стандарте МЭК такого требования нет. Кроме состояний в SFC еще есть и действия. Они способны работать параллельно, независимо от состояний . Исполнитель SFC имеет полное право вешать их на разные процессы. В многоядерных системах будет физически параллельно.

Вот поэтому я и не хотел заводить разговор о параллельности
Фон Неймана никто не отменял, несмотря на прерывания

Значит параллелизм в автоматном подходе есть. Он выражается гиперавтоматом. В нем реализуется простейший механизм синхронизации задач (автоматов). Его приходится самостоятельно кодировать в прикладной программе, вместо того чтобы использовать готовые механизмы ОС.

Не очень понял конечно, какой такой готовый механизм синхронизации... Это, если в 1 ветви 1 шаг, а в параллельной 10, то 1-я ветвь будет ждать завершения соседних 10-ти...

Допустим, иногда внутри этого цикла делаются некоторые громоздкие вычисления или блокирующая запись на флеш диск и др. В итоге, наш цикл подзастревает допустим на 1-2 секунды. Еще есть аварийный вход. По его изменению реакция обязана происходить, например, за 1 мс. Решение: на быстрый вход ПЛК вешаем событийную задачу с высшим приоритетом. Она мгновенно останавливает цикл и делает то, что должна. Нигде никакого лишнего кода писать не приходится. Для программирования напрягли 0.5 извилины.

Если в SFC сделать 2 параллельных шага, в одном шаге будет выполнятся быстрый код, в другом долгий код.
Вопрос: Не используя событийных задач с высшим приоритетом, чему будет равен цикл ПЛК (быстрому или долгому коду)?

+ Ничто не мешает нам использовать событийные задачи с высшим приоритетом в "switch-технологии"

Автоматный подход очень полезная штука. Раздражают только попытки подать его как универсальную ‘суперкувалду’.

Не совсем "суперкувалду", а один из работающих вариантов реализации автоматного подхода

Есть много других замечательных подходов. Например, событийные, процесс ориентированные...

Язык Рефлекс - замечательная вещь
Если бы с него можно было в ST код генерить - было бы замечательно, однако я не нашел.
И, кстати, подход генерации кода С,ST,Pascal - подобного по графам аналогичен предложенному в "switch-технологии"

Помните, мы обсуждали инструмент PLC Link? Он интегрирует CoDeSys в MATLAB Simulink с непосредственным выполнением в ПЛК и визуальной отладкой. Это было нужно для математически сложных задач, типа динамического управления лопастями генераторов. Тема получила развитие. Теперь в MATLAB появился PLC Coder. Жалко, нет случая попробовать.

Касаемо автоматной части (генерация из Stateflow) PLC Coder генерит код, аналогичный MetaAuto-конвертеру, только предварительно нужно его очищать от служебного кода. + Matlab стоит дороже Visio

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

...Matlab стоит дороже Visio

С MATLAB и PLC Link фишка в том, что мы строим математическую модель системы управления. Например, для ветряков известна система диф уравнений. Матлаб способен их решать с нужным шагом и точностью. Параллельно рисуем систему управления. Запускаем это все на компьютере, смотрим. Можем попробовать разные регуляторы, четкие, нечеткие. Выбираем лучшее решение. Дальше делается волшебство. Оно заключается в том, что управляющая модель автоматически конвертируется в CoDeSys и запускается в ПЛК параллельно. Мало того, система сравнивает точность результатов вычислений в компьютере и ПЛК и строит графики. Мы можем менять настройки. Например, указываем применять REAL переменные либо более тяжелые библиотеки высокой точности. Результатом моделирования является рабочая, верифицированная программа в ПЛК. Программирования нет вообще. Понятно, что все это передовая наука и пока не дешево. Но, впечатляет

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

Вот поэтому я и не хотел заводить разговор о параллельности
Фон Неймана никто не отменял, несмотря на прерывания

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

Не очень понял конечно, какой такой готовый механизм синхронизации... Это, если в 1 ветви 1 шаг, а в параллельной 10, то 1-я ветвь будет ждать завершения соседних 10-ти...

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

Если в SFC сделать 2 параллельных шага, в одном шаге будет выполнятся быстрый код, в другом долгий код.
Вопрос: Не используя событийных задач с высшим приоритетом, чему будет равен цикл ПЛК (быстрому или долгому коду)?

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

+ Ничто не мешает нам использовать событийные задачи с высшим приоритетом в "switch-технологии"

Как?

Не совсем "суперкувалду", а один из работающих вариантов реализации автоматного подхода

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

Язык Рефлекс - замечательная вещь
Если бы с него можно было в ST код генерить - было бы замечательно, однако я не нашел.

См. тут. http://reflex-language.narod.ru/arti...nd-S-STenh.pdf

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

С Рефлексом все четко. Весь необходимый функционал есть в рантайме. Нужно ввести в ST несколько ключевых. Вполне реально написать плагин и получим поддержку Рефлекса в CoDeSys.

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

[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?