Перейти к содержанию
    

Язык Рефлекс - диалект Си для программирования ПЛК

Есть предложение - может Владимир Зюбин создаст на форуме отдельную ветку для обсуждения Рефлекса? У меня есть желание задать вопросы по языку.

 

Возражений нет. Для более подробного ознакомления можно посетить

http://reflex-language.narod.ru/

 

"Язык Рефлекс, известный также под именем "Си с процессами", ориентирован на программирование управляющих алгоритмов в промышленной автоматизации и робототехнике: для систем, предполагающих активное взаимодействие с внешней средой, технологическим оборудованием, физическими процессами через датчики и органы управления."

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вопросы такие:

1. История возникновения языка - год, автор, от кого произошел, ...

2. Users Manual на сам язык (по примеру на сайте можно понять, но тяжело :)

3. Кратко - 10 отличий от IEC61131. Как я понял - Рефлекс это полный аналог PDU-SFC-ST. Т.е. что нового даст мне Рефлекс, кроме русских букв в идентификаторах и возможности хранить код в CVS?

4. Как я могу "прикрутить" Рефлекс к своему контроллеру (система исполнения, компилятор, ...)

 

(можно ссылками, но лучше - коротенько здесь)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вопросы такие:

1. История возникновения языка - год, автор, от кого произошел, ...

 

Рефлекс - это развитие проекта СПАРМ (средство программирования алгоритмов работы

микроконтроллеров, авторы Зюбин В.Е., Карлсон Н.Н. 1988-1990 гг). Год создания настоящей

версии языка Рефлекс - 1998 (Зюбин В.Е. с участием Петухова А.Д., Данчина Д.Ю.). Год ее реализации

(создание транлятора) - 2002 год.

 

В основу языка Рефлекс легли идеи, почерпнутые из языков ЯРУС, Си, QuickStep, СПАРМ. Да, до СПАРМ был проходной вариант ЯРУС-П (ЯРУС на Паскале, 1985-86), не оконченный.

 

Так что генеалогия примерно такая:

 

(ЯРУС+Паскаль) -> ЯРУС-П (1986)

(ЯРУС-П+ЯРУС+Си) -> СПАРМ (1990)

СПАРМ + QuickStep -> Рефлекс (1998)

 

Разумеется, что оказывали влияние на Рефлекс и другие языки, те же языки МЭК 61131-3.

История использования:

 

- 1989-1992 - применялся при автоматизации электроавтоматики станков ЧПУ (СПАРМ,

адаптация на х86 + VME),

- 1994-97 - применялся для автоматизации установок выращивания монокремния методом

Чохральского 221УА100 (СПАРМ, адаптация на мультипроцессорной системе Intel 196 + Multibus)

- 2002-2005 - автоматизация установок выращивания монокремния методом Чохральского 221УМК090

(Рефлекс, адаптация MicroPC+UNIO)

 

 

2. Users Manual на сам язык (по примеру на сайте можно понять, но тяжело :)

 

Существует описание языка, в каком-то виде.

http://reflex-language.narod.ru/doc/index.html

 

Ну, а вообще планируется этот раздел расширять описанием трансляторов, библиотек для разных

платформ, проектов.

 

3. Кратко - 10 отличий от IEC61131. Как я понял - Рефлекс это полный аналог PDU-SFC-ST. Т.е. что нового даст мне Рефлекс, кроме русских букв в идентификаторах и возможности хранить код в CVS?

 

Ну в общем-то так, функционально язык покрывает SFC+ST. Ну и русскоязычность его один из

основных плюсов (впрочем, и англоязычность не исключается).

 

На мой взгляд основные преимущества языка Рефлекс (как языка):

1. Си-подобность = легкость изучения для Си-программистов, минимизация смешаноязыкового

программирования

2. Более удобные и надежные средства для управления потоками (SFC он ближе к сетям Петри со

всеми заморочками вокруг фишек, проблемой конвергенции потока управления и т.д.)

3. Однородность представления (чисто текстовый вид и все плюсы текстового представления:

потенциально высокая переносимость, модифицируемость текста и т.д.)

 

Ну, а плюсы текущей реализации языка (транслятора языка) таковы:

1. Полный контроль пользователя над исходными текстами, расширяемость,

2. Повышенная переносимость программ (адаптацию языка на платформе может делать пользователь),

3. Минимальные требования к целевой платформе... (шесть байтов на процесс, образы регистров УСО(~N*3), переменные, стек глубиной в два call-а без параметров)

 

Разумеется, при этом не исключается возможность и появление других вариантов реализации языка,

например, под интерпретационной моделью исполнения, с полновесными IDE и т.д.

 

4. Как я могу "прикрутить" Рефлекс к своему контроллеру (система исполнения, компилятор, ...)

(можно ссылками, но лучше - коротенько здесь)

 

Системы исполнения не требуется, на выходе получаются StandAlone приложения.

Разумеется, что не исключено исполнение под операционной системой.

 

Транслятор языка - по запросу, выходные файлы - на языке Си, со всеми вытекающими...

библиотеки открыты, системозависимых функций - от пяти до пятнадцати (зависит от случая).

В самом простом случае адаптация сводится к тому, чтобы:

а) организовать вызов функции Control() с заданной частотой,

б) написать функцию считывания байта/слова из модуля УСО,

в) написать функцию записи байта/слова в модуль УСО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...

1. Полный контроль пользователя над исходными текстами, расширяемость,

...

 

1. Извините, но какой контроль пользователя и над какими исходными текстами понимается?

2. Что понимается под расширяемостью языка?.

 

В моем понимании, язык расширяемый если его синтаксис и семантика могут изменятся

пользователем в сторону специализации.

Поправьте, если я не прав.

 

P.S. Что вы думаете о принципах предложенных в языке ДССП. ( http://forth.org.ru/~dssp )

( долгое время развиваемом в МГУ)

Изменено пользователем Kopa

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...

1. Полный контроль пользователя над исходными текстами, расширяемость,

...

 

1. Извините, но какой контроль пользователя и над какими исходными текстами понимается?

2. Что понимается под расширяемостью языка?.

 

В моем понимании, язык расширяемый если его синтаксис и семантика могут изменятся

пользователем в сторону специализации.

Поправьте, если я не прав.

 

Разговор шел про текущую реализацию языка, а не про сам язык.

Имелся ввиду контроль пользователя над всеми исходными текстами проекта (включая системные).

Под расширяемостью имелось ввиду не расширяемость языка, а функциональная расширяемость проекта (например, написание дополнительного отладчика и интеграция его в систему, или встроенная обработка исключительных ситуаций типа деления на нуль с диагностикой).

 

Ну, а синтаксис языка Рефлекс при этом, разумеется, сохраняется.

 

P.S. Что вы думаете о принципах предложенных в языке ДССП. ( http://forth.org.ru/~dssp )

( долгое время развиваемом в МГУ)

 

Если честно, то я не понял, что это за язык и в чем его проблемная ориентированность. В вопросах-ответах этого, к сожалению, нет. А вот что меня озадачило (см. FAQ), так это то, что первая версия ДССП на два порядка более производительная, чем пятая... впрочем, может, для ДССП это не главное.

В общем, принципов ДССП я не понял, поэтому, к сожалению, прокомментировать их не могу.

Изменено пользователем Владимир Е. Зюбин

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Существует описание языка, в каком-то виде.

http://reflex-language.narod.ru/doc/index.html

А почему нельзя сюда попасть с главной страницы?

 

За информацию - спасибо! пойду читать ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

P.S. Что вы думаете о принципах предложенных в языке ДССП. ( http://forth.org.ru/~dssp )

( долгое время развиваемом в МГУ)

 

Если честно, то я не понял, что это за язык и в чем его проблемная ориентированность. В вопросах-ответах этого, к сожалению, нет. А вот что меня озадачило (см. FAQ), так это то, что первая версия ДССП на два порядка более производительная, чем пятая... впрочем, может, для ДССП это не главное.

В общем, принципов ДССП я не понял, поэтому, к сожалению, прокомментировать их не могу.

 

Один из принципов - минимальный разрыв между системой команд языка и процессором

В идеале одна команда ЯВУ должна транслироваться в одну команду процессора.

 

Производительность версии, думаю, упала при усложнении внутренней организации рантайм

структуры языка ( может ООП навесили или что, то в этом роде )

 

Меня, в языке интересует наличие метапрограммирования, что из знакомства с Вашим языком

не видно.

 

Из плюсов Рефлекса - Язык покрывает часть возможностей предоставляемых операционной системой.

В этом плане, хотелось бы иметь возможность сопряжения языка с любой осью для МК.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Меня, в языке интересует наличие метапрограммирования, что из знакомства с Вашим языком

не видно.

 

Из плюсов Рефлекса - Язык покрывает часть возможностей предоставляемых операционной системой.

В этом плане, хотелось бы иметь возможность сопряжения языка с любой осью для МК.

 

Не совсем понятно, что Вы называете метапрограммированием. Как я понимаю - это создание средствами языка модификаций языка (а ля Лисп). В Рефлексе этого нет. Тут другая идея. Пользователь не язык конструирует, а описывает алгоритмы работы некой системы управления на языке очень похожем на Си. Это почти Си, но Си, расширенный понятием процесс. Вообще говоря, Рефлекс - это Си с процессами. Некая ортагональ к Си++ (который называли "Си с классами").

 

В Рефлексе (как языке) программа строится как иерархия процессов (логически параллельных потоков управления). И на основе такого подхода можно сконструировать произвольный процесс. Это основная идея языка Рефлекс, ну и его ориентация - это задачи автоматизации.

 

В текущей версии транслятора (не языка, а транслятора языка) выходные файлы после трансляции - это файлы на Си. Такой подход обеспечивает переносимость программ на произвольную платформу.

Реализация программ, написанных на языке Рефлекс (выходные файлы на Си), ориентирована на stand-alone исполнение (вообще без ОС). Так что проблем совместить ее с любой ОС и любым микроконтроллером нет. Реализация, что сделана у нами, ориентирована на минимизацию требований к ресурсам платформы, повышенную переносимость и открытость для сторонних пользователей (разработчиков и производителей микроконтроллеров). Разумеется при этом есть некие минусы (например, необходимость стороннего Си-компилятора).

 

Но в принципе реализация может быть другая. Разработчик контроллера может "заточить" Рефлекс под свою платформу (создать полноценную IDE, реализовать компилятор Рефлекса, или там байт-код, или интерпретатор, и т.д.). Это будет альтернативная реализация языка Рефлекс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Меня, в языке интересует наличие метапрограммирования, что из знакомства с Вашим языком

не видно.

 

Из плюсов Рефлекса - Язык покрывает часть возможностей предоставляемых операционной системой.

В этом плане, хотелось бы иметь возможность сопряжения языка с любой осью для МК.

 

Не совсем понятно, что Вы называете метапрограммированием. Как я понимаю - это создание средствами языка модификаций языка (а ля Лисп). В Рефлексе этого нет. Тут другая идея. Пользователь не язык конструирует, а описывает алгоритмы работы некой системы управления на языке очень похожем на Си. Это почти Си, но Си, расширенный понятием процесс. Вообще говоря, Рефлекс - это Си с процессами. Некая ортагональ к Си++ (который называли "Си с классами").

 

или (а ля Лисп) или что-то ( а ля Форт).

А решать задачу на низкоуровневых средствах, не имея возможности работать в терминах

предметной области мне не хочется. В этом случае сложность алгоритма при переходе

от одного уровня к другому линейна ( не упрощается). Работая с большим чужим С проектом

сложно, зачастую, отделять уровни абстракции.

 

[quote

 

Но в принципе реализация может быть другая. Разработчик контроллера может "заточить" Рефлекс под свою платформу (создать полноценную IDE, реализовать компилятор Рефлекса, или там байт-код, или интерпретатор, и т.д.). Это будет альтернативная реализация языка Рефлекс.

 

В этом случае для реализация операционных возможностей среды достаточно использовать

существующие компиляторы. Рефлекс в этом случае не поможет.

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

основе подключенного ini файла. Или мнемоники псевдоассемблера

Изменено пользователем Kopa

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не совсем понятно, что Вы называете метапрограммированием. Как я понимаю - это создание средствами языка модификаций языка (а ля Лисп). В Рефлексе этого нет. Тут другая идея. Пользователь не язык конструирует, а описывает алгоритмы работы некой системы управления на языке очень похожем на Си. Это почти Си, но Си, расширенный понятием процесс. Вообще говоря, Рефлекс - это Си с процессами. Некая ортагональ к Си++ (который называли "Си с классами").

А решать задачу на низкоуровневых средствах, не имея возможности работать в терминах

предметной области мне не хочется. В этом случае сложность алгоритма при переходе

от одного уровня к другому линейна ( не упрощается). Работая с большим чужим С проектом

сложно, зачастую, отделять уровни абстракции.

 

Вообще работать с чужими большими проектами сложно. Тут уж ничего не поделаешь. Нужна документация. Дополнительный уровень абстракции. Мы используем блок-схемы. Чтобы охватить проект с высоту птичьего полета. Ну и, зачастую, сами же ими и пользуемся.

 

Что же касается Рефлекса, то это очень высокоуровневый язык (удобный для использования человеком). Основной довод - при общении с заказчиком мы пользуемся исключительно его терминологией. Да и вся программа терминологически сооветствует автоматизируемому объекту.

И диалог с заказчиом конструктивный и продуктивность работы высокая.

 

Но в принципе реализация может быть другая. Разработчик контроллера может "заточить" Рефлекс под свою платформу (создать полноценную IDE, реализовать компилятор Рефлекса, или там байт-код, или интерпретатор, и т.д.). Это будет альтернативная реализация языка Рефлекс.

В этом случае для реализация операционных возможностей среды достаточно использовать

существующие компиляторы. Рефлекс в этом случае не поможет.

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

основе подключенного ini файла. Или мнемоники псевдоассемблера

 

Тут надо поставить точки над i. Рефлекс не предназначен для "реализации операциональных возможностей среды". Он не для этого разрабатывался. Цель его создания - комфортное описание алгоритмов управления промышленными объектами: станками, конвейерами, роботами, и всяким прочим технологическим оборудованием, типа: насосы, клапаны, двигатели, источники питания и т.д. и т.п.

 

При РЕАЛИЗАЦИИ языка (а реализаций может быть много) нами в качестве выходного формата был выбран язык Си. Основная причина такого решения - простота реализации:

Не нужно писать кодогенератор для целевой платформы. При этом гарантируется хорошая оптимизация по производительности, заведомо более высокая, чем через псевдоассемблер. Ну и по мелочам: удобство настройки на платформу, отсутствие дополнительных ран-тайм ядер, прозрачность.

 

Опять же повторюсь, возможны любые другие подходы при РЕАЛИЗАЦИИ языка, в частности, через байт-код или псевдоассемблер, но, к сожалению, у нас такой реализации нет. А идея интересная, типа ISaGRAF-подхода, правда, могут возникнуть проблемы с использованием на низкобюджетных контроллерах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как добавить Рефлекс в свой контроллер? Как Вы видите это процесс?

Т.е. хотелось бы что-то типа такого:

программа на Рефлексе -> compiler -> байт код.

На сайте только описание языка, а нужен компилятор генерирующий байт код.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как добавить Рефлекс в свой контроллер? Как Вы видите это процесс?

Т.е. хотелось бы что-то типа такого:

программа на Рефлексе -> compiler -> байт код.

На сайте только описание языка, а нужен компилятор генерирующий байт код.

 

для существующей и доступной реализации

схема создания программ на языке Рефлекс такая:

текст на Рефлексе -> 
               текст на Си->
                    Си-компилятор целевой платформы ->
                                                    + ---> исполняемый код
                      библиотеки целевой платформы --->

 

Т.е. в наличие есть только компилятор, генерирующий Си-код.

Описания его, к сожалению, нет. Только небольшой help по запуску без параметров.

Эдакий спартанский вариант. Как вариант (чисто теоретический, нужна проработка) можно встроить транслятор Рефлекс в препроцессор Си-транслятора целевой машины, тогда схема упрощается. (Для некоторых Си-трансляторов такая штука просто делается).

 

Насчет компилятора, генерирующего байт-код вопрос интересный, но, увы. :'(

Возможно, через некоторое время появится интерпретатор языка Рефлекс. Есть небольшая группа, которая исследует возможность адаптации Рефлекса на LinuxPLC.

Изменено пользователем Владимир Е. Зюбин

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Цель его создания - комфортное описание алгоритмов управления промышленными объектами: станками, конвейерами, роботами, и всяким прочим технологическим оборудованием, типа: насосы, клапаны, двигатели, источники питания и т.д. и т.п.

 

При РЕАЛИЗАЦИИ языка (а реализаций может быть много) нами в качестве выходного формата был выбран язык Си. Основная причина такого решения - простота реализации:

Не нужно писать кодогенератор для целевой платформы. При этом гарантируется хорошая оптимизация по производительности, заведомо более высокая, чем через псевдоассемблер. Ну и по мелочам: удобство настройки на платформу, отсутствие дополнительных ран-тайм ядер, прозрачность.

 

Не умоляя достоинств С программирования, в очередной раз попалась ссылка

на применение Форта для решения задач автоматизации http://www.forth.org.ru/~st/

( j,jheljdfybz на хлебокомбинате.)

 

Хотелось бы услышать мнение по этому поводу:) почему так происходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не умоляя достоинств С программирования, в очередной раз попалась ссылка

на применение Форта для решения задач автоматизации http://www.forth.org.ru/~st/

( j,jheljdfybz на хлебокомбинате.)

 

Хотелось бы услышать мнение по этому поводу:) почему так происходит.

 

Это может происходить, например, из-за того что человек привык писать на форте и ему сложно перейти на процедурный язык. А вообще, я лично с трудом представляю применение форта для автоматизации (управления). Что там за идеология, какая структура программы, какая стратегия управления... по ссылке этого, к сожалению, не видно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В документации сказано:

 

1. "2.5.4 Адрес регистра в модуле IO может быть в диапазоне от 0 до 2;"

Какой в этом смысл, если

"2.5.5 Адрес модуля IO может быть в диапазоне от 0 до 0xFFFFF"

 

2. "2.6.8 Возможны процессы, использующие пересекающиеся множества входных и выходных переменных."

Кто последним установит выход, т.е. как определяется последовательность выпонения процессов?

 

3. "2.7 - в состояниях нет возможности организации циклов и переходов"

Не совсем ясен смысл - 'for' и 'while' отсутствуют, или нет перехода сам в себя?

 

4. "2.11.5 Описание программы начинается с резервированного слова "Прогр""

А как задается точка входа (типа 'main')? Или нет главного процесса - все процессы стартуют вместе?

 

5. 'ТАКТ' един для всех процессов или каждому процессу можно назначить свой 'ТАКТ'?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...