Комментарии 76
Два раза переключить язык в одном слове?
Кислотные цвета и поиграться со шрифтами?
То, чему не подыскал место в статье - рабочее место "автоматчика" :)
Насколько я знаю, логика LD имитирует физические релейно-контактные схемы, и сделан LD специально для тех динозавров, кому удобно решать задачу в терминах этих схем. В вашей задаче LD полностью определяется автоматом. Почему бы тогда не генерировать весь LD из описания автомата? Минус ошибки кодирования, минус синхронизация графа и LD при изменениях графа. Описание автомата потребуется сделать машиночитаемым, например, текстовым на основе dot. Плюс удобный просмотр изменений в версиях, плюс возможность анализировать автомат программно, например, верифицировать на невозможность запрещенных состояний (как BPF). Идея на поверхности, нет ли такого уже для ПЛК? В отличие от попыток генерировать код из UML для прикадных программ, здесь схема четко задает всю логику.
Вы все правильно пишете. Все в идеале именно так. И те, кто делает подобное, делают это именно так. Или пытаются сделать именно так. Но здесь много нюансов. Этим надо заниматься и заниматься серьезно, иметь под это средства. Ну, а чтобы иметь возможность реально работать "здесь и сейчас", то проще все эти "минусы" взять на себя. В данном случае это совсем не сложно. И, главное, что помогает и помогает серьезно в работе. Я же работаю именно так и ни кто меня не заставляет работать именно так.
Есть ли что-то подобное для ПЛК? Не знаю. Но, скорее всего, нет. Это, если речь о подобном. Такого же, как предлагается, нет точно. Иначе бы я знал. Скрыть это сложно ;)
Есть такое это SimInTech: https://habr.com/ru/post/307090/
На хабре есть масса статей где люди так и делают. Например эта
Собственно и я об этом. Есть примеры, ну, очень хорошо проработанных идей. Я к ним отношу UML (все-таки в ней есть что-то похожее на автоматы). Но это почти чистая идея. Она, как идея, где-то была взята в качестве основы для конкретной практической наработки. Тот же StateFlow. И, казалось бы, что еще надо для счастья? И кому-то это "счастье" подходит. Как это и произошло в случае упомянутой статьи. Но это "счастье", поверьте, не будет долгим.
Мне StateFlow не подходит. Совсем. И не по причине большой привередливости. А потому, что эта модель не обеспечивает нужное качество проектирования. Это главное. Я бы на все остальное закрыл глаза, но ... RS, блин его, триггер в StateFlow не работает. Хоть ты ... тресни. Проверено. Лично.
И зачем мне тогда вся остальная "красота" StateFlow? О ней, кстати, тоже есть что сказать. Но зачем? Если все ясно - не работает и точка. Но пример МАТЛАБ-а очень хороший. Как показатель куда надо стремиться. Но, честное слово, ожидаючи какого-то идеала, можно и жизнь "просвистеть".
Если бы можно было в StateFlow внедрить модель, которую нужно мне, то ... Но, во-первых, это невозможно, а, во-вторых, зачем? Чтобы увязнуть? Есть, ведь, оказываются, очень простые приемы, которые позволяют организовать работу не хуже, а лучше (!), чем в StateFlow. (В смысле качества работы, а не "картинок", конечно. Тут только можно позавидовать) И даже на языке LD и на ПЛК. На Qt и C++, конечно, было веселее, но... как говорится, "жизнь диктует свои законы". Пусть немного ручками (не как в MATLAB-е, не как в моей родной ВКПа на С++), но зато надежно и предсказуемо. А это в реальной работе стоит больше и ценится выше, чем любая "красота" и "картинки". Но это мое личное мнение. И мой личный немалый опыт. В том числе и на крайнем моем поприще - ПЛК. Для меня это именно так и есть.
Качество работы и проектирования - понятия весьма расплывчатые. Особенно расплывчатые, когда никто собственно это не может проверить.
Лучше говорить о фактах доступных всем.
В Simulink самые продвинутые средства рефакторинга гибридных диаграмм и средства отладки диаграмм.
Хотя да, в средах проектирования под ПЛК можно встретить более предметно ориентированные библиотеки. Но они будут черными ящиками. и отлаживать такие программы можно только с реальным железом.
Симулинк позволяет дольше оставаться в виртуальном окружении, т.е. реже вставать со стула. Ни это ли предвестник счастья?
Качество работы и проектирования - понятия весьма расплывчатые. Особенно расплывчатые, когда никто собственно это не может проверить.
И тут Вы глубоко ошибаетесь. Все проверяется. И это одна из тем моих статей - тестирование на параллелизм. И здесь одна из возможных проверок - тест на RS-триггер. Берете и проверяете. Как любой тест, он имеет для этого все необходимое: однозначную модель, известные результаты. Запускайте тест, фиксируйте результаты, делайте выводы.
Симулинк позволяет дольше оставаться в виртуальном окружении, т.е. реже вставать со стула. Ни это ли предвестник счастья?
Абсолютно нет возражений. Более того, я в какой-то степени даже пострадавший от такого "счастья". Дело в том, что мой предшественник (по словам моих начальников) не сидел на стуле, а постоянно что-то делал в цеху. Я "сломал", похоже, их представление о программировании, т.к. очень редко выходил в цех. Но, во-первых, мне нужно было время на освоение, а, во-вторых, разбираясь, я создавал технологию и собирал все, что выше на фото моего рабочего места - стенд для проектирования. Так, огрызаясь, я организовал нужное мне "счастье" и где-то 90% (а, может, и больше) я теперь делаю за столом. В цех выхожу, когда все отладил на стенде. Сейчас все работает и ситуация, вроде, устаканилась.
Так что справедливо выражение, что "каждый кузнец своего счастья" :) Но если бы не автоматная технология (на что я тоже, кстати, потратил уйму времени "за столом и стулом"), то, уверен, "счастья" было бы много-много меньше. По крайней мере, если говорить обо мне. Цель была поставлена, цель была достигнута. Лично я "счастлив". В рамках работы с ПЛК, конечно. И один из результатов такого "счастья" - цикл статей про автоматы на ПЛК ;).
Безусловно, счастья было бы больше, если бы работа походила на работу в Симулинк. Но почему-то мне кажется, что на ближайшую перспективу (да даже на отдаленную) мне такого счастья не дождаться. Я, если честно, уже счастлив тому, что удалось сделать.
Вот только ходят слухи, что, может, придется уходить с Дельты (ситуация, понимашь). Но это уже не будет горе. Будет, конечно, беда, но, думаю, не очень уж большая. Переживали всякое, переживем и это. Надеюсь ;)
RS триггер в симулинке рисуется очень просто.
Вот рабочая модель с верификацией
Если какая-то программа вам подсовывает RS триггер без элемента задержки Memory, то значит вы получаете действительно кота в мешке. Упрощенная схема RS триггера как ее обычно рисуют
физически не реализуема и нарушает принцип причинности. А симулинк как раз вам такой принцип нарушить не даст.
Ну и кто тут самый надежный?
Вот такой подход мне нравится... :) Когда все конкретно. Теперь только нужно будет довести обсуждение до логического конца и разобраться. Может, действительно, я и ошибаюсь. Конечно это "перевернет" мои представления. И о реальных процессах и о программных. Не хотелось бы, но ... я готов ;)
Итак, начнем с Вашей фразы
физически не реализуема и нарушает принцип причинности.
здесь я не понял. Все же это обычная схема на дискретных логических элементах ИЛИ-НЕ (часто называют - НЕ-ИЛИ, NOR и т.п., но мне как-то ближе ИЛИ-НЕ). Собирал лично ручками. Правда были И-НЕ, но собирал таки. Физически :) Поэтому уточните. И что это за "принцип причинности"?
Выше схема в симулинке. Можно ее чуть изменить? Соединить установочные входы триггера и подать в эту точку входной сигнал. От одного из нарисованных там же генераторов. И привести картинку сигналов. Только чтобы на ней отображались и входной и выходной сигналы.
Принцип причинности в том что причина не может существовать одновременно или после следствия.
Когда вы в симуляторе рисуете упрощённо RS триггер, то симулятор (если он правильный) должен это расценить как факт одновременной подачи и входного сигнала, и сформированного на его основе, выходного.
Так симулятор делать не должен позволять, поскольку физически не реализуемо.
Когда же вы паяете микросхемы, вы всегда имеет элемент задержки (все микросхемы имеют задержку, хоть и пикосекунды) и эта задержка ещё будет разная между разными гейтами.
Вот тогда вы должны в симуляторе честно рисовать эту задержку.
А если симулятор не требует её рисовать и все же выполняет симуляцию RS триггера, то значит он эту задержку принял по умолчанию без вас, и какая она вы не знает. Это будет, что называется, кот в мешке.
Посему, если хотите от меня адекватную модель RS триггера, то укажите все реальные его тайминги.
Вообще проблема автоматного программирование в отсутствии учёта таймингов и параллелизма в реальном времени.
Поэтому симуляторы ПЛК спокойно могут игнорить причинность, вводить задержки размером в доли базового такта и быть спокойными, что программа все равно выполняется корректно.
Прежде всего спасибо за ответ. На этом этапе, когда переходим к конкретике, все обычно "сливаются". Вы пока держитесь :) Спасибо. Но перейдем к делу.
Все же мне хотелось бы увидеть картинку для схемы, но с теми изменениями, которые я просил. Ну, ведь, это согласитесь не сложно. Надеюсь, что увижу.
Теперь далее. Когда я "паяю" я имею прежде всего логический элемент (ЛЭ), имеющий три контакта - два входа и один выход. Я знаю еще, что это элемент И-НЕ или ИЛИ-НЕ. Больше я о нем ни чего не знаю. Ну, вот такой - не очень любопытный до характеристик ЛЭ. Короче программист, но ... умеющий паять. Далее я беру еще один такой же элемент и проводочки. Все это соединяю по схеме "как обычно" триггера (Вы ее привели). Дальше соединяю входы, подключаю к точке генератор прямоугольный импульсов, к выходам триггера подключаю двухлучевой осциллограф и .... что я вижу? Вы скажете - да почти ни чего. Что в симуляторе, что на макете. Но, ведь, уже есть, что сравнивать.
Если симулятор хороший, то он должен и симулировать хорошо, т.е. в идеале картинки в симуляторе и на осциллографе должны быть одними. Если нет - пытаемся понять причину. Во внутрь ЛЭ мы не влезем (может только их, например, поменять местами, заменить на другую серию и т.п.). А с симулятором можно творить, что угодно, добиваясь, в конце концов, максимального приближения к реальности. И, если этого добьемся, то, похоже, мы что-то уже поняли в этом деле. Так что, еще раз, хотелось бы увидеть "картинку" с симулятора (извините за настойчивость, но у меня, к сожалению, МАТЛАБ-а нет).
Далее.
Посему, если хотите от меня адекватную модель RS триггера, то укажите все реальные его тайминги.
Поскольку я "тупой програмист", то в этих "таймингах" не секу, но у меня есть логический блок с функцией ИЛИ-НЕ (так писать привычнее). У него два входа и один выход. Я их тупо соединяю и что я должен видеть? А я должен видеть работу RS-триггера. Я должен быть уверен, что это и есть триггер. И если у меня такая уверенность есть, то я схему не паяю. Если нет, то тогда что ж - засучивай рукава, брат-программист ;) ...
Так что кот не кот, но я использую то, что у меня под руками - доступные элементы. Пусть это некая библиотека. Да тот же симулинк, если конкретизировать. Собственно Вы так и поступили "собрав" схему в симулинке. Только зачем-то (с позиции тупого программиста) добавили третий элемент - memory (на макетной плате ее, замечу, нет!). Но пока на это не будем обращать внимание. Надо так надо. Опять же - хочу картинку ;)
Вот тогда вы должны в симуляторе честно рисовать эту задержку.
Если Вы помните я "тупой программист". А потому - с какой стати?
А если симулятор не требует её рисовать и все же выполняет симуляцию RS триггера, то значит он эту задержку принял по умолчанию без вас, и какая она вы не знает. Это будет, что называется, кот в мешке.
А вот это по-честному. Но, во-первых, меня "тупого программиста" это и не интересует. А, во-вторых, даже если я и "тупой", но, Вы удивитесь, - знаю :)
Вообще проблема автоматного программирование в отсутствии учёта таймингов и параллелизма в реальном времени.
Вот тут даже не спорю - утверждаю. Именно это и есть. Вокруг этого и "ломаются копья". Я утверждаю, доказываю, что - есть! Это нет у обычного программирования. А у автоматного есть и еще раз есть. Могу повторить еще раз :) Но я все не "трындычиха", которая просто трындит, а все это, как раз, и описал в своих статьях. Что, как и за счет чего.
Поэтому симуляторы ПЛК спокойно могут игнорить причинность, вводить задержки размером в доли базового такта и быть спокойными, что программа все равно выполняется корректно.
Есть разница между "верить" и "знать". И тут, прошу прощения, Вы больше верите, а я больше знаю. Программа RS-триггера в реальном (не симуляторе) ПЛК, созданная по классическим принципам обыxного программирования, не работает корректно. Она вообще, кроме как отражая устойчивые состояний, не работает как триггер (который, если помним, собран на макетной плате из реальных элементов). Так что это реалии обычного программирования на ПЛК. А созданный по автоматной технологии - работает. Вот в это и есть качественное отличие автоматного программирования от обычного. Даже на ПЛК.
Ну, что это я опять скатился на похвалы АП... Не обращайте внимания ;) А "картинку" я все же жду. Для той схемы триггера, что создали именно Вы. Про "реальные тайминги" я в силу своей тупости пока не ведаю. Давайте анализировать то, что есть. То, что, как Вы утверждаете, в ПЛК "все равно выполняется корректно". Вот давайте и посмотрим насколько корректно...
Я теряю нить нашего спора.
Так вы согласны или нет что идеальный RS триггер невозможен?
Ну и как я сделаю симуляцию реального RS триггера на микросхемах если вы не даёте его детализации.
Я полагаю вы имеете симулинк и в курсе что он на идеальный триггер ругается по поводу алгебраической петли.
Мой элемент задержки memory вставлен только чтобы избежать петли. Чтобы модель была по настоящему адекватной нужны тайминги!
То что вы называете подходом "тупой программист" не избавляет от необходимости знания таймингов. Возможно вы думаете что они пренебрежимо малы. Но симулинк так может не думать, особенно на variable-step моделях. Он может взбрыкнуть и пожаловаться на несходимость.
Так что сразу определитесь будет ли у вас модель с variable-step или с fixed-step, а также какой из 11 сольверов (решателей) вы выбираете.
Я симулинк рассматриваю как эталон симулятора. Если в нем что-то не идёт, значит неправильная идея или модель.
Вы попробуйте подать на триггер на микросхемах частоту побольше, там пару сотен мегагерц и поглядите. Там чудеса начнутся.
Так вы согласны или нет что идеальный RS триггер невозможен?
Тут надо бы разобраться, что такое идеальный триггер. Тот, который Вы нарисовали и без элемента памяти - безусловно невозможен. Но в рамках АП на автоматных моделях логических элементов (ЛЭ) он реализуется. И без элементов памяти. Просто потому, что модели элементов отражают свойства реальных ЛЭ.
Теперь ближе к теме. К счастью МАТЛАБ я не удалил и даже нашел проект, который соответствует Вашему (ну немного его подправил). Вот эта схема.
Рис. 1. RS-триггер с одним элементом memory
Вот триггер с двумя элементами памяти:
Рис.2. Триггер с двумя memory
И чем объяснить разницу в результатах их работы? Добавили-то всего ничего, а что получили достаточно заметную разницу в результатах? И, заметим, с точки зрения среды обе эти схемы корректны. Как "тупому программисту" понять какая правильно работает?
А вот проект уже мой, который включает автоматные модели ЛЭ.
Рис. 3. RS-триггер на автоматных ЛЭ
Правда в нем задействованы элементы И-НЕ, но это не принципиально. Если сравнить результаты работы на рис.2, то они идентичны. Так что замена библиотечных идеальных ЛЭ на разработанные мною автоматные ни чего не изменила. Явно дело в чем-то другом? В чем?
Вспомним, что в реальной схеме нет элементов памяти, а только реальные логические элементы. А проблема в том, что вычислительная модель, используемая в матлаб, не отражает каких-то свойств реальных объектов. В раках автоматной технологии (см. реализацию RS-триггера на языке LD) также элементы памяти не используются. Видимо, вычислительная модель АП уже учитывает определенные свойства реальных процессов. Какие свойства? Не буду делать тайны. Одно свойство. Инерционность реальных объектов. И только лишь.
Диаграммы Steteflow работают по тактам.
Перейдя на диаграммы Stateflow вы просто ввели задержки величиной в такт. Переход из состояния в состояние требуют один такт. Настоящий RS триггер так не работает.
Что тут сказать. У вас просто неадекватная модель.
Адекватная модель я думаю была бы в variable-step c правильными задержками.
Ну подумайте логически. Если идеальный RS триггер невозможен, то что вы симулируете тогда?
Вы симулируете видимо физические логические гейты. Но тогда модель должны быть аналоговой и гораздо более сложной.
Если же вы симулируете логическую функцию RS, то вы нарушает её ограничения, она не допускает на входе запрещённых состояний. Это все равно что симулировать деление на ноль или как брать корень из -1.
По идее модель функции на такое запрещённое воздействие должна выругаться и прекратить выполнение, как прекращают выполнение программы при делении на ноль.
Логически - так логически...
По идее модель функции на такое запрещённое воздействие должна выругаться и прекратить выполнение, как прекращают выполнение программы при делении на ноль.
Это по идее. А как на эту идею ("запрещенное" воздействие) отреагирует реальный RS- триггер? Поясню чуть подробнее. Что будет на выходах триггера (на элементах, видимо, ИЛИ-НЕ), когда на входах будут две единицы?
И еще. Прочитайте мою статью. В ней обратите на замечание 2. И хорошо бы почитать книгу Фрике К. Вводный курс цифровой электроники. 2-е исправленное издание. – М.: Техносфера, 2004. – 432с. А в ней в главе 7 (Асинхронные триггеры) раздел 7.4. (Анализ с учетом задержки вентилей). Просто в ней другой подход, чем у меня. Может, он Вам будет ближе.
Правильную книгу выбрали.
Но в ней к сожалению нет категорического запрета не пытаться симулировать идеальный RS триггер. А симулинк в такой запрет ясно тыкает носом. И в этом его сила. Т.е. он сильней даже этой сильной книги.
А симуляция реальных CMOS микросхем не думаю что для нас обоих представляет интерес.
Словом с этим триггером полагаю вы забрели не в ту степь пытаясь как-то связать его с преимуществами графической нотацией и автоматами Мура (которые применяются в ПЛК).
И еще раз напомню мою позицию - сила в гибридной графической нотации, а не в некоем "автоматном программировании".
И еще раз напомню мою позицию - сила в гибридной графической нотации, а не в некоем "автоматном программировании".
Иметь "позицию" неплохо. Главное, чтобы под ней была крепкая основа. "Графическая нотация" почти бесполезна, если базируется на достаточно "мутной" модели. Вы так и не ответили на некоторые заданные вопросы. Про "запрещенные" вещи, про разницу в работе "правильных" триггеров и т.п. Вот Вам еще результаты моделирования:
Моделирование переключений триггера
Здесь я уже подал на входы комбинации сигналов за счет разной частоты генераторов. И опять разные результаты?
И триггер все же в той "степи" ;) Он тестирует МАЛАБ на параллелизм. И последний, действительно, к сожалению, этой проверки не прошел. Сильный-слабый МАТЛАБ :). Сильный-то он "сильный", но
"слабый" в реализации параллельных процессов. .
Алгоритм работы RS-триггера
Выше модель поведения триггера из книги Фрике. Она по сути такая же как у меня. А два совпадающих доказательства, полученные разными способами говорят о правильности результата.
Вы ссылаетесь на рисунки где в триггер введены задержки. Это уже попытка симуляции физических триггеров.
Я же написал что физические триггеры нам обоим не интересны потому что мы понимаем невозможность создания их адекватной модели из-за недостатка знаний о физической структуре.
Фрике сделал свои собственные допущения (а они нам нужны? ) о задержках и принялся вручную моделировать. Мне это его моделирование не несет никакой информации. Пока он для своей книжки проанализировал только одну модель, я в симулинке могу проанализировать сотни. Да собственно и вы продемонстрировали только что силу симулинка. А давайте на своем ПЛК продемонстрируйте такое же количество подходов.
Сами не осознавая сейчас пиарите симулинк и гибридную графическую нотацию. Полностью поддерживаю ваши усилия.
Вот только слово "параллелизм" вы употребляете не по назначению. Похоже вы этим словом пытаетесь бороться с принципом причинности. Хотя вроде бы уже согласились что причина и следствие не могут быть одновременно.
Автоматы всегда выполняются "последовательно" и никогда не "параллельно" . Если речь не идет о независимых автоматах.
Но если вы говорите о "параллельности" независимых автоматов, то вы еще не упоминали объектов синхронизации (например ивенты) между ними. В ПЛК есть конечно независимые потоки, но вы их не упоминали. Значит на ваших диаграммах нет никакого "параллелизма".
А в симулинке где вы нарисовали две диаграммы параллельно они на самом деле выполняются одна за другой, а не параллельно.
Даже если в Stateflow сделать тип диаграммы OR (где как бы несколько диаграмм выполняются независимо друг от друга), у них все равно будут стоять номера указывающие последовательность выполнения этих диаграмм.
Вы ссылаетесь на рисунки где в триггер введены задержки. Это уже попытка симуляции физических триггеров
Задержек в триггере нет. Есть элементы памяти. Они нужны, чтобы разорвать алгебраические цепи или по-другому обратные связи. Их необходимость описана, например, у Глушкова В.М. (см. кн. Синтез цифровых автоматов). Но если модель автомата изменить (см. инерционные автоматы у меня), то в элементах памяти нужды уже не будет.
Я же написал что физические триггеры нам обоим не интересны потому что мы понимаем невозможность создания их адекватной модели из-за недостатка знаний о физической структуре.
Мне - интересен. А в смысле их знания мне достаточно знания об их структуре (два процесса и связи между ними), знания об операциях, выполняемых процессами. А поскольку элемента ключевые схемы, то их прекрасно моделируют элементы с двоичным кодированием. Т.е. все, что мне нужно от триггера, мне известно. Но не известно его поведение. Та таблица истинности, которую Вы приводили, дает не верное представление о его работе. Тот граф, который у Фрике, или у меня дают понимание работы физического триггера. в том числе как он поведет себя при подаче на его входы запрещенных комбинаций, о том, что переключении у него на выходных обязательно будут запрещенные комбинации, что в определенной ситуации триггер должен войти даже в режим генерации. Таблица истинности об этом не дает понимания. И вообще. Триггер - это последовательностная схема и описывать ее таблицей истинности, мягко говоря, не верно.
Фрике сделал свои собственные допущения (а они нам нужны? ) о задержках и принялся вручную моделировать.
Очень даже нужны. Фрике "забыл", что задержки бывают двух типов. Поэтому его модель будет "генерить" даже при разных задержках. А реальный триггер в режим генерации не входит. Почему? Потому что 1) его элементы имеют разные величины задержек и 2) тип этих задержек - инерционные (о типах задержек см. Армстронг Дж. Моделирование цифровых систем на языке VHDL и в моей статье)) На ПЛК, кстати, эти задержки легко создаются и тогда модель триггера фактически неотличима от физической работы.
Похоже вы этим словом пытаетесь бороться с принципом причинности.
Нет в теории автоматов "принципа причинности". Но есть понятие обратных связей, алгебраических цепей и т.п. В теории с ними борятся введение в их разрывы элементов памяти (см. Глушков Синтез...). Я сформулировал понятие инерционного автомата и в этом случае эти элементы не нужны.
Автоматы всегда выполняются "последовательно" и никогда не "параллельно"
Есть понятие сети автоматов. В них автоматы формально параллельны (см., например, Кузнецов и др. Введение в дискретную математику, сети синхронных автоматов). Но для того, чтобы реализовать сетевую модель автоматов не нужны ни потоки, ни ядра, ивенты и что-либо еще. Достаточно одного ядра процессора. Как это сделать я демонстрирую на языке LD (на С++ это, конечно, несколько сложнее)
Даже если в Stateflow сделать тип диаграммы OR (где как бы несколько диаграмм выполняются независимо друг от друга), у них все равно будут стоять номера указывающие последовательность выполнения этих диаграмм.
В том-то и беда: результат зависит от последовательности работы элементов. В параллельной среде этого быть не должно. Так, я переставляю элементы модели триггера (на языке LD), а результат будет такой же. И будет ли это только триггер или схема много сложнее (из любого числа элементов) в параллельной среде мы должны иметь один и тот же результат. В симулинке этого нет. Нет потому и параллелизма. Потому-то для меня он (симулинк) почти образец для подражания с точки зрения реализации, но абсолютно не пригоден для работы, т.к. "внутре" у него последовательная модель вычислений. Может, правда, ее можно подкорректировать, как я это сделал на LD? Т.е. образец есть. Но пока такой задачи нет, да и, если честно, не очень ясно пока, как это сделать.
Ок, чтоб вам было понятно, привожу цитату книги на которую вы ссылаетесь:
Идеальный RS триггер не может рассматриваться в теории автоматов и в сетях автоматов, потому что в нем обратная связь без задержки. Но никто, конечно, не запретит его рисовать на бумаге, как никто не запретит рассуждать о бесконечностях и сингулярности.
Вы ввели задержку, это потому что я вам сказал.
Ну отлично. Но при чем тут параллельность? Уже есть задержка (её физический размер в секундах ничем не ограничен), т.е. куча времени процессору обсчитать все состояния к следующему такту. На следующем такте процессор обсчитает все новые состояния так как будто все сигналы пришли одновременно и все состояния установились одновременно (типа параллельно в вашей лексике). И все нормально. В чем проблема?
Симулинк может симулировать любой алгоритм, кроме не поддающихся алгоритмизации и автоматизации!
И да, результат зависит от последовательности, поскольку последовательность в сетях автоматов и задаёт сам алгоритм. Без стрелочек графов ваш автомат не есть автомат, а просто рисунок на бумаге.
Лучше один раз увидеть...
Этот пример показывает...
Я просто приведу автоматную реализацию данного примера на языке LD
Схема генератора на одном элементе И-НЕ
А вот модель задержки. Выше она отключена и подключается, чтобы уменьшить частоту генератора (без нее частота очень большая).
Универсальная модель задержки -транспортная/инерционная
Инерционный автомат решает все проблемы обратных связей (циклических цепей и т.п.), когда нет необходимости вставлять задержки в разрыв цепей. подробнее об этом в статье. Дополнительно - статья
Ну называйте задержку как хотите, но это только означает что ваши автоматы работают последовательно и по тактам.
Никакой "параллельности" нет. Занимаетесь игрой слов.
Я все же называю так, как должно называть, как это принято. И не ясно как связано имя задержки с тем, как работают автоматы.
А параллельность есть. Нужно отличать модель параллельных вычислений от реализации этой вычислительной модели модели. В нашем случае реализация, действительно, последовательная, но это ни сколько не меняет сути вычислительной модели. Если по результатам ее работы Вы не сможете отличить, как она реализована, то это только означает, что "ядро" корректно реализует модель. А уж как работает ядро не столь важно. Точнее - совсем не важно. Если результаты работы (диаграмма сигналов) триггера и много более сложной схемы (см. подробнее примеры) ровно такие, как у реальных схем (а там уж точно все работает параллельно), то и модель вычислений (в рамках которой созданы модели работы триггера и схем) должна считаться параллельной. И в этом главный смысл понятия вычислительной модели.
Так что ни какой игры слов. Да, ядро последовательное, а вычисления параллельные. Вот у матлаба и вычисления и модели последовательные. Об этом говорит привязка к последовательности работы объектов. А у автоматных ФБ на LD такой привязки нет. Значит они параллельны по своей сути. Но не по реализации, конечно. Это воспринимается, как парадокс, но ... результаты тестирования убеждают, что все параллельно. Например, не зная о реализации Вы не сможете отличить параллельна ли модель или последовательна (приведите пример, если сможете). В матлабе можно. Достаточно изменить последовательность блоков. Все просто. Очень просто ;)
Еще раз. Параллельно поскольку используемая вычислительная модель параллельна. А как она реализована - дело чуть ли не десятое. Главное, чтобы ее работа соответствовала ее формальному определению. У нас - соответствует в точности Ну, или почти. Но там мелочи... ;).
Вы ввели задержку, это потому что я вам сказал.
Да нет, конечно. Те примеры, которые я привел, созданы в 2018-м году. Просто удача, что я не удалил ни матлаб, ни эти примеры. Хорошо, что еще вспомнил как работать с матлабом:)
Я имел в виду что задержку вы в симулинке ввели после моего совета. Полагал что вы просто плохо знаете симулинк, и подсказал вам решение.
Причем там эта задержка называется memory (память) как раз так, как называются элементы задержки в теории сетевых автоматов - памятью. Т.е. автоматы с памятью
Никакая вычислительная модель не может быть параллельной
Вы не можете в формуле (x+y)*z всё сделать параллельно.
Вы сначала должны сложить и только потом умножить.
Инерционная задержка - это вообще феерично. У времени и его отрезков нет никаких качеств кроме величины.
Ну давайте продолжать играть в слова. Сначала дайте определение понятию "параллельно".
Симулинк я, действительно, практически не знаю... Но пока мне хватает тех знаний, что есть. Но Вы затронули одну очень важную тему, названную Вами "игра в слова". Действительно, чтобы меньше было "игры" нужна однозначная трактовка "слов"... Ну, что ж - давайте по ходу разбираться и с этим... Для этого, конечно, надо начинать с теории, где определяются базовые понятия...
Итак. Начнем с "автоматы с памятью". В теории есть автоматы с памятью и автоматы без памяти. Автомат без памяти - это автомат с одним состоянием. Автоматы с памятью - автомат с большим числом состояний. Задержка или memory (память) - это тоже автомат, но очень простой, как минимум, с двумя состояниями.
Никакая вычислительная модель не может быть параллельной
Здесь тоже заглянем в теорию. Поскольку существует теория параллельных вычислений, то, видимо, существуют и параллельные вычислительные модели. Иначе, что ж она рассматривает?
Вы не можете в формуле (x+y)*z всё сделать параллельно.
Могу. См. статью, где я показываю, как это делается. В данном случае нужно иметь два параллельных блока - блок сложения и блок умножения. Установить между ними связи и ... далее "ловить" результат их работы.
Инерционная задержка - это вообще феерично.
Признаюсь я столь же восхищен этим понятием. Впервые о ней я прочитал у Дж. Армстронга. Так что - все к нему. Главное, что ее можно строго определить, чтобы четко отличить от другой задержки - транспортной (тоже, если что, - к Армстронгу).
У времени и его отрезков нет никаких качеств кроме величины.
С временем вопрос сложнее. Даже физики не дают точного его определения. Вот так довольно странно - явно есть что-то ощущаемое всеми, но точного определения его нет. Кибернетика (дискретная) поступила просто. Объявила время дискретным и ввела это понятие в конечный автомат. Лично мне пришлось с этим согласится. И не жалею об этом :) Более того, я стою на концепции единого дискретного времени. "Подсмотрел" это у Глушкова (кажется, в кн. Синтез цифровых автоматов).
По поводу инерционности автоматов (не задержки). "Классики" часто упоминают инерционность реальных систем: всегда есть время реакции на изменение входного сигнала (подробнее в моей статье).
Сначала дайте определение понятию "параллельно".
Вот это самое интересное. Наверное, с этого надо было бы и начинать ;) Кратко я бы сформулировал так - параллельно это все, что нельзя распознать, как последовательное. Это, как тест Тьюринга на искусственный интеллект. На примере RS-триггера это должно выглядеть так. Помещаем его во внутрь любого "ящика". Если извне Вы не сможете отличить, какой там триггер внутри, то реализация его столь же параллельна, как и он сам (в реальном исполнении, конечно). Например, по миганию выходов ПЛК (он, как "черный ящик") Вы не сможете сказать какой триггер к ним подключен: реальный или реализованный по автоматной технологии. У матлаба это распознается "по щелчку". Можно, правда, сделать и так, что будет сложно понять, но это надо знать как. Вот, как-то так ;)
Значит у вас термин параллельно - это все что вычисляется за такт.
Я понял.
Просто иногда вы путаете автоматные сети с абстрактными автоматами (функции на графах) где нет понятия времени и тактов.
Значит у вас термин параллельно - это все что вычисляется за такт. Я понял.
Вы поняли лишь частично. И упустили при этом главное. В-первых, для меня параллельно - это сеть конечных автоматов (с абстрактным состоянием), работающих в едином дискретном времени. Это с точки зрения управления. Но, кроме управления, есть операторы - предикаты и действия (а есть еще память). Они (те, которые актуальны на текущем такте), да, должны по времени укладываться в такт. Это если такт жесткий, или собой определять длительность этого такта, если длительность плавающая. В первом случае - это синхронная модель автоматов, во втором, - асинхронная (все это по Глушкову). Так же очень важно, как эти операторы исполняются.
Если сказанное выше не учитывать, то это будет ... все тот же "триггер в МАТЛАБ". Ведь и у МАТЛАБ и у ПЛК есть понятие дискретного такта. Но ни то ни другое параллельным считать нельзя.
Просто иногда вы путаете автоматные сети с абстрактными автоматами (функции на графах) где нет понятия времени и тактов.
Вы меня почти обидели (шучу) :) Скорее Вы, прошу прощения, что-то не так или не до конца понимаете ;) Нет автоматов, у которых нет тактов (такты - это модель времени, составная часть определения модели автомата). Без дискретного времени это не автоматы или некорректное их определение.
Вот тут проблемка и кроется.
В книжках реально когда говорят об абстрактных автоматах не имеют в виду автоматные сети, а именно автоматы без времени и тактов. Это по сути графы с функциями.
И если вы не понимаете контекст, то вы и превратно понимаете термин "автомат". А потом транслируете эту путаницу в своих статьях.
Идеальный RS триггер как логическая функция есть автомат без времени.
А вы все время хотите его спутать с автоматной сетью. Сетью он становится когда в нем появляется время и такты. И в таком виде он прекрасно симулируется в симулинке.
В книжках реально когда говорят об абстрактных автоматах ... а именно автоматы без времени и тактов.
А можно конкретно - в каких? Те, что я привык читать (см. ссылки в моих статьях) такого нет. Я, возможно, устарел и не в курсе современных подходов в теории автоматов.
А потом транслируете эту путаницу в своих статьях.
Хотелось бы опять же конкретики. Я даю ссылки на литературу, где дается теория автоматов. В ней такой путаницы нет.
А вы все время хотите его спутать с автоматной сетью. Сетью он становится когда в нем появляется время и такты. .
Сеть он становится поскольку он имеет такую схему, которую адекватно кроме как сетью описать нельзя. А такты - это неотъемлемое качество автоматной модели.
Если Вы ведете речь о другой модели, то ... какие проблемы? Очень даже хорошо. Есть с чем сравнивать.
И в таком виде он прекрасно симулируется в симулинке.
Это я совсем не понял... Ну и где и как это можно увидеть? Пока то, что предлагалось ни как не соответствует поведению реального RS-триггера. Или есть какой-то вариант в загашнике?
Можно по другому сформировать, задежка на такт интегрирования, без указания величины задежки. Такая задержка будет определятся тактом вычисления. В свойствах данного блока не указывается влелична задержки, она разная для разных тактов исполнения но всегда одинаково сдвигает выход относительно входа. И одинаково работает на любых частотах дискретизации
Насколько я понял инерционный автомат, просто по умолчанию содерджит задержку на один такт, вычислений. И обратная связь, это не алгебраическая петля, а как раз значение выхода с предыдущего такта вычислений? Цитирую из статьи:
"Существенной особенностью приведенного закона функционирования КА является привязка выходных каналов автомата к следующему моменту времени подобно изменению внутреннего состояния. Это исключает мгновенную реакцию автомата на текущее изменение сигналов входных каналов. Так моделируется свойство инерционности, присущее всем реальным системам."
Или я не прав?
Насколько я понял инерционный автомат, просто по умолчанию содерджит задержку на один такт, вычислений.
Да, это так.
И обратная связь, это не алгебраическая петля, а как раз значение выхода с предыдущего такта вычислений?
Обратная связь - это по большому счету просто связь любого выхода с любым входом. А обратная просто потому, что сигнал распространяется по некому циклическому пути от входного канала некоторого автомата опять же на его вход. Этот путь может включать несколько автоматов, а может и ни одного. В последнем случае мы просто замыкаем выход автомата на его вход.
Так??
У меня в ВКПа (да и на ПЛК) структурно это выглядит так. Правда, только структурно, т.к. такой графики, как у Вас у меня, к сожалению ;), нет. Все остальное именно так, как на моем рис. Т.е. не должно быть лишних элементов, которые бы отличали структурно модель от ее реального аналога. Я уж не говорю о том, что исключение "лишних элементов" не должно сказать на качестве работы модели.
Упрощенная схема RS триггера как ее обычно рисуют [...] физически не реализуема и нарушает принцип причинности.
Физически она как раз реализуема и именно так и работает. Это в симулинке она не работает из-за упрощений в модели.
Это в симулинке она не работает из-за упрощений в модели.
Не из-за упрощений. На LD, ведь, работает. А не работает потому, что симулинк не реализует параллельную модель вычислений. В этом вся проблема.
На LD вам ПЛК вставляет такт между обсчётами реле, вот и весь фокус.
Эт как раз ПЛК не умеет параллельно вычислять и везде вставляет такты. т.е. задержки.
Кстати, только что принесли заказ из Австралии. Там заказчик требует сделать схему строго на LD. Управление большими ангарными воротами (много двигателей).
Вот бы найти аутсорсера. А то мы LD ну совсем не переносим.
Если еще и с командировками, то, может, и смогу чем-то помочь :) Пишите в личку.
Хм, если там такты вставляются — значит, это JK триггер выходит, а не RS...
На LD вам ПЛК вставляет такт между обсчётами реле, вот и весь фокус.Эт как раз ПЛК не умеет параллельно вычислять и везде вставляет такты. т.е. задержки.
Я в такие детали обычно не вникаю, но ... Это, похоже, несколько не так: такт ПЛК формируется за счет кода всех цепей (код выполняется слева направо и сверху вниз) И по идее это время контролируется и не должно превышать заданной настройками величины такта.И параллельно он, конечно, не вычисляет, но его об этом можно "попросить", если реализовать модель параллельных вычислений. И, если все будет нормально, то, думаю, вы параллельное вычисление не отличите от последовательного (ну, все как я описал ранее). Задержки - отдельная тема. Они могут быть кратны числу тактов или задаваться таймерами.
Можете прсмотреть на рпботу тригира в StateFlow от SimInTech. Прскольку мы разработчики, было бы интересно понять в чем проблема и исправить. У нас StateFolow организован, не как отдельное прилодение к Simulink, а непосредственно в функционально блочных диаграммах и практически можно комбинировать тригеры и автомат состояний, возможно мы пока не со всеми клсяками столкнулись.
Я попробовал закачать SimInTech, но что-то не пошло. Меня не пустили :)
Но дело даже не в этом. В моей статье показано, как должен вести себя триггер (приведен граф его поведения). У Фрике также. В книжке Шалыто тоже что-то подобное. Т.е. есть полное единодушие в том, как должен вести себя триггер: при переключении обязательно проходит через запрещенное состояние (это должно ловиться другим внешним элементом), имея равные задержки элементов он обязательно должен входить в режим генерации. Это должно происходить в ситуации, когда, имея на входах "запрещенные" входные сигналы (для триггера на элементах И-НЕ это нули), на его входы подается сохраняющая комбинации - две единицы.
В точности так должен вести себя и триггер в SimInTech. Если этот тест не проходит, то ... дело плохо. Если проходит - уже лучше. Дальше нужно экспериментировать с величиной задержек, изменяя их произвольно у каждого элемента. Задержки должны использоваться двух типов - транспортные и инерционные. С транспортными задержками генерация будет наблюдаться, инерционные задержки ее будут гасить (как у реального триггера). Если и этот тест будет пройдет, то можно надеяться уже на идеал среды на реализацию параллельных процессов :) Но, чтобы быть окончательно уверенным, желательно пройти еще несколько тестов посложнее. Обычно, когда я вношу (давно уже не вносил) какие-то изменения в ядро, я провожу тестирование именно в таком порядке. Проходит - фиксируем, не проходит - ищем ошибку. Только так.
... и практически можно комбинировать тригеры и автомат состояний...
Не очень понятно. Триггер - это тоже автомат. Термин "автомат состояний" - не понятен. У автомата обязательно есть состояния. Если нет состояний - это комбинационная схема.
Поэтому выше получается "масло масляное", т.е. комбинировать "автоматы с автоматами". Ну, да. А как иначе? Правда, нужно пояснить как "комбинировать". Параллельно - это одно. Как-то по-другому (есть разные способы соединения автоматов) - другое. Т.е. это тоже надо пояснять - как комбинировать?
Есть такое для ПЛК это SimInTech: https://habr.com/ru/post/307090/
Для любознательных и настойчивых в поисках истины;)
Сегодня случайно наткнулся на видео по триггерам да и еще в рамках Матлаб. Поменял элементы memory на используемые там задержки и ... результат стал много ближе к желаемому.
Генерация триггера
Установка в единичное состояние
Установка в нулевое состояние
Тайминг видео:
4.49 "Переход в непредсказуемое состояние...". Все давно предсказуемо: переход произойдет в состояние, определяемое элементом, имеющим меньшую задержку.
5.37 "...безумно переключаться между запрещенными состояния выходов...". Ситуация, отражающая правильное поведение идеального триггера (триггер, имеющий элементы с равными задержками или транспортного типа).
А какой же тип задержек у модели? Изменяем величины задержек, делая их разными, и видим, что генерация по-прежнему происходит (см, 1-й рис. выше). А это характерно только для задержек траспортного типа. У реального же триггера задержки инерционные. Если в библиотеке Симулинк есть задержки инерционные (а я, надеюсь, что они есть), то тогда есть шанс привести к модель к виду, отражающему реальное поведение триггера.
А ведь можно моделировать поцесс и проектиррвать программу управления в одной среде, и на выходе пооучать код Си, готовый к загрузке в любой контролер:
Безусловно, можно. Но, например, у меня в ВКПа (на С++) среда используется и для моделирования и для реализации. И это очень удобно. Отмоделировал, отключил модель объекта, и сразу работаешь. При этом, если процессы быстрые, то в среде есть возможность их замедлить, чтобы удобнее было смотреть на результаты моделирования...
Я просмотрел статью по ссылке. Солидно. Чтобы разобраться предлагаю следующее. Вы делаете триггер, а я нагреватель воды. Сделаю даже на языке LD. Правда, модель объекта пока не буду делать - хлопотно. Для нагревателя, думаю, достаточно будет двух ФБ. Первый - нагреватель, второй - мигалка. В проекте последних будет два объекта - один для красной лампочки, второй - для зеленой. Попробую к вечеру набросать и выложить. Сделал бы и быстрее, но ... текучка навалилась.
По поводу преобразований в Си. Можно и так. Но, например, в моем случае нужно включать в код и ядро реализации автоматов. Если говорить о языке LD, то нужно особым образом кодировать автоматы и организовывать им среду исполнения. Ну, как описано в статьях и представлено в моих примерах. Можно, конечно, и по другому, но идея не должна пострадать при этом. Также будет и на Си. Но среда, которая будет это делать, о подобном будет ли "знать"? Это надо в нее вложить. Тогда можно будет доверять такому код. Я уверен, что в Вашу среду это не заложено и потому есть определенные сомнения и в правильности работы модели и соответственно в работе конечного кода (на Си, LD и т.д.).
Да, можете посмотреть статью. И в ней - на моделирование квадратичной функции и ПИД-регулятора. Особенно про адаптивный ПИД-регулятор. Там есть и модель объекта. И представлены проблемы, которые при этом могут возникнуть.
Нагреватель ксати есть готовый в SimInTech и даже с регулятором уровня можно взять отсюда: https://habr.com/ru/post/652157/
Дело в том, что мы автоматы реализуем на стандартных блоках. Основной блок для создания автомата, это условное выполенени модели. Если условие false субмодель не выполняется. Поскольку генерация кода для стандартных блоков отлажена проверина и перепроверена, то и полученный из ни автомат должен работать точно так же как и модель в SimInTech. (До этого было так) Но это не точно!
Модели для проекта Нагреватель
Автомат Нагреватель
Автомат Мигалка
За правильность пока не отвечаю. Делалось, как говорится, походя и в спешке ;) Далее нужно реализовать и тестить. И тогда будет понятно.
"минус" - это правильно ;) Но, замечу это были лишь эскизы моделей. Нагреватель оказался правильным, а вот Мигалку пришлось при реализации корректировать. Немного, но все же. Теперь она такая.
Мигалка
По поводу "симуляции". Отношусь к ней с осторожностью. Для ПЛК обычно симуляторы есть. Но предпочитаю работать на реальном ПЛК. Также и с объектами. Создание хорошего симулятора (ПЛК, объекта и т.п.) - это огромная, сложная и трудоемкая работа. И "уважуха" тому, кто это делает или сделал. Но, как правило, все это симулируется не очень надежно и не в полном объеме. Если есть возможность работать на реальном оборудовании, то лучше иметь какой-то для этого стенд.
https://habr.com/ru/post/307090/ Здесь и автомат и мигалка и генарция в код си в трех частях
Еще чуть-чуть и я начну разбираться в Вашем коде :) Чем-то он мне даже стал нравиться, но он, к сожалению, не про автоматы. Почему? Да потому, что в автоматах состояние - это неделимая единица. У Вас, если "ковырнуть" состояние, то в нем скрывается некая реализация неких переходов. Это совсем не соответствует теории автоматов. Я, поверьте, не критикую, я - констатирую. Ваша среда неплохая и реализует определенные идеи, но они к собственно автоматам имеет такое же отношение, как горсть земли к понятию Земля, как планета. Вроде, по названию одно, но по сути разные вещи.
Я не придираюсь к терминам, но нет понятия "автомат состояний" (см. ниже). И кажется я об этом уже говорил. Есть просто автомат. Он просто имеет состояния. Без состояний он не автомат. В лучшем случае - комбинационная функция.
В смысле состояний тот же МАТЛАБ честнее, т.к. там есть и состояния (как неделимые сущности), так и переходы, нагруженные условиями переходов и действиями на них. Но МАТЛАБ все портит, введя "вложенные состояния". И здесь Вы с ним пересекаетесь. Только у Вас, похоже, все состояния вложенные, а у МАТЛАБА лишь некоторые.
Соответственно и инерционная задержка (см. ниже) у Вас достаточно оригинальная (мне в ней разобраться пока сложно). У меня это обычный автомат, у Вас - пока что-то для меня не очень понятное. Есть какие-то "флаги переходов", есть "вектор активности состояний", есть чуть более понятные "номера состояний", но ... Сравните с моей моделью инерционной задержки. Там автомат. Там нет каких-то иных понятий - "вектора", "активности", "номеров" и т.п. Т.е. все строго в рамках теории конечного автомата. У Вас я просто автомата не вижу. Может это моя "близорукость", но, честное слово, ... не получается. Хотя, не скрою, я старался что-то рассмотреть ;)
Поэтому, как мне представляется, если бы в Вашу систему/среду/язык ввести настоящие автоматы, то это только бы многие вещи резко упростило. Да и код бы стал бы намного яснее и прозрачнее. Именно в терминах автоматов. А так я даже не вижу что-то похожее на автоматы МАТЛАБ-а (не имея в вижу его вложенные состояния, конечно). Есть своя реализация, которая может кому-то нравиться или нет, но это реализация, имеющая связь с автоматами только использованием одних и тех же слов, но с разным их смыслом.
Чем-то он мне даже стал нравиться, но он, к сожалению, не про автоматы. Почему? Да потому, что в автоматах состояние — это неделимая единица. У Вас, если "ковырнуть" состояние, то в нем скрывается некая реализация неких переходов.
Это же просто выбор угла зрения. В математике (а ТА — раздел математики) любой объект можно как рассматривать аксиоматически, считая неделимым — так и конструктивно, "собрав" из составных частей.
Пример ещё из алгебры: при изучении свойств полей элементы поля считаются неделимыми, у поля нет ни одной операции которая бы "разбирала" элемент поля на составляющие. Тем не менее, это ничуть не мешает образовывать поле рациональными числам, состоящим из числителя и знаменателя. Или комплексным числам с действительной и мнимой частями.
Также и с автоматами. Если у чего-то можно найти множество состояний, входной и выходной алфавиты и функцию перехода — это что-то можно рассматривать как автомат.
Я не придираюсь к терминам, но нет понятия "автомат состояний"
Извините, а где вы его там нашли? Беглый поиск выявил только "автомат состояния", что несёт вполне определённый смысл.
Поэтому, как мне представляется, если бы в Вашу систему/среду/язык ввести настоящие автоматы, то это только бы многие вещи резко упростило. Да и код бы стал бы намного яснее и прозрачнее.
Инструменты создаются для удобства использования, а не для внутренней красоты, осознайте это уже. Никому не интересен понятный код инструмента, нужно чтобы инструментом было удобнее пользоваться.
Все эти вложенные состояния появились не просто так, а потому что они нужны при решении реальных задач.
Вы еще больше утвердили мня в двух вещах:
1) лучше разбираться в чем-то одном, чем знать о многом
2) нельзя игнорировать даже на первый взгляд бредовые идеи (можно сказать и по-другому, но остановимся на этом - более мягком варианте :)
Итак. Оставим поля чистым математикам, а поговорим об автоматах.
Безусловно, инструменты создаются для удобства. Но, если они игнорируют теорию, то превращаются в обычные костыли.
Но все же об удобстве. В программировании очень удобны подпрограммы. И тут даже речь уже идет не об удобстве, а о необходимости. Без них оно (программирование) просто немыслимо. И "вложенные состояние" - следствие данной необходимости. Только оформлены они как "костыли". С точки зрения теории нужно было бы говорить о вложенных автоматах. И как это сделать, я описал в двух статьях. Мне удобно использовать все это и теория при этом не страдает. Т.е. удобно во всех местах, т.е. не нигде не трет :)
Но все же о вложенных состояниях. С точки зрения теории это должен быть "вложенный автомат" у некоторого состояния автомата Мура. Это чтобы и волки были целы и овцы сыты :) В моих упомянутых статьях говорится о вложенных автоматах для автоматов Мили. Но, если Вы не слышали, а знаете ТА, то переход от автоматов Мура к автоматам Мили просто элементарен и однозначен (обратно, если помните, нет). Так вот. Надо ли делать автоматы Мура с вложенными состояниями? Или, по-другому, могут ли у автоматов Мура быть вложенные автоматы? Можно ответить положительно и на тот и другой вопрос. И даже понятно, как это сделать. Но ... насколько это актуально? Мое мнение - не актуально. Ведь, есть автоматы Мили и если Вам по силам начала теории, то можно сделать "по щелчку" то, что Вы хотели бы сделать с подобных ситуациях с автоматами Мура. Главное в том, что требуется это очень и очень редко. Так зачем усложнять реализацию, которая явно скажется на эффективности работы?
По поводу "автомата состояния". В свете сказанного я смотрю на этот термин как на своеобразный "костыль". Может без него нельзя в SimInTech? Это решает разработчик. Я бы мог, кстати, что интересно, назвать несколько цепей, объединенных одним входным состоянием тоже автоматом состояния;) Но в данном случае (и не только в этом) это совсем лишнее (для SimInTech не берусь утверждать). Как мне кажется, данный термин притянут к реализации. Но, может, следовало бы придумать иной термин, чтобы не было путаницы с терминологией теории?
С точки зрения теории нужно было бы говорить о вложенных автоматах. И как это сделать, я описал в двух статьях.
"Вкладывать" один автомат в другой нужно тем способом, который удобен в использовании.
С точки зрения теории нужно было бы говорить о вложенных автоматах. И как это сделать, я описал в двух статьях. Мне удобно использовать все это и теория при этом не страдает. Т.е. удобно во всех местах, т.е. не нигде не трет :)
К сожалению, вы во всех своих статьях разбираете задачи, которые без автоматов делаются гораздо проще нежели через автоматы, вроде логических функций, задержек и вычисления факториала. То есть вы занимаетесь задачами с искусственными усложнениями, которые не имеют практического применения. Поэтому тот факт, что вам что-то удобно, совершенно не означает что удобно будет и практическому программисту.
Но, если Вы не слышали, а знаете ТА, то переход от автоматов Мура к автоматам Мили просто элементарен и однозначен (обратно, если помните, нет). Так вот. Надо ли делать автоматы Мура с вложенными состояниями?
Да, надо. Автомат Мура лучше ложится на такие концепции программирования как декомпозиция, а оттого зачастую (но не всегда) удобнее в использовании. К виду автомата Мили же его при необходимости всегда может привести компьютер.
Поэтому тот факт, что вам что-то удобно, совершенно не означает что удобно будет и практическому программисту.
Согласен. Не означает. Но только давайте учтем, что я все же "практический программист" и усложнять себе работу мне совсем не с руки: мне платят все же не за сложность, а за результат. Я заинтересован сделать быстро, качественно, надежно. Поэтому и автоматная модель, и способ и сам принцип вложенности, ориентация на автоматы Мили, параллелизм и т.д. и т.д. все сделано исключительно в этих целях - сделать мою практическую "программистскую жизнь" комфортной.
Понятно, что кому-то эта "жизнь" кажется сложной. Но это больше их проблема. Есть много и таких, которые идут, скажет так, в ту же сторону, но только, может, иным путем. Тот же "их" МАТЛАБ или "наш" SimInTech. Но мой взгляд они несколько "плутают", а их взгляд я, возможно что-то усложняю и слишком академичен. Время, думаю, расставит все по своим местам. Но я столько уже этим (автоматами) занимаюсь и все практически (!), но всегда с оглядкой на теорию, что меня с этого пути уже ни чем не свернуть. Я прекрасно вижу их проблемы и то, чем это закончится, т.к. это было пройдено и осмысленно неоднократно практически и теоретически. Мне просто есть с чем сравнивать. И ПЛК здесь скорее эпизод. Интересный, в чем-то поучительный (даже для меня), но ... эпизод. Основное сделано на С++...
Меня удивляет, что на нынешних ПЛК (при их стоимости-то) нет возможностей пусть даже не очень крутых ПК (это чтобы я программировал на С++:). Технически это сделать, думаю не сложно. По стоимости ПЛК + панель к нему, наверное, уже дороже, чем достаточно хороший ПК. И я думаю, что не так уж долго этого осталось ждать. Пока же приходится демонстрировать возможности автоматной технологии на языке LD :)
А задачи я решаю разные - от простых до самых сложных. Например, не такой уж сложный (но и не совсем уж и простой) мой проект на ПЛК у меня содержит порядка 40 параллельных автоматов (разных!). Проект на промышленном ПК (С++, Qt) был посложнее. При этом на С++ работалось гораздо легче и комфортнее. Но пока вот так ;)
Так что, еще раз, все что я делаю, то только с прицелом на практическое использование. Да, порой, приходится тратить много усилий на создание нужного автоматного окружения, но я уже на этом не заморачиваюсь. Все это проходилось не раз и не два. И я знаю, что рано или поздно все окупится. Даже не взирая на убогость возможностей языка и платформы. Ну, как здесь на ПЛК ;). Но теперь мне даже где-то нравится работать (пусть даже на LD). Просто я рисую автоматы (на уровне модели они мало отличаются от тех, что были на С++), а уж как их реализовать - дело почти десятое. Да, на С++, как ни удивительно, все гораздо проще, а на LD сложнее, но здесь главное технология, а не инструмент ее реализации. И это, замечу, вывод "практического программиста" :)
Меня удивляет, что на нынешних ПЛК (при их стоимости-то) нет возможностей пусть даже не очень крутых ПК (это чтобы я программировал на С++:).
Это как раз ни разу не удивительно. Если сделать поддержку С++ — это будет уже не ПЛК, а МК (микроконтроллер). И такие уже давным-давно существуют.
А что мешает этот микроконтроллер вставить в ПЛК и чтобы и на нем был С++.
Кстати, было дело - работал и на микроконтроллере. Какой-то там наш (Воронеж) аналог Atmel. И была там какая-то студия. Кажется AVR Studio (уже подзабыл). Я и там, конечно, организовал автоматы :) С++ был, правда, существенно урезанный. Но я все равно делал разработку на ПК, тестил, потом адаптировал под AVR, чтобы залить в железо. Помню даже, что получилось и даже неплохо :) Было жаль, когда проект прикрыли... А так были планы, чтобы развить дальше...
А вот на кой вам понадобились автоматы когда под рукой был С++?
Интересный вопрос! ;) А зачем мне они на LD? Просто потому, что в С++ их нет, как и в LD. Как и в LD в C++ нет параллелизма. Или совсем кратко - автоматы это другой уровень проектирования. Например, от Си после С++ меня просто воротит. Просто потому, что в нем нет объектов. Конечно, когда есть только Си, как LD в ПЛК, то я ими пользуюсь, но вынуждено. Но тогда хотя бы автоматы-то я могу сделать? Как в LD. Замечу, что при этом "автоматные объекты" это много круче (в смысле удобнее) для "практического программиста", чем без все это же, но без объектов. А так мы, как "практические программисты", конечно используем то, что есть, но добавляем при это то, что нам необходимо. Поэтому без объектов я еще как-то могу представить свою работу. Без автоматов - уже нет. Отсюда и выводы....
Э-э-э…
Во-первых, в С++ параллелизм есть, надо лишь найти подходящую библиотеку.
Во-вторых, в LD параллелизм присутствует по построению языка.
Что же до автоматных объектов — зря вы их сравниваете с отсутствием любых объектов, сравнивайте лучше с наличием нормальных.
Всего три предложения и все они вызывают возражения ;).
Во-первых, в С++ параллелизма точно нет. По той причине, что ни одна из известных мне его библиотек или последних нововведений в него не реализуют какую бы то ни было модель параллельных вычислений. Одновременность (типа многопоточности, многоядерности) это совсем не параллелизм. Но подробнее лучше посмотреть в моей статье.
Во-вторых, в LD параллелизма нет по определению. Уже в документации на язык подчеркивается, что его операторы исполняются слева направо и сверху вниз. Это исходная точка. Но мы "выкрутились", введя автоматы. Т.е., как ни странно, но какой ни есть параллелизм, но в LD мы ввели.
По поводу автоматных объектов, Вы, похоже, не так меня поняли. Если сравнивать автоматные объекты с обычными, то с внедрением автомата в объект мы только расширяем его возможности, наделяя поведением. Обычные объекты, как известно, поведением не обладают. Поэтому только те объекты, которые нужно или хотелось бы сделать активными, и есть смысл превращать в автоматные. И потом, автоматы и объекты сравнивать нельзя. Первые - это про поведение/алгоритм, вторые (в чистом виде) - структура. Они могут существовать независимо друг от друга. Но как только мы их "скрещиваем", то получаем качественный эффект во влиянии друг на друга.
Во-первых, в С++ параллелизма точно нет.
У вас какое-то своё определение параллелизма?
Во-вторых, в LD параллелизма нет по определению.
LD — это имитация релейных схем. В релейных схемах параллелизм есть, по определению.
Обычные объекты, как известно, поведением не обладают.
Чего?! Объект — это инкапсулированные состояние+поведение, и это всегда так было.
У вас какое-то своё определение параллелизма?
Вы крайне невнимательны. Я же выше привел ссылку на мою статью, которая даже так и называется "Модель параллельных вычислений"/ Наверное надо было добавить "Моя..."? :)
LD — это имитация релейных схем. В релейных схемах параллелизм есть, по определению.
Вы какой-то несговорчивый ;) В реальных - есть. В языке LD - нет. Мы, надеюсь, о языке говорим?
Чего?! Объект — это инкапсулированные состояние+поведение, и это всегда так было.
На "пальцах". ООП началось с того, что к давно известному понятию "структура" добавили методы. Но методы при этом определяют в лучшем случае отдельные действия объекта, но не целостный алгоритм поведения объекта. У объекта нет средств, которые бы задавали последовательность работы его методов. Насколько помню, кажется, Г.Буч в своей книге эту тему (поведение объектов) осветил достаточно подробно (сейчас, к сожалению, нет под рукой, чтобы посмотреть).
Так вот. Когда мы внедряем автомат в объект, то последний использует его методы и тем самым определяет его поведение (своей таблицей переходов/выходов), как последовательность работы его методов.
а вот илюстрация как в автоматах состояния реализуется инерционная задержка как раз блок задержки на шак интегировани при моделирования или задержка на такт в контроллере
Да, а "клип" Водонагреватель мне даже понравился. Реализация "автоматов" чуть подкачала, но это я уже придираюсь ;).
Технология автоматного программирования для ПЛК на языке LD