Всем привет! Отдельное спасибо Виктории за то, что дала мне ссылку на эту ветку.
С интересом просмотрел ветку, увидел для себя много интересно, старых знакомых и несколько вопросов по Рефлексу, на которые посчитал уместным ответить.
1.
Цитата("Evgeny_CD")
Но я не понимаю, зачем вообще городить огород Почему нельзя взять Python, LUA, RUBY, написать расширение под целевую задачу (эти языки просто по определению расширяемые) и наслаждаться реультатом? Процессы, нити в этих языках есть, сами языки, мягко говоря, помощнее всех этих мэков и рефлексов вместе взятых будут. Или виновата косность мышления?
Дело тут не в косности мышления, а в проблемной ориентированности. Вы можете настроить Си или Си++ под решение задач управления, но: 1) появляется дополнительная сложность, связанная с реализованной стратегией управления (которая не связана с базовым языком напрямую), б) появляются семантические "дырки", т.е. появляются ситуации, которые сематически корректы с точки зрения Си++, но ошибочны в рамках выбранной концепции. Например, решено определять состояния процесса (автомата) через константы (как это делается в реализации автоматов на Си, тем же проф. Шалыто в т.н. switch-технологии), а вот контролировать корректность употребления этих констант нет никакой возможности. Для Си/Си++ - это просто константы, в) в МЭК языках активно используется искусственныя метафоризация: посмотрите, например, на язык релейно-контактных схем - LD, с исторической точки зрения психологические преимущества этого языка очевидны (использование метафоры "реле"), но ввести такую метафоризацию в Ruby... увы, невозможно.
2.
Цитата("Andrew2000")
Рефлекс, как я понял, это еще один вариант SFC+ST.
(поправьте, если я не прав)
В некотором смысле это так. Рефлекс действительно и обладает свойствами алгоритмических языков (как и ST), и обеспечивает манипуляции с потоками управления (порождение, схлапывание, логический параллелизм), как SFC. Другое дело, логический параллелизм реализован в Рефлексе более изящно, чем в SFC. Например, в SFC конвергенция (схождение) параллельных потоков управления обеспечивается исключительно пользователем, сторонними средствами, флажками и т.д., а в Рефлексе это делается нативными средствами языка (есть операции проверки окончания выполнения потока управления (процесса)). Есть и еще некоторые плюсы, так что Рефлекс покрывает возможности SFC+ST.
3.
Цитата("Evgeny_CD")
Для меня так и остается загадкой, почему PLC'шники не использовали богатый мир скриптовых языков "в своих целях". Одна мысль есть - тот же Python "повзрослел" как раз в 98-99 годах, когда МЭК исполнилось 5 лет... LUA, RUBY еще более молодые языки.
Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:
1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);
2) цикличность исполнения алгоритма (управляющее воздействие-реакция объекта, и т.д. по циклу);
3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;
4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);
5) логический параллелизм исполнения, отражающий независимость и параллелизм процессов на технологическом объекте, активная работа с потоками управления, конвергенция, дивергенция и т.д.
К сожалению, ООП для этого класса задач просто не подходит.
Кстати, тому же LD из МЭК 61131-3 лет шестьдесят... он старее, чем Си и Питоны вместе взятые. Первые работы по нему - 40-е годы прошлого века. МЭК - это попытка стандартизации, причем, многие говорят, что при этом еще присутствовало и желание законсервировать текущее положение, т.е. конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...
4.
Цитата(Andrew2000)
На (=AK= @ Mar 6 2006, 14:42) "Зюбин - единственный, кто утверждает, что IL произошел от STEP5."
Ясно, спасибо за информацию.
На сайте Фиорда в презенташке нашел: "IL - Подобен SIEMENS (Step 5)"
т.е. наверное Step 5 подобен IL
Ремарка: =АК= не совсем прав, утверждая, что родство IL с STEP5 от Сименс это исключительно мои фантазии.
Разумеется, это не я придумал, а так заявляют многие наши зарубежные коллеги, например, глава "Steinhoff Automation" Armin Steinhoff. Это же утверждают и наши специалисты, и это видно по приведенной ссылке с сайта Фиорда. Хотя, возможно, мы все ошибаемся, указывая причины появления IL в стандарте МЭК61131-3.
5.
Цитата("(AlexandrY @ Mar 7 2006 @ 01:24) ")
Известный всем стандарт IEC61131-3 для PLC уже заменяется новым стандартом IEC61499 который сам определяет событийно управляемую модель поведения ...
Это не совсем так. МЭК61499 - это скорее событийная надстройка над МЭК61131-3. В настоящее время по крайней мере. Внутренности блоков программируются на МЭК61131-3. Сайт -
http://www.holobloc.com/ кстати, автор - небезызвестный Кристенсен, бывший глава МЭК 61131-3.
6.
Цитата("=AK=")
Зюбин только протяжно бредит, упиваясь собственным невежеством.
Ремарка: 1) Нельзя ли конкретизировать Ваше утверждение? Какие из моих утверждений, Вам кажутся бредовыми? 2) Нельзя ли представиться? Мне кажется, что Ваша анонимность мешает Вам вести конструктивный диалог... Например, об "общеизвестной простоте освоения LD и FBD", что, если быть кратким, - просто фикция.