Цитата Сообщение от Владимир Ситников Посмотреть сообщение
Да, сейчас для ПР программы можно составлять только через ...барабанная дробь... рисование схем.
Поймите же наконец, что смысл текущей темы и состоит в том, чтобы расширить эти границы. Кто-то по-прежнему будет рисовать схемы, а кто-то будет использовать и более удобные языки.

Вы хоть 100500 раз можете сказать, что "в ОЛ обязательно работа должна быть как с железом", но эти слова ничего не стоят.
Я предлагаю, что должна быть возможность создавать ОЛ макросы-программы и на нормальных языках. Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.). Я учитываю, что оба подхода должны будут как-то вместе сосуществовать (если делать по-нормальному, то никаких проблем не будет), и, опять же, там не потребуются космические вливания в разработку/поддержку/документирование ОЛ.
В результате получим контроллер с поддержкой МЭК языков и конским ценником.
"Конский ценник" поставит крест на нишевом применении ПР. Что я буду логарифмировать в конечном автомате, который работает на дискретных сигналах?
Онлайн-режим для этого намного полезнее.

Вот найдётся кто-то "идейный", который сделает "макрос автонастройки ПИД". Макрос возьмут и взорвётся объект. Вот здорово будет.... В ОЛ физически нет возможности сделать тест этого самого ПИД регулятора. Вручную что-ли на вход подавать "температуру печи" и щёлкать выполнение "одного цикла"? Тестировать нужно не один сценарий, а много. Тестировать нужно и ошибки датчиков. По-хорошему, при любой модификации алгоритма нужно заново всё перепроверять.
Нужно правильно оборудование подбирать соответственно выполняемой задаче.
А что-нибудь взорвать всегда помогут. В Чернобыле и Фукусиме с этой задачей справились на "отлично", несмотря на всю защитную автоматику.
Был уже один, который утверждал, что "в железе законы математики не действуют".
Это как?
Можете пояснить?