DRAKON.SU

Текущее время: Воскресенье, 26 Июнь, 2022 20:23

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 10 ] 
Автор Сообщение
СообщениеДобавлено: Понедельник, 11 Апрель, 2022 11:07 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5434
Откуда: Москва
Критические замечания участника tonyk о реализации языка ДРАКОН для ПЛК

tonyk писал(а):
Дракон — штука хорошая, правильная. Я сравниваю её с позиций ПЛК. Но есть одно "но", которое обнуляет ценность сегодняшней реализации Дракона.

Дракон- это графический язык программирования. А где графическая отладка? Я её не заметил. Ведь если вы можете по графической схеме построить исполняемый код, так постройте его для виртуальной Дракон-машины, чтобы можно было его тут же, в среде программирования, запустить и отладить.

Естественно, что в процессе отладки значения всех переменных должны отображаться прямо на схеме программы. Даже не говорю о том, что необходимо иметь возможность отладки и на "железном" контроллере, наблюдая значения переменных и имея возможность их изменять.

Как это выглядит и работает, можно посмотреть в любой среде разработки для ПЛК на примере графических языков FBD, LD, SFC.

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

Будь симулятор и графическая отладка, Дракон можно было бы встраивать в МК, получая полноценный ПЛК.

tonyk писал(а):
За питьём кофе полистал сайт. Ребята, вы в тупике. И будете в нём до тех пор, пока не появится текстовый формат языка Дракона.

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

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

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

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

Обязательно нужен формат обмена отладочной информацией между средой программирования и исполнения.

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

Пока сделайте главное, дайте описание текстового формата Дракона в БНФ.

tonyk писал(а):
Наличие текстового синтаксиса позволит выгружать схему в виде текстового описания алгоритма, который можно обратно загрузить в редактор.

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

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

А самое главное- это отделение мух от котлет. В редакторе рисуется схема алгоритма, которая выгружается в виде текста, который уже можно транслировать в любой прикладной язык.

Даёшь Дракон в БНФ!


tonyk писал(а):
У меня есть свой проект по созданию ПЛК по стандарту ГОСТ Р МЭК 61131.

Свои мысли я тут высказываю с позиций разработчика ПЛК, по мнению которого проект "Дракон" уходит далеко от того, что нужно инженерам-практикам.

Более того, исходя из своего скромного опыта, я сильно сомневаюсь, что с нынешним подходом к разработке Дракон будет доведён до состояния, когда он будет массово использоваться, например, в ПЛК.

Глядя на происходящее, думаю, что если ничего не менять в вашей работе, то Дракон так и останется игрушкой для разума энтузиастов.

Повторюсь, я смотрю на Дракон с позиций разработчика ПЛК. Мне нравится концепция Дракона, будь у Дракона то, о чём я написал (текстовый формат, протокол обмена с рантаймом и т.п.), с удовольствием занялся бы переносом его на ПЛК.

Дракон и МЭК для меня- не конкуренты, это разные способы решения практических задач, поэтому я и делюсь своими мыслями и опытом.

tonyk писал(а):
Чему меня может научить Алексей Муравицкий, как ковылять на костылях с шильдиком "Дракон"? Я знаком со способом, который использует Алексей в работе с ПЛК.

Дабы прибить все споры на корню, просто ответьте на вопрос, почему кроме Алексея никто не использует Дракон на ПЛК?

почему тогда языки, созданные по такому "отсталому" стандарту, как ГОСТ Р МЭК 61131-3 существуют, развиваются и кормят их создателей, а чудо по названием "Дракон" за столько лет так и не доросло до уровня стандарта и остаётся игрушкой горстки энтузиастов?

tonyk писал(а):
Дракон ооочень коммерческий проект. Без открытой IDE, генерирующей на выходе что-то, пригодное для переваривания в МК, ИМХО, Дракон нафиг не нужен.

Не буду спорить с вашими маркетологами, которые выбрали такую стратегию продвижения Дракона, просто предложу обдумать, почему так популярны C, Codesys, Altium Designer и далее по списку.

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

Одним из преимуществ любого ПЛК является его массовость, которая позволяет всесторонне протестировать, в первую очередь, компиляторы и среду выполнения программ пользователя на целевом контроллере.

Ну, и по технике оказалось, что на Дракон вообще не предусмотрена работа с периферией контроллеров.

Нет даже упоминаний о низкоуровневой работе с регистрами периферии целевого контроллера, нет понятия "функциональный блок".

Не заметил возможности написания фрагментов программы на языках низкого уровня, например, С/С++ или ассемблер. Да много чего нет, без чего эффективное использование Дракона вряд ли возможно.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Дискуссия
СообщениеДобавлено: Среда, 15 Июнь, 2022 14:37 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 16
Владимир Паронджанов, вот иллюстрация того, о чём я говорил: отсутствие текстового формата диаграммы языка Дракон приводит к тому, что идёт распыление сил и времени разработчиков. Alex_st_Tomsk с товарищем сделали очередной редактор и генератор программы. Заметьте, очередной и непригодный для практического использования (Alex_st_Tomsk, без обид, дело не в тебе). Сколько ещё нужно вот таких игрушечных редакторов, чтобы осознать необходимость разделения редактора языка Дракон и кодогенератора в целевой язык? Сколько ещё нужно времени, чтобы создать формат обмена отладочной информацией между исполняемым кодом и редактором,а, по-сути, отладчиком для Дракона? Без этого Дракон так и будет игрой разума энтузиастов и темой студенческих работ.

Люди, которые создают редакторы, как показывает моё общение с ними, не работали в промышленности, не готовили документацию серьёзным заказчикам, поэтому не представляют, что нужно получить. У них просто нет такого опыта, хотя знаний достаточно для создания хорошего продукта. Грустно наблюдать, как хорошая задумка деградирует из-за, ИМХО, не правильного подхода к реализации.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Июнь, 2022 18:15 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5434
Откуда: Москва
tonyk писал(а):
Владимир Паронджанов: отсутствие текстового формата диаграммы языка Дракон приводит к тому, что идёт распыление сил и времени разработчиков.
Тоник, спасибо за замечание.
Вы хорошо знаете, что проблема отчасти решена с помощью концепции гибридных языков:
Дракон-Си
Дракон-Си#
Дракон-Java
Дракон-JavaScript
и т. д.

Я понимаю так. Разработать текстовый формат диаграммы языка Дракон — значит разработать новый язык программирования.
Это очень сложная задача. Я за нее не берусь.

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

Насчет практической работы. Алексей Муравицкий получил новый редактор (пробную версию), сделанный по его требованиям. Сейчас идет тестирование. Через месяц-другой он, надеюсь, об этом объявит. Посмотрим.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Июнь, 2022 07:56 

Зарегистрирован: Вторник, 27 Апрель, 2021 05:25
Сообщения: 14
Позволю себе вмешаться в дискуссию, потому что последнее сообщение критиковало экзистенциальную природу нашей созданной среды. Согласен с Владимиром Паронджановым, что tonyk требует создания целого нового языка программирования. И не простого, а золотого. Обращаюсь к его цитате:
tonyk писал(а):
Среда программирования на Драконе должна выдавать программу на Драконе.

Во-первых, так получится передавать программу между разными среда программирования.
<...>
Обязательно нужен формат обмена отладочной информацией между средой программирования и исполнения.
Обязательно нужны расширения языка для взаимодействия с оборудованием целевой платформы, например, обработчики прерываний, запись-чтение в регистры управления периферийными устройствами и т.п.

Я не совсем понимаю возможность передачи текста условного "Дракон-формата" в разные среды программирования. То есть одна программа "Дракон-формата" должна быть "хамелеоном" и запускаться и как Сишный файл в условном CodeBlocks, и как файл ".java" в Apache NetBeans? Возможно ли это теоретически? Разные языки искали решения именно этой проблемы "кроссплатформенности". И решение в виде гибридного языка программирования не уникально для ДРАКОНа (вспомните Jython).

tonyk писал(а):
Не заметил возможности написания фрагментов программы на языках низкого уровня, например, С/С++ или ассемблер. Да много чего нет, без чего эффективное использование Дракона вряд ли возможно.

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

В этом тезисе хотелось бы заметить, что гипотетически желаемого "хамелеона" можно организовать, если гибридный язык будет наиболее приближен к машинному коду. Возьмём например ассемблер. Я кажется видел, что кто-то ранее на форуме пытался сделать такой язык, но потом бесследно исчез.
Предположим, что иконы языка ДРАКОН будут скрывать за собой шаблоны некоторых ассемблерных вставок. Пользователь будет добавлять икону, за которым скрыт заранее прописанный фрагмент кода, подобно ИС ДРАКОН Геннадия Тышова. В таком случае возникают вопросы. Необходимо ли изменять арсенал икон языка ДРАКОН из-за такой привязки? Как реализовать зависимость ассемблера от архитектуры процессора? Предложить выбор пользователю? А если пользователь не знает?
Ну и это касаемо только низкоуровневых ЯП. Как быть, если разрабатывается веб-приложение на высокоуровневых языках программирования Python, Java, C#? Уж там-то зависимость от аппаратного обеспечения слабая. Не изучал подробно этот вопрос, но кажется в веб-приложениях нет универсального языка, который бы можно было использовать аналогично ассемблеру. То есть считаю появление языков ДРАКОН-Java, ДРАКОН-JavaScript и подобных полностью оправданным. Но, касательно ДРАКОН-Ассемблер, предполагаю, что нужен большой анализ потребностей пользователя/заказчика, нужно ПО для определения архитектуры процессора.
Конечно, было бы хорошо в будущем наводнить мир всего одной технологией, это бы решило много проблем. Но пока язык ДРАКОН можно назвать швейцарским ножом, который с помощью специалистов можно менять. Очевидно, что у ГРАФИТ-ФЛОКС и DrakonTech были разные сферы применения. Я к тому, что любое предприятие при желании с помощью специалистов может разработать собственный ДРАКОН для их собственной техники. Достаточно уточнить контекст и, допустим, икона "Формальные параметры" будет уже иметь более конкретный смысл.

может я неправильно понял тему, если что, прошу прощения


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 15:47 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 16
Alex_st_Tomsk писал(а):
Я не совсем понимаю возможность передачи текста условного "Дракон-формата" в разные среды программирования. То есть одна программа "Дракон-формата" должна быть "хамелеоном" и запускаться и как Сишный файл в условном CodeBlocks, и как файл ".java" в Apache NetBeans?

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

Насчёт исполнения тоже интересная ситуация. Как проверить правильность работы нарисованной Дракон-схемы? Сейчас- никак. Сравните со средами разработки для ПЛК, в которых всегда есть симулятор, поэтому даже без загрузки программы в реальный ПЛК можно проверить работу алгоритма. Я уже не говорю о том, что в симуляторе обязательно есть отладка, чем даже не пахнет в Драконе. Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.

Посмотрите на clang, именуемый в народе "шлангом". Программы на любых языках транслируются в промежуточное представление, которое хоть интерпретируй, хоть транслируй в машинный код целевого процессора.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 17:13 

Зарегистрирован: Вторник, 27 Апрель, 2021 05:25
Сообщения: 14
tonyk писал(а):
Каждый новый редактор Дракона хранит файлы в своём формате, поэтому для каждого нового редактора его автор создаёт свой формат. В итоге всё, что было создано ранее в других редакторах невозможно открыть в новом.

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

Я знал об ИС Дракон и "Фабуле", позже познакомился с DrakonHub и DrakonTech. Но мне изначально было дано задание: создать собственную "автономную" графическую среду программирования. Варианта совершенствования существующих даже не рассматривал. Может появится желание у случайных читателей этого форума. Но чтобы оно появилось, надо:
1. Признать недостатки среды, перечислить эти минусы
2. Выложить открытый код с внятным пояснением
3. При желании оставить свои контактные данные

Таким образом рано или поздно получится хорошая среда, соблюдающая все правила языка ДРАКОН, интерпретирующая схему в код на почти любом ЯП. Думаю, что в этом вопросе не будет кровавой погони за деньгами и славой, поэтому почему бы не сделать это (многоточие)

tonyk писал(а):
Насчёт исполнения тоже интересная ситуация. Как проверить правильность работы нарисованной Дракон-схемы? Сейчас- никак. Сравните со средами разработки для ПЛК, в которых всегда есть симулятор, поэтому даже без загрузки программы в реальный ПЛК можно проверить работу алгоритма. Я уже не говорю о том, что в симуляторе обязательно есть отладка, чем даже не пахнет в Драконе. Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.


Смотрел недавно вот это видео: https://www.youtube.com/watch?v=MFPqCqc ... rgeySmolov , в котором Владимира Даниловича спрашивают тоже самое. Как проверить правильность Дракон-схемы? Был ответ, что дракон-схема - это слепыш. Он не гарантирует правильность написания слов, не отслеживает контекст и прочее. А отладка дракон-схемы действительно относится к области фантастики и искусственного интеллекта. Тем не менее по этому поводу у нашего дуэта разработчиков была пара мыслей.
Возникала мысль встроить компилятор прямо в среду, а порядок исполнения отражать на подсветке ячеек дракон-схемы. Если в исполнении программы возникала ошибка, проводился анализ отчёта компилятора и относительно строки с ошибкой подсвечивалась проблемная икона. Из-за сроков и незначительного опыта разработки приложений мы даже не рассматривали внедрение компилятора. Всё осталось мыслями.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 18:10 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 99
Откуда: Киев
Владимир Паронджанов писал(а):
Я понимаю так. Разработать текстовый формат диаграммы языка Дракон — значит разработать новый язык программирования.
Это очень сложная задача. Я за нее не берусь.
Нет, создание текстового формата диаграмм не означает автоматического создания полного языка программирования. Язык может, и это даже желательно, задаваться модульно - язык выражений, язык операторов, язык типов, язык подпрограмм и т.д. ДРАКОН - это язык операторов и подпрограмм, и плоско-текстовое, как и любое другое представление программы на ДРАКОН будет задавать только эту часть. Как это может выглядеть, можно посмотреть в PlantUML (но нежелательно, чтобы он выглядел именно так).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 18:22 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 99
Откуда: Киев
tonyk писал(а):
Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.
С одной стороны ДРАКОН только декларируется таким, но решает лишь частные подзадачи вопроса, да и то не всегда лучшим образом. С другой стороны инструменты для создания надёжных программ не полагаются на интерактивную отладку, так как она показывает лишь частные случаи использования, а для надёжности необходимо размышления для всех случаев, что возможно лишь в формальном доказательстве, пусть и неполном или хотя бы в многочисленных тестах. Если свой собственный код нужно исследовать в пошаговом отладчике(что я такое сделал?), то ни о какой надёжности речи быть не может. Как-то заставить работать, конечно, помогает(~90% индустрии).

tonyk писал(а):
Посмотрите на clang, именуемый в народе "шлангом". Программы на любых языках транслируются в промежуточное представление, которое хоть интерпретируй, хоть транслируй в машинный код целевого процессора.
И обратите внимание, что это просто очередной собственный внутренний формат


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Июнь, 2022 18:32 

Зарегистрирован: Пятница, 01 Апрель, 2022 12:31
Сообщения: 16
Alex_st_Tomsk писал(а):
Насчёт формата, в таком случае, могу ответить, что это легко решить обыкновенной договорённостью между разработчиками.

Это должно быть явно прописано. Отсутствие текстового формата диаграммы- это слабое место Дракона.
Alex_st_Tomsk писал(а):
А отладка дракон-схемы действительно относится к области фантастики и искусственного интеллекта

Нет тут никакой фантастики и ИИ. Просто нужно кое-что немного детерминировать перед рисованием, и тогда Дракон можно будет транслировать в свой Дракон-код, который хоть интерпретируй, хоть транслируй в Си, Ява или иврит :))). В Инете есть несколько проектов рисования программ в виде блок-схем, которые транслируются в исполняемый код, а тут имеется супер-логичный графический язык, который невозможно перевести в исполняемый код? Парни, вы чё-то не догоняете... ;)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 19 Июнь, 2022 09:51 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5434
Откуда: Москва
Уважаемые коллеги!

Благодарю всех, кто принял участие в дискуссии.
Моя позиция такова.

1. Массовое применение языка программирования ДРАКОН возможно (в качестве гибридного языка).

2. Массовое применение языка программирования ДРАКОН произойдет в следующей области:
Цитата:
программируемые логические контроллеры;
— сенсорные программируемые контроллеры;
— сенсорные панельные контроллеры;
микроконтроллеры; см.
программируемые (интеллектуальные) реле;
робототехника; см.

3. Опытными специалистами по программированию ПЛК (программируемых логических контроллеров) являются:
— Алексей Муравицкий,
— tonyk.

4. Муравицкий и tonyk имеют разные точки зрения. Кто из них окажется прав, покажет время.

5. Муравицкий работает над созданием нового ДРАКОН-редактора, пригодного для эффективного программирования ПЛК.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 10 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2022, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB