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

Первоначально опубликовано Владимир Е. Зюбин 1. Никто на Паскаль не нападал. Критиковался его выбор в качестве базы для одного из языков МЭК-стандарта. Выбор в качестве основы Си выглядит куда более предпочтительным... и именно в силу специфики Си.

Я и не имел в виду "нападки", или не сумел сказать так как хотел: хотелось подчеркнуть различную целевую направленность этих языков.

Первоначально опубликовано Владимир Е. Зюбин Более того, не побоюсь высказать крайне дискуссионную мысль: факт использования Си как языка трансляции Паскаля говорит о том, что Паскаль это, скорее, уже умирающий язык. :-(

А здесь нет ничего "дикуссионного", и тем более "крайне"...
Конечно, Pascal, в том виде, как он сформулирован Н.Виртом - это не только умирающий, а уже умерший язык... А в том виде, в какой он трансформировался в Delphi или Kylix (как он, в чертях, пишется... ;-)) - так это просто "одоробло" (Чтоб потом не отвечать на возмущённые реплики адептов, сразу объясняю, почему "одоробло": потому, что язык - это органичная конструкция, в него нельзя произвольно наталкивать то, что понравилось "в другом месте" - именно так всегда развивался BASIC. В противном случае - язык эклектичный, и содержит в себе внутренние противоречия, которые вылезают в конкретных применениях. Так именно и случилось в Borland - это не моё утверждение, а Н.Вирта).

Так вот далее. Pascal, конечно, мёртвый язык. Ктати, у нас (назовём это СНГ) - он задержался дольше, чем в других местах, более популярен. На то есть причины:

- косность высшей школы, которая как заладила как "попка дурак" преподавание на Pascal в поздние 70-е, так и долдонит это дальше... (ведь проще долдонить заученный курс, чем учить новое, да ещё в бедственных условиях, в которых находится высшая школа).

- традиционная приверженность наших программистов Borland. Это началось ещё со времён DOS Borland C 3.1 - я сам на это долго "подсел". За рубежом Borland во многих регионах был почти неизвестен, тем временем, как у нас - используем повсеместно. А потом ... Delphi - и, по традиции, - восхваление, что "Borland это cool"... А на то, что действительно блестящая школа компиляторщиков Borland к тому времени ушла и делала TopSpeed Modula-2 - внимание не обратили, а к тому времени в Borland работали уже подёнщики..., которые гораздо лучше понимали рынок, но гораздо хуже - компиляторы.

Но утверждение "Pascal мёртв" ни в коей мере нельзя относить к Pascal языковой линии! Хотя бы одно то, что существует и активно развивается язык ADA, в том числе и free в GNU проекте GNAT... есть мощное русскоязычное сообщество GNAT. Плюс "виртовская" линия Modula - Oberon...

Первоначально опубликовано Владимир Е. Зюбин [QUOTE=Olej] [QUOTE=Владимир Е. Зюбин] Тезис, который я отстаивал: в силу специфики языка и предметной области для МЭК технически более грамотным было бы выбрать в качестве основы для ST - Си.

Разработчики МЭК 61131 тоже знали о языке С и С++, но по каким-то причинам выбрали ST(аля Паскаль). Будем же относиться к ним с уважением и примем на веру, что для этого были веские причины. Возможно например:
1. Паскаль в изучении проще, чем С
2. от крутых программеров слышал, что Паскаль (Delphi) очень удобен для БОЛЬШИХ поектов, т.к. программа на Паскале, в силу специфики компиляторов компилируется гораздо быстрее, чем программа на С и С++.

Какова же цель стандарта МЭК 61131?
Рискну сказать:
автоматизация БОЛЬШИНСТВА (т.е. не ВСЕХ) АСУ ТП,
с минимальными издержками, в т.ч.
обучение персонала за минимальное время, разработка и отладка алгоритмов за минимальное время.

Именно по этой причине в МЭК 61131 есть НЕСКОЛЬКО ПРОСТЫХ в изучении языков. Разные производители реализуют МЭК 61131 по разному -- в соответствии со своей коммерческой стратегией.

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

Если установки по выращиванию монокремния востребованы рынком, будем радоваться за тов. Зюбина. Будем надеятся, что вопрос о выращивании лопаток для реактивных двигателей тоже будет интересен и востребован соответствующими организациями.

Первоначально опубликовано bessonov Первоначально опубликовано Владимир Е. Зюбин Тезис, который я отстаивал: в силу специфики языка и предметной области для МЭК технически более грамотным было бы выбрать в качестве основы для ST - Си. Разработчики МЭК 61131 тоже знали о языке С и С++, но по каким-то причинам выбрали ST(аля Паскаль). Будем же относиться к ним с уважением и примем на веру, что для этого были веские причины. Возможно например: 1. Паскаль в изучении проще, чем С 2. от крутых программеров слышал, что Паскаль (Delphi) очень удобен для БОЛЬШИХ поектов, т.к. программа на Паскале, в силу специфики компиляторов компилируется гораздо быстрее, чем программа на С и С++.

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

Первоначально опубликовано bessonov Какова же цель стандарта МЭК 61131? Рискну сказать: автоматизация БОЛЬШИНСТВА (т.е. не ВСЕХ) АСУ ТП, с минимальными издержками, в т.ч. обучение персонала за минимальное время, разработка и отладка алгоритмов за минимальное время. Именно по этой причине в МЭК 61131 есть НЕСКОЛЬКО ПРОСТЫХ в изучении языков. Разные производители реализуют МЭК 61131 по разному -- в соответствии со своей коммерческой стратегией.

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

Если МЭК об этой проблеме молчит, то он не прав и его
нужно поправить... что и сделано в статье.

Первоначально опубликовано bessonov По выращиванию кристаллов. Не знаком с особенностими этого технологического процесса, но верю что всё очень сложно. Особенно в связи с тем, что в плане выращивания лопаток для мощных реактивных двигателей мы очень сильно отстали от запада. Аргументирую тем, что наши авиационные двигатели не проходят требования запада по шуму и экологичности. Этот факт общеизвестен. :( Если установки по выращиванию монокремния востребованы рынком, будем радоваться за тов. Зюбина. Будем надеятся, что вопрос о выращивании лопаток для реактивных двигателей тоже будет интересен и востребован соответствующими организациями.

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

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

Анализа не проводилось?
Ваш перл похож на чёрный юмор.

Первоначально опубликовано Владимир Е. Зюбин Я совершенно с Вами согласен... и постоянно повторяю, что МЭК-языки ориентированы на низкоквалифицированных пользователей и крайне простые алгоритмы. Может таких простых задач и большинство, но сложные задачи это тоже реальность. МЭК 61131-3 создает искусственный барьер между простыми и сложными задачами, а также между узкоспециализированными задачами.

Если вы не делали сложных проектов на МЭК 61131, то это не значит, что их ни кто не делает. Опрометчивое и не профессиональное утверждение.

Первоначально опубликовано Владимир Е. Зюбин Пока на черный юмор похож только МЭК 61131-3... :-) А если Вам известен такой анализ, то не переливайте из пустого в порожнее, а просто дайте на этот анализ ссылку. С интересом ознакомлюсь.

Разумеется я не знаком анализом.
Но если стандарт работает, то к чему голосовные утверждения?
ищите анализ на http://www.ieee.org

Если бы стандарт был не актуален, его ни кто бы не использовал :) и более того, ни кто бы не знал о существовании этого стандарта. Он был бы вытеснен другими реализациями.

Первоначально опубликовано Владимир Е. Зюбин Хотя, возможно Вы и правы, тема действительно непростая... начиная с вопроса, что такое "сложность"... :-))) Давайте, начнем с простого и будем программировать на LD включение клапана... а потом рассмотрим практические проблемы LD c фиксацией отказов, с повторным использованием, с модифицируемостью...

LD предназначен для замены уже реально работающих релейных схем на PLC контроллер.
Какие же тут проблемы?