Comments 10
UFO just landed and posted this here
Были ли у вас случаи, когда для срабатывания триггера нужно не просто множество событий, а некоторая их частичная упорядоченность по времени? Как боролись: введением вспомогательных триггеров?
Если я правильно понял имеется в виду случай, когда при срабатывании триггера должно произойти несколько действий, но не сразу а последовательно, в таких случаях возможно 2 варианта:
- просто использовать delay или его аналог, подходит к случаям когда заранее известно, что ничего другого в это время не произойдет.
- вспомогательные триггеры, тут несколько вариантов, наиболее простой в реализации это добавление счетчиков, значение которых обновляется в соответствии с прошедшим временем (по millis к примеру), в таком случае условием для триггера будет значение этого счетчика. Похожее у нас используется для событий по времени.
при срабатывании триггера должно произойти несколько действийНе совсем это имел ввиду: «триггер» A должен сработать, когда сначала был открыт кран, а затем включен насос, а не просто когда кран открыт и мотор включен. Причем, насос может включаться вручную. Т.е сам по себе триггер на открытие крана не нужен. А ведь может быть еще и другой «триггер» В(аварийный), который срабатывает когда, сначала включается мотор, а потом открывается кран.
история вопроса
Предложил использовать событийный адрес, но не смог придумать убедительного примера. В комментарие к своей предыдущей статье автор Парадигма ситуационно-ориентированного программирования написал:
P.S. Чтобы лишний раз не путаться в терминах, можно назвать «триггеры» А и В, например, «метатриггеры».
Понятие «событийный адрес» не нужно.Мне кажется, случай с насосом как раз является таким примером. Хотя если и он не достаточно показателен(можно просто по событию включения проверять открытость крана), можно предствить цепочку из трех и более событий.
P.S. Чтобы лишний раз не путаться в терминах, можно назвать «триггеры» А и В, например, «метатриггеры».
В таком случае тут достаточно просто добавить 2 глобальные переменные — время запуска мотора и время открытия крана, затем на триггере использовать в качестве условия сравнение этих переменных.
Заполнять их значения по действию с соответствующих триггеров.Ничего сложного вроде как нет.
Заполнять их значения по действию с соответствующих триггеров.Ничего сложного вроде как нет.
Спасибо, думал в этом направлении. Также нужны триггеры на обратные действия. Ведь мотор может включаться и выключаться несколько раз, также как и кран может открываться и закрываться. Возникает разделение триггеров на ключевые(активные), приводящие к действиям и вспомогательные(информативные), работающие в паре(открытие/закрытие, включение/выключение) и запоминающие время и последнее состояние.
Другой вариант: для каждого событийного адреса на основании предыдущих состояний формировать ожидаемые(несколько, так как инициирующее(первое в цепочке) событие может произойти еще раз после начала отслеживания) состояния и сравнивать их с текущим. При совпадении по маске, продолжать отслеживать цепочку. При наступлении ключевого события сработает «метатриггер». Из плюсов этого варианта — большая скорость реагирования, поскольку не нужно смотреть историю — мы ожидали ключевое событие.
На самом деле, возможна произвольная комбиная отслеживания и проверки истории. Событие, при котором происходит и проверка истории и запуск отслеживания можно назвать базовым. Но можно пойти еще дальше и допустить несколько базовых событий(дерево точек отсчета как вперед так и назад во времени), сброс ожидания событий по таймеру…
Также нужно помнить, что каждый триггер, который должен срабатывать повторно, должен где-то сбрасываться.
Другой вариант: для каждого событийного адреса на основании предыдущих состояний формировать ожидаемые(несколько, так как инициирующее(первое в цепочке) событие может произойти еще раз после начала отслеживания) состояния и сравнивать их с текущим. При совпадении по маске, продолжать отслеживать цепочку. При наступлении ключевого события сработает «метатриггер». Из плюсов этого варианта — большая скорость реагирования, поскольку не нужно смотреть историю — мы ожидали ключевое событие.
На самом деле, возможна произвольная комбиная отслеживания и проверки истории. Событие, при котором происходит и проверка истории и запуск отслеживания можно назвать базовым. Но можно пойти еще дальше и допустить несколько базовых событий(дерево точек отсчета как вперед так и назад во времени), сброс ожидания событий по таймеру…
Также нужно помнить, что каждый триггер, который должен срабатывать повторно, должен где-то сбрасываться.
Все так, сразу видно человека, который «в теме») По сути информативный и ключевой ничем не отличаются, просто информативный «ничего не делает». Второй вариант выглядит довольно красивым, но уже достаточно сильно зависит от языка реализации, в текущей реализации программа пригодна для любых языков с похожим на Си синтаксисом, если затачивать под конкретную платформу можно построить любой алгоритм выбора триггера. В текущей реализации можно поступить похожим образом, используя только более правильную «сортировку» триггеров. Метатриггер это насколько я понял просто триггер который зависит от других триггеров, такой в текущей реализации уже есть. По поводу сброса тоже думал, можно было реализовать на уровне приложения, но тогда это ставит жесткие рамки, по сути для сброса достаточно скинуть bool значение на false чтобы активировать триггер, это можно сделать из любого действия или вынести на уровень шаблона кода. Похожее я использовал для удаленного управления, все свободное от работы время контроллер слушает сеть на наличие команд.
Уважаемый автор, а Вы не думали в сторону языков релейной логики?
Например, можно использовать вот это
Например, можно использовать вот это
Это очень хорошее решение для задач с идеальным ТЗ, в которых не может быть отклонений от изначально поставленной задачи. К примеру пример из практики, изначально было N устройств и определенная схема взаимодействия, к концу разработки было уже N+6 устройств и совсем другая схема взаимодействия. В случае с релейной логикой пришлось бы для каждого случая с нуля паять всю логику (которая была бы очень не простой). В случае с моим решением достаточно поменять пару триггеров в интерфейсе, чтобы получить полностью готовое решение с учетом изменений.
Sign up to leave a comment.
Автоматическая генерация программного кода микроконтроллера на основе событийно-ориентированной модели