Alexey_Donskoy писал(а): Владимир Ситников писал(а): от того, когда будет выполняться автомат не зависит способ его компиляции. В случае автономной программы паузу можно реализовать простым циклом ожидания, например. Хотя это и извращение, но теоретических препятствий нет.
Вы о том, что от среды выполнения может зависеть то, в какую именно форму должны компилироваться паузы?
Да, под Arduino паузы делаются одним образом (busywait, delay), под МЭК 61131 другим (запуском на следующем цикле ПЛК). Да, тут я полностью согласен.
Но это прямо что-то кардинально меняет?
По крайней мере, на "куда возвращаться" это никак не влияет.
По-моему, асинхронные автоматы (те, которые не ждут в цикле, а возвращают управление) хороши тем, что несколько таких автоматов можно выполнять "параллельно". Т.е. один общий цикл, который по очереди дёргает автоматы и крутится в цикле, если нужна задержка.
Синхронный автомат (который уже сам ждёт в циклах) в асинхронный превратить гораздо сложнее.
Поэтому:
1) Да, от среды исполнения может зависеть как именно реализуются паузы
2) Как автомат получит управление в следующий раз, он должен продолжить выполнение с места, где остановился. Либо продолжить паузу, либо сдвинуться дальше, если время прошло. Это, вроде как, не зависит ни от языка, ни от среды выполнения.
3) Вариант "автомат возвращает управление" универсален. Если уж очень нужны будут паузы в виде "тупых циклов" (Arduino?), то их тривиально можно прикрутить во внешнем вызывающем коде. При этом, в самой Дракон-схеме ничего меняться не будет.
4) Правила "возврата управления" должны быть явно видны из рисунка. Например, если уж решили, что "на паузах возврат управления", то это должно автоматически происходить. Не должно оставаться лазейки для ошибок типа "где-то там внутри иконы забыли написать return".
5) Более того, в генерируемом автомате должна генерироваться и защита от зацикливания. Иными словами, если он прокрутился более N циклов и не вернул управление, то что-то должно происходить. Например: возврат управления (вызывающая программа посмотрит, увидит зацикливание и, например, перезапустит), или передача управления в специальную ветку "обработки зацикливания".
Что именно должно быть маркером "возврата управления" вопрос наполовину решённый.
Почти наверняка паузы должны возвращать. Тут возражений не было, и были примеры, когда такое поведение упрощало понимание алгоритмов в Дракон-виде.
"Цикл ожидания" -- тоже должен. Но там нюанс: "цикл ожидания с нулевой задержкой" визуально невозможно отличить от repeat until (в котором не нужно возвращать управление на каждой итерации). Как поступать в этом случае -- неясно. Например, можно возвращать управление на любых обратных прыжках и каким-то образом (каким?) позволить пользователю указать "век_воли_невидать_это_repeat_until_цикл_быстрый_не_надо_возвращать_упраление" для случая, если реально сделан repeat until цикл в котором все итерации нужно сделать в рамках одного действия автомата.
|