Возможность программирования на более низком, чем ОЛ схемы уровне

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

Ну а если писать всю программу на 1 ФБ (к чему тов. Ситников и продвигает свой продукт), т.к. сделать нормальную фрагментацию кода, как и планировалось на PRU это сложно, лучше всё впихнуть внутрь - число входов и вн. состояний зашкаливает и проверить все комбинации в принципе невозможно.

Владислав, тут я буду вынужден призвать модератора и обратить внимание на то, что текущая тема не имеет отношения к PRU.
Чего это вы постоянно скатываетесь на PRU?

Вспомните, что тут мы обсуждаем ПР и ОЛ.
Вспомнили?

Тогда вспомните, что я предлагаю создавать на p-code отдельные блоки и их использовать в финальной ОЛ программе.
Разумеется, при составлении p-code блоков будет удобно использовать имеющиеся ОЛ блоки, имеющиеся ОЛ макросы и другие p-code блоки.
Иными словами, я никого не призываю составлять ОЛ программу в виде одного единого ФБ. Ни в коей мере. Я за разделение кода на понятные фрагменты.


Поэтому сравнивать "простой SR триггер" и "суперсложный p-code блок" совершенно неправильно. Как вообще язык поворачивается сравнивать две совершенно разные вещи? Понятно, что на p-code можно сделать говнокод. Но говнокод можно сделать и в текущем ОЛ макросе. Значит ли это, что нужно срочно запрещать ОЛ макросы?
Правильно сравнивать "ОЛ макрос" и аналогичный по существу блок, написанный на p-code.
Например: "макрос вычисления синуса" и аналогичный "p-code вычисления синуса".

Если уж захотелось управлять ШД на ПР-ОЛ, то, милости прошу. Давайте сравним сложность составления ОЛ макроса для управления ШД (с разгоном, торможением, аварийным остановом и прочим). И сравним возможность протестировать этот самый "ШД макрос", написанный в ОЛ с макросом, написанным на p-code.

Что, ОЛ макрос для ШД это "Логика простая и понятная. Циклов нет, сложных переходов нет, отладка проста"? Едва ли.