Наконец‑то мы добрались до конечной цели — графики, которая достаточно близко к реальности моделирует интересующие нас объекты. Речь пойдет об объектах систем управления (СУ). Это датчики, переключатели, индикаторы, моторы, конвейеры, объекты типа рассматриваемой нами гильотины и т. д. и т. п.

Данный цикл статей - не техническая документация, не подробное описание научных идей. Это краткое, обобщенное описание возможностей среды ВКПа на простом примере. Демонстрация процессов и принципов работы в ней. Идеи - проверенная временем часть. Они описаны в статьях, ссылки на основные из них приведены в  первой части [1]. Без понимания этого материала невозможно разобраться, зачем вообще нужна подобная среда. Ведь, существует и другое автоматное программирование. Но только идеи, положенные в их основу, другие.

Отличие идей - это главное, чем объясняется необходимость среды ВКПа. Другой такой просто нет, как нет по большому счету и таких идей. И,  вообще, без понимания основ теории автоматов невозможно объяснить необходимость данной модели вычислений. Ведь, без автоматов программисты когда-то вполне обходились, а большая часть без них обходится и до сих пор.

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

В моих статьях часто используется аббревиатура ВКПа. Это сокращение названия программной среды проектирования по канонам технологии автоматного программирования - среды автоматного Визуально-Компонентного Программирования (подробно основы ее теории описаны в статьях [1, 2]). Объяснение, что это за среда, конечно, дается, но, признаю, что делается это часто по ходу, достаточно поверхностно и разбросанно по многим статьям.

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

Буквально за последние месяцы была проделана объемная целенаправленная работа по развитию среды и, что особенно важно, по повышению качества ее работы.  Раньше она была рассчитана на одного пользователя, который с ее проблемами легко мирился. Но, как говорится, до поры до времени... Теперь этот пользователь, а заодно и разработчик, решил сконцентрировать силы на доведении ее до нормального рабочего состояния.  Пришло, так сказать, время перейти на новый уровень качества среды. И, может, это прозвучит нескромно, но захотелось заодно поделиться также удовольствием от нынешней работы в ВКПа...

Упомянутая в заглавии книга (далее H&H) - это про железо [15]. Я - про программирование, но на базе "железной модели" конечного автомата. И там и там математическая основа одна. Все это, действительно, крутая железная концепция, помогающая поставить не только синтез цифровых схем, но и программирование на совершенно другие рельсы, определяющие его будущее.

Параллелизм у программистов нынче в моде. Но, видимо, они (программисты) совсем не в курсе, что разработчики железа давным-давно погружены в эту тему. А потому им (я все про программистов) есть у кого поучиться. Но, похоже, некие амбиции-заскоки этому  мешают. Но, если вы этим не страдаете, то прочитайте книгу H&H и дойдите, ну, хотя бы до 4-й главы. Попробуйте реализовать одно-два упражнения, используя свой, программистский инструментарий - всякие там корутины, потоки и весь сопутствующий этому террариум. Убедитесь в его полном бессилии. И тогда, может, это заставит кое-что пересмотреть, переосмыслить. Только представьте: логический элемент - отдельный процесс, десятки, сотни, тысячи элементов - множество параллельных процессов, и все это в вашей ладошке (это я про смартфон) и даже работает!

Но пришло время исполнять обещанное (см. предыдущую часть темы в [1]). И пусть количество "плюсов" пока не достигло заданной планки, но ... если каждый "минус" считать за два "плюса", то это уже более чем ... ;) Так что спасибо всем, давшим положительную оценку - нет, не автору, а затронутой теме. Области знаний, от которой многое сейчас зависит.  Это те слова, которые мы вправе сказать в адрес теории, посвященной  синтезу цифровых схем, в адрес тех, кто занимался и занимается ее развитием, становлением и внедрением в практику.

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

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

Итак, начнем...

"Зацепила" крайняя статья про многопоточность [1]. Но, с другой стороны, - а что ожидал автор, предложив исходное решение без синхронизации? Получил то, что и должен был получить. На другое рассчитывать было бы достаточно наивно. Во-первых, потому, что используется весьма  проблемная модель параллелизма. Во-вторых, расплывчатое представление о решаемой проблеме (по крайней мере, если судить по описанию). Но это уже мое личное мнение и хотелось бы его пояснить. И не просто так, а подкрепив решением.

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

Но, может, автор достиг чего-то нового? Да, вроде, нет. То, что нужно синхронизировать - не новость. Нов ли предложенный механизм синхронизации? Не знаю, поскольку не специалист в  Python. Надеюсь такие найдутся и ответят на этот вопрос.

Покажу, как подобные проблемы решаю я. Причем совсем не прибегая ни к многопоточности, ни к всему тому, что нынче на волне успеха в так называемом параллельном программировании. И, как сказал автор статьи, "не спешите закрывать вкладку", а посмотрите, что будет дальше. А вдруг вам понравится?

Но для начала...

Краткая история вопроса

Использование переменной-счетчика в качестве общего ресурса - отнюдь не новость. Это элементарный и естественный подход к демонстрации проблем множества параллельных процессов. Насколько я припоминаю, впервые с подобным примером в серьезной литературе я столкнулся в книге [2].Предлагаемые там решения не вызвали восторга, а потому были задвинуты. И, кстати, об этом я не испытываю сожаления.

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

Программисты, как правило, кушают то блюдо, которое им подают. Будь это язык программирования, библиотека, фреймворк или IDE. Однако, это еще полбеды. Удивляет нежелание выбирать. Хотя это тоже можно объяснить. Выбор‑то, может, и есть, сколько новых языков появилось за последнее время, но только разницы между ними особой нет. В результате, попробовав раз, попробовав два, мы устаем и останавливаемся на чем‑то одном, т. е. пресыщаемся...

Конечные автоматы и соответственно автоматное программирование (АП) интересны в первую очередь параллелизмом и эффективностью его реализации. Причем параллелизм у КА присутствует уже на уровне компонентного КА, но несомненно важнее параллелизм сетей автоматов. На примере простого алгоритма НОД было показано, как можно легко превратить любой алгоритм в процесс, а затем из них создать более сложную схему. «Сетевая конструкция» позволяет эффективно представлять параллельные процессы и создает понятную, простую и теоретически обоснованную теорию параллельных вычислений (см. подробнее [3]).

Модель отдельного КА определяет точки и механизмы взаимодействия (здесь вспоминаем про состояния) между параллельными процессами. Состояния автомата фиксируют моменты программного и/или аппаратного прерывания/приостановки/взаимодействия процессов (см. автоматный код НОД в статье). И не важно идет ли речь идет об имитации параллелизма в рамках одного потока или это будет множество потоков или даже ядер, т. е. того, что в иной подаче звучит как in parallel и concurrently. И здесь уже надо говорить об едином времени подобно единому времени реальных процессов. Соответственно, уточняя при этом, что на формальном уровне речь идет о сетевой автоматной модели с единым дискретным временем. При этом допускается, что разные сети вправе иметь индивидуальное дискретное время.

Дискретное время — важнейший элемент автоматной модели. Оно, как и состояния, зашито в определении модели. И уже только состояния и дискретное время выделяют автоматы на фоне других моделей. Дискретное время играет важнейшую роль в формировании качественно иной, например, по отношению к той же многопоточности или многоядерности, модели и теории параллельных вычислений. Важно также понимать, что любые асинхронные сети такой теории не имеют. Можно даже утверждать, что теория параллелизма на базе КА не была бы возможна без дискретного времени и, конечно, состояний. И актуальны они именно в своей «связке».

На рис. 1 приведена блок-схема алгоритма нахождения наибольшего общего делителя двух натуральных чисел из книги Н. Вирта[1]. С таких алгоритмов, да и с подобных книг,  начинается или должно начинаться знакомство с программированием. И, кстати, книга Н.Вирта была одной из первых, с которой в свое время познакомился и я. Так что здесь присутствует и некий личный мотив.

Поводом для написания статьи послужило не очень приятное для меня событие: модератор Хабра убрал теги – «С++» и «Параллельное программирование» из моей крайней статьи [1]. Этому предшествовало сообщение пользователя, который по его словам не заметил в статье ни С++, ни параллелизма и поспешил об этом известить весь свет. На самом деле он, скорее всего, просмотрел статью по диагонали и попросту "не врубился". Другим объяснить сей казус сложно. Я объяснил причины его заблуждения, но это не было принято во внимание. В ответ – тишина и, более того, пошли у него на поводу.

А до этого, но тоже в контексте рассматриваемой статьи (теперь все это складывается в один пазл), произошло еще одно событие.  Другой пользователь, решивший, видимо, поддержать автора, выразил благодарность, но допустил не очень лестные высказывания в адрес специалистов Бауманки. Не то, чтобы я с ним был во всем согласен, но поскольку на асфальте розы не растут, то в чем-то он был все же прав.

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

В контексте автоматного программирования ВКПа опять вспомним про SimInTech. Представляется удобным и наглядным создать аналог проекта из в SimInTech, который основан на базе элементов ее библиотеки «Конечные автоматы». Так мы осваиваем проектирование в рамках данных сред и заодно проведем сравнение технологий автоматного программирования. Ну, а за основу для достижения поставленных целей возьмем проект «Нагреватель» из SimInTech.  

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

Графы на рис. 1 представляют собой модель автоматной программы в ВКПа. И уже на уровне модели видны основные отличия. Кратко или, так сказать, в первом приближении они сводятся к следующему. На уровне отдельного процесса (автомата) мы сразу разделяем программу на части. Это операторы, названные предикатами и действиями, и управление программы – собственно модель конечного автомата (КА). А на уровне самой программы в общем случае это сеть из автоматов. В соответствии с данным ранее определением все это вместе и составляет автоматную программу.

Продолжим. Наша текущая цель - на примере  аттракторов достичь равенства результатов в SimInTech  и ВКПа.  Делать мы это будем приведением моделей к наиболее универсальной базе - используя языки программирования (ЯП). В ВКПа уже есть реализация на С++. Осталось создать ее в SimInTech. В таком виде они будут соответствовать друг другу. А в идеале, если языки одинаковые, даже просто совпасть. Все это должно способствовать равенству результатов. И на этом пути, кроме освоения внутреннего языка программирования SimInTech,   особых препятствий не предвидится.

Блоки на внутреннем ЯП в SimInTech создаются на базе блока PL  - блок библиотеки Динамические. Напомним реализацию модели аттрактора Лоренца на стандартных библиотечных блоках. Она приведена на рис. 1. Далее мы ее будем называть исходной схемой. Часть ее вместе с соответствующим кодом на языке программирования SimInTech (LangBlock22) представлена на рис. 2.

Я уже не знаю кому и чему верить. Собрался было подводить итоги по обсуждению аттрактора Лоренца, но что-то меня заставило "поиграть" еще с одним - мотором Рикитаке [1]. И, честное слово, какого-либо подвоха я, ну, никак  не ожидал. Просто потому, что по виду графиков он был, пожалуй, наиболее стабильным и характерным по внешнему виду во всех программных пакетах - MATLAB, SimInTech и ВКПа (cм. также предыдущую статью [2]).

            На структурном уровне рассматриваемые аттракторы можно представить в виде трех блоков ("черных ящиков"), отличающихся лишь видом связей. Структурная модель аттрактора Рикитаке представлена на рис. 1а, а на рис. 1б для сравнения приведена схема аттрактора Лоренца.

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

И, вроде бы все так, да не всегда. Критично ли наличие ошибок в программах? Странный вопрос - конечно, критично. Но, тем не менее, найдутся и те, кто скажет – не беда. И даст этому свое объяснение. Здесь, правда,  можно вспомнить, как фирма Intel объясняла несущественность ошибки деления с плавающей точкой в процессоре Pentium (подробнее см. [1]). Но общественность и пользователи объяснили Intel, что она не права. И, понеся большие репутационные и финансовые потери,  ей пришлось с этим согласиться и исправить положение.

Далее, обсуждая конкретные программы, мы столкнемся с тем, что нужно считать ошибками. Отличие от ситуации с Intel только в том, что необходимо будет конкретизировать, кто ошибается и ошибается ли и где источник ошибок. Но то, что идет явно не по плану, подтверждают результаты нашего тестирования. Просто ситуация несколько сложнее проблемы одной операции деления FDIV. 

Итак. Выберем для экспериментов три среды: две известные – это MATLAB, SimInTech и одну, известную больше по статьям вашего покорного слуги, - среду параллельного автоматного программирования ВКПа. Для первых двух можно скачать ограниченные версии.  Их возможностей вполне будет достаточно для наших примеров. Ну, а в отношении третьей - придется довериться автору.

Времена нынче суровые. Откуда «прилетит» непонятно, но то, что «прилетит», сомневаться уже не приходится. Вот оно и … «прилетело». В связи с определенными обстоятельствами (возможно, вы даже догадываетесь какими) предложено рассмотреть  переход с ПЛК фирмы Delta на ПЛК от Haiwell. Мы, как говорится, и не такое  переживали, а потому качаем среду проектирования HaiwellHappy и пытаемся ее освоить. Самих ПЛК, хотя они уже заказаны (?!),  пока нет, но есть симулятор. Но для начала этого вполне достаточно…   

Путь проторенный. А потому в целях обучения и одновременно внедрения технологии автоматного программирования создаем – что? - правильно, модель RS-триггера. Почему? – см. статью [1]. Но, если кратко, то триггер - это фактически мизерный проект, от которого пользы – ну, просто туча. В этом и предстоит далее убедиться.

Однако, смотрим, на что же позарились наши менеджеры?… Цена ПЛК – хорошая! Ну, то есть – относительно небольшая. Для нормального менеджера этого, видимо, уже достаточно. Но работать-то – программистам!  Ставим среду и создаем наш первый проект. Это, как уже было сказано, модель реального RS-триггера.

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

Соловей!.. Ведь, слушайте, ведь вот пичуга! Ну, смотреть не на что!.. Ну, мелочь пузатая!.. А ведь как, подлец, природу украшал!.. Что делал, мерза­вец!.. Э-тю-тю-тю-тю-тю-тю, тю-тю-тю!..

Райкин А. Люди и манекены

Рассмотрим алгоритм, который заимствован из несложного проекта системы управления прессом. В сам проект вникать не будем, а рассмотрим лишь его небольшую и, пожалуй, самую простую часть – управление валками. На пульте управления есть кнопка «Валки» (на рис. 1 сигнал X6), при нажатии на которую посылается сигнал, который то прижимает, то отпускает валки. Преобразуем алгоритм управления валками в автоматную форму и посмотрим, что из этого получится.

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

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

1. Автоматное программирование: определение, модель, реализация.

2. Вот, как просто! Автоматы в деле. Для ПЛК фирмы DELTA.

3. Автоматы в деле. Штабелер. Засады ПЛК.

Задание на проектирование программы

В предшествующей статье мы уже рассматривали штабелер. Здесь будет более сложный его  вариант. Это узкое «крыло», которое, находясь в исходном состоянии, с паузой после старта проката подхватывает лист металла и поддерживает его в процессе движения. После останова проката и отсечения листа оно выполняет «отскок» вперед, освобождая конец листа, который падает на приемное устройство - гидростол.  После этого "крыло" возвращается в исходное состояние. Во время этих движений прокат должен быть остановлен. После исполнения задания (формирования нужного числа листов заданной длины)  «крыло» перемещается в заключительную позицию за пределы гидростола. Возврат в исходное состояние происходит после нажатия кнопки «Штабелер». Выполнение самого задания начинается с нажатия кнопки «Прокат», а длина отдельного листа и общее их количество указывается на панели оператора. 

После нажатия кнопки «Сброс» (прокат останавливается, переходя в режим паузы) штабелер должен войти в режим паузы. Повторное нажатие кнопки выполняет реальный сброс системы управления. Продолжить прокат, находясь в ситуации паузы,  можно с помощью кнопки «Прокат». Штабелер, находясь в режиме «Автомат», может входить в тот же режим паузы, но после формирования текущего листа.   Работа штабелера в режиме системы «Полуавтомат» несколько отличается от работы в режиме «Автомат». В первом случае он останавливается после выполнения проката и ожидает срабатывания гильотины (в режиме «Полуавтомат» она запускается вручную). Дождавшись, он сбрасывает лист и перемещается в заключительную позицию. Из нее нажатием кнопки Штабелер «крыло» возвращается в исходное состояние. В режиме «Автомат» перемещение в заключительную позицию происходит только после выполнения задания.

Штабелер – устройство, расположенное после гильотины.  Для отражения своего состояния он может иметь один или два датчика. Таких состояний обычно два - закрытое и открытое. Находясь в исходном состоянии - закрытом, штабелер принимает лист металла и затем - в открытом состоянии сбрасывает его в накопительное устройство. После этого возвращается в исходное состояние. Мы рассмотрим штабелер, содержащий один датчик. Для правильной трактовки текущего состояния штабелера нужно в ручном режиме установить его в исходное состояние и далее вести отсчет состояний уже от него.

Запуск и режимы работы штабелера

Система управления линией профилирования металла поддерживает три базовых режима - ручной, полуавтоматический и автоматический. В программе им соответствуют реле - M9, M10, M11. Штабелер имеет всего два режима работы, названных  далее ручным и автоматическим. В ручном режиме работы системы он работает соответственно в ручном режиме, а в остальных - в автоматическом.

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

На рис.1 представлен код, который запускает в работу штабелер, устанавливая единичное значение флагу bПускШтабелера. При этом текущий режим ему задается флагом bРежимШтабелера, нулевое значение которого определяет ручной режим работы, единичное - автоматический.

А что сказка дурна — то рассказчика вина.
Изловить бы дурака да отвесить тумака,
ан нельзя никак — ведь рассказчик-то дурак!
А у нас спокон веков нет суда на дураков!..
Леонид Филатов.

При обсуждении предыдущей статьи буквально, как "чертик из табакерки", выскочил вид программирования, названный шаговым. Автор был готов к подобному, поскольку был знаком ним, хотя, может быть, и "шапочно". В документации на ПЛК такое программирование носит, правда, название пошагового управления (видимо, это и сбивало меня на термин "пошаговое программирование"). Но это не столь принципиально, чтобы по этому поводу «ломать копья». Важна суть, а именно в силу ее далее эти термины будем считать равноправными.

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