Соцопрос: языки МЭК 61131-3.

Первоначально опубликовано _IP_ Первоначально опубликовано globus Наделять надо не языки МЭК а среду разработки. Как это? Можно по подробнее. Может быть не хорошо одну единственную среду наделять, надо неким образом вогнать это в стандарт, дабы была совместимость? Дабы долезть до железа, писать драйверы и т.п. нужна возможность обращаться к произвольным областям памяти (указатели), динамически выделять память, вызывать функции API операционки и др. Это же дополнительные функции (команды) в языках. Разве нет?

Речь идет не о стандартизации среды, а о наделением ее, как правильно заметил San, служебными средствами учитывающих особенности конкретной аппаратной системы . Т.е. чем больше будет знать среда о специфичном железе тем меньше тебе понадобиться прибегать к Си.

Скажите, каждый раз когда понадобится та или иная функция, обращаться на вашу фирму, чтоб её разработали ?  Или-же один раз и навсегда снабдить среду продуманным средством, чтобы я сам мог вызвать функцию из  WIN API !?  Как говориться - почуствуйте разницу !

Насчет частоты применения Си - Вы слишком утрировали, надобность в системных функциях гораздо реже, но очень необходима !

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

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

С уважением, SAN

Первоначально опубликовано sanwork Скажите, каждый раз когда понадобится та или иная функция, обращаться на вашу фирму, чтоб её разработали ?

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

Первоначально опубликовано sanwork Или-же один раз и навсегда снабдить среду продуманным средством, чтобы я сам мог вызвать функцию из  WIN API !?

Почему вдруг именно из Win а не из VxWorks или QNX? Очень многие ПЛК вообще не имеют внутри ОС. Каждый изготовитель контроллера волен использовать ту ОС, которую считает нужным. Он абсолютно элементарно может сам сделать для CoDeSys библиотеку для вызовов функций API ОС. Это вообще не проблема разработчика универсальной системы МЭК программирования.
Заметьте что в Си ситуация совершенно аналогичная. В самом языке и близко нет никаких команд ОС, это делается библиотеками.
Один большой вопрос в том, что данное средство вообще можно давать только очень продвинутым пользователям. Для его применения нужно иметь глубокие знания о внутреннем устройстве системы.  Иначе результаты могут быть не предсказуемы.

Первоначально опубликовано sanwork Насчет частоты применения Си - Вы слишком утрировали, надобность в системных функциях гораздо реже, но очень необходима !

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

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

Что за модель такая? Я такое предлагал? Где это было, что мы пили?
Доработать языки МЭК, так чтобы на них можно было писать драйверы – предлагал. Но это из другой оперы.

Первоначально опубликовано _IP_ Вы не могли бы пример привести такого средства? Что это? Некие конфигураторы, связанные с особенностями железа или специальные библиотеки?

CoDeSys, Isagraf Enhanced, Labview embedded (последний не МЭК язык)…
Вы же не пьете Пенталгин когда выбираете ту платформу под которую будете реализовывать проект. За Вас большинство операций делает среда. Возможность среды инкапсулировать в свой проект «чужой» код расширяет ее функциональность (гибкость) и позволяет использовать ее для решения широкого спектра задач. Вы же прекрасно понимаете и знаете что все охватить невозможно и у каждой железки или ОС есть свои тонкости. И если среда не будет предоставлять возможности инкапсуляции в себя того же Си то и цена ей будет соответствующая.

Первоначально опубликовано _IP_ Почему в Си программы никто не засовывает фрагменты Бейсике? Потому что язык самодостаточный. Давайте сделаем аналогично в МЭК и упростим себе жизнь.

А как же ассемблерные вставки?

Первоначально опубликовано s_smirnov Вот и договорились, самый самодостаточный язык это Ассемблер

Супер!

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

Однако, стратегически мы всячески стремимся к совместимости контроллеров. Одного из наших партнеров сейчас вынуждают платить огромные деньги за ремонтный модуль для ПЛК фирмы С., который снят с производства. Немудрящий контроллер, поменять бы его целиком. Сейчас полно контроллеров, которые не хуже и целиком в 8 раз (!!!) дешевле чем один этот чудо-модуль. Но! Это повлечет полную переделку всего прикладного ПО, что практически не реально (просто некому). Монополизм изготовителей ПЛК достал. Поэтому умные люди в новые работы закладывают контроллеры, которые программно совместимы с контроллерами других изготовителей. Таких примеров уже много. Есть системы (например автосборка),  в которых стоят контроллеры компаний ABB либо Beckhoff + SoftPLC на верхнем уровне +  панельные ПЛК Berghof (локальные пульты). Все соединено только стандартными сетями (Ethernet, CANopen). Все запрограммировано в CoDeSys. Все прикладное ПО переносимо. Никакой большой беды нет в том, если очередной заказчик попросит поставить контроллеры Wago. Стоит один раз попробовать насколько здорово иметь совместимые контроллеры, потом времена когда ставили все оборудование одной фирмы (с фирменным инструментальным ПО) вспоминается с ужасом. Совместимость ПЛК – это здорово.

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

Поэтому, повторяю вопрос: что есть в Си, чего недостает в МЭК? Дайте пример, типа алгоритм: if … else … for – в Си пишется легко, а МЭК ну никак. Нет рекурсии, нет динамического выделения памяти, указателей на функции. Все это можно обойти. Чего еще нет?

Один из пользователей CoDeSys (из США) предложил следующее: В МЭК есть функциональные блоки. Если нужно неким образом изменить поведение блока (например сбросить или задать параметры), то обязательно нужно приделывать дополнительные входы. Блок получается как ежик, что не красиво. Все входы надо постоянно анализировать, что не эффективно. В CoDeSys V2 есть действия в блоках (расширение стандарта МЭК) их очень здорово использовать для таких целей. Но хорошо бы добавить параметры в действия (как методы класса в ООП). Получится очень удобно. Отлично! Добавлено в V3. Очень многие //строковые комментарии просили – добавили.

Один умный человек (с ником SAN ) предложил одну полезную функцию в SoftMotion добавить – будет сделано.

Давайте креативно обсуждать недостатки МЭК языков. Сейчас удачный момент, вполне можем добавить то, чего в нем не достает. Есть идеи?