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

Первоначально опубликовано bessonov to Владимир Е. Зюбин: Ни кто не спорит, что язык С -- хороший язык. Для реализации сложных математических алгоритмов (например базе фильтра Калмана) язык С прекрасно подходит по сравнению с МЭК61131-3. Но не легко будет тому программеру, который попытается реализовать алгоритм работы релейной схемы в язык С. Напротив, на языках МЭК61131-3 эту задачу решить гораздо проще. Надо чётко понимать , что разные языки разработаны под разные типы задач.

никаких проблем. Хотя еще проще - использовать Си с классами (или C++ "с человеческим лицом" ;-) )
Можно даже пид-регулированием заниматься

Нет, Владимир :) Бензина я ни на кого не плескал. :))

По этому поводу могу предложить альтернативу.
Содайте новую тему под названием "Хоть Димка и салага, но в хлебало здесь за свой базар получит по-взрослому", и пусть себе ребята обсуждают , уверен что рейтинг этой темы побьёт все рекорды. :))

 

[чтобы попать в тему, надо кому-нибудь ответить?
на всякий случай отвечаю самому себе :)   ]

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

то есть не так, чтобы просто пошуметь и разойтись, оставшись при своих мнениях?

На самом деле, конечно, никакой альтернативы нет (должно быть и то, и другое),

однако у обоих вариантов на сегодня есть недостатки, которые хотелось бы .. не просто констатировать, а преодолеть.

Сначала о Си.Программирование на Си само по себе вовсе не требует высокой квалификации. Вычислительный алгоритм напишет на этом языке любой студент, это ничем не сложнее, чем на Бейсике, не говоря уж о structured text.
(и найти студента, знающего ST, намного сложнее). И отлаживать ВЫЧИСЛИТЕЛЬНЫЕ алгоритмы на Си не сложнее, чем на чем-либо другом. А уж вносить изменения в большие проекты на объектно-ориентированных языках (хотя бы и на С++), даже легче.

К сожалению для Си

1) часто недоступна или труднодоступна инфраструктура, обслуживающая мзковские языки, например, сетевая. Др. словами, если ты пишешь на Си, значит ты кульный хацкер, значит тебе ничего не стоит написать свой сетевой протокол и пощупать руками внешние устройства через прерывания, DMA и пр. Для этого ДЕЙСТВИТЕЛЬНО НУЖНА ВЫСОКАЯ КВАЛИФИКАЦИЯ. Но собственно язык здесь не виноват, просто пишущего на этом языке оставили без соответствующей поддержки. Так, может быть, надо просто предоставить эту поддержку?

2) в отличие от мэка, инфраструктура, даже если она есть, не стандартизирована, отсюда и проблемы с переносимостью.
В мэке определено однозначно понятие "вычислительной компоненты" (функциональный блок и программа), способы задания информационных потоков между ними (связывание программ с удаленными переменными), способы задания потоков управления (задачи, их приоритеты и периоды), конфигурации узла (ресурсы) и т.п. Для Си СТАНДАРТНОГО представления этих вещей не наблюдается.
Конечно, на C++ очень легко определить класс FunctionBlock, Task и т.д. Но каждый определит их по-разному, виртуальные функции назовет по-разному, и переносимости по исходным текстам не будет. Так, может быть, пора это как-то стандартизировать, в форма неких базовых классов или даже макросов?
Этакий Си (плюсплюсный) взгляд на мэковские понятия? Это сделать нетрудно, трудно договориться..

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

Теперь про мэковские языки. НА мой взгляд, они сильно неравноценны -некоторые из них, я согласен, просто пережиток (IL), некоторые - дань определенному историческому типу мышления (LD), а вот ФБД и Structured Textболее интересны. ST как будто самый гибкий из них, но.. трудно отделаться от вопроса: а зачем изобретать новый процедурный язык, когда есть масса хороших старых и новых - Си, Паскаль, Ада? Java и пр, и пр. Не проще ли, раз уж мы пишем на процедурном языке, писать, как здесь выражались , "на нормальном", и не изобретать специальный язык для пром. автоматизации? Такой "отраслевой" язык обречен на вечное отставание от мэйнстрима (ООП например, в мэках 61131 до сих пор нет), при том, что каких-либо принципиальных преимуществ по сравнению с ними он не дает.

Язык FBD, не смотря на его сегодняшнюю примитивность, по замыслу определенную ценность представляет как сдвиг в сторону большей декларативности программирования - то есть это язык, интуитивно основанный на идее вычислений, управляемых потоком данных. Однако (кроме технических ляпов типа jump-ов), он практически не масштабируем, то есть не позволяет структурировать крупные проекты. Казалось бы, можно инкапсулировать один блок в другой, создав компактное описание на верхнем уровне системы. Но нельзя инкапсулировать много связей в одну "сложную" - а значит, из "крупного" блока будут тянуться сотни информационных связей, которые придется соединять руками, что и сведет на нет всю простоту "укрупненной картины". Итак, основной недостаток ФБД для крупных проектов - это невозможность агрегировать элементарные связи в сложные, так же, как агрегировать простые блоки в сложную ФБД-диаграмму. Далее, этот язык не позволяет описывать массовые или повторяющиеся вычисления (здесь приводились примеры с обработкой массива сэмплов с какого-либо датчика) Я тоже считаю, что десятикратный Copy/Paste фрагмента диаграммы - это не метод программирования циклов :-).

Я ничего не говорю про ООП, то есть наследование, а также параметрический полиморфизм, которые также были бы уместны. Почему бы не унаследовать PID-регулятор от абстрактного регулятора, а адаптивный PID-регулятор от просто PID-регулятора? (я имею ввиду наследование ФБД-диаграмм?)

Но сама по себе идея ФБД, то есть задание графа информационных связей вместо графа управления, весьма продуктивна. И, поскольку в "мэйнстриме" таких языков нет, ФБД представляет определенную ценность даже в его нынешнем виде. Хотя идея далеко не нова, можно вспомнить, напимер, т.н. "вычислительные модели Тыугу", это, кажется, 1970й год (или 72й?), а также многочисленнные попытки создать машины, управляемые потоком данных.. . Но чего то сколько-нибудь распространенного, общепризнанного и, тем более, стандартного, нет, только вот Мэк стандартизовал... Есть, правда, еще 499й мэковский стандарт, но это как бы правильно поставленный вопрос и совершенной неудовлетворительное и громоздкое решение.

Конечно, лучше всего было бы придумать некие расширения языка ФБД, устраняющие указанные недостатки, и стандартизировать их. Но это нереально, поскольку часто не удается договориться и о более понятных вещах. Здесь возможен компромисс - создание некоего "мета-фбд" (пусть пока propreatory), который бы описывал систему в терминах потоков данных и при необходимости транслировался в стандартный ФБД как в своего рода ассемблер. Этот стандартный фбд в течение некотрого времени мог бы оставаться тем (пусть и примитивным) стандартным общим знаменателем. Между прочим, и в своем нынешнем виде вполне пригодном для многих не очень сложных проектов.

В общем, мне кажется, что Си (плюсплюс) с хорошо поддержанной инфраструктурой плюс ФБД и "мета-фбд" (плюс LD для ностальгирующих любителей катушек-релюшек) были бы вполне адекватным "букетом", покрывающим нужды достаточно большой части разработчиков АСУ ТП.

Хотя .. я понимаю, что для определенного типа алгоритмов требуется еще кое-что..

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

А то зацикливание на круге задач, очерченных мэком 61131, мне кажется, сужает тему. Хочется, чтобы дискуссия стала конструтивной и реально привела бы к улучшению ситуации, то есть к улучшению языков или средств программирования, появлению новых языков или средств, там, где это необходимо.
Нельзя просто молиться на мэк или на си - нет идеальных языков. Нужно улучшать
(или специализировать, в случае с Си, создавая библиотеки и классы) и то и другое, а может быть, в некоторых случаях, создавать нечто совершенно третье.

Я допускаю, что мои конкретные предложения относительно си и ФБД для кого-то

покажутся спорными. Но они не на пустом месте - проблема-то есть. Может быть, кто-то предложит другое решение или .. другую проблему. Собственно, языковая проблема возникает тогда, когда создатель программы замечает одно из двух:

1) (рутина) Написание кода (или рисование диаграммы) в определенных случаях требует большого количества рутинной работы, чреватой переутомлением и ошибками, в то время как смысл этой работы на словах можно объяснить достаточно коротко.

2) (недостаточная декларативность) Запрограммировать не так уж и сложно, но "принципиальные точки" программы зарываются куда-то в глубину функций и операторов (например, программирование конечного автомата с помощью
while(1){ switch(AutomataState){ case 1: ....} } ), а возможные ошибки оказываются семантическими и не отлавливаются компилятором (забыл break
в case).

Я бы предложил продолжить дискуссию (если у кого-то еще осталось такое желание) в несколько ином ключе, то есть обсудить языковые проблемы и соображения по их решению (может быть, подобное соображение окажется просто ссылкой на уже готовое решение, незнакомое некоторым в силу их невежества :).

Первоначально опубликовано Дмитрий Теркель Конечно, на C++ очень легко определить класс FunctionBlock, Task и т.д. Но каждый определит их по-разному, виртуальные функции назовет по-разному, и переносимости по исходным текстам не будет. Так, может быть, пора это как-то стандартизировать, в форма неких базовых классов или даже макросов?

И в результате мы получим нечто вроде "IEC-1131 для тех, кто пишет на C". А насколько это нужно?

Первоначально опубликовано Дмитрий Теркель Теперь про мэковские языки. НА мой взгляд, они сильно неравноценны -некоторые из них, я согласен, просто пережиток (IL), некоторые - дань определенному историческому типу мышления (LD)

Скорее, LD - это дань наглядности и удобству отладки. Если нужно выполнить большое количество операций "И", "ИЛИ", "НЕ" - то на LD это получается удобнее всего. Хотя для других целей он, конечно, малопригоден, поэтому его необходимо использовать в комплексе с другими языками.

Первоначально опубликовано Дмитрий Теркель а вот ФБД и Structured Textболее интересны. ST как будто самый гибкий из них, но.. трудно отделаться от вопроса: а зачем изобретать новый процедурный язык, когда есть масса хороших старых и новых - Си, Паскаль, Ада? Java и пр, и пр.

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

Первоначально опубликовано Дмитрий Теркель Такой "отраслевой" язык обречен на вечное отставание от мэйнстрима (ООП например, в мэках 61131 до сих пор нет), при том, что каких-либо принципиальных преимуществ по сравнению с ними он не дает.

А какие преимущества для задач автоматизации даст ООП? Инкапсуляция? В принципе, ФБ и есть объект, обладающий своим собственным состоянием... Наследование и полиморфизм? А настолько ли они нужны при решении задач достаточно узкой тематики?

Первоначально опубликовано Дмитрий Теркель Язык FBD, {...} Казалось бы, можно инкапсулировать один блок в другой, создав компактное описание на верхнем уровне системы. Но нельзя инкапсулировать много связей в одну "сложную" - а значит, из "крупного" блока будут тянуться сотни информационных связей, которые придется соединять руками, что и сведет на нет всю простоту "укрупненной картины".

Это не совсем так. Связи можно создать, ипользуя пользовательские типы данных. Если же этого сделать не удается - значит, неправильно само разбиение программы на функциональные блоки, или неправильно спроектированы информационные связи.

Первоначально опубликовано Дмитрий Теркель Далее, этот язык не позволяет описывать массовые или повторяющиеся вычисления (здесь приводились примеры с обработкой массива сэмплов с какого-либо датчика) Я тоже считаю, что десятикратный Copy/Paste фрагмента диаграммы - это не метод программирования циклов :-).

Вот именно для этого и придуман ST. Вообще, в МЭКовском стандарте каждый язык проблемно-ориентирован и ни в коей мере не претендует на универсальность. Потому что изначально не ставилось такой задачи.

Впрочем, десятикратный Copy / Paste  может дать лучшие результаты, чем цикл... если в цикле допущена ошибка и он получился бесконечным :)

Первоначально опубликовано Дмитрий Теркель Я ничего не говорю про ООП, то есть наследование, а также параметрический полиморфизм, которые также были бы уместны. Почему бы не унаследовать PID-регулятор от абстрактного регулятора, а адаптивный PID-регулятор от просто PID-регулятора? (я имею ввиду наследование ФБД-диаграмм?)

Поясните, пожалуйста, идею наследования диаграмм. Что-то я слабо себе это представляю... Или речь идет просто о вызове вложенного функционального блока?

Что же касается полиморфизма - его отсутствие у меня пока еще ни разу не вызвало трудностей... Так ли уж он необходим в промышленности?

Первоначально опубликовано Дмитрий Теркель Но сама по себе идея ФБД, то есть задание графа информационных связей вместо графа управления, весьма продуктивна. И, поскольку в "мэйнстриме" таких языков нет, ФБД представляет определенную ценность даже в его нынешнем виде. Хотя идея далеко не нова

Если мне память не изменяет, было некогда такое CASE-средство для Java, которое называлось "Java Studio"... В принципе, там использовалась та же идея.

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

Разве эта задача не решается с помощью SFC? Или имеется в виду нечто другое?

 

Дмитрий Милосер
Для начала найди мне датчик давления со скоростью ответа быстрее 100 мс :) И представь, что таких датчиков у тебя ...с тысячу. А теперь поуправляй с помощью них и 485-го интерфейса парой сотен клапанов, напиши программу на Си, а я посморю за какое время управишься ты. Мне для всего этого потребуется:

Вот я и говорю МЭК и подобные для простых задач, вы мыслите очень узко, датчиков давления может и нет, а у нас не только давление, расход, но движение кучи железа которым нужно управлять по скорости вовремя останавливать, и таких обьектов до шести, вот вам и время реакции.

Ну а ваша сообщение по поводу С++ и МЭК я даже не буду коментировать, замечания по каждому вопросу, видны не очень глубокие знания.

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

Давайте жить дружно и помагать друг другу, а не доказывать кто круче.