Вид для печати
Добрый вечер.
Практически во всех текстовых языках программирования есть замечательный оператор case. Этот оператор незаменим при построении конечных автоматов.
Конечный автомат — абстрактный автомат, число возможных внутренних состояний которого конечно.
У кого есть какие мысли по реализации конечного автомата на ПР200 ?
А зачем пошаговое выполнение для конечного автомата ,если для отладки ,то в симуляторе есть .Чем 1 цикл ПР не шаг ?
Я поправил название темы. Вопрос прежний: как построить конечный автомат на ПР200 ? Был бы текстовый язык в ПР200 не было бы проблемы.Цитата:
Сообщение от rovki
Используйте для ветвления SEL .
Вообще все уже давно придумано). Есть статья http://media.wix.com/ugd/1d208a_bf15...3477246f4d.pdf Альтермана Игоря "Формальные методы программирования логических контроллеров". В принципе метод можно использовать для контроллеров в которых есть LD и FBD.
Это не серьезно.Цитата:
Сообщение от rovki
А двоичный дешифратор байта(ов) , чем не Case?
Это ближе к телу. ;)Цитата:
Сообщение от ferret_maybe
Задача немного абстрактная ..Стиралка -автомат в принципе конечный автомат ,команда аппарат которого делали с использованием макроса ППЗУ ..
Это как ? Может поясните.Цитата:
Сообщение от SA104
Тогда спрошу так: как в ОЛ реализовать оператор case ?Цитата:
Сообщение от rovki
Используйте 1 макрос ППЗУ на 16 условий(ветвлений) .На входе 0-15 ,на выходе 0-65532, задаются в свойствах макроса.
Дайте, пожалуйста, ссылку на этот макрос. Посмотрю что это такое.Цитата:
Сообщение от rovki
Вот мой вариант на 257 шагов и 32 выхода! Всегда можно подкорректировать под свои нужды!Цитата:
Сообщение от IVM
вот . их можно наращивать (вход В)Цитата:
Сообщение от IVM
Это микропрограммный автомат. Составление и отладка микропрограммы довольно трудоемкая задача.Цитата:
Сообщение от Сергей0308
Везде нелегко, но это же одноразовое действие! Так можно упростить, на каждом шаге выбираешь состояние выходов, это проще будет, но тогда получится EEPROM, типа того:Цитата:
Сообщение от IVM
Если скрестить два этих макроса и немного доделать!
Вот ещё макрос, который можно использовать как 32 ячейки памяти:
Я такой конструкцией пользуюсь.Цитата:
Сообщение от IVM
На входе переменная,
при выполнении условия активирован один из выходов.
Константы для примера показаны. Можно вместо них другие условия применить (результат вычисления, сравнения и.т.д.)
как-то я делал Детерминированный конечный автомат, т.е там была не таблица переходов, а граф, замкнутый в кольцо....
ща найти на форуме не могу, но похоже старые вложения всё равно все сдохли....
PS речь там, если я правильно помню, была про пресс.
вот пример Case
Чем думать, как построить конечный автомат, лучше думать, как проще решить поставленную практическую задачу.
А если у вас нет практической задачи, и конечный автомат вам нужен для неких теоретических изысканий, то ПР200 не лучшее средство для этого=)
PS ОЛ по сути есть функциональный язык программирования. Каждый макрос в нем есть детерминированная функция без побочных эффектов, то есть макрос не может изменить значения каких бы то ни было внешних переменных, и результат его работы зависит только от значения входящих аргументов, поэтому попытка реализовать там что либо из императивной парадигмы будет проваливаться)
К сожалению, ОЛ лишен всех преимуществ настоящих функциональных ЯП таких как полиморфизм, частичное применение, функции высшего порядка, рекурсия и прочее. Иначе ничего бы не стоило организовать например, списки и пользоваться ими аки массивами)
Таким образом, если вы хотите сделать полноценный Case, который мог бы совершать произвольные действия на определенные значения бегущей переменной, то ничего у вас не выйдет ввиду того, что ОЛ не поддерживает доступ к внешним переменным. Если вы хотите просто сделать функцию результат которой зависит от входной переменной, то это функция SEL.
Конечно есть практическая задача, которая элементарно решается при помощи оператора case.
Так сколько выходов Вам нужно и на входе целочисленная переменная состояния или например 8 дискретных входов с количеством состояний 256? Если напишите состояния выходов для каждого состояния на входе! Я пока до конца не представляю этот блок, что Вы хотите!Цитата:
Сообщение от IVM
В посте #21 дан исчерпывающий ответ на мой вопрос. Пытаться реализовать полноценный оператор case на CFC невозможно.
Ваше предложение подходит для чисто дискретной задачи. В моей задаче кроме дискретных выходов надо работать с аналоговыми выходами, ПИД-регуляторами и проч.
Разве? А как же ФБ, которые хранят состояние и создают побочные эффекты?Цитата:
Сообщение от anthrwpos
Первый попавшийся TON/TOF/SR и т.п. блок это побочный эффект.
Чего-чего?Цитата:
Сообщение от anthrwpos
Во-первых, ОЛ поддерживает доступ к переменным (как просто переменным, так и к сетевым переменным).
Во-вторых, примеры "совершения действий на определённые значения переменной" уже приводили, а тут внезапно оказывается, что "это невозможно".
Надо побольше оптимизма! 16 дискретных выхода(16бит) могут заменить аналоговый выход! Тоесть Вам надо чтобы в зависимости от входного состояния(например у меня в 1 макросе 257 состояний) меняется состояние выхода( для 16 бит: 0-65535), если так, то это вполне можно сделать в ОЛ и Ваш пессимизм преждевременный!Цитата:
Сообщение от IVM
По сути Вам нужен мультиплексор целочисленных или вещественных значений на необходимое количество состояний(входов)?
Макросы мультиплексоров выкладывались и у меня есть с расширением на сколько угодно входов, если что, скажите!
Вот один из вариантов мультиплексора целочисленных переменных с расширением на 16 входов, можно состряпать аналогичный для вещественных значений!
Вложение 30673
Это я из первого макроса взял, что выше выложил!
Сергей0308 Тут больше подойдёт стек который вы предлагали для клапанов с поплавками.
1) Никакой макрос не делает ничего кроме вычисления результата своей работы. - это отсуствие побочных эффектов.Цитата:
Сообщение от Владимир Ситников
2) история результата работы любого макроса определяется историей состояний его входов. - это детерминированность (в указанном смысле).
ОЛ не поддерживает глобальные переменные. То есть возможность из внутренних макросов менять внешние переменные.Цитата:
Чего-чего?
Во-первых, ОЛ поддерживает доступ к переменным (как просто переменным, так и к сетевым переменным).
И кстати это обстоятельство вообще говоря не позволяет называть эти объекты макросами. Макрос это по определению некая программа, имеющая доступ ко всему внешнему окружению и выполняющая в нем некие запрограммированную последовательность действий. А у нас тут не макросы, а самые настоящие функции.
Как ловко жонглируем терминами "детерминированная функция без побочных эффектов" и "историей состояний его входов".Цитата:
Сообщение от anthrwpos
Перевожу с русского на русский: эти два утверждения совершенно противоположны и одновременно не могут сосуществовать.
На всякий случай, дам ссылку на Wikipedia про побочные эффекты:
https://ru.wikipedia.org/wiki/%D0%9F...D%D0%B8%D0%B5)
Нужная часть:
Очевидно, TON/TOF/SR/BLINK и т.п. функциональные блоки хранят и изменяют состояние. Их вызов сопряжён с чтением и записью этих значений.Цитата:
Сообщение от Wikipedia
Операция "write to FB" так вообще один сплошной побочный эффект.
Согласно определению с Wikipedia, если ОЛ-макрос содержит что-нибудь типа TON/TOF/SR/BLINK, то этот макрос нужно называть "недетерминированными функциями с побочными эффектами". Ведь, наличие TON/TOF/SR/BLINK может привести к тому, что "будет разный результат при одних и тех же входных аргументах".
И после этого будем говорить, что "Каждый макрос в нем есть детерминированная функция без побочных эффектов"? Ну как такое можно говорить?
Не стоит выдавать желаемое за действительное (ну или зачем ещё говорить высокопарные слова?)
Очевидно, что большинство программ/макросов с побочными эффектами (как я говорил, TON/TOF/BLINK/SR/write to FB -- и всё, получай побочный эффект)
Вот те раз. А сетевые переменные не глобальные что-ли?Цитата:
Сообщение от anthrwpos
Подразберитесь с теорией. Разумеется, из внутренних макросов менять внешние переменные нехорошо, но это (изменение внешних) не является необходимым критерием на "наличие побочных эффектов".Цитата:
Сообщение от anthrwpos
Например, блок BLINK ничего не меняет, но это побочный эффект -- "обращение к источнику времени". Его вызываешь, и он возвращает разное.
Аналогично и блок TON в макросе это тоже побочный эффект, хоть он "как бы" и не изменяет "внешнюю переменную"
массив чисел и последовательность переданных чисел принципиально не сильно отличаются. Поэтому я считаю, что детерминированность в том смысле что я написал, можно считать детерминированностью.Цитата:
Сообщение от Владимир Ситников
что-то в приведенной вами цитате свалены детерминированность и побочные эффекты в кучу) Вероятно автор данной строчки написал её не разобравшись и уж точно, что он не процитировал её из учебной литературы)Цитата:
На всякий случай, дам ссылку на Wikipedia про побочные эффекты:
хранение и чтение внутреннего локального состояния самой функции не считаются побочным эффектом.Цитата:
Очевидно, TON/TOF/SR/BLINK и т.п. функциональные блоки хранят и изменяют состояние.
Операция "write to FB" является вариантом явной передачи в функцию аргумента. Она ничем не отличается от дополнительного входа, куда мы так-же передаем аргумент.Цитата:
Операция "write to FB" так вообще один сплошной побочный эффект.
чем они глобальные? Из макросов их не прочитать.Цитата:
Вот те раз. А сетевые переменные не глобальные что-ли?
необходимым критерием побочного эффекта является выход который зависит не только от входящих аргументов, но и от чего-то еще внешнего.Цитата:
Подразберитесь с теорией. Разумеется, из внутренних макросов менять внешние переменные нехорошо, но это (изменение внешних) не является необходимым критерием на "наличие побочных эффектов".
Blink(n,m) всегда выдает 0 первые m миллисекунд и 1 последующие n и так далее. В смысле "выход есть развертка во времени", блинк - обычная чистая функция.Цитата:
Например, блок BLINK ничего не меняет, но это побочный эффект -- "обращение к источнику времени". Его вызываешь, и он возвращает разное.
Итого, всё во что уперлись наши разногласия - это правомерно ли считать ли развертку во времени аргументом или результатом работы функции.
У нас в физике например, есть единое пространство-время и относительность одновременности. Это значит, что принципиальной разницы между разверткой в пространстве и во времени нет и посему мы вправе считать последовательность во времени частным случаем массива или списка)
Вынес обсуждение побочных эффектов в отдельную тему: Макросы ОЛ: с побочными эффектами и/или детерминированные?Цитата:
Сообщение от anthrwpos
PS. Не думал, что человек может называть термины "чистая функция", "функциональное программирование" и при этом считать blink чистой функцией.
Просто человек не делает различия между функциональным блоком(макросом) и функцией.Цитата:
Сообщение от Владимир Ситников
Функциональный блок(макрос) обладает внутренней памятью в которой храниться состояние внутренних переменных(переменной) и в зависимости от внутреннего состояния и входа формируется выходное воздействие (выход из функционального блока). У функции же в зависимости от входа формируется выход (за один такт выполнения).
Так же у функции (в большинстве случаев) один выход, а функциональный блок может обладать несколькими выходами или тоже только одним. Собственно получается, что макрос - это функциональный блок. Детерминируемый или нет? Думаю, что да - ведь мы делаем функциональные блоки (макросы) с уже известным(предсказанным) поведением при известном внутреннем состоянии и входном воздействии.
Есть очень простой пример: SR-триггер. Он является недетерминированным в том плане, что при одних и тех же значениях S и R на входе он может возвращать TRUE, а может возвращать FALSE. Например, если подать S=FALSE, R=FALSE, то невозможно предсказать что именно вернёт SR.Цитата:
Сообщение от ferret_maybe
Ещё раз: "недетерминированность" не означает, что "вообще невозможно предсказать поведение SR-триггера. Оно означает лишь то, что для такого предсказания нужно знать всю историю событий.
В этом плане операция ADD является детерминированной и чистой. Т.е. результат ADD не зависит от прошлых запусков ADD, не зависит от какого-то скрытого состояния, а зависит только от аргументов.
Поэтому, если в макросе используются ОЛ ФБ или обратные связи, то этот макрос уже перестаёт быть детерминированным. Это не значит, что ОЛ ломается. Это значит, что для понимания принципа работы такого макроса нужно учитывать потенциальные скрытые состояния.
PS. Если продолжение, то имеет смысл в теме Макросы ОЛ: с побочными эффектами и/или детерминированные
PPS. Тов. писал, что "каждый макрос в ОЛ есть детерминированная функция без побочных эффектов", и именно это неправильно. Да, в ОЛ могут быть макросы, являющиеся "детерминированной функцией без побочных эффектов". Например, если макрос состоит только из математики и логики (ну, ADD/AND/NOT/fMUL и т.п.). Но заявлять, что "каждый макрос в ОЛ без побочных эффектов" это явное лукавство, т.к. куча макросов направлена именно на побочные эффекты (на изменение внутреннего состояния ФБ, используемых в макросе). Если в макросе обратная связь или какой-нибудь ФБ, то всё, макрос наверняка с побочным эффектом и недетерминированный.
http://neerc.ifmo.ru/wiki/index.php?...ечные_автоматыЦитата:
Сообщение от Владимир Ситников
Можете остаться при своем мнении.
Так. С вами понятно. Вы перепутали "детерминированный конечный автомат" и "детерминированную функцию".Цитата:
Сообщение от ferret_maybe
К слову: слова "побочный эффект" и ДКА рядом редко упоминаются. Это из разных опер. А вот слова "детерминированность функции", "чистота функции", "побочные эффекты", haskell это вполне понятно из какой оперы.
Так говорят что этого нельзя сделать в ОЛ, тогда пусть ждут когда в ОЛ ST добавят, думаю что не пройдёт и 100 лет! Вы как думаете можно это сделать в ОЛ? Я не понимаю, что они хотят!Цитата:
Сообщение от Василий Кашуба
drvlas уже делал конечный автомат для весового терминала, по моему на девять циклов. Я и ещё несколько человек помогали ему в создании этого проекта.Цитата:
Сообщение от Сергей0308