Читаем между строк или как?Сообщение от Алексей Геннадьевич
Я же и говорю: никому не впилось программирование ПР на C.
Переводя с русского на русский: прошивка ПР от ОВЕН, а прикладной код на IL. Разумеется, в IL не должно быть возможностей прямого доступа к памяти/портам ввода-вывода, а только оговоренный перечень инструкций.
Безопасность кода сохраняется, и всё норм.
Тема "Модули расширения для ПР200" длится примерно эти самые 1-2 года и ничего.
Поэтому никуда за эти 1-2 года прогресс не сдвинется. Как есть сейчас ПР+ОЛ, так и останется. Как сейчас полезна возможность IL в ОЛ, так и через год-два никуда потребность не денется.
Ну, разве что конкуренты сделают.
Это минус.
Но тема располагается в разделе "Среда программирования OWEN Logic" и ждёт часа, когда на неё обратит внимание тот, кто разрабатывает ОЛ-ПР.
Вы бы для начала лог загрузки пары проектов, выложили. там И два входа на выход, ИЛИ два входа на выход. Может быть и понятней стало, как там загрузка происходит. А Овен это делать точно не будет, тогда ПР будут мешать продажи ПЛК. (и прибыль упадет 100%)
Dmitriy Murashov
SPS Software Engineer Automation Engineering RUS
Для начала бы сделал ,что сделал Сергей -автор FLprog .Вот где поле деятельности для программистов http://flprog.ru/forum/1...
электронщик до мозга костей и не только
Алексей Геннадьевич приводил пример, когда p-code ускорит выполнение ОЛ программ -- массивы:
Ещё один пример -- условные переходы. Сейчас ОЛ программа вся целиком выполняется, а с условным переходом можно пропускать ненужный на текущем этапе код.
Конечно, если "архитектура ПР-ОЛ" заключается в том, чтобы ОЛ было унылым, и ПР медленным, то да, действительно такая "архитектура" не позволит ничего сделать.
Неужели действительно архитектура ПР-ОЛ заточена под то, чтобы для ПР было невозможно программировать?
Под программировать я имею ввиду сделать макрос "ПИД с автонастройкой", "вычислить логарифм", "вычислить квадратный корень".
Русским языком же сказано - делайте макросы ,если будут хорошие и популярные разработчики встроят в код .Вот и возьмитесь сделать адаптивный ПИД регулятор на том что есть (один раз по мучайтесь ).В принципиальных электрических схемах нет условных переходов и не чего ...
Русским языком говорю: если нечего сказать -- мимо темы.
Полагаю, вы не понимаете, что макрос логарифма, написанный в ОЛ, и "нормальный макрос логарифма", который можно "встроить в код" это совершенно разные вещи.
Поэтому нужно понимать, что существование макроса "адаптивного ПИД" никак не поможет добавлению в ОЛ нормального "адаптивного ПИД". Его всё равно придётся переделать на нормальном языке программирования.
Должны же понимать, что ОЛ не на электрических схемах пишется?
Должны же понимать, что ПР не на электрических схемах работает? Да, да. Программа выполняется STM процессором, и ни о каких "электрических схемах" (нарисованных в ОЛ) этот процессор не думает.
У него есть набор инструкций и он по очереди их выполняет. Переходы у него есть. Как условные, так и безусловные.
Зачем же электрические схемы приплетать сюда?
К текущей теме схемы никак не относятся, а лишь намекают на неграмотность.
Да как вы не понимаете ,что речь идет о пользователях,а не процессорах ,для них работа в ОЛ должна быть как с железом .Козе понятно ,что все реализуется программно ,а значит последовательно.Поэтому без намеков говорю - Королева из вас не получится никогда ,в лучшем случае Эйнштейнили Прокурор.
И то что будет сделан ПИД в ОЛ не то же самое ,что реализация его в библиотеке ,то же всем понятно. Просто нужна реализация для понятия и отладки алгоритма ,а уж потом реализовать его на любом языке нет проблем .
Да, сейчас для ПР программы можно составлять только через ...барабанная дробь... рисование схем.
Поймите же наконец, что смысл текущей темы и состоит в том, чтобы расширить эти границы. Кто-то по-прежнему будет рисовать схемы, а кто-то будет использовать и более удобные языки.
Вы хоть 100500 раз можете сказать, что "в ОЛ обязательно работа должна быть как с железом", но эти слова ничего не стоят.
Я предлагаю, что должна быть возможность создавать ОЛ макросы-программы и на нормальных языках. Я приводил случаи, когда схемный подход крайне плох (автонастройка, логарифм, массивы, итеративные вычисления и т.п.). Я учитываю, что оба подхода должны будут как-то вместе сосуществовать (если делать по-нормальному, то никаких проблем не будет), и, опять же, там не потребуются космические вливания в разработку/поддержку/документирование ОЛ.
Не нужна. Отлаживать можно и нужно на любом нормальном языке программирования. Делать автонастройку через ОЛ схемы можно либо от безысходности (прямо нужно на ПР, а в ОЛ нормальных средств нет), либо из идейных соображений (кто-то любит кроссворды решать, а кто-то загогулины в ОЛ рисовать).
Если же нужен нормальный промышленный алгоритм (проверенный, рабочий, и т.п.), то делать его в ОЛ схемах подобно смерти.
Я уже много раз говорил, что ОЛ схемы не поддаются тестированию, и сейчас повторю: даже, если кто-то и сделает "макрос автонастройки ПИД", то его невозможно будет проверить. Вдруг через N часов работы там какая-нибудь ошибка окруления накопится? А вдруг он вразнос пойдёт?
Вот найдётся кто-то "идейный", который сделает "макрос автонастройки ПИД". Макрос возьмут и взорвётся объект. Вот здорово будет.... В ОЛ физически нет возможности сделать тест этого самого ПИД регулятора. Вручную что-ли на вход подавать "температуру печи" и щёлкать выполнение "одного цикла"? Тестировать нужно не один сценарий, а много. Тестировать нужно и ошибки датчиков. По-хорошему, при любой модификации алгоритма нужно заново всё перепроверять.
Был уже один, который утверждал, что "в железе законы математики не действуют". Так вот. Смоделировать автонастройку ПИД можно и нужно это делать без всяких мучений с ОЛ.
Более того, при моделировании на нормальном языке, можно сразу в модель подавать разные условия на вход, и сразу видеть как поведёт себя система.
В общем, rovki в руководители проекта разработки софта не годится.
В руководители "рисования схем" -- не исключаю. А к разработке софта (и руководству разработкой) уж точно допускать нельзя.
PS. Понятно, что тема никак не про обсуждение rovki. Тем не менее, некоторые проецируют "о, rovki, это тот, на чьих макросах 100500 проектов построено, значит он дело говорит, а Владимир Ситников никак понять не может". Поэтому и подчёркиваю, что опыт rovki в составлении схем никак не делает ему авторитета в текущей теме (которая больше про "доработку ОЛ" и про "управление проектами разработки софта")
Ваши права
