DRAKON.SU

Выше в теме и был акцент на этом отличительном признаке, а также и последствиях...

Компактность — это хорошо.
Но для языка ДРАКОН важно другое — легкость ПОНИМАНИЯ, скорость ПОНИМАНИЯ.
Компактность может вступать в противоречие с этим главным требованием.

Это творческий эксперимент.
Некоторые экспериментальные новые иконы могут войти в состав языка ДРАКОН, а некоторые могут не войти.

Ответ может дать только время.
Время покажет, что некоторые новации выдержали испытания временем и завоевали поддержку пользователей.
А другие — нет.

Люди должны иметь право на эксперимент.
Но это не значит, что любая новация войдет в состав языка.

ДРАКОН уже сейчас очень сложен.
Есть опасность, что дополнительное усложнение может
оказаться невозможным.

Почему?
Потому что перегруженное судно может затонуть.
Об этом следует постоянно помнить.

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

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

Не имея режима исполнения схемы, наглядность дракона будет падать и падать!

Не помогут ни новые иконы, ни сокращение старых!

Это хорошая идея. Но ее надо пояснить.

Что вы предлагаете?

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

Что такое оживление иконы Вопрос?
Просьба пояснить

"Оживить икону" обозначает что икона является не только объектом содержащим текст и п-текст, но и в режиме исполнения схемы переключает маршрут в зависимости от значения вопроса в иконе .
Режим исполнения - в этом режиме редактирование схемы не доступно кроме икон коментариев.
В режиме исполнения дракон последовательно выполняет иконы группы " действие" и иконы группы "вопрос " .
Выполнять иконы - производить действия указанные пользователем для этой иконы
Например
1)присвоить имени Насос_1 значение ИСТИНА
2) А=в+с где в=3, с=1 результат выполнения А=4
3) вопрос А=4 ? Выполняем следующую икону

В ИС Дракон все это имеется.
Отображается (оживляется) маршрут выполнения. Маршрут переключается в зависимости от значения в иконе Вопрос. Значение иконы Вопрос визуализировано.

Да LKom имеется ручной вариат без учета данных в нутри иконы. Маршрут переключает сам пользователь и может его переключить как ему вздумается.
ТЕКСТ И П-ТЕКСТ К ПЕРЕКЛЮЧЕНИЮ МАРШРУТА ОТНОШЕНИЯ НЕ ИМЕЕТ!
Такой режим хорошо применять на конференциях но не более.
Отладку программы сделать не возможно особенно если вопросов в программе и вложенных подпрограммах великое множество, а действий над данными еще больше!

Дошло уже до того, что алгоритм, написанный другим человеком не совсем читаемый- например Алексей Донской создал алгоритм КЗР.
При возможности эмуляции - я думаю проблем с пониманием не возникло бы.
Я думаю следующее:
1) Все форумчане в том числе и разработчики Дракон редакторов -определенно ориентируются на теорию В.Паранджарова
Соответственно Владимиру Даниловичу необходимо, как это сделал Петр Первый - вводить стандартизацию (В 1712 г. вышел Указ Петра I о едином калибре пистолетов и ружей.)
2) Касаемо разработчиков Дракон редакторов - как говорил Зам по Технике 400 ОРВБ:
" Не бывает не откручиваемых гаек - есть механик, который не хочет их откручивать".
Этот афоризм жестко подходит под описание разработчиков Дракон редакторов.

Режим редактирования. Имеется в виду инструментальный компьютер. Правильно?

Режим исполнения. Какой компьютер имеется в виду?
Инструментальный компьютер?
Или ПЛК?

Просьба пояснить

Именно еще в Драконе и на компьютере
Разработка любого ПО заключается (по этапно)
1) режим редактирование - собственно создание алгоритмической программы
2) режим исполнения - проверка работы алгоритма, выявление недоработок
3) режим редактирования - исправление устранение доработка алгоритмической программы
4) режим исполнения - проверка работы алгоритма, выявление недоработок
и тд пункты 3 и 4 чередуются до получения удовлетворительного результата

после получения удовлетворительного результата можно компилировать и создавать EXE-файл, можно загружать в ПЛК и т.д и тому подобное

И можете себе представить - это придумал не я, ЭТО МИРОВАЯ ПРАКТИКА

Алексей, я понимаю вашу идею чуть-чуть иначе.
Режим исполнения — это исполнение EXE-файла в ПЛК.

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

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

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

Все зависит от качества реализации прогона.
Очень часто пишу программы для ПЛК без железа. Железо уже на объекте и установлено.
Т.е вся программа тестируется на компьютере еще до железа.
Сложнее всего приходится с блоками написанными в драконе.
Пробывал писать и главную программу в драконе но отсутствие эмулятора сказалось отрицательно.
Очень не наглядно.
Теперь блоки пишу в драконе, а главную программу собираю в КДС на языке CFC

Алексей, вы выполняете сложную работу — без права на ошибку.

А как работают ваши знакомые и коллеги?
Они тоже пишут программы для ПЛК без железа?
Потому что железо уже на объекте и установлено.

Честно за коллег не скажу.
Благодаря наличию в КДС и Овен лоджик режимов отладки а в КДС есть еще и виртуальный контроллер больша часть ПО разрабатывается без железа.
Для некоторых однотипных процессов есть отработанные подпрограммы которые не нуждаются в повторной проверке, они хранятся в виде библиотек.
Это такие подпрограммы как блок отопления , всяческие регуляторы и т.д
Программу для ПЛК начинаю писать ранее чем ПЛК пришел с завода.
Если что то сумущает в программе могу загнать ПЛК на стенд.
У меня есть насосный стенд, тепловой стенд, вентиляционый

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

Т.к ПЛК это стандартизированый продукт то у меня в наличии как правило есть весь модельный ряд Овен и даже такое оборудование которое Овен только анонсирует, что скоро появится в продаже, есть уже у меня на бетта тесте

Рассуждения с автором http://bortx.ru/ на предмет схожести и различия SFC с ДРАКОНом навели на размышления. Предлагаю обсудить очередную идею.

Всем знакомая Пауза используется в качестве задержки в исполнении алгоритма единственным способом: с указанием времени (см. рис.1)


Если рассматривать предельный случай, то минимальная пауза - пауза с нулевым значением времени ожидания (см.рис.2)


Думается, допустимо обозначить предельные значения паузы как ЛОЖЬ и ИСТИНА, понимаемая их как полное отсутствие задержки и бесконечную паузу (см.рис.3)


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


Использование Паузы с логическими аргументами возможно в мультипотоковых системах, хотя правая Иконка на рис.4. вполне пригодна и для однопоточных процессов.
Для однопоточных систем я полагаю хорошо подходит вариант алгоритма со Временной Вставкой, т.к. он позволяет влиять на результат аргумента Паузы (см.рис.5)


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

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