В предыдущих статьях мы фрагментарно описали практику автоматного программирования для ПЛК. Здесь мы сведем все в одном месте и кое-что добавим. Ответы на вопросы, которые все же могут возникнуть после прочтения данного материала, можно найти в ранее написанных статьях автора. Перечень базовых статей следующий:
Задание на проектирование программы
В предшествующей статье мы уже рассматривали штабелер. Здесь будет более сложный его вариант. Это узкое «крыло», которое, находясь в исходном состоянии, с паузой после старта проката подхватывает лист металла и поддерживает его в процессе движения. После останова проката и отсечения листа оно выполняет «отскок» вперед, освобождая конец листа, который падает на приемное устройство - гидростол. После этого "крыло" возвращается в исходное состояние. Во время этих движений прокат должен быть остановлен. После исполнения задания (формирования нужного числа листов заданной длины) «крыло» перемещается в заключительную позицию за пределы гидростола. Возврат в исходное состояние происходит после нажатия кнопки «Штабелер». Выполнение самого задания начинается с нажатия кнопки «Прокат», а длина отдельного листа и общее их количество указывается на панели оператора.
После нажатия кнопки «Сброс» (прокат останавливается, переходя в режим паузы) штабелер должен войти в режим паузы. Повторное нажатие кнопки выполняет реальный сброс системы управления. Продолжить прокат, находясь в ситуации паузы, можно с помощью кнопки «Прокат». Штабелер, находясь в режиме «Автомат», может входить в тот же режим паузы, но после формирования текущего листа. Работа штабелера в режиме системы «Полуавтомат» несколько отличается от работы в режиме «Автомат». В первом случае он останавливается после выполнения проката и ожидает срабатывания гильотины (в режиме «Полуавтомат» она запускается вручную). Дождавшись, он сбрасывает лист и перемещается в заключительную позицию. Из нее нажатием кнопки Штабелер «крыло» возвращается в исходное состояние. В режиме «Автомат» перемещение в заключительную позицию происходит только после выполнения задания.
Алгоритм управления штабелером в форме двух взаимодействующих конечных автоматов (КА) представлен на рис. 1. Более простой автомат представляет алгоритм работы с датчиками, другой - алгоритм управления штабелером. Реакцию на сигнал паузы, на кнопку «Штабелер», а также на сигнал запуска реализуется обычными средствами языка LD и вынесено за рамки нашего обсуждения.
Процесс создания модели программы
Программирование начинается с модели программы. В нашем случае это будет модель в форме конечного автомата. Ее (модель) можно «держать в голове», рисовать на листе бумаги, но настоятельный совет – используйте графический редактор. У нас это редактор Microsoft Office Visio. Он обладает всем, что помогает нарисовать граф, подобный графу автомата на рис. 1. Причем, чем сложнее автомат, тем больше выгоды будет от его применения. Далее, например, путем обычного копирования элементов имеющегося графа можно создавать графы уже любой сложности.
В нашем случае от графического редактора нужно не так уж много. Рисовать, во-первых, состояния в форме кружков с пометками внутри – именами состояний (у нас это будут только номера). Во-вторых, соединять состояния направленными дугами и помечать их условиями переходов и выдаваемых сигналов. Кроме этого, Visio позволяет легко изменять вид графа, перемещая вершины, что ведет к автоматическим изменениям соединяющих их дуг.
Вершинам графа можно поставить в соответствие то или иное действие, ассоциировать с ним некую предысторию работы алгоритма и т.д. и т.п. Например (см. рис.1), вершина 0 – это начальное состояние алгоритма. Вершина с номером 33 – состояние ошибки. В состоянии 1 выдаются сигналы управления движением крыла. В состоянии 4 – лист сброшен и выполняется «отскок», при котором крыло попадает в состояние 2. Из него модель может продолжить работу или, выполнив задание, перейти в состояние 44 и т.д. и т.п.
Фактически каждое состояние алгоритма имеет тот или ной смысл, а потому, наблюдая за ними (а мы такую уникальную возможность имеем!), можно понять, что происходит с алгоритмом в любой момент времени. Возможность наблюдения за состояниями превращает тестируемый алгоритм из «черного ящика» в «белый ящик».
Автоматная модель позволяет объективно оценить сложность будущей программы. Она зависит от числа состояний автомата, количества входных/выходных каналов, связности графа, т.е. множества и разнообразия переходов, и сложности предикатов и действий. Предикаты и действия в случае ПЛК достаточно просты. Обычно это: прочитать вход ПЛК в случае предиката и/или установить выходной сигнал в случае действия. А вот логика алгоритма, особенно при взаимодействии с другими функциональными блоками, способна доставить массу хлопот.
Так что программирование для ПЛК не столь уж простое, как это может показаться на первый взгляд.
Процесс кодирования
Создав модель, мы переходим к ее реализации. Перейдя в дерево проекта, в папке функциональных блоков (ФБ), создаем заготовку - функциональный блок. Он должна иметь элементы, соответствующие конструкции автомата на языке LD. Как минимум, это два входа и один выход. Входные каналы – это канал сигнала сброса и канал с присвоенным автомату элементом массива текущих состояний автомата. Выходной канал – элемент массива теневых состояний с индексом равным индексу текущих состояний.
Код вызова ФБ для штабелера представлен на рис. 2. Данный функциональный блок имеет описанные выше каналы. Остальные каналы задаются локальными переменными соответствующего типа. Так, переменные типа VAR_INPUT создают входные каналы, VAR_OUTPUT – выходные, VAR_IN_OUT – совмещенные входные/выходные каналы, а тип VAR – это обычные локальные переменные.
Рис.3 дает полное представление о локальных переменных. Переменные с именами bClear, inState, outState соответствуют упомянутым выше каналам. На рис. 4 приведен код инициализации ФБ и код работы с таймерами. Инициализация при включении ПЛК и/или получении сигнала сброса устанавливает автомат в начальное состояние.
Создав заготовку, можно приступить к кодированию автомата. Код каждого перехода автомата имеет единый вид: сначала идет проверка текущего состояния автомата и входных условий, затем, если это необходимо (для автоматов Мили), - выполнение действий и в завершение изменение текущего состояния. Если текущее состояние не изменяется, то последнюю операцию можно опустить. Образец кодирования переходов, исходящих из начального состояния 0 (см. рис.1) дан на рис. 5.
Реверс-инжиниринг
Не секрет, что программисты не любят документировать программы. От этого часто страдают они же сами, т.к. часто спустя уже какое-то время даже сам автор программы с трудом может разобраться в своем творении. Но, даже понимая это, рисование блок-схем, графов, детальное описание алгоритма и т.п. – это не про программистов. Достаточно кратко, весьма ярко и доходчиво процесс документирования программ описан в статье [1]. Полемизируя с ней, можно утверждать, что в рамках технологии автоматного программирования программы все же обладают свойством самодокументирования и это совсем не чушь.
Безусловно, разобраться с алгоритмом программы по ее коду весьма проблематично. На рис. 6 приведен код программы, созданный для модели на рис.1, в режиме просмотра для последующей распечатки. Это восемь убористо заполненных листов на языке LD. Сравните его с графом автомата. Что из них нагляднее и понятнее, думаю, вопрос риторический.
Но, с другой стороны, зная принцип кодирования автоматной программы, вы можете по коду программы легко восстановить граф автомата. Так, во-первых, сразу ясно, сколько состояний имеет программа. Во-вторых, легко восстановить переходы между состояниями, т.к. каждой цепи соответствует, как правило, ровно один переход, а действия программы привязаны или к состояниям программы, или представлены на соответствующих переходах. Останется только добавить смысловую интерпретацию условий и действий, в чем может помочь уже комментарий. Конечно, если их нет (совсем уж, видимо, «гениальный» программист создавал программу или комментарии просто не доступны), то придется все интерпретировать самому.
Тестирование программы
Тестирование, наверное, самый важный этап во всем процессе разработки программы. Программа, работающая с ошибками, ни кому не нужна, будь она трижды автоматной или какой-то там еще. Но автоматы и здесь предоставляют возможность, которой нет у программ, спроектированных обычным способом. Только автоматная программа позволяет автоматически отслеживать текущее состояние программы. А это может сказать о многом, т.к. отражает поведение программы в динамике.
Конечно, в программу можно ввести флаги, отражающие ее поведение. Но, во-первых, флаги нужно придумать, правильно расставить и предусмотреть код для их установки и сброса. Т.е. то, что на уровне автомата формируется естественным образом, в случае использования флагов требует определенных усилий и сосредоточенности. В конце концов, использование флагов просто ненадежно, за что их не критиковал разве что только ленивый.
Но у ПЛК есть одна неприятная особенность – отсутствие пошаговой отладки. Присуще ли это только ПЛК фирмы DELTA или и другим – не знаю, но в данном случае, как говорится, что есть, то есть. Для программистов, привыкших к возможностям современных отладчиков, это будет, скорее всего, если не шоком, то определенной «новостью» (как это было для автора). Но и здесь состояния автомата более чем кстати.
Рис. 7 демонстрирует процесс отладки. Из него следует: штабелер находится в состоянии 1 и идет процесс проката, т.к. флаг проката bЕслиПрокат = true. «Крыло» находится в движении, о чем говорят установленные сигналы управления двигателем – Y20 и Y22. При этом оно явно сошло с исходной позиции, т.к. awState[47] = 2 (см. автомат датчиков на рис.1). Режим работы выбран автоматический – bM10M11 = true, т.е. это режим «Полуавтомат» или «Автомат». Нам остается только крутить энкодер и отслеживать состояние проката на панели оператора, где отображается текущая длина листа в поле «Исполнено» (см. рис.8).
Заключение
Существует просто огромный пласт информации, обсуждающий этапы проектирования программ (см., например, [2]). Но среди этой информации мало такой, которая бы за базу брала модель программы. А от нее зависит многое, если не все. В основе технологии автоматного программирования лежит сетевая конечно-автоматная алгоритмическая модель. Это позволяет охватить и параллельные процессы, без которых современное проектирование просто немыслимо. И если обычное программирование только-только осваивает параллелизм, то в ПЛК в той или иной мере его используют давно. Здесь он может быть представлен модулями POU, которые содержать разнообразные функциональные блоки, работающие параллельно.
Но параллельно работающие ФБ, взаимодействуя друг с другом, порождают достаточно сложные процессы, поведение которых необходимо анализировать. Анализ этого - весьма сложная и трудоемкая задача. Для модели штабелера это еще выполнимо и сводится к построению для сети из двух автоматов эквивалентного однокомпонентного автомата. Это будет автомат, имеющий 27 состояний. Уже одно их количество (а, ведь, нужно еще найти все переходы между состояниями) способно подавить любое желание строить подобные планы.
Поэтому дальнейший анализ на уровне параллельных процессов, как правило, делается на основании интуитивных предположений. Например, если нет сомнений в правильности созданных автоматов, то не так уж много причин беспокоиться и по поводу их совместной работы. Хотя в этом случае только полноценное тестирование способно рассеять все сомнения на этот счет.
И все же основной вывод, к которому пришел лично я, как программист, уже довольно давно: только следование технологии - необходимая основа качественного программирования. Нынешнее программирование, если и является, как принято считать, искусством, то искусством кустарным. Все в нем сделано как-то - "на коленке". Чтобы искусство превратилось в мастерство, нужна технология, опирающаяся на теорию. Я выбрал и выбираю автоматную технологию, которую описал в своих статьях.
Если бы была технология, которой бы я доверял больше, чем своим автоматам, то я бы использовал ее. И, казалось бы, есть из чего выбирать. Тот же UML или Simulink, на память приходят автоматы в Qt, SWITCH- технология, в конце концов, и т.д. и т.п. Но на поверку оказывается, что это или вовсе не автоматы, а только их названия, или весьма ограниченные версии автоматов. Поэтому я выбираю те автоматы, где ... правильно работает модель RS-триггера. Почему он? Потому что объективные доказательства правильности его работы доказывают корректность параллельных свойств среды исполнения параллельных процессов. Ведь, все так просто!
Ну, вы понимаете о чем я... Лично у меня-то выбора уже нет, а у вас ... на одну испытанную технологию больше. Везет же! Но только кому?...
Литература.
Комментарии (20)
kozlyuk
29.09.2022 11:43Насколько я знаю, логика LD имитирует физические релейно-контактные схемы, и сделан LD специально для тех
динозавров, кому удобно решать задачу в терминах этих схем. В вашей задаче LD полностью определяется автоматом. Почему бы тогда не генерировать весь LD из описания автомата? Минус ошибки кодирования, минус синхронизация графа и LD при изменениях графа. Описание автомата потребуется сделать машиночитаемым, например, текстовым на основе dot. Плюс удобный просмотр изменений в версиях, плюс возможность анализировать автомат программно, например, верифицировать на невозможность запрещенных состояний (как BPF). Идея на поверхности, нет ли такого уже для ПЛК? В отличие от попыток генерировать код из UML для прикадных программ, здесь схема четко задает всю логику.
lws0954 Автор
29.09.2022 12:03Вы все правильно пишете. Все в идеале именно так. И те, кто делает подобное, делают это именно так. Или пытаются сделать именно так. Но здесь много нюансов. Этим надо заниматься и заниматься серьезно, иметь под это средства. Ну, а чтобы иметь возможность реально работать "здесь и сейчас", то проще все эти "минусы" взять на себя. В данном случае это совсем не сложно. И, главное, что помогает и помогает серьезно в работе. Я же работаю именно так и ни кто меня не заставляет работать именно так.
Есть ли что-то подобное для ПЛК? Не знаю. Но, скорее всего, нет. Это, если речь о подобном. Такого же, как предлагается, нет точно. Иначе бы я знал. Скрыть это сложно ;)
Indemsys
29.09.2022 12:32+1На хабре есть масса статей где люди так и делают. Например эта
lws0954 Автор
29.09.2022 16:40Собственно и я об этом. Есть примеры, ну, очень хорошо проработанных идей. Я к ним отношу UML (все-таки в ней есть что-то похожее на автоматы). Но это почти чистая идея. Она, как идея, где-то была взята в качестве основы для конкретной практической наработки. Тот же StateFlow. И, казалось бы, что еще надо для счастья? И кому-то это "счастье" подходит. Как это и произошло в случае упомянутой статьи. Но это "счастье", поверьте, не будет долгим.
Мне StateFlow не подходит. Совсем. И не по причине большой привередливости. А потому, что эта модель не обеспечивает нужное качество проектирования. Это главное. Я бы на все остальное закрыл глаза, но ... RS, блин его, триггер в StateFlow не работает. Хоть ты ... тресни. Проверено. Лично.
И зачем мне тогда вся остальная "красота" StateFlow? О ней, кстати, тоже есть что сказать. Но зачем? Если все ясно - не работает и точка. Но пример МАТЛАБ-а очень хороший. Как показатель куда надо стремиться. Но, честное слово, ожидаючи какого-то идеала, можно и жизнь "просвистеть".
Если бы можно было в StateFlow внедрить модель, которую нужно мне, то ... Но, во-первых, это невозможно, а, во-вторых, зачем? Чтобы увязнуть? Есть, ведь, оказываются, очень простые приемы, которые позволяют организовать работу не хуже, а лучше (!), чем в StateFlow. (В смысле качества работы, а не "картинок", конечно. Тут только можно позавидовать) И даже на языке LD и на ПЛК. На Qt и C++, конечно, было веселее, но... как говорится, "жизнь диктует свои законы". Пусть немного ручками (не как в MATLAB-е, не как в моей родной ВКПа на С++), но зато надежно и предсказуемо. А это в реальной работе стоит больше и ценится выше, чем любая "красота" и "картинки". Но это мое личное мнение. И мой личный немалый опыт. В том числе и на крайнем моем поприще - ПЛК. Для меня это именно так и есть.
Indemsys
29.09.2022 17:09Качество работы и проектирования - понятия весьма расплывчатые. Особенно расплывчатые, когда никто собственно это не может проверить.
Лучше говорить о фактах доступных всем.
В Simulink самые продвинутые средства рефакторинга гибридных диаграмм и средства отладки диаграмм.
Хотя да, в средах проектирования под ПЛК можно встретить более предметно ориентированные библиотеки. Но они будут черными ящиками. и отлаживать такие программы можно только с реальным железом.
Симулинк позволяет дольше оставаться в виртуальном окружении, т.е. реже вставать со стула. Ни это ли предвестник счастья?lws0954 Автор
29.09.2022 19:58Качество работы и проектирования - понятия весьма расплывчатые. Особенно расплывчатые, когда никто собственно это не может проверить.
И тут Вы глубоко ошибаетесь. Все проверяется. И это одна из тем моих статей - тестирование на параллелизм. И здесь одна из возможных проверок - тест на RS-триггер. Берете и проверяете. Как любой тест, он имеет для этого все необходимое: однозначную модель, известные результаты. Запускайте тест, фиксируйте результаты, делайте выводы.
Симулинк позволяет дольше оставаться в виртуальном окружении, т.е. реже вставать со стула. Ни это ли предвестник счастья?
Абсолютно нет возражений. Более того, я в какой-то степени даже пострадавший от такого "счастья". Дело в том, что мой предшественник (по словам моих начальников) не сидел на стуле, а постоянно что-то делал в цеху. Я "сломал", похоже, их представление о программировании, т.к. очень редко выходил в цех. Но, во-первых, мне нужно было время на освоение, а, во-вторых, разбираясь, я создавал технологию и собирал все, что выше на фото моего рабочего места - стенд для проектирования. Так, огрызаясь, я организовал нужное мне "счастье" и где-то 90% (а, может, и больше) я теперь делаю за столом. В цех выхожу, когда все отладил на стенде. Сейчас все работает и ситуация, вроде, устаканилась.
Так что справедливо выражение, что "каждый кузнец своего счастья" :) Но если бы не автоматная технология (на что я тоже, кстати, потратил уйму времени "за столом и стулом"), то, уверен, "счастья" было бы много-много меньше. По крайней мере, если говорить обо мне. Цель была поставлена, цель была достигнута. Лично я "счастлив". В рамках работы с ПЛК, конечно. И один из результатов такого "счастья" - цикл статей про автоматы на ПЛК ;).
Безусловно, счастья было бы больше, если бы работа походила на работу в Симулинк. Но почему-то мне кажется, что на ближайшую перспективу (да даже на отдаленную) мне такого счастья не дождаться. Я, если честно, уже счастлив тому, что удалось сделать.
Вот только ходят слухи, что, может, придется уходить с Дельты (ситуация, понимашь). Но это уже не будет горе. Будет, конечно, беда, но, думаю, не очень уж большая. Переживали всякое, переживем и это. Надеюсь ;)
Indemsys
29.09.2022 22:32RS триггер в симулинке рисуется очень просто.
Вот рабочая модель с верификацией
Если какая-то программа вам подсовывает RS триггер без элемента задержки Memory, то значит вы получаете действительно кота в мешке. Упрощенная схема RS триггера как ее обычно рисуют
физически не реализуема и нарушает принцип причинности. А симулинк как раз вам такой принцип нарушить не даст.
Ну и кто тут самый надежный?lws0954 Автор
30.09.2022 09:39Вот такой подход мне нравится... :) Когда все конкретно. Теперь только нужно будет довести обсуждение до логического конца и разобраться. Может, действительно, я и ошибаюсь. Конечно это "перевернет" мои представления. И о реальных процессах и о программных. Не хотелось бы, но ... я готов ;)
Итак, начнем с Вашей фразы
физически не реализуема и нарушает принцип причинности.
здесь я не понял. Все же это обычная схема на дискретных логических элементах ИЛИ-НЕ (часто называют - НЕ-ИЛИ, NOR и т.п., но мне как-то ближе ИЛИ-НЕ). Собирал лично ручками. Правда были И-НЕ, но собирал таки. Физически :) Поэтому уточните. И что это за "принцип причинности"?
Выше схема в симулинке. Можно ее чуть изменить? Соединить установочные входы триггера и подать в эту точку входной сигнал. От одного из нарисованных там же генераторов. И привести картинку сигналов. Только чтобы на ней отображались и входной и выходной сигналы.
Indemsys
30.09.2022 12:18Принцип причинности в том что причина не может существовать одновременно или после следствия.
Когда вы в симуляторе рисуете упрощённо RS триггер, то симулятор (если он правильный) должен это расценить как факт одновременной подачи и входного сигнала, и сформированного на его основе, выходного.
Так симулятор делать не должен позволять, поскольку физически не реализуемо.Когда же вы паяете микросхемы, вы всегда имеет элемент задержки (все микросхемы имеют задержку, хоть и пикосекунды) и эта задержка ещё будет разная между разными гейтами.
Вот тогда вы должны в симуляторе честно рисовать эту задержку.
А если симулятор не требует её рисовать и все же выполняет симуляцию RS триггера, то значит он эту задержку принял по умолчанию без вас, и какая она вы не знает. Это будет, что называется, кот в мешке.Посему, если хотите от меня адекватную модель RS триггера, то укажите все реальные его тайминги.
Вообще проблема автоматного программирование в отсутствии учёта таймингов и параллелизма в реальном времени.
Поэтому симуляторы ПЛК спокойно могут игнорить причинность, вводить задержки размером в доли базового такта и быть спокойными, что программа все равно выполняется корректно.lws0954 Автор
30.09.2022 14:07Прежде всего спасибо за ответ. На этом этапе, когда переходим к конкретике, все обычно "сливаются". Вы пока держитесь :) Спасибо. Но перейдем к делу.
Все же мне хотелось бы увидеть картинку для схемы, но с теми изменениями, которые я просил. Ну, ведь, это согласитесь не сложно. Надеюсь, что увижу.
Теперь далее. Когда я "паяю" я имею прежде всего логический элемент (ЛЭ), имеющий три контакта - два входа и один выход. Я знаю еще, что это элемент И-НЕ или ИЛИ-НЕ. Больше я о нем ни чего не знаю. Ну, вот такой - не очень любопытный до характеристик ЛЭ. Короче программист, но ... умеющий паять. Далее я беру еще один такой же элемент и проводочки. Все это соединяю по схеме "как обычно" триггера (Вы ее привели). Дальше соединяю входы, подключаю к точке генератор прямоугольный импульсов, к выходам триггера подключаю двухлучевой осциллограф и .... что я вижу? Вы скажете - да почти ни чего. Что в симуляторе, что на макете. Но, ведь, уже есть, что сравнивать.
Если симулятор хороший, то он должен и симулировать хорошо, т.е. в идеале картинки в симуляторе и на осциллографе должны быть одними. Если нет - пытаемся понять причину. Во внутрь ЛЭ мы не влезем (может только их, например, поменять местами, заменить на другую серию и т.п.). А с симулятором можно творить, что угодно, добиваясь, в конце концов, максимального приближения к реальности. И, если этого добьемся, то, похоже, мы что-то уже поняли в этом деле. Так что, еще раз, хотелось бы увидеть "картинку" с симулятора (извините за настойчивость, но у меня, к сожалению, МАТЛАБ-а нет).
Далее.
Посему, если хотите от меня адекватную модель RS триггера, то укажите все реальные его тайминги.
Поскольку я "тупой програмист", то в этих "таймингах" не секу, но у меня есть логический блок с функцией ИЛИ-НЕ (так писать привычнее). У него два входа и один выход. Я их тупо соединяю и что я должен видеть? А я должен видеть работу RS-триггера. Я должен быть уверен, что это и есть триггер. И если у меня такая уверенность есть, то я схему не паяю. Если нет, то тогда что ж - засучивай рукава, брат-программист ;) ...
Так что кот не кот, но я использую то, что у меня под руками - доступные элементы. Пусть это некая библиотека. Да тот же симулинк, если конкретизировать. Собственно Вы так и поступили "собрав" схему в симулинке. Только зачем-то (с позиции тупого программиста) добавили третий элемент - memory (на макетной плате ее, замечу, нет!). Но пока на это не будем обращать внимание. Надо так надо. Опять же - хочу картинку ;)
Вот тогда вы должны в симуляторе честно рисовать эту задержку.
Если Вы помните я "тупой программист". А потому - с какой стати?
А если симулятор не требует её рисовать и все же выполняет симуляцию RS триггера, то значит он эту задержку принял по умолчанию без вас, и какая она вы не знает. Это будет, что называется, кот в мешке.
А вот это по-честному. Но, во-первых, меня "тупого программиста" это и не интересует. А, во-вторых, даже если я и "тупой", но, Вы удивитесь, - знаю :)
Вообще проблема автоматного программирование в отсутствии учёта таймингов и параллелизма в реальном времени.
Вот тут даже не спорю - утверждаю. Именно это и есть. Вокруг этого и "ломаются копья". Я утверждаю, доказываю, что - есть! Это нет у обычного программирования. А у автоматного есть и еще раз есть. Могу повторить еще раз :) Но я все не "трындычиха", которая просто трындит, а все это, как раз, и описал в своих статьях. Что, как и за счет чего.
Поэтому симуляторы ПЛК спокойно могут игнорить причинность, вводить задержки размером в доли базового такта и быть спокойными, что программа все равно выполняется корректно.
Есть разница между "верить" и "знать". И тут, прошу прощения, Вы больше верите, а я больше знаю. Программа RS-триггера в реальном (не симуляторе) ПЛК, созданная по классическим принципам обыxного программирования, не работает корректно. Она вообще, кроме как отражая устойчивые состояний, не работает как триггер (который, если помним, собран на макетной плате из реальных элементов). Так что это реалии обычного программирования на ПЛК. А созданный по автоматной технологии - работает. Вот в это и есть качественное отличие автоматного программирования от обычного. Даже на ПЛК.
Ну, что это я опять скатился на похвалы АП... Не обращайте внимания ;) А "картинку" я все же жду. Для той схемы триггера, что создали именно Вы. Про "реальные тайминги" я в силу своей тупости пока не ведаю. Давайте анализировать то, что есть. То, что, как Вы утверждаете, в ПЛК "все равно выполняется корректно". Вот давайте и посмотрим насколько корректно...
Indemsys
30.09.2022 18:00Я теряю нить нашего спора.
Так вы согласны или нет что идеальный RS триггер невозможен?Ну и как я сделаю симуляцию реального RS триггера на микросхемах если вы не даёте его детализации.
Я полагаю вы имеете симулинк и в курсе что он на идеальный триггер ругается по поводу алгебраической петли.
Мой элемент задержки memory вставлен только чтобы избежать петли. Чтобы модель была по настоящему адекватной нужны тайминги!
То что вы называете подходом "тупой программист" не избавляет от необходимости знания таймингов. Возможно вы думаете что они пренебрежимо малы. Но симулинк так может не думать, особенно на variable-step моделях. Он может взбрыкнуть и пожаловаться на несходимость.
Так что сразу определитесь будет ли у вас модель с variable-step или с fixed-step, а также какой из 11 сольверов (решателей) вы выбираете.Я симулинк рассматриваю как эталон симулятора. Если в нем что-то не идёт, значит неправильная идея или модель.
Вы попробуйте подать на триггер на микросхемах частоту побольше, там пару сотен мегагерц и поглядите. Там чудеса начнутся.
lws0954 Автор
01.10.2022 15:11Так вы согласны или нет что идеальный RS триггер невозможен?
Тут надо бы разобраться, что такое идеальный триггер. Тот, который Вы нарисовали и без элемента памяти - безусловно невозможен. Но в рамках АП на автоматных моделях логических элементов (ЛЭ) он реализуется. И без элементов памяти. Просто потому, что модели элементов отражают свойства реальных ЛЭ.
Теперь ближе к теме. К счастью МАТЛАБ я не удалил и даже нашел проект, который соответствует Вашему (ну немного его подправил). Вот эта схема.
Рис. 1. RS-триггер с одним элементом memory
Вот триггер с двумя элементами памяти:
Рис.2. Триггер с двумя memory
И чем объяснить разницу в результатах их работы? Добавили-то всего ничего, а что получили достаточно заметную разницу в результатах? И, заметим, с точки зрения среды обе эти схемы корректны. Как "тупому программисту" понять какая правильно работает?
А вот проект уже мой, который включает автоматные модели ЛЭ.
Рис. 3. RS-триггер на автоматных ЛЭ
Правда в нем задействованы элементы И-НЕ, но это не принципиально. Если сравнить результаты работы на рис.2, то они идентичны. Так что замена библиотечных идеальных ЛЭ на разработанные мною автоматные ни чего не изменила. Явно дело в чем-то другом? В чем?
Вспомним, что в реальной схеме нет элементов памяти, а только реальные логические элементы. А проблема в том, что вычислительная модель, используемая в матлаб, не отражает каких-то свойств реальных объектов. В раках автоматной технологии (см. реализацию RS-триггера на языке LD) также элементы памяти не используются. Видимо, вычислительная модель АП уже учитывает определенные свойства реальных процессов. Какие свойства? Не буду делать тайны. Одно свойство. Инерционность реальных объектов. И только лишь.
Indemsys
01.10.2022 16:54Диаграммы Steteflow работают по тактам.
Перейдя на диаграммы Stateflow вы просто ввели задержки величиной в такт. Переход из состояния в состояние требуют один такт. Настоящий RS триггер так не работает.
Что тут сказать. У вас просто неадекватная модель.
Адекватная модель я думаю была бы в variable-step c правильными задержками.Ну подумайте логически. Если идеальный RS триггер невозможен, то что вы симулируете тогда?
Вы симулируете видимо физические логические гейты. Но тогда модель должны быть аналоговой и гораздо более сложной.Если же вы симулируете логическую функцию RS, то вы нарушает её ограничения, она не допускает на входе запрещённых состояний. Это все равно что симулировать деление на ноль или как брать корень из -1.
По идее модель функции на такое запрещённое воздействие должна выругаться и прекратить выполнение, как прекращают выполнение программы при делении на ноль.
lws0954 Автор
01.10.2022 18:27Логически - так логически...
По идее модель функции на такое запрещённое воздействие должна выругаться и прекратить выполнение, как прекращают выполнение программы при делении на ноль.
Это по идее. А как на эту идею ("запрещенное" воздействие) отреагирует реальный RS- триггер? Поясню чуть подробнее. Что будет на выходах триггера (на элементах, видимо, ИЛИ-НЕ), когда на входах будут две единицы?
lws0954 Автор
01.10.2022 19:02И еще. Прочитайте мою статью. В ней обратите на замечание 2. И хорошо бы почитать книгу Фрике К. Вводный курс цифровой электроники. 2-е исправленное издание. – М.: Техносфера, 2004. – 432с. А в ней в главе 7 (Асинхронные триггеры) раздел 7.4. (Анализ с учетом задержки вентилей). Просто в ней другой подход, чем у меня. Может, он Вам будет ближе.
Indemsys
01.10.2022 23:03Правильную книгу выбрали.
Но в ней к сожалению нет категорического запрета не пытаться симулировать идеальный RS триггер. А симулинк в такой запрет ясно тыкает носом. И в этом его сила. Т.е. он сильней даже этой сильной книги.
А симуляция реальных CMOS микросхем не думаю что для нас обоих представляет интерес.
Словом с этим триггером полагаю вы забрели не в ту степь пытаясь как-то связать его с преимуществами графической нотацией и автоматами Мура (которые применяются в ПЛК).И еще раз напомню мою позицию - сила в гибридной графической нотации, а не в некоем "автоматном программировании".
IDDQDesnik
Два раза переключить язык в одном слове?
Кислотные цвета и поиграться со шрифтами?
Astronom71
Поддерживаю, оператор после 8 часов смотрения на панель с такой раскраской, вспомнит о вас...
Astronom71
Ссылка на статью о дизайне HMI
https://realpars.com/high-performance-hmi/