DRAKON.SU

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

Да, назначение эмулировать работу физической. Теоретическая машина должна быть приближена к физической. Я использую усредненый вариант из своей отрасли. Физические входы и выходы назначаются пользователем и могут иметь какие то параметры при отладке программы.
Честно, забыл сюда включить интерфейсную часть, она тоже является глобальными переменными

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

а что не так? в параллельных процессах так и происходит. а в не параллельных - это не возможно.

Да все здорово . Но что есть параллельный процесс?

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

Но для Автора диаграммы это без разницы. Мы, например, используя "бинарные Паузы" и "Временные Вставки", вообще не паримся об этом. Ардуинка нигде не парализуется

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

Тогда нужен обработчик событий, я не прав Дмитрий?

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

Несколько параллельных процессов с висящими на этих процессах произвольными Синхронизаторами смогут обрабатывать события "только в путь".
Ну или в традиционной схематике: циклы ожидания

Кстати, того же эффекта можно добиться и с обычным Синхронизатором. Организуем несколько параллельных процессов, и устанавливаем там Синхронизаторы с запредельным временем срабатывания, с вызовом нужных диаграмм, и зацикленное на начало собственной ветки. При наступлении нужного события устанавливаем нужный таймер в текущее время, и Синхронизатор запускает целевой процесс. Затем время таймера опять ставим в запредельное положение, и так по кругу.

Хорошо есть обработчик.....
Тогда каждая ветка событие?

под событие можно выделить одну или более веток.

кстати, с параллельными ветками, зацикленными сами на себя, можно провернуть и такой вариант:

Сильно криво работают задачи, а дракон на сегодня не способен вообще работать с задачами. В дракон подпрограмму вставить проблемно! Не в ту ветку установишь и начинаются приключения, столько раз на этом ловился.

прогнозируемо, если не в ту ветку вставить, любой алгоритм неправильно будет работать

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

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

Дмитрий, а более подробно объясните что есть вставка? Как данные попадают в вставку ( в нутри вставке там другая схема со своими маршрутами и данными ? Видимость этих данных?)? Какой внешний вид приобретает вставка? По каким законом вставляется вставка в ту или иную ветку?

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

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

Проблемы организовать классическую вставку ("включение") в С++ нет (см. #include). Я не использую первый подход, у меня в генераторе Вставка - это вызов функции без параметров. Так можно лучше сэкономить место в памяти.

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

Да токой же подход вызов ФБ.
Сначало в ветвлениях обрабатываются аргументы. А потом в самом конце вызывается ФБ( но аргументы уже присвоены в зависимости от маршрутов течения алгоритма и входных условий ПЛК). Причем обработчик событий пишится для каждой конкретной конфигурации ПЛК и задачи этого ПЛК