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

Небольшая ремарка ...

Сорокин:

>Прочтите внимательно, и осознайте, что никто не
>говорит, что переносимость - это плохо...

>>>>>>>>>>>>>>>>>>>

Вы так же читайте внимательно. Моя реплика относится
не к статье, а к Вашему предыдущему письму.

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

Так я и в предыдущем своем письме не говорю, что
переносимость это плохо! 8-)

>>>>>>>>>>>>>>>>>

 

>>>>>>>>>>>>>>>>>

Из этого следует, что раз «поумнение» связано с уменьшением разговоров о переносимости, то «подурнение» (а дурное не может быть хорошим) – с увеличением разговоров о переносимости. Возможно я Вас просто неверно понял.

 

 

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

>>>>>>>>>>>>>>>>>>

Нужно наверное просто уточнить, что Вы говорите о двоичной переносимости. Такой задачи при создании МЭК 61131-3 и не ставилось. Однако стандарт позволяет обеспечить переносимость первого уровня (на основе единых синтаксиса и семантики языков), а так же переносимость второго уровня для текстовых языков (на основе общепринятых способов хранения текстовых данных).

 

С Уважением,

 

Сергей Сорокин

Сергей Сорокин:
Из этого следует, что раз «поумнение» связано с уменьшением разговоров о
переносимости, то «подурнение» (а дурное не может быть
хорошим) – с увеличением разговоров о переносимости.
Возможно я Вас просто неверно понял.

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

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

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

Причем, понятно, касается это в основном графики...
(см. также статью)

По моему мнению спор о том что эффективнее C или МЭК, может продолжаться бесконечно. Особенно если его направлять в русло наносекунд.

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

1. Средства разработки на языках МЭК (типа IsaGraf, UltraLogic и т.д.) для инженеров-технологов создаются ПРОГРАММИСТАМИ на языках Си++, Паскаль и т.д. (ну не на FBD же писали UltraLogic). Создаются они для того, чтобы инженеры могли реализовывать свои задачи (как правильно было сказано "на понятных инженерам языках") не привлекая квалифицированных программистов.

2. Далее, наличие в средстве разработки на языках МЭК возможности писать на Си и Асме, определяется только амбициями и опытом программистов, создавших это средство разработки:

    а) Умные и амбициозные - Мы создали блоки FBD на все случаи жизни. Пишите на МЭК. И нам проблем меньше. (Сименс, AllenBredley. Причем как правило у них действительно блоки ну почти на все случаи жизни).

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

    в) Умные + проблем себе поменьше - Вариант б). Только ограничим ка мы им Си. Ну чтоб по памяти и прерываниям не лазили, а если вдруг какой-то блок не стандартный понадобится (тот же пример с корнем квадратным и других степеней), то пусть не бедняга инженер полиномы раскладывает и в FBD реализует, а попросит (наймет или сам вумный) знакомого программиста и он ему за -надцать минут напишет на Си блок под названием SQRT :-).

Вот и все. Надо просто знать свою специализацию и не лезть в области профессионализма других людей.

Да кстати, этот же спор можно переложить на Скада пакеты. Например, зачем нам ущербный VBA. Хотим писать на Си++. :-). А ответ все тот же.

Совершенно верно... есть типовые решения
для разных случаев жизни...

если система простая, не требует эффективности
при организации исполнения, не предъявляет
особых требований к надежности, допускает зависимость
от третьесторонних производителей ПО, то ISaGRAF
может и подойти...

Кстати, чтобы расставить все точки над е...
лично я не призываю программировать на Си.
Есть много языков четвертого поколения,
ориентированных на описание алгоритмов работы
систем управления... другое дело они не попали
в МЭК 61131-3... а то были бы не менее известны, чем
ассемблер IL... ;-)

Что касается МЭК 61131-3... наиболее продвинутым
средством является SFC+ST... только вот ST уж
больно Паскаль напоминает... надо всегда об этом
помнить, когда МЭК и Си противопоставляется... ;-)

Что же касается производителей, то во многих случаев
имеет смысл заказывать ПО у профессионалов... и уж
точно в бытовой массово выпускаемой продукции
(стир.машинах, микроволновках, пылесосах и т.п.)
логика пишется не на МЭК 61131-3... ;-)