DRAKON.SU

Язык ДРАКОН и важное заявление Владимира Ситникова (visi) о планах создания нового дракон-редактора


http://forum.easyelectronics.ru/viewtop ... 47#p475747 и далее

http://forum.easyelectronics.ru/viewtopic.php?f=13&t=8992&p=478358#p478358
Владимир Ситников, 30 ноя 2016, 19:30 Вы писали
Хотите показать свой Дракон?
Или расскажите, какие прилагали усилия?

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

В этом направлении я переложил одну из задач на тот подход, который мне видится перспективным и разумным (см viewtopic.php?f=78&t=6068&p=100413#p100412 ), но там всё ещё есть неоднозначные моменты. Поэтому считаю, что там нужно обсуждение (и, наверняка нужно рассмотреть ещё примеров).
Это самое обсуждение я начал как на этом форуме (предыдущая ссылка), так и на форуме ОВЕН ( http://www.owen.ru/forum/showthread.php?t=27487 ), где гораздо больше тех, кто используют ПЛК в реальных задачах.

О CoDeSys к http://www.owen.ru/forum/showthread.php ... post259607
смотрите
viewtopic.php?p=100410#p100410 , икону 19.

И?

Я знаю, что ИС Дракон может генерировать CoDeSys ST код.
Но вы сравните схему, которую пришлось делать А_МУР'у ( viewtopic.php?f=78&t=6068&start=20#p100336 ) и ту, как может выглядеть тот же алгоритм: viewtopic.php?f=78&t=6068&p=100413#p100412
Что скажете? Только не надо говорить, что схема А_МУР понятная.

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

Нашёл сообщение Alexey_Donskoy



И такое
Если я правильно понимаю, то Дракон обходит стороной вопрос того, "где объявляются переменные" и "как действия узнают над какими данными они работают".
Вообще говоря, да, это непростой вопрос. В моём примере про насосы есть такая же проблема. Действия "15 найти рабочий насос" и "23 подать команду на запуск насоса" связаны непойми как. Ну, можно, конечно, связать их через глобальные переменные (т.е. 15-е действие запишет номер найденного насоса, а 23е его оттуда прочтёт).

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

Это, конечно, печально.

Это конечно печально.
Вы все проблемы свалили в кучу.
Сюда же свалили чужие проблемы, том числе проблемы Alexey_Donskoy, который "не нашёл возможности выделить на это ресурсы".

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

На 1 вопрос Вам ответят, т.к. можно ответить кратко, даже не повторяя вопроса.
На кучу вопросов отвечать не будут, ну кто же захочет копаться в куче вопросов.

1. Сравнивать схемы Вашу и А_МУР по критерию понятности я не буду. Займитесь своей схемой.

Какой следующий вопрос?

Хотите быстро разобраться с ИС Драконом, обратитесь к Г. Тышову.

Я задал один и конкретный вопрос: "Но вы сравните схему... Что скажете?"
Это один мой вопрос, и адресован он вам.

Прямо совпадение: всё как вы учите.
Но почему-то вместо ответа предлагаете мне "заняться своей схемой".
Вопрос задан, он один, ответа нет.

"Займитесь своей схемой." - это и есть ответ.

И чем не с ней заниматься?

Задайте вопрос по своей схеме.

http://www.owen.ru/forum/showthread.php ... post259616

Ну да. Это чисто алгоритмический слой, который в сложных проектах сам по себе не имеет существенного значения.
Я бы даже сказал, имеет минимальное значение.
Потому что основные проблемы - в грамотном "размазывании" функциональности (с учётом ограничений), в адекватной инкспсуляции, в корректной работе с данными.

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

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

Если, к примеру, ран-тайм поддерживает многопоточность или хотя бы деление ТП по разным приоритетам, то, соответственно, каждый такой участок кода ОБЯЗАН быть отдельным примитивом с точкой входа НАЧАЛО и выхода КОНЕЦ.

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

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

Не пойму. Можете более детально? Или пример какой-нибудь?


Одна из моих целей в том, чтобы можно было использовать существующие runtime'ы. Те же ОВЕН ПЛК. Работают под управлением CoDeSys. Поменять runtime там без вариантов. Есть море автоматизаторов, которые программируют ПЛК, плюются от CoDeSys, но вариантов-то у них нет. С другой стороны, если компилировать Дракон-схемы в CoDeSys языки, то они смогут программировать на Драконе для существующих у них ПЛК. Это гораздо лучше, чем пытаться создать и выпустить новый "Дракон-совместимый ПЛК".


Ну я же приводил пример: в прикладной программе мы включаем насос, делаем паузу на 10 секунд, и постом смотрим появилось ли давление.
Разумеется, если просто так сделать "паузу на 10 секунд", то контроллер перезагрузится по строжевому таймеру. А Дракон без пауз для ПЛК не нужен.

Если приглядеться, то на сайте http://drakon-practic.ru/ есть ссылка "Одна из дракон-схем охранной сигнализации (.gif 44K)". И на этой схеме "циклы ожидания" помечены словом RTOS. Крайне и крайне похоже на то, что я говорю: возврат в ОС в чётко обозначенных местах схемы.


Говорил же: не поддерживается многопоточность.
Прикладной код будет выполняться до тех пор, пока самостоятельно не вернёт управление в runtime.
Если будет выполняться слишком долго (>5 секунд), то сработает строжевой таймер и перезагрузит ПЛК целиком.


В таком случае от Дракона почти не остаётся смысла. Видели схему А_МУР? Там же сплошь и рядом "код состояния=3", "запуск таймера", "проверка Q таймера".
С моей точки зрения, польза Дракон схем была бы как раз в том, что программист мог бы указать паузы, ожидания и т.п. "как ему видится", и чтобы не думать постоянно над тем, "а что же выполняем сейчас".


В сторону "уникальных" я пока не смотрю.

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

Кстати, почему? 15 лет назад это очень приличная система была - с тех пор что-то изменилось в худшую сторону?

По-моему, это очень нездоровая идея.
Это означает, что море людей, пытающихся программировать ПЛК, подходят к вопросу непрофессионально.
И здесь уже нет разницы, какой там язык на самом деле - дело в людях, а не в языке.

Заменить SFC Драконом - здоровая идея, потому что Дракон немного получше. Но только немного - ведь это всего лишь форма. Навскидку я не вижу ничего такого, что можно сделать на Драконе и нельзя на SFC.
А выбор формы - в значительной мере дело вкуса (и, главное, предыдущего опыта).

И ещё раз спрошу - какая разница?

Это справедливо для любого языка из стандарта (ну разве что LD так зациклить не получится ).

Вы уже и ответили!
Идеальных случаев не бывает; в любой системе программирования есть платформо-зависимые части (для вас ими стали пресловутые таймеры с паузами).
Вынести их в максимально абстрактный слой (чисто алгоритимческий) априори не всегда возможно.

Так кто мешает рантайм поменять?
Для CoDeSys это никаких проблем не представляет. Другой вопрос, нужно ли.

Для потребителя это разумно.
Но я - производитель 15 лет назад мы рассматривали и применение CoDeSys. Потом решили, что там слишком много того, что не нужно, и не хватает очень многого, что нужно.
Пришлось сделать свою систему программирования...

А по-простому?
Разумеется, я не на Драконе "IDE для программирования ПЛК" программирую.
Вы о том, что "нет смысла в Драконе, т.к. он в любом реальном проекте займёт не более 1%"?


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


И да и нет. С одной стороны, "не умеешь программировать" -- учись или не берись, но зачем вообще тогда нужно 61131, если есть C? Почему-то тяжело идёт освоение C у автоматизаторов.
Ну я и не предлагаю составлять программу целиком на Драконе. Скорее, в духе SFC, когда на SFC рисуется общая схема, а конкретные действия уже на каких-то 61131 языках.


Разница в чём? На ST, LD, CFC сделать "паузу в 10 секунд" непросто. Можно, но нужно объявлять всякие переменные (которые нельзя объявить по месту, даже одноразовые), и т.п.
На SFC, да, можно такое сделать, но SFC, визуально сложнее читается.


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


Ну, я со стороны смотрю. ОВЕН не предоставляет документацию по заливке самопальной прошивки на свои ПЛК. Вариант с CoDeSys'ом это вариант только с ним. Сейчас бета-тестируют вариант с прошивкой MasterScada.
В общем, когда есть имеющийся ПЛК, то в нём рантайм не особо поменяешь. Да и время нужно на написание.

Владимир, можно вам скооперироваться с А_МУРом.
Получилось так, что на форуме вы 2-е заинтересованы Драконом и CoDeSys.

Если двое, то я не ходок в Дракон.

Вы хотели быть пионером.
Ваши слова:

Нет, только о том, что применение инструмента должно быть оправданным.

Затем, что С - принципиальное зло. Даже при грамотном подходе разработка надёжных приложений на нём крайне затруднена.

А как вы думаете, почему в стандарт включены столь разные языки?
Очевидно, потому, что ни один из них не годится на все случаи жизни.
Скажем, большинство задач релейной защиты намного удобнее решается на FBD, какое-нибудь нетривиальное управление оборудованием - на ST. LD включили исторически, для поддержки старых кадров. И никого не знаю, кто бы работал на IL (и для чего его выгодно было бы применить).
SFC стоит здесь особняком. По своей сути он является ортогональным FBD - тот показывает поток данных, а этот - поток управления. Но для потока управления визуальный SFC не даёт принципиальных преимуществ перед текстовым ST. И зачем он тогда?
Комбинировать ST с SFC - это масло масляное. А выбирать между SFC и ST - во многом опять же дело вкуса. Предлагать же нечто третье из той же серии - ну если только это даст какие-то ОЧЕНЬ большие бонусы.
ИМХО, разумеется.
Сам я всегда ST выберу

Да никаких.

СCoDeSys'ом можно легко договориться (правда, это касается производителя, не потребителя. Тут производитель может быть против, потому как портированный рантайм - его собственность).

О, интересно!