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

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

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

Так, может ли шаговое программирование (пошаговое управление) «помножить на ноль» автоматное программирование (АП)? Вот тот вопрос, на который хотелось бы получить незамедлительный ответ. Его поиском мы и займемся...

Модель RS-триггера

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

Почему RS-триггер?

Ответим несколько подробнее заодно и на этот достаточно часто задаваемый вопрос... Конечно, дело не в триггере, а в той структуре/схеме, которую он представляет. Мы формируем модель параллельных процессов и на ее базе по плану должны создать аналогичную реальному триггеру программную модель. Она тоже должна содержать два параллельных процесса, иметь такие же связи и в работе отражать нюансы, характерные для реального триггера (вспомним про объект, который плавает и крякает и по совокупности этих признаков должен называться уткой, т.к. на нее очень похож).

Связи триггера относятся к классу обратных связей. Причем – перекрестных. Обратные связи, тем более подобного вида, создают множество проблем, как в теории, так и на практике.  Теория их фактически отвергает, а практика использует в полной мере, но объяснить и описать при этом поведение подобных систем почти всегда дело достаточно проблематичное. Хорошо бы иметь теорию, которая в этом помогала бы, но ее фактически нет. Круг замкнулся (?)...

Можно и по-другому: триггер есть, но о его работе, судя по известным описаниям,  имеется лишь общее представление. Да и об этом, если уж прямо и честно, знает не такой уж широкий круг людей. Почему-то мне кажется, что «чистые программисты» (не запятнавшие себя знаниями в электронике) в их число не входят.

Знакомство с RS-триггером или, скажем так, его прочтение любому программисту будет полезным. Это, во-первых, напомнит и/или даст представление о работе чисто логических  процессов. В них параллелизма не меньше, чем в любых сложных вычислениях. Триггер в демонстрации параллельности легко заменяет примеры из области, скажем,  банковских расчетов (примеры на эту или аналогичную тему почему-то чаще всего встречаются при рассмотрении параллельных вычислений). Во-вторых, он позволяет убедиться в ущербности современной теории параллельных вычислений и практических подходов их реализации. Ни корутины, ни многопоточность, ни, тем паче, многоядерность ни в малейшей степени не могут объяснить поведение RS-триггера или хотя бы просто реализовать его точное поведение по методике приведенной далее.

Так что … вперед. Мы же по отношению к параллельным вычислениям на примере RS-триггера все это продемонстрируем. Теоретически это сделано в предыдущей статье. В настоящей – чистая практика. Но если вы знаете другой достойный по качеству [параллельный] пример, то мы реализуем и его. Даже на ПЛК, даже на языке релейных диаграмм. Весьма желательно только, чтобы по форме он представлял «рафинированный параллелизм».

Тестирование

Теперь проверим то, что получилось. Первое, что сразу бросается в глаза - отсутствие генерации. Ее нет ни при запуске программы, ни по сигналу сброса. Это явная ошибка.

А присутствуют ли устойчивые состояния? Рассмотрим и это, «собрав» только дополнительно схему, показанную  на рис. 4. Последняя при каждом переключении  триггера проверяет его на запрещенное состояние. Каждый переход триггера между устойчивыми состояниями должен наращивать счетчик. Результаты следующие: переключение между устойчивыми состояниями есть, но оно не симметрично, т.к. переход в одно состояние счетчик наращивает, а возврат в обратное состояние – его не изменяет. А это еще одна серьезная ошибка в функционировании модели асинхронного триггера.

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

Проблемы программирования

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

Так, не удалось создать функциональный блок логического элемента И-НЕ, использующий шаговые реле. Его программирование и, затем, последующая компиляция приводит к ошибке (см. рис.5):

Устранить ее удалось только прямым переносом кода из функционального блока в программный модуль типа PRG. Далее пришлось данный код представить в двух экземплярах (по числу элементов триггера) и установить связи между элементами, используя выходные переменные ПЛК.

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

Выводы

Метод пошагового управления соответствует автоматному программированию, но  только лишь в очень малой степени, а потому заменить его не может. Да, шаговое реле (в терминах языка LD) можно интерпретировать в качестве отражения тех или иных состояний программы, а код, который им соответствует, как реализацию функций переходов и выходов конечного автомата. Но и не более того. А посему в силу отмеченных аналогий шаговое программирование (или пошаговое управление) было бы правильнее называть автоматным программированием. Хотя, что там лукавить, это далеко не самый лучший его вариант. Тестирование также показало, что создание множества автоматов путем активации нескольких шаговых реле не реализует параллелизм от слова совсем.

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

Все описанное и ранее и выше, как можно видеть,  совсем не сложно. Сложнее другое – научиться мыслить автоматами, что потребует, вероятно, определенной «ломки сознания» (по факту последовательного и блок-схемного). А на это придется потратить, скорее всего, немало времени и терпения. Но сделать это сейчас будет уже много-много легче. Все-таки на текущий момент автоматное программирование совсем уже не «То-Чаво-Не-Может-Быть»…

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