ST, паузы, async/await/coroutines

[capzap]

Разумеется, разворачивать будет не КДС.

т.е. вместо привычной записи

res:=OwenFileOpenAsync('usb:test.dat','a',ADR(handle));
		IF res = ASYNC_DONE THEN
			(* выполняем дальнейшие действия по теме *)
		END_IF;

в КДС будет "портянка" кода, даже если она кем то протестирована

[Владимир Ситников]

т.е. вместо привычной записи

res:=OwenFileOpenAsync('usb:test.dat','a',ADR(handle));
		IF res = ASYNC_DONE THEN
			(* выполняем дальнейшие действия по теме *)
		END_IF;

Такая запись не подойдёт, ведь, вы что, на каждый цикл ПЛК будете заново открывать файл?

После того как он откроется его до закрытия открывать не нужно.
Иными словами, если мы начали файл писать, то открывать его ещё раз даже вредно.

[Владимир Ситников]

хочу вернутся на пару строк вверх

Наверняка что-то умное, но всё равно непонятное.

[Владимир Ситников]

так в кейсе можно шагать куда угодно

Можно, и что?

[Владимир Ситников]

так это и есть одна из основных фишек кейса

Ну, фишка, и что?
Вы о том, что "всё и так можно сделать на CASE'ах?

Наверняка же понимаете, что "делить CASE состояния вручную" тяжелее и менее надёжно.

[Владимир Ситников]

Не. Вы выделяете часть задач делаемых на автоматах для другого редактора ?

Почему часть? Можно и все задачи в другой редактор перенести.

Вон, например, ПЛК110 + MasterScada4D. Там вообще КДС нет. И, ничего.

[Владимир Ситников]

А зачем там ST с кейсом оставили ?

В 4D?
Так в стандарте есть CASE, вот и оставили. Какие с ним проблемы?

Я же не говорю, что нужно срочно все CASE'ы переписать на паузы. Я говорю, что ПАУЗА и встраивание асинхронных ФБ в сам компилятор может сильно упростить понимание, поддержку и написание кода.

[Владимир Ситников]

Обычное начало потокофилов ))

Снова какие-то странные комментарии.

[Владимир Ситников]

Просто эквивалент tthread'а с блокирующими операциями. Но к ним тогда нужны человечьи события, а их тут нету.

Снова мимо кассы?

"события", "state machine" это, да, может требоваться одновременно с асинхронным выполнением, но это не исключающие, а дополняющие друг друга штуки.

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

"обработка сетевого протокола" -- тут, возможно, поинтереснее. И, вполне возможно, что тут нужна комбинация автомата (ну, обычного) и асинхронщины.

Как вариант, можно сделать "полноценную библиотеку modbus" и посмотреть потребуются ли там "события" или нет.

[Владимир Ситников]

Где ? Вы это и пытаетесь с самого начала предложить. Пост #35 - просто классический вариант из статей на тему "а потоке это все проще .."

Тут я вас поправлю: пост 35 называется "а в императивном духе гораздо проще".
К потокам он не имеет отношения, т.к. я с самого начала заявлял, что код не будет "блокироваться".

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

Я же говорю про async/await/coroutines/fibers -- когда "сама работа делится на небольшие кусочки и выполняется понемногу".
Смысл не в том, чтобы "с помощью какой-то матери создать поток в КДС", а в том, чтобы "составлять программу в обычном императивном стиле, а компилятор при этом подменял код на автомат, прерывающийся и продолжающий работать оттуда, где закончил".

Да, грубо (ну, очень грубо) можно это назвать потоками, но это называется fiber, coroutine и т.п.