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

Наверное надо в шестнадцатый раз сказать, что
искать "хорошие" и "плохие" языки - глупость. :-)

Идет работа над тем, что я не понимаю... я такие вещи
всегда приветствую, только пока особых успехов в нашей
работе не видно...

Разве что, я узнал, что ST a la МЭК - это все же
структурный язык. Но пока не понял, зачем и кому это
нужно... :-)

Первоначально опубликовано Olej [QUOTE=Владимир Е. Зюбин] В этой ситуации более эффективным решением является программирование на Си, не смотря на все присущие этому подходу минусы. [QUOTE] Господа, ваш спор по 15-му кругу уже становится даже не смешным... Вы решили выяснить "хорошие" и "плохие" языки? Так об этом целые книжки написаны и всё давно решено... Да C "матлингвистически" ;-) - хороший язык (достаточно). Только тогда почему С? Есть ряд гораздо более приличных альтернатив, в том числе и для задач управления: начнём с С++, Modula-2 (кстати, "почти" Pascal), Oberon, и, наконец ADA. А любой язык, создаваемый для упрощенчества (для того, чтоб прикладник мог описывать хоть как-то свою область) - он всегда "убогий". См. на этот предмет Э.Дэйкстра (вы хоть кого-то за авторитеты считаете? ;-)) "Открытое письмо в IEEE" - где мэтр всерьёз предлагает "... квалифицировать обучение программированию на BASIC как уголовное преступление..." И всё равно будут находиться люди, работающие и на том, т на другом, и на третьем...

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

К чему аргументировать очевидные вещи?
Хотя, по-видимому, Ваша критика справедлива...
анализ текущего состояния в области средств описания
управляющих алгоритмов объектов автоматизации и
циркулирующих в среде специалистов мифологем показывает,
такие вещи, следует аргументировать...

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

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

Последнее так, промежду прочим, к основной теме не
относится, но тем не менее...

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

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

Ну что ж Ваше описание того, что должно быть, очень
близко к тому, что творится в языке Reflex. Разве что,
сделано это без привлечения средств ОС и на Си.

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

По-вашему, наверное, если компьютер "управляет другими фиговинами" - он уже не компьютер, а контроллер? Функционально-то может и так, но по здравому смыслу компьютер и контроллер - не совсем одно и то же.

Скажем, в Вашей системе лазерной резки, где все (?) управляется компьютером (персоналкой?), называть его контроллером - большая натяжка. Персоналка может этим управлять, но автоматически контроллером она от этого не станет, останется компьютером.

evgen Ну кто вам доктор, если вы сужаете область АСУТП до уровня ПЛК, а потом кричите "не могу" ?

Я разделяю компот и мух. Компьютер (в т.ч. используемый в АСУ ТП) программируйте на чем угодно, в т.ч. и на сях. Контроллер (т.е. ПЛК, или надежная "фиговина, которая занимается управлением других фиговин") предпочтительно программировать на МЭК-языках.

Посмотрев профили участников, выступающих в этом треде "за С и против МЭК", нетрудно убедиться, что все они используют не контроллеры, а компьютеры. Причины разные, у меня лично впечатление сложилось такое:

-- Система лазерной резки.
Вероятно, истоки надо искать в проектных решениях, принятых на ранних стадиях. Вероятно, стояла дилемма: или разделить систему на HMI и контроллер(ы), или поставить компьютер, который будет делать и то и другое "в одном флаконе". Последний вариант дешевле, на фоне российской экономической действительности n-летней давности он наверняка выглядел предпочтительнее. Вдобавок, система, хоть наверное и кормит, но есть "соцстрах" в виде РАН, которому в обмен надо давать "науку". А какая "наука" в классическом HMI+PLC варианте? Вот и стоит комп с OS/2, получился некий странноватый гибрид десктопа и реалтайма, но ведь работает же...

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

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

-- Установки гальванического покрытия
Этот случай принципиально другой, отличный от двух предыдущих. Судя по всему, здесь - классическая задача для ПЛК. Однако используется  "недо-ПЛК". Причина совершенно прозрачна, и многократно высказана: китайские "недо-ПЛК" гораздо дешевле, при этом достаточно надежны и доступны. "Достаточно надежны" - для конкретной (неответственной) задачи. Программировать их надо на С, дык, что за беда, невысокая зарплата программиста вполне компенсирует затянутые сроки разработки за счет использования С.

 

Я вот за себя отвечу. Работа по созданию
автоматизированной установки выращивания монокремния
была не НИРовская, а ОКРовская. В настоящее время эти
установки в модернизированном варианте выпускаются
партиями. Идут переговоры о поставке подобных установок
за рубеж. Язык Reflex, использованный при выполнении
договора - это отдельная разработка. А прежде, чем его
огульно критиковать и "вшивать" окружающим о
технологичности использования ассемблера, Паскаля и
прочих языков МЭК, настоятельно рекомендую почитать про
свойства языка в трудах "некому не нужных
конференций". :-)

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

Первоначально опубликовано Доктор Q [...] -- Система выращивания кристаллов Ситуация в чем-то очень похожая. Только вместо HMI, кажется, требовался какой-то специализированный блок. В отличие от предыдущего варианта, где есть хоть какой-то тираж и повторяемость, в данном случае, скорей всего, вообще не надо было работающее изделие сделать (специфика РАН). Что-то типа НИР с результатом в виде бумажного отчета  и несколькими "публикациями" в сборниках "трудов" никому не нужных конференций. Поэтому главный напор был сделан не на практическую пользу, а на "изобретение велосипеда" в виде самопального язычка, про который, похоже, в открытую рассказать-то даже стыдно. На мой взгляд, выглядит как типичная "совковая наука", человек набирал себе "галочек" на диссер.

Первоначально опубликовано Доктор Q По-вашему, наверное, если компьютер "управляет другими фиговинами" - он уже не компьютер, а контроллер? Функционально-то может и так, но по здравому смыслу компьютер и контроллер - не совсем одно и то же.

Вот здесь заключено то сакраменталное зерно, которое приводит к взаимному непониманию участников разговора на протяжении уже 29-ти страниц обсуждения :D.

Абсолютно так, как вы говорите, дело обстояло ещё 3-5-7 лет назад...

Первоначально опубликовано Доктор Q Скажем, в Вашей системе лазерной резки, где все (?) управляется компьютером (персоналкой?), называть его контроллером - большая натяжка. Персоналка может этим управлять, но автоматически контроллером она от этого не станет, останется компьютером.

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

Я когда-то начинал свою "разработческую" деятельность (это была моя 1-я работа) - в проекте первой в СССР системы автоматического управления пуском-остановом турбин АЭС, делавшимся Министерством Общего Машиностроения (кто знает - было такое весёлое место ;-)). Уже тогда "от мОлодежи" был альтернативный эскизный проект - на микроконтролерных секциях К589... но основной проект потянули на жёстко реализованной логике алгоритмов на К134 (чтоб представляли уровень интеграции). И сделали - такой контроллер в 2-х полноразмерных стойках. И это был удачный проект - потом, неоднократно делая новые версии "изделия" - его лет 15 продавали в экспортные контракты по строительству станций и поставке турбин. В том проекте я работал чисто как схемотехник, т.е. область эта мне ... если не "известна", то "была известна".

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

Последние несколько лет я делаю такое-же realtime ПО, но уже на другой основе: пром-PC под управлением OS QNX. Посмотрите номенклатуру оборудования хотя бы того же форм-фактора PC-104+ ... Например на том же сайте Prosoft (или "Ниеншанц Автоматик" - чтоб меня не обвинили в рекламе ;-)). Те же модели от Liperth (может я и неправильно написал, но смотреть лень и негде под рукой, а вы поймёте об чём речь).

Чем это не "контроллер" в привычном восприятии?: размер, конструктив, климатика... Почему не предпочтительнее применять такое изделие и на низовом уровне сбора и обработки данных? В плюсах:
- унифицированные средства разработки ПО, соответствующие стандарту POSIX;
- OS реального времени QNX, которая даёт вашему приложению базис API, составляющий до 50-70% процентов объёма по сравнению с автономным исполнением;
- отличная климатика применительно к к конечному изделию - если микросхема специализированного контроллера допускает 100g & -40...+85, то попробуйте ещё "вытянуть" эти характеристики на "обвязке", печатной плате и т.д.

Что в минусах? Только стоимость! Да и то:
- стоимость prom-PC оборудования стремительно падает, гораздо быстрее, чем универсального компьютерного оборудования, где уже произошло насыщение;
- в ряду тех же PC-104 можно подобрать вполне адекватные задаче образцы в пределах $150;
- в сравнении с $20-$50 это может и смущать попервах, но пересчитайте в конечное изделие: обвязка, работа схемотехника, конструктивы, печатные платы... сколько?
- и то, что почти никогда не считают в стоимость: разработка ПО на стандартах POSIX.
- но и это ещё не всё - а стоимость, сохранённая на рекламациях и авариях - когда ПО стоит на стандартизованном и предсказуемом в поведении фундаменте?

И я это описал не умозрительно - последние несколько работ выполнялись именно так: "лучше поставить N PC в промисполнении, от низового уровня до верхних". И показали продуктивность подхода.

[QUOTE=Доктор Q]

Я разделяю компот и мух. Компьютер (в т.ч. используемый в АСУ ТП) программируйте на чем угодно, в т.ч. и на сях. Контроллер (т.е. ПЛК, или надежная "фиговина, которая занимается управлением других фиговин") предпочтительно программировать на МЭК-языках.

[QUOTE]
Так что, может, не стоит всегда спешить так категорично "разделять компот и мух"?

А вот об предпочтительности ПО... Тут есть ещё один фактор: тиражность изделия.
- если делается достаточно тиражное изделие, то, наверное, при прочих равных, лучше поручить разработку ПО профессионалам именно этого дела: на С, С++, ADA ... чём хотите из числа "универсальных языков программирования" (вот эта "универсальность" - не пустое слово). Такая реализация по своим ТТД будет гарантированно выше.
- а вот если делается единичная или штучно-тиражная АСУТП... вот тут есть повод подумать об специализированных средствах типа МЭК - разработку осилят и менее "программисты", но специалисты, лучше понимающие технологическую сторону управляемых процессов.