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

Обсуждение применения Switch-технологии. Инструменты.
т.к. никто не хочет много читать, оставил только самое необходимое...


По Switch-технологии, 2 книжки и статья:
1) Шалыто А.А. Алгоритмизация и программирование задач логического управления СПбГУ ИТМО. 1998. 55 с
Книга не большая, можно и почитать
2) SWITCH-технология - автоматный подход к созданию программного обеспечения. 27 с
Все четко, ничего лишнего.
3) Вавилов К.В. Программирование за... 1 (одну) минуту. 9 с
Небольшая статья о применении

+ 2 части статьи Татарчевского В.А. по 3 листа. Часть 4 Часть 5

для общего развития:
Шалыто А.А. Новая инициатива в программировании. Движение за открытую проектную документацию

Применение для FBD!
Книга
Реальный пример

Цитата:

---

Сообщение от gtfox

см. картинки внизу вот этого сообщения

---

Применение для C++!
Конвертор Visio2Switch Головешин А.

Применение для C++,C#,ASSEMBLER!
MetaAuto - Преобразование графов переходов, представленных в формате MS Visio, в исходные коды программ для различных языков программирования. Канжелев С.Ю., Шалыто А.А.

Применение для ST!
Visio2ST - Предлагаю вариант реализации программы MetaAuto С.Ю. Канжелева, сконфигурированную для языка ST, для практического применения при программировании ПЛК на CoDeSys или другой среде.
В MetaAuto, для переделки выходного языка не нужно лезть в исходники – достаточно исправить конфиги. Что и было сделано.

Visio2ST

СУТЬ программы вкратце:
1. Создаем в Visio граф переходов автоматов
2. Используем программу MetaAuto для языка ST
3. Получаем текст программы

Приемущества:
1. Текст программы в точности соответствует графу переходов и вашим мыслям - они изоморфны.
2. Автоматическая генерация кода. Не тратится время на набор текста и уменьшаются ошибки.
3. Предлагаются простые и адекватные методы создания проектной документации, которая будет однозначно и полностью понятна всем: Заказчику, Технологу (Проектанту), Разработчику, Программисту, Оператору (Пользователю) и Контролеру.

SWITCH-технология применительно к ПЛК:
Основное, что хотелось бы сказать по поводу моего понимания SWITCH-технологии, применительно к программированию ПЛК это:
1. Один автомат – один CASE.
2. Нет понятий вложенность, вызываемость, событие. Все автоматы выполняются в каждом цикле ПЛК. Любое "событие" – это изменение переменной, ее и отражаем на графе. Взаимодействие автоматов – по номеру состояния.
3. Использовать реальные имена переменных, а не абстрактные x5, е20, z35. Улучшается читаемость и понимаемость текста. Описание переменных не на графе, а в экселе, которые целиком копируются в кодесис и являются частью кода.

Структура кода автомата на ST:
Каждое состояние автомата состоит из разделов:
1. (*Действия при первоначальном входе в это состояние*) (необязательный)
2. (*Действия, постоянно выполняющиеся в этом состоянии*) (необязательный)
3. (*Запускаем таймер этого состояния*) (необязательный)
4. (*Запоминаем текущее состояние перед выполнением перехода*) (необязательный, если нет предыдущих)
5. (*Проверка условий на дугах и выполнение переходов*) (обязательный)

Visio2ST - качаем тут:
_METAAUTO_VISIO2_ST_CPP_password=1.zip (42.06 Мб)


Пожелание: вопросы задавать после прочтения metaAuto.pdf и также материалов 1-3 в начале сообщения.
Также обсуждение Switch-технологии было здесь

Собратья по теории:
1) Стандартный SFC еще
2) CoDeSys Professional Edition + UML
3) Визуальный язык ДРАКОН Среда Видеоурок Форум
4) Язык Рефлекс http://reflex-language.narod.ru
5) MATLAB PLC Coder + Stateflow

а чем программка нарисованная в SFC с МЭК шагами глобально отличается от диаграмм нарисованных в VISIO ? ( ну конечно кроме того, что первый вариант уже работает, а диаграмму еще через предлагаемый конвертор прогонять нужно! )

Цитата:

---

Сообщение от Дмитрий Артюховский

а чем программка нарисованная в SFC с МЭК шагами глобально отличается от диаграмм нарисованных в VISIO ? ( ну конечно кроме того, что первый вариант уже работает, а диаграмму еще через предлагаемый конвертор прогонять нужно! )

---

Шалыто А.А. Switch-технология. Алгоритмизация и программирование задач логического управления СПб.: Наука, 1998., 628 с
стр. 13, последний абзац http://is.ifmo.ru/books/switch_pdf/_switch19.pdf

Цитата:

---

глобально отличается

---

Глобально, может и ничем, но:
1. Если это графический язык, то почему такой убогий, в нем нет наглядности, могли бы что-нибудь типа Stateflow Матлабовского сделать...
2. CoDeSys_V23_RU.pdf стр.182 есть неоднозначности, и я думаю могут возникнуть другие моменты, когда SFC будет ограничивать мои действия
3. Если в среде программирования есть ST, то я пишу программы только на ST. Это дает свободу действий и уверенность в адекватном поведении.

SFC - это собственно не язык, а средство структурирования программы, повышение ее читабельности и удобства отладки....
разумеется при серьезной задаче альтернативы ST нет, но уже при размере программы более 2000-3000 строк становиться тупо неудобно и ниразу не наглядно... вот тут то и появляется SFC, в модулях которого и вписываются куски кода, логически разделенные по каким либо признакам.... например: начальная инициализация, рабочее состояние, состояние обслуживания, аварийное состояние и др. Использование чистого ST с вставкой функциональных блоков, либо функций, для повышения читабельности, все же несет дополнительные накладные расходы на вызовы процедур и менее устройчивы из-за возможных перекрытий переменных и прочих неприятностей, например увеличение требуемого количества флагов в селекторах...

а по самому принципу использования switch, нет смысла спорить с самим капитаном "Очевидность".... для этого даже не нужно читать книжки по 700 страниц ))) (и уж точно не писать их!) .... разве что ТИЦ покрутить нужно )))

Абсолютно согласен с Дмитрием. SFC, наоборот, считается языком самого высокого уровня из тех, что представлены в CoDeSyS. И если сравнивать по наглядности с ST, то последний однозначно "отдыхает".

На счёт StateFlow в Matlab: в чем состоит принципиальное "богатство" этого редактора перед SFC? Я лично не заметил.

Логическое управление подразумевает однозначное описание задачи в виде булевых выражений. Зачем нужно изобретать велосипед? Все логические вещи прекрасно реализуются на LD.

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

Хотя, я лично не считаю, что LD может полностью заменить тот же ST.

Я и не утверждаю, что LD может заменить ST. С чего это Вы взяли? Чисто релейные алгоритмы однозначно описываются в LD, только это я и сказал. Например там невозможно обработать массивы, написать нормально связь по COM порту и т. п. Это надо конечно делать на ST или IL, хотя на IL сложней, но гибкость и лаконичность выше всяческих похвал.
Вопрос же применения конечных автоматов, о котором вещает топикстартер, стар, как телефон Белла (или I8080:D ). Эффективность применения этих методов в системах управления технологическим оборудованием до сих пор под большим вопросом.

Цитата:

---

Сообщение от Алексей Дмитриев

Вопрос же применения конечных автоматов, о котором вещает топикстартер, стар, как телефон Белла (или I8080:D ).

---

Не спорю, но телефоны применяли и развивали, потому что это удобнее чем голуби...
еще цитата

Цитата:

---

Не так важно кто нечто придумал первым - важно кто начинает это использовать не от случая к случаю, а как технологию: "Как делаются общественно-политические изобретения. Например, само по себе изобретение паровой машины еще не вело к промышленной революции — нечто подобное создавалось и раньше в других странах Европы. Заслуга Джеймса Уатта была не в том, что он изобрел паровую машину, а в том, что сумел продать первые сто экземпляров. Это и есть опыт цивилизации — когда открытие, возникшее исторически случайно, начинает использоваться сознательно, как технология, и воспроизводится в дальнейшем опыте (Виталий Лейбин. Русский репортер)".
Я считаю, что так произошло с автоматным программированием, которое распространяется все шире и шире - http://www.state-machine.com/about/customers.php. Название нашего сайта уже много лет связано с автоматным программированием, у этого сайта даже понятие автомат даже входит в его название. Обратите внимание каким компаниям нужны инструменты для автоматного программирования! А мне все не верили, как оно важно.

---

Цитата:

---

Сообщение от Алексей Дмитриев

Эффективность применения этих методов в системах управления технологическим оборудованием до сих пор под большим вопросом.

---

Если не трудно, то укажите источники информации.

Программирование с использованием автоматов на CASE и многозначным кодированием является одним из древнейших классических методов. Применяется со времен незапамятных. У меня сохранилась автоматная программа для контроллера охранной сигнализации 20 летней давности.

Тема многократно разбиралась всячески. Например.

В работах Шалыто подход отшлифован до технологии, получивший название Switch. Безусловно это здорово.

Практически главным образом напрягает то, что под Switch технологию так и не появилось никакого интегрированного инструментария. Если я нарисовал граф в Visio, то подключив кабель к ПЛК, я должен видеть оживший граф прямо в Visio. Только тогда можно говорить о какой-то наглядности сопоставимой с SFC и т.п.. Смотреть же на ассемблер, Си или FBD и представлять в голове что этому соответствует в исходном графе... теоретически возможно. Но, нужно быть убежденным сторонником чтобы получать удовлетворение от самого процесса :)

Цитата:

---

Сообщение от gtfox

..могли бы что-нибудь типа Stateflow Матлабовского сделать...

---

Уговорили...
См. CoDeSys Professional Edition.

Цитата:

---

Чисто релейные алгоритмы однозначно описываются в LD

---

А чем этот LD лучше ST вообще? Места занимает больше, а общей картины зависимостей всё равно нет.

Цитата:

---

1. Если это графический язык, то почему такой убогий, в нем нет наглядности

---

В чём убогость? Возвраты плохо отображаются? Или что-то ещё?

Цитата:

---

Сообщение от Yegor

В чём убогость? Возвраты плохо отображаются? Или что-то ещё?

---

1) Пустые квадраты. Информативности - минимум, места - много
2) Тупые линейные списки (сверху вниз). Нарисуйте автомат на 5 состояний, связи - каждый с каждым.
3) Неудобный пользовательский интерфейс. Рисование этого автомата в симулинке занимает 1 минуту и без напрягов и матершинных слов, все просто, прозрачно и лаконично.

Цитата:

---

LD vs ST

---

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

Цитата:

---

Сообщение от Валенок

Рисовать не буду.

---

А чего? простой примерчик, не сложный то...

Цитата:

---

Сообщение от Валенок

Сканер или фотик после потребуется.

---

э... это в смысле шутка?

Цитата:

---

Сообщение от Валенок

А чисто пример приведу.

---

Пример не понятный. В моем из каждого состояния 4 перехода...

Цитата:

---

Сообщение от capzap

А Ваш пример, видимо должен быть понятным :)

Минут пять смотрел на "звезду" пока она не превратилась в картину на моем столе: за крышкой ноутбука торчит бутылка минералки а за ней спинка стула. С SFC всё понятно и ни во что схема не превращается :) наверное привычка, которую ...

---

ничего конструктивного не увидел

Цитата:

---

Сообщение от Валенок

Кому ?

И чо пять-то. Давайте десять. А ?

---

ну, дык кто-нибудь нарисует автомат с 5-ю состояниями, и связями - каждое с каждым (4 перехода из каждого состояния!) в SFC, или настолько сложная задача?
для чистоты эксперимента добавил условия переходов и действия в состояниях

Ладно-ладно: да, SFC неудобен для представления большого числа связей. Но и сгенерированный из диаграммы ST не намного удобнее в этом плане — в нём много служебного кода, который сам занимает место и заставляет выравнивать всё остальное. При этом в процессе отладки мы наблюдаем число, которое приходится сопоставлять в уме, а не зрительно.

Ещё Switch это всегда переход в одно состояние. А если надо больше?

Ну и наконец Визио с Экселем денег стоят.

Цитата:

---

Сообщение от Yegor

в нём много служебного кода, который сам занимает место и заставляет выравнивать всё остальное.

---

Да. Но код максимально структурирован и выровнен (дальше работает автовыравнивание), при этом руками пишется очень мало и в определенных местах, если вообще пишется...

Цитата:

---

Сообщение от Yegor

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

---

Ну, я в процессе отладки наблюдаю текущее словесное описание состояния, при помощи динамически текстов... (см. рисунки)

Цитата:

---

Сообщение от Yegor

Ещё Switch это всегда переход в одно состояние. А если надо больше?

---

Ох... не хочу я разводить разговор о параллельности... тут проблемы в головах, а не в реализации...
1) В Switch-технологии автомат всегда находится только в одном состоянии
2) "Паралельные" бывают только физические процессы, а вычислительные - последовательные, хоть вы и видите в SFC 2 одновременно работающих состояния.
3) Если 2 физических процесса происходят одновременно, то для их описания используются 2 автомата, которые запускаются по изменению 1 логической переменной. Если нужно одному подождать - смотрим за номером состояния другого

Цитата:

---

Сообщение от Yegor

Ну и наконец Визио с Экселем денег стоят.

---

:) если внимательно посмотреть на скриншот таблицы первого поста, то там Libre Office Calc, ну а визио - да.

Цитата:

---

Сообщение от capzap

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

---

читай первый пост

Цитата:

---

Сообщение от Валенок

Ну и ?

---

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

Цитата:

---

Сообщение от Валенок

Хотя на практике сделал бы по условию прямое присвоение state внутри шага и по нему перешел бы как в первом примере

---

Не, дак дут вообще все условия скрыты, наглядность 0,5

Цитата:

---

Сообщение от Валенок

Чем это ? Давайте все-таки 10 состояний нарисуем. И рыбу сеткой ловить будем.

---

Сложный автомат - сложный граф, все в порядке вещей. Хотя, сложные процессы обычно разбиваются на более простые.

Цитата:

---

Сообщение от Валенок

Вот мне надоть по условию :
Y < (u*234/sin(e+7)*14.467*d) OR FR.Df[y]^AND NOT Gh
безусловно перейти в спец.состояние игнорируя любые другие расклады. Аварии тут, понимаете ли, отрабатываются. Обычное дело. Что делаем ?

---

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

Цитата:

---

Сообщение от Валенок

Не ответили - кому ?

---

мне, кому ж еще :)

Цитата:

---

Сообщение от Валенок

Чьих ?

---

тех кто задает вопросы о переходе в 2 состояния

Цитата:

---

Сообщение от Валенок

Чой-то Ваше нагляднее моего?

---

:) стрелочка висит в воздухе и подписана "Open", а не проведена к состоянию "Open". Чего не сделать возможность располагать блоки состояний произвольно на поле.

Цитата:

---

Сообщение от Валенок

А у Вас наглядность будет если каждое условие по объему будет сравнимо с аварией (см. выше/ниже) а не эти деццкие а=b ? Шагов будет 10 с такими условиями и наглядно лазать по полосочкам разыскивать условия и определять их очередность ?

---

Именно так. Для этого они и рисуются. Просто, если оно скрыто, то нужно залезть еще куда нибудь и найти эту самую недетскую строку (хотя, я обычно из сложной строки столбец делаю :) )

Цитата:

---

Сообщение от Валенок

Oй что это ? Переходим к структурному поверху ? А как же все условия скрыты ??

---

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

Цитата:

---

Сообщение от Валенок

И 10 – сложный ?

---

ну, 10 больше чем 5, вроде как сложнее...

Цитата:

---

Сообщение от Валенок

Т.е. это длинющее условие размножаем ? Да ?

---

Да. Проверяется только 1 раз в каждом цикле.

Цитата:

---

Сообщение от Валенок

Просто они с земли. Они предусматривают что можно на красную кнопку нажать или автомат выбить в любой момент

---

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

Цитата:

---

Сообщение от Валенок

Ну вот. С этого и надо было начинать. :) Существует куча способов заставить шаги SFC идти в любом порядке не прибегая к внешним воздействиям.

---

интересно конечно...

И какой смысл спорить, действительно неплохой способ с помощью case (или подобного) разбить сложную последовательность действий на части (с любыми переходами), я это этапами называл пока пару лет назад не наткнулся на http://is.ifmo.ru/
Но зачем так ревностно этому подходу имя присваивать, и зачем настаивать на каком-то способе оформления проекта? и так гемору с бумагами и прочим хватает. Очень надеюсь что заказчики на is.ifmo.ru не начитаются, а то проникнутся идеей опенсорса и начнут требовать у нас исходники с прогами и подробнейшими коментами, которые годами оттачивались, денег конечно как обычно платить не захотят.

Цитата:

---

Сообщение от Валенок

Просто отвертка. Из набора.

---

конечно неплохо когда кто-то делится своими отвёртками, только я не понимаю зачем это в теорию возводить.

Ну и так для прикола
http://forums.mrplc.com/index.php?ap...s&showfile=615
ну очень похоже на то что здесь, в архиве флешь ролик с конвертацией из визио в ST омрона. только американец почему то запамятовал дать своему творению "правильное" название.

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

Цитата:

---

Сообщение от Валенок

Т.е. сложные условия вы все-таки куда-то прячете ? Тогда и я вернусь к первому варианту

---

Нет. Вы прячете в состояние, а куда переходить суете в переменную state. У меня все условия нагромождены на графе.

Цитата:

---

Сообщение от Валенок

Сложное условие копи-пасте в кучу мест ? Класс. Программирование в лоб. Макросная вставка кода работающего с секторами/дорожками при любой необходимости сделать просто write() ??? Функции/подпрограммы/процедуры/прерывания отдыхают – это лишнее.
Особенно удобно вылавливать ошибки. Условие А из 2 в 1 точно написано, из 3 в 7 перепустали переменную, а из 9 в 4 вообще забыли исправить – хотели копипастить, но позвонили из клиники, тещу забрали в стационар.

---

Читаем первый пост. Один раз исправляем в графе и автоматически получаем код.

Цитата:

---

Сообщение от Валенок

Вы хоть поняли необходимость параллельных шагов ? Даже если они квазипараллельные

---

не очень. если можно еще раз и одним предложением. "Паралельные шаги нужны для...."

Цитата:

---

Сообщение от Валенок

Для объективного сравнения чего, нужно оба предмета изучить досконально. Причем я не утверждаю что смог это сделать.

---

Мы в равных положениях, я знаю это, вы знаете то, вот и выясняем +сы -сы

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

Цитата:

---

Сообщение от BETEP

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

---

Чтобы понять уровень сложности конвертера откройте его исходники и документацию

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

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

Цитата:

---

Сообщение от BETEP

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

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

---

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

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

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

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

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

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

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

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

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

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

Цитата:

---

Сообщение от Валенок

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

---

:)

Цитата:

---

Сообщение от BETEP

up

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

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

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

Цитата:

---

Сообщение от Игорь Петров

Хм. В стандарте МЭК такого требования нет. Кроме состояний в 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 :)

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

Как?

Цитата:

---

Сообщение от gtfox

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

---

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

Цитата:

---

Сообщение от gtfox

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

---

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

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

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

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

Цитата:

---

Сообщение от Игорь Петров

С 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 конвертер уже делает то что необходимо. Если бы были средства использования рефлекса то не появился бы конвертер.

Цитата:

---

Сообщение от Игорь Петров

:confused: Обсуждая подобные темы в ветке по 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) версия

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

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

Цитата:

---

Сообщение от gtfox

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

---

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

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

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

Цитата:

---

Сообщение от gtfox

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

---

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

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

Цитата:

---

Сообщение от gtfox

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

---

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

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

Цитата:

---

Сообщение от Игорь Петров

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
долго отсутствовал по рабочим причинам

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

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

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

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

не так всё просто с временем цикла контроллера, не зря ведь придумали обработку части входов и выходов вне основного цикла, Наверно это кому то нужно.
управление через SysLibPort и timer.lib

В шапке темы обновил архив с Visio2ST. Добавил язык С++ для применения кода в Arduino
_METAAUTO_VISIO2_ST_CPP_password=1.zip (42.06 Мб)