DRAKON.SU

Новый дракон-редактор для ПЛК (программируемые логические контроллеры)

Бизнесмен Алексей Муравицкий и программист Алексей Степанов ведут разработку нового дракон-редактора для ПЛК.

Алексей Муравицкий известен как системный интегратор фирмы ОВЕН.
В последнее время А. Муравицкий работает системным интегратором НИИСИ РАН (Научно-исследовательского института системных исследований Российской академии наук).

Новый дракон-редактор разрабатывается для работы с ПЛК 1, ПЛК 2 "Багет", разработанных В НИИСИ РАН.

Ссылка на ПЛК 1:
https://www.niisi.ru/%D0%9F%D0%9B%D0%9A ... D0%9A1.pdf

Ссылка на ПЛК 2:
https://www.niisi.ru/%D0%9F%D0%9B%D0%9A ... D0%9A2.pdf

В НИИСИ РАН разработана также ОСРВ (операционная система реального времени) для ПЛК.

Алексей Степанов ранее (в 2000–2003 годах) уже имел опыт разработки дракон-редактора как часть большой системы негражданского назначения. Разработка была закончена, сдана заказчику, но на вооружение не принята. Результаты опубликованы в статье:
Пересказ статьи см. здесь Прокрутите вниз до слов:

Скачать Drakon-Editor MS
https://drakon.su/knigi_vladimira_paron ... _editor_ms

Краткие пояснения к дракон-редактору:

Уважаемые коллеги!
Прошу высказывать критические замечания о редакторе Drakon-Editor MS

Здравствуйте. Во-первых, спасибо, что наконец-то этой проблеме нашли какое-то решение - ДРАКОН для ПЛК двух типов "Багет". Хорошее начало, полагаю.

Во-вторых, свои пометки я разделил на более глобальные, концептуальные, можно сказать, и мелкие.
Начну с глобальных:
Минусы
- Только в инструкции я смог отыскать, что дракон-схемы интерпретируются на Си. Но для меня тогда странно, почему в редакторе можно создавать дракон-схемы классов. Тот Си, которому учился я, не был объектно-ориентированным языком. Поэтому прошу авторов дать пояснение в справочных материалах, на какой язык идёт интерпретация. Язык Си переживал несколько изменений и его история вам подскажет, какую версию вы взяли за основу: https://en.wikipedia.org/wiki/C_(programming_language)#History
И вообще в таком случае, как вы себе представляете дракон-схему класса? Класс это просто перечень параметров и методов создаваемых экземпляров. Поэтому дракон-схемы классов если и делать, то это должны быть примитивы с возможными атомами Действие (для ключей) и Вставка (для методов).
- Хотелось бы увидеть какие-то подсказки в заполнении икон фрагментами программ или примеры, чтобы было на что ориентироваться.
- Самый главный минус пока что, на мой взгляд, отсутствие возможности пересадки и заземления лиан. Это большая сложность, но в этом главная изюминка языка ДРАКОН. Это требует, возможно, пересмотра всей структуры хранения схем. Пересадка лиан - жемчуг теории ДРАКОНа, а в Си такая вещь интерпретируется в виде меток и goto. Это сделает ваш инструмент удобным для непрограммистов, потому что программисты, основываясь на этих конструкциях, смогут и сами код написать безо всякого интерпретатора. А когда перед ними появляются разветвления, слияния в неожиданных местах, они озадачатся как это интерпретировать. А ваш интерпретатор сам расставит все метки и goto.

Плюсы
+ Интересный аналог валентных точек, невиданный мною ранее.
+ Прекрасная реализации операции рокировки, когда вместе с "Да" и "Нет", меняются местами и содержимое обоих плечей развилки.
+ Хорошая навигация по редактору в виде дерева такого: вот тебе список всего, вот список классов, вот список функций и т.д.
+ Ощущается влияние Геннадия Тышова - меньше кликов, больше действий. И в дополнение ещё его решение двух окон для иконы: "Имя" и "Код".

И есть ещё несколько мелких заметок по поводу интерфейса.
= Я бы изменил цвет икон верхней панели ("Открыть", "Сохранить" и т.д.) на более насыщенный, так как складывается впечатление, что эти кнопки неактивны. Действительно, какие-то неактивны ("Сгенерировать код", например), но активные надо как-то выделять...
= Был момент, который я действительно хотел испытать - создал схему впритык правому краю и попытался добавить туда атом. В результате при наведении на самую правую вертикаль высвечивается панель выбора атома, но она скрывается за рамки редактора частично. В этом случае надо делать перенос высвечивающегося окна влево (насколько я понимаю, у вас она автоматически появляется всегда справа).
= В целом хотелось бы все значки в области редактора покрупнее. Я имею ввиду выбор атома, рокировку, добавление ветки, варианта, удаление иконы и так далее.

Ну и не могу обойти стороной визуальное выделение икон. В таких редакторах как DrakonHub, Фабула, иконы можно как-то стилизовать. Интересно, найдёте ли вы в этом необходимость или нет.

В целом такая версия редактора уже достойная и как я предполагаю со своими целями справляется - с помощью него можно программировать ПЛК. Если планируются какие-то изменения и правки, я бы порекоммендовал больше придать редактору "драконовости". Потому что, глядя на схемы, которые можно гипотетически создать в этом редакторе, нельзя сказать, что ДРАКОН - эргономичный язык. У него как у папье-маше есть детали, которые придают ему эргономичность. Постепенно опуская детали, эргономичность теряется. К деталям я бы отнёс: пересадку и заземление лиан, правило шампура (выделение шампура жирной линией), веточные циклы (тоже как вариант).

Ответ Алексея Степанова

Приветствую!
Благодарю за обратную связь!
Прокомментирую некоторые моменты.


Не совсем так. Просто есть конкретная задача: здесь и сейчас писать код для этих ПЛК, поэтому они и выбраны как объект для тренировок и отладки технических решений. Но фишка редактора в том, что он не привязан к какому-либо конкретному языку и какой-то конкретной платформе. Генерацию кода можно реализовать для массы языков - это сугубо техническая задача. Гораздо важнее сделать удобную среду разработки, которая не будет причинять боль пользователям и не будет вводить их в ступор.


Классы вполне можно реализовать на C, а также и на других языках, где их нет в явном виде. В случае C это может быть структура с членами, методы реализуются через указатели на функции. Можно сделать, например, наследование и некоторые другие элементы ООП - просто пока таких задач нет, но если они возникнут - особых проблем нет.
Класс был введен больше для удобства разработчика, т.к. это довольно удобный и понятный способ описания разных сущностей. А раз так, то почему бы не описать содержимое класса дракон-схемой?


Примерно так и планируется. Члены класса - действия (сгруппированы в ветках для удобства), методы - полноценная дракон-схема.
Классы в редакторе еще не доделаны, там есть над чем подумать и что доработать.

Язык Си переживал несколько изменений и его история вам подскажет, какую версию вы взяли за основу
В случае генератора кода на C планируем придерживаться ANSI-С по причине хорошей портируемости результата.


Я так понимаю, речь идет о том редакторе, при помощи которого заполняется содержимое икон? Если да, то такого редактора пока нет, он в разработке. Сейчас там для тестов была сделана возможность писать "свободный код", т.е. код на целевом языке платформы. Но это временное решение. Вообще, создание удобного, простого, но в то же время гибкого редактора выражений для содержимого икон - не самая тривиальная задача, тут есть над чем подумать.


Всё это будет реализовано. Кстати, заземление веток в развилке уже есть.


К слову, помимо такой рокировки, иногда требуется просто сменить назначение веток развилки, т.е. поменять местами "Да" и "Нет" не меняя содержимого самих веток. Такой вариант тоже будет.


Да, косяки там еще есть. В будущих версиях будем исправлять.

На самом деле, эта версия редактора - прототип, макет. До готового решения ещё далеко и планов на самом деле очень много. В частности,

планируется к реализации:

- Создание библиотек, которые можно будет подключать к проекту. Библиотеки могут быть как нативные для целевой платформы, так и созданные пользователем в этом же редакторе.

- Утилитарные иконы для упрощения задания содержимого икон. Например, для действия приравнивания одной переменной к другой (а это весьма распространенная операция при программировании) вовсе не обязательно писать руками выражение. Можно дать пользователю максимально упрощенную форму, в которой он в два клика укажет, что нужно сделать.

- Будет не просто генерация кода, а вызов компилятора для целевой платформы, запись результата в ПЛК. Всё как в серьезных средах разработки: нажали кнопку - получили результат, без необходимости делать руками все промежуточные операции.

- Визуальная отладка кода - как на эмуляторах, так и на целевых ПЛК. В том числе - удалённая отладка.

Меня ответы тёзки, Алексея Степанова, устраивают. Вот что значит общаться на одном языке и мыслить на одной частоте. Не знаю как на будущую версию отреагирует критик tonyk со стороны своих профессиональных интересов, но мне со стороны разработки лично всё понятно. В дальнейшем видимо вы будете предлагать для какого конкретного ПЛК пользователь хочет создать схему и в зависимости от его вида настраивать изменять некоторые аспекты управления (я в ПЛК не специалист, в будущем планирую почитать литературу, чтобы ещё вникнуть в проблему).
В общем прототип хороший, план на будущее у вас есть и можно пожелать только успехов, ведь ваш редактор сделает ДРАКОН известнее и полезнее

Дополнительный материал от Алексея Муравицкого

Создалась качественно новая ситуация в области разработки коммерческого ДРАКОН-конструктора (а затем IDE) для программирования и отладки программируемых логических контроллеров (ПЛК).

Суть в том, что образовалась настоящая конкурентная среда. В работу (и в конкуренцию) включились два разных проекта:

1. На Easyelectronics участник serega3001 28 апреля 2023 сделал заявление о коммерческом проекте FalangIDE

2. И вот теперь Алексей Муравицкий и Алексей Степанов сделали свое заявление о коммерческом проекте Drakon Editor MS.

Конкуренция — двигатель прогресса!

Скачать Drakon-Editor MS обновление Версия 1_0_4

Две картинки от Муравицкого:

Пояснение от Алексея Муравицкого

Появился проблеск надежды, что в обозримом будущем появится _интегрированная_ среда (ИС) работы с Драконом. Похоже, что многие забыли значение термина "ИС". Он означает сведение в единую среду разработки редактора, симулятора и отладчика. Далее конспективно напомню то, о чём уже писал ранее.

Наличие стандартного текстового формата для программ на Драконе позволяет передавать программы между разными средами программирования на нём от разных авторов.

Приземление Дракона на реальное "железо" потребует создание стандарта на передачу исполняемого кода и отладочной информации между ИС и "железом".

Наличие симулятора автоматически тянет за собой создание стандарта на среду исполнения (рантайм) Дракона на "железе". Для меня не вызывает сомнений необходимость выложить в открытый доступ каркас рантайма с методикой его привязки к "железу". Кстати, задумайтесь, что "железо" может быть и не "железным", а программой, работающей на этом же ПК. И раз уж речь зашла о ПЛК, то у них ОЗУ может быть и 100К, и 256М, а Дракон хочется запускать везде.


Мне бы такую уверенность... Я сам пока не до конца понимаю как решать некоторые проблемы, которые у вас, приземляющих Дракона, возникнут. Без обид, просто моя оценка: редактор, выгружающий текстовый вид Дракон-программы и компилятор, преобразующий эту программу в эквивалент, например, на Си- это, примерно, 20% того, что нужно сделать для создания полноценной ИС.

Выкладываю документ, который подготовил начальник ПТО ОКБ АМУР №3 Исаев Алексей Владимирович

"Инструкция по среде разработки Drakon Editor MS"
Инструкция предварительная, в дальнейшем будет исправлена и дополнена по вашим замечаниям

Уважаемые коллеги!
Прошу высказывать критические замечания об инструкции для Drakon-Editor MS

Ну вы говорите, что текущий продукт это условно 20% от ИС. Но это пока редактор, а не ИС. Нигде не написано, что это ИС. ИС - это система, которую вы себе представили, и говорите, что этот редактор - лишь маленькая часть того, чего бы вам хотелось.
Я же смотрю на то, что мне вот показали сегодня, сказали что это и я говорю как оно мне, потому что пока у меня такая точка зрения. Когда появится время, начну разбираться в этих ПЛК и тогда уже начну рассуждать с другой позиции.

Владимир Даниелович попросил меня посмотреть новую инструкцию и прокомментировать её.

1. Хотелось бы содержание инструкции с гиперссылками на разделы. Удобство такого изменения, думаю, комментировать не надо.

2. 4 раздел надо поменять местами с 6 пунктом 3 раздела. То есть пользователь создаёт проект и ему показывается дерево проекта. Дальше должно идти описание, а что это за дерево такое. И тогда потом пользователь поймёт и скажет "мне надо вот это". Тогда в конце 4 раздела для добавления программного элемента предлагаю такую формулировку: "Дерево проекта можно раскрыть до программных сущностей, нажимая на стрелки, находящиеся слева от узлов дерева. Чтобы добавить ту или иную программную сущность (класс, функция, программа), необходимо нажать на знак плюс".

3. 5 раздел, таблица типов данных. Пустой столбец можно убрать, шапку таблицы лучше выделить полужирным, чтобы не сливалось, и "Аналог" лучше заменить на "Аналог на Си (версия С99)". Насчёт версии языка ещё раз прошу уточнить. Потому что вы в таблице используете типы bool, (un-)signed long long. Не понимаю смысла в строке Логический троичный. Получается его нельзя будет интерпретировать на Си? Но оно есть в редакторе. Нужен ли этот тип данных в целом?

4. 6 раздел я не с первого раза понял. Надо сперва подвести к тому, что переменные задаются, если открыть шторку справа от панели с деревом проекта. Момент с веткой для объявления переменных тоже не совсем понял. Это необязательная процедура. В Си переменные можно объявлять где угодно, это же не Паскаль. А вообще пришла идея объединить 5 и 6 разделы в один пятый раздел "Объявление переменных" и тремя подразделами "типы переменных", "типы данных" (также можно перечислить их в виде таблицы), "создание переменной" (наглядные скрины из редактора). Пока что в шестом разделе описан локальный случай и общей картины процесса я так и не увидел.

Возникло ощущение, что инструкция создавалась за один день и под конец автор устал)) Без негатива, потому что я понимаю его)
Видимо, инструкция неполная, нужно ещё много пунктов дополнить:

— как делать дракон-схемы,
— обозначения икон,
— как открывать проекты,
— как сохранять проекты,
— как генерировать код.

В общем я дал обратную связь по тому, что было отправлено. Спасибо.

Я НЕ читал то, что комментируют, но в контексте прочитанного меня насторожило вот что.

Как только вы начнёте приземлять Дракона, так сразу же возникнет вопрос с объектами, которыми будет оперировать Дракон-программа. Заметьте, я не сказал "тип", а сказал "объект". Говорю в смысле С++, где объект это набор данных со списком доступных для этих данных операций. Вот тут нужно определиться, как быть, потому что в разных языках, через которые получается исполняемый код, имеются разные типы данных, и нужно или обеспечить реализацию какого-нибудь MONEY для всех целевых языков, или работать только с теми типами данных, которые есть на целевой платформе.
С точки зрения редактора проблемы нет, потому что он просто выгружает декларацию переменной с указанием её типа, отдавая на откуп компилятора с Дракона решение как работать с этим типом данных, но будет лучше, когда редактор будет знать, для каких целевых платформ какие типы данных поддерживаются.

Ещё задумайтесь вот над чем касательно Редактора.

Например, для типа int операция сравнения с нулём очевидна и имеет смысл. А для float? Как Редактор будет рисовать программу, ведь логически правильный алгоритм будет однозначно работать с одним типом данных, но не предсказуемо с другим.

Бизнесмен Алексей Муравицкий и программист Алексей Степанов неправильно ведут разработку нового дракон-редактора для ПЛК.
Разработка Дракон-редактор организована "перевернутой с ног на голову"!

Ведь в редакторе надо последовательно:
1. отражать требования заказчика для алгоритмиста,
2. потом алгоритмист формирует алгоритм для программиста,
3. потом программист формирует программный код,
4. потом тестировщик тестирует и при необходимости возвращает с замечаниями алгоритмисту(2) или программисту(3),
5. только потом программа зашивается в ПЛК,
6. потом технический писатель составляет инструкцию по эксплуатации,
7. потом производится сдача системы с ПЛК заказчику,
8. потом, если есть замечания заказчика, корректируются требования заказчика(1),
9. только потом производится оплата разработки.

Все эти этапы должны найти отображение в Дракон-документации сформированной в Дракон-редакторе.
Примером может быть использование ИС Дракон, описанное в докладе А.А Араптанова. Смотрите доклад https://forum.drakon.su/viewtopic.php?p=107041#p107041 .


Таким образом Дракон-редактор должен быть редактором общего назначения, имеющим расширение на связь с системой программирования ПЛК.

Всем требованиям к Дракон-редактору отвечает ИС Дракон.
В ИС Дракон требования реализуются за счет понятия Дракон-лист, наличия в Дракон-схемах множества слоёв ввода текста от участников процесса разработки - это точки ввода : А, Б и П.
Смотрите по ссылке https://drakon.su/programma_is_drakon.

Нарушена последовательность разработки Дракон-редактора, т.к. ориентирована на требования связанные с ПЛК и игнорируется этапность разработки системы с ПЛК.
У Алексея Муравицкого с 2019 года так складывается со всеми программистами Дракон-редактора - Лаптев, Ермаков и другие. Все эти неудачи нашли отображения на форуме.

Почему не написано? Это не так. Разработчики заявили
что это среда разработки (подразумевается: интегрированная среда разработки).

Где это написано?

1. Здесь написано "Инструкция по среде разработки Drakon Editor MS"

2. В самой инструкции на стр. 1 есть заголовок Инструкция по среде разработки Drakon Editor MS

Привожу цитату из Википедии
https://bit.ly/3CfZ0QS

Откровенно говоря, огорчился.

На языке описания алгоритмов один человек-алгоритмист рисует алгоритм, который другой человек-программист преобразует в программный код, третий тестирует. Что за бред? Смысл того, о чём я уже устал говорить тут, заключается в том, что после создания алгоритма нажимается кнопочка "Компилировать", потом кнопочка "Загрузить"- и получите работающий алгоритм на "железе" или в эмуляторе "железа" с визуализацией всех значений. Мы рисуем алгоритм, проверяем работу алгоритма, какая, нафиг, разница через какой язык программирования и в какую систему команд преобразован наш алгоритм? Преобразование диаграммы в машинный код- это формализуемая задача, которая давно и успешно решается компьютерами. Собираться втроём нужно для цели употребления шашлычка под коньячок, но не для создания работающей программы на Драконе.

99% пользователей ПЛК вообще не представляют во что преобразуется их программа и как она исполняется в "железе". Зато они видят результат её работы и видят результаты в промежуточных точках. Дракон язык более высокого уровня, чем графические языки стандарта ГОСТ Р МЭК 61131-3, которые, кстати, были созданы для того, чтобы люди-НЕпрограммисты могли реализовывать алгоритмы управления. На работе рядом со мной трудятся люди, которые на Бейсике даже решение системы линейных уравнений не смогут запрограммировать, зато хорошо разбираются в оборудовании, технологии, могут разобраться в программе работы ПЛК на графических языках и внести в неё изменения для изменения алгоритма работы оборудования. То есть это люди, которые мыслят алгоритмами, и для них Дракон был бы очень полезен. И таких людей на производстве много.

Tonyk, получается что Вы считаете себя, как говорится, "и швец, и жнец, и на дуде игрец".

Так не должно быть организовано!