DRAKON.SU

Дорогие друзья, всем здравствуйте!

I. Вступление.
=================================================
1) Сразу скажу:
а) Очень интересный раздел!
б) Я - начинающий программист.
в) Стараюсь текст форматировать согласно, можно сказать, стилю этого форума - разграничивать, выделять,
обрамлять - всё для лучшего восприятия.

2) Ниже приведу порядок ознакомления с данной темой:
а) Прочитал статью для микроконтроллеров - AVR. Учебный курс. Конечный автомат.
б) Изучаю как справедливо заметил Di Halt (автор статьи выше) замечательный цикл статей Владимира Татарчевского, опубликованный в журнале Компоненты и Технологии.
в) Кратко посмотрел пару презентаций на сайте Анатолия Абрамовича Шалыто.
г) Наконец и здесь, на моём одном из любимейших форумах, нашел данный раздел.

II.Собственно вопрос
=================================================
1) Как показать передачу по Modbus'у используя "Дракон"?
В 7ой статье из цикла (п.II.2.б) есть небольшая схема (по-моему, называется граф-схема). Прикрепил ниже.
Возможно ли её принять за исходную для перевода в ДРАКОН-схему?

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

3) Степан Митькин предлагал использовать для перехода конечного автомата в новое состояние иконку "Ввод".
Можно ли также сделать здесь, подразумевая этой иконкой получение сообщения устройством от другого устройства?

В адресе две ошибки. Правильный адрес http://easyelectronics.ru/avr-uchebnyj- ... tomat.html

Насколько я понимаю, предполагается, что один автомат работает в одном потоке.
В таком случае, чем плоха для визуализации этого автомата обычная ДРАКОН-схема "силуэт"?
Вот, я когда-то изобразил серверную часть UDP-chat клиента на каком-то подмножестве протокола ICQ.
Там автомат (самая нижняя схема) постоянно "крутится" в одном Активном Объекте (т.е. нити) и обрабатывает поступающие пакеты.
http://sage.com.ua/screens/UDPChatServerDRAKON.png

Указанную схему можно переложить на ДРАКОН. Но она слишком простая.
Это цикл актора в общем виде. Hello world.
Hello world на любом языке смотрится элегантно.

Владимир, лучше всего, если Вы нарисуете свою собственную дракон-схему и выложите ее.

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

Приведите какой-нибудь конкретный пример автомата.
Конечный автомат особенно хорош, когда:
1. У него может быть несколько состояний.
2. Он принимает несколько видов сообщений.

Fixed. Спасибо.



Вот это да! Сейчас, наверное, на А3 распечатаю и буду внимательно изучать! Тема клиент-серверного приложения для меня очень интересна! Если есть еще какие-нибудь схемы, может быть статьи (для новичка), если не затруднит, выкладывайте, я с удовольствием прочитаю.



Ну вот, когда написано/изображено - действительно просто))) Здесь, наверное, еще стоит какие-нибудь таймеры использовать. Мол, не пришло за такое время - либо повтори, либо хватит ждать и что-то делай?

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



Очередь сообщений.
Возможно немного отдаляясь от темы. Там в статьях была упомянута возможность очереди сообщений. Т.е., я так понял, думаешь задать некую последовательность команд и для этого делаешь "какую-то очередь сообщений". Это, наверное, может быть, к примеру, буфер указателей, каждый из которых указывает на какое-то сообщение. Т.е., возможно, это как в программирование называется FIFO. Т.е. очередь для отправки сообщений заполняется и в это же время отправляется?

По поводу наглядного изображения ответа прибора я предложил использовать вторую точку входа:
viewtopic.php?f=78&t=5593&start=20

Строго говоря, в алгоритме работы Modbus должна быть только одна ветка, так как это протокол (в 99% реализаций) со строгой иерархией. Пока сервер не спросит -- клиент не ответит.
Клиент, конечно, и так может не ответить, но это уже ветка проверки условия "ответил? да-нет".
В целом, это линейный алгоритм, без какой-либо произвольной логики или непредсказуемости.

Спасибо за ценные мысли. Лучшее понимание самого протокола приходит.

Выкладываю что на данный момент получилось.

1. С чего переделывал:


2. Что получилось:

Получилось прикольно.
Но я позволю себе предложить улучшение.

Ветка == состояние == точка ожидания

Можно принять следующее соглашение:
1. Каждая ветка силуэта — состояние автомата.Кроме последней, в ней очистка ресурсов.
В этом соглашении получается, что ветка == состояние == точка ожидания.
2. Сразу под заголовком ветки находится икона "Выбор" с текстом "ждать".
Каждая икона "Вариант" соответствует типу входящего сообщения. При этом срабатывание таймера — это тоже сообщение.
Таким образом, диаграмма наглядно показывает, что автомат делает в зависимости от:
- состояния
- типа входящего сообщения.

Прошу обратить внимание, что данный подход не является пустой болтовнёй. DRAKON Editor генерит боевой код из таких силуэтов.
Поведение нового редактора (https://drakon-editor.com) задаётся автоматами данного вида.

Данный подход оправдал себя на практике.

Степан, спасибо за комментарий!

Оффтопик по редактору drakon-editor
Как заметили, пользовался Вашим редактором при создание схемы.
По-моему, еще полгода назад где-то написал про значок жабы, что, мол, выглядит ядовито. Сейчас-же захожу, и приятный Дракончик, протягивающий руку, как бы здоровающийся, приветствующий. Возможно, посмотрели мой комментарий и, по-крайней мере, мне очень приятно стало видеть такого приветствующего парня




Примерно так и думал.



Стал читать еще темы из раздела и понял, что вопрос с длинной простыней уже ставился.
По-моему, в приведенной мною схеме каждая ветка как-раз и выражала состояние автомата.



Очень ценные и толковые советы! Какая наглядность сразу появляется! Спасибо за приведенную схему!
Только пока не совсем понял как Вы спрятали состояния "Передать сообщение" и "Приём сообщения" в другие состояния (в "Ожидания команды на передачу сообщения от основной программы" и "Ожидание ответа ведомого" соответственно).

Т.е. получается, хотим, чтобы каждому состоянию по ветке. Но вот эти два состояния спрятаны внутри состояний (==внутри веток).

UPD:
А... Дракончик шагает) Разглядел)

Да, здесь получается именно так. Но можно сделать и по-другому.
Можно развернуть эти состояния, "Передать сообщение" и "Приём сообщения", в отдельные ветки.
Разворачивать их имеет смысл, если в этих состояниях автомат принимает сообщения. Таймаут, например, или команду "прервать".


Персонажа Дракошу придумал талантливый дизайнер Сергей Миронов.

В продолжение тему решил перевести данную схему (из 7ой статьи из цикла статей, приведенного в 1ом посте):
"Конечный автомат приема сообщения Modbus в режиме RTU"


В Дракон-схему:


=============================================================
По поводу правил построения Дракон-схем.
Сейчас вспоминаю книгу.
Рассматривая силуэт (т.е. когда много веток):

1. Необходимо стараться идти всё правее и правее для завершения алгоритма?
Т.е. если в конце ветки есть выбор и одно направление ведет к продолжению выполнения алгоритма, то его правее?
Или (может это только у примитива - т.е. только когда 1 ветка), чем чаще, тем центральнее?
2. Конец - всегда?
Конечный автомат опрашивается постоянно. Т.е. он - как отдельный поток. Т.е., по идее, конца нет (только когда программа сама завершиться). Но, в Дракон-схеме, насколько помню, конец должен быть всегда?

=============================================================

Спасибо, принял.

Думаю, что да. Но для автоматного силуэта это правило в любом случае будет нарушаться.

Нет, конец в силуэте не обязателен. Бывают бесконечные алгоритмы (например, алгоритмы управления).
В DRAKON Editor Web конец обязателен. Но этот недостаток будет исправлен.