Средство для программирования контроллера: Си или МЭК 61131?

Первоначально опубликовано Владимир Е. Зюбин Использование в качестве структурных элементов функций малоэффективно при создании алгоритмов работы сложных объектов автоматизации. Такой вид структуризации неадекватен задаче.

Как всегда, никаких фактов и примеров. Неадекватен и все. :))) Какие структурные элементы адекватны?

Первоначально опубликовано Владимир Е. Зюбин Не значит, что лучше, не значит, что хуже... "Распространен и популярен" - это качества, которые измеряются... а "лучше/хуже" - это лирика. Прочувствуйте разницу.

Лучше и хуже это суждения на основе объективных и/или субективных данных. Просто понятия "Лучше и хуже" более широкие и поэтому требуют уточнения. Метакачество. Объективно или субъективно оно вопрос к человеку его применяющему. Например самая первая цитата в данном сообщении. :))

Первоначально опубликовано Владимир Е. Зюбин Я думаю, многие компиляторы Си написаны на Си. Не исключаю, что некоторые из них, написаны на Си++. И уверен, что ни один здравомыслящий человек не станет делать этого на Паскале... ;-)

Первый компилятор на Си написан на АСМе. Это не ущемляет возможностей языка СИ? А вообще все компиляторы это машинные команды в исполняемом файле, кроме интерпритируемых языков.

Первоначально опубликовано Дмитрий Милосер Ага, вы сейчас договоритесь до того, что кто-то начнет утверждать, что Исаграф на МЭКовских языках написан Давайте уже придем к менению, что логичнее и производительнее всего писать средства разработки\драйвера\средства визуализации и программирования на Си, а алгоритмы управления тех процессом в большинстве случаев - на МЭК. Тогда и спор сам собой утрясется :)

ISaGRAF на СИ.
Драйвера и нижний уровень на СИ. Согласен.
Средства разработки. Си - компиляторы и нижний уровень. Интерфейсы легче, быстрее и качественнее в С Bilder или Delphi.
Алгоритмы управления тех процессом в большинстве случаев - на МЭК. Согласен.

Первоначально опубликовано Владимир Е. Зюбин Раземеется, ни ST, ни какой другой "МЭК-язык" не позволяет написать транслятор... Так что, время паниковать еще не пришло... :-)

МЭК не предназначен для трансляторов, он для управления тех процессом.

Первоначально опубликовано Владимир Е. Зюбин Но над этим фактом (Дельфи на Си++) есть смысл хорошенько подумать... ;-) а умные люди (к коим без ложной скромности я отношу и себя :-) уже давно над этим фактом размышляют... и кое-какие выводы уже наклевываются...

Повторяю компилятор Object Pascal написан на СИ, но компилятор не есть среда разработки.

Я слышал, что вы работаете в основном под дос на Си. Я думаю, что для доса это самый правильный выбор.

Первоначально опубликовано Olej Первоначально опубликовано VSerg О СИ. Возможность выполнить одну и ту же операцию несколькими способами уменьшает структурированность языка. Гы! (дальнейшие комментарии вообще могли бы быть не нужны). Откуда это вы достали, юноша, этот ... "перл", "откровение"...? Структурность ЯП - это, вообще-то говоря - формальный признак, формализация его (необходимые и достаточные условия) сделана в работах Хоара, Вирта ... прекрасно изложена, например, у Янга "Языки программирования реального времени"... Но уж никак не познаётся из трёпа на форумах - там всё что угодно напишут, вплоть до цитируемого выше... "определения". Но чем только и заинтересовал меня разговор в этой теме - это ж нужно столько страниц форума извести на спор: "структурный - не структурный"... И что ж это структурность вам такого даёт неоценимого? "Структурность" - только способ (один из!) достижения некоторой цели, и всё...

Да согласен. :) Взглянув со стороны, действительно перл. :)
Что дает структурность, как определение, то ничего особенного не дает. Меня он тоже заинтересовал своим объемом. Я работал с ISaGRAF и СТ и высказывания автора мягко говоря не корректны. Как и выяснилось, что в исходники CТ, автор скорее всего не заглядывал. :)

Mike_K  И просьба не обижайте вы С++ и ТСР/IP  работаем мы с ними не жалуемся

http://cliki.tunes.org/C%20language

C language The most common modern systems programming language to date, by Brian Kernighan and Dennis M. Ritchie (K&R). It's low-level, and the typing is rather weak. It was designed in the late '70s as a portable assembler for the PDP series (nominally compatible machines but with various word lengths), and it is still the state of the art in that area, although, as a systems programming language, it is more adapted to the PDP-11 than to modern architectures.

In the '80s, C (in our opinion wrongly) became the language of choice for general purpose programming. C offers absolutely no particular interest when cut from all its standard compilers and libraries, since you can no longer port existing software

http://en2.wikipedia.org/wiki/C_language

Although C is usually termed a high level language, it is only a "higher-level" language when compared to assembly language, and is significantly lower-level than most other programming languages.

 

Первоначально опубликовано Доктор Q C language The most common modern systems <A class=internal href="http://cliki.tunes.org/programming%20language" onmouseout="window.status='';" onmouseover="window.status='programming language'; return true">programming language</A> to date, by <A class=internal href="http://cliki.tunes.org/Brian%20Kernighan" onmouseout="window.status='';" onmouseover="window.status='Brian Kernighan'; return true">Brian Kernighan</A> and <A class=internal href="http://cliki.tunes.org/Dennis%20M.%20Ritchie" onmouseout="window.status='';" onmouseover="window.status='Dennis M. Ritchie'; return true">Dennis M. Ritchie</A> (K&R). It's <A class=internal href="http://cliki.tunes.org/low-level" onmouseout="window.status='';" onmouseover="window.status='low-level'; return true">low-level</A>, and the typing is rather weak. ...

А что? - если какая-нибудь глупость, сказанная "времён Очакова и покоренья Крыма", изложена латиницей - то это уже авторитет в завершающей инстанции?
"Тупые вы, тупые...".

 

[/QUOTE]

Первоначально опубликовано Владимир Е. Зюбин [QUOTE=VSerg] Использование в качестве структурных элементов функций малоэффективно при создании алгоритмов работы сложных объектов автоматизации. Такой вид структуризации неадекватен задаче.

Я отчасти с Вами согласен, несмотря на то, что Вы, как обычно, не снисходите до аргументации и уточнений ;) Попробую уточнить (как я это понимаю).

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

Что касается уровня 1, то мэк в лице ST обеспечивает удовлетворительный уровень структуризации (правда, тот же уровень можно обеспечить и любым другим современным процедурным языком :). Хотя для больших проектов отсутствие ООП может быть недостатком, но, в целом, дела не так уж плохи.

В качестве уровня 2) предлагается SFC. Вот здесь структурность действительно не на высоте. Сети Петри, может быть, хороши как модели поведения программы (они для этого и создавались), но совершенно непригодны для их НАПИСАНИЯ, поскольку охватить одним взглядом сеть и понять, что она корректно работает и делает то, что нужно, весьма проблематично. Я также не в восторге от идеи использования конечных автоматов, по той же самой причине. Конечный автомат - это программирование с goto. В "обычном" программировании от этого давно ушли (хотя программа, конечно, отображается на автомат, но не всякий автомат соответствует ХОРОШЕЙ СТРУКТУРНОЙ программе).

Поэтому на мой взгляд, естественнее было бы писАть управляющие выч. процессом алгоритмы .. на обычном языке, где структуризация сама по себе имеется. Единственно, эти алгоритмы должны выполняться совершенно в другом "реальном времени", чем алгоритмы 1-го уровня. Управляющая программа должна доходить до точки ветвления и приостанавливаться до тех пор, пока одно из условий ветвления не станет истинным. Входя в блок ({} в сишном смысле), она может активировать некоторое количество функциональных блоков 1-го уровня. Они будут работать в другом вемени - приодически, в другой нити (или нитях) ОС. Они будут автоматически деактивироваться при выходе управляющей программы из блока (то есть по "}" в сишном смысле), в котором они были активированы. Разумеется, перед выходом из блока управляющая программа также должна споткнуться на условии, и провисеть на нем некоторое время.
В общем, я достаточно хорошо представляю, как это можно было бы реализовать на C++ (если это кому-нибудь надо), разумеется, на многонитевой ОС. Кстати, на нижнем (1-м) уровне ФБД (в метафоричеком или даже прямом смысле) вполне может подойти. Управляющий алгоритм в этом случае занимается определением "активного" подграфа диаграммы. И метафора доктора насчет ленивых вычислений, возможно, также уместна, если ее понимать в смысле автоматического определения "активного" подграфа ФБД, который должен активироваться для обеспечения требуемого набора выходов (или обеспечения входов тех блоков, которое были активированы управляющим алгоритмом явно). Тем самым управляющая программа будет освобождена от подробного перечисления активных функциональных блоков.