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

Интересно – а чем нормальный язык отличается от ненормального? Может ненормаьлный язык не позволяет создать работающую программу? И что подразумевается под словом стабильность и почему она зависит от языка программирования?  Что означает гибкость для программы в контроллере и зачем она там нужна?

Теперь по статье. Статья конечно довольно язвительная и видно что автор находился в  упомянутой им «фазе цинизма». Однако в статье есть много нестыковок и по существу.

Первое что бросается в глаза – это что автор не совсем правильно понимает цели и задачи таких организаций как PLC Open и IEC, а действительные или мнимые недостатки конкретного продукта ISaGRAF почему то распространяются на сам стандарт IEC-1131-3 (сейчас он имеет номер IEC-61131-3). Основная же причина недовольства автора стандартом лежит в том, что он рассматривает стандарт «с точки зрения хорошего инженеринга», забывая что стандарт это не результат инженерного проекта по разработке языков программирования.

Автор видит в стандарте 3 проблемы:

Проблема 1.

Стандарт описывает устаревшие по мнению автора языки IL и LD, чем потакает ретроградам, двоешникам, и вообще «пользователям с определенными (и, увы, не лучшими) традициями».

Однако во первых стандарт никого не заставляет пользоваться этими языками (так же как стандарт по Ethernet, по прежнему содержащий раздел по сети 10Мбит/сек с топологией «шина», не заставляет вас тянуть коаксиальный кабель), а во вторых скажем язык LD по прежнему действительно очень популярен на дискретных производствах.

Язык ассемблера подобный IL неоправдан так как «интерпретатор означает невозможность создания ни быстродействующего, ни малого по объему кода».

Здесь следует отметить, что наличие интерпретатора это проблема ISaFRAF образца 98 года, а не стандарта. Там где на IL создан большой задел программного обеспечения, использование наработанных алгоритмов важнее чем абстрактная скорость (зачем выжимать время обработки цикла до 1 мсек, когда сам цикл составляет скажем 1 сек) . Для формирования быстрого кода, ассемблер IL может быть откомпилирован напрямую или через промежуточное преобразование в ассемблер целевой платформы, но стандарт этот вопрос не регулирует.

Проблема 2.

Возможные проблемы с переносимостью ПО на другую платформу если пользователь пишет процедуры на С.

Но стандарт не определяет в себе язык С, и эта проблема никакого отношения к стандарту не имеет. Если программист решит испрользовать дополнительные возможности каких нибудь инструментальных средств разработки (скажем язык С в ISaGRAF или Flowchart в ряде других систем), он сам должен позаботиться о переносимости (которая вобщем то в большинстве случаев и не требуется). Так же программист на Borland C сам решает пользоваться ему ассемблерными вставками через директиву «#pragma asm» или нет. Опять же автор почему то уверен, что без С не обойтись. Однако пример того же Ultralogik показывает, что программы, написанные скажем на том же FBD, не уступают по компактности и скорости программам написанным на С.

Проблема номер 3.

Отсутствие единого двоичного формата предсталения проектных лданных в различных системах программирования IEC-61131-3.

Но стандарт и не ставит своей целью определение этих двоичных форматов. Поэтому эти претензии никакого отнощения к стандарту не имеют. Например существует стандарт на условные графические обзначения электронных компонентов – он же не определяет двоичные форматы для хранения этих компонентов в различных САПРах. И ни один реально мыслящий человек не требует двоичной совместимости между скажем P-CAD и OrCAD. Другое дело, что желательна возможность переноса проектов из одной инструментальной системой в другую. В PLCOpen для этого ведется работа над универсальным форматом предсталения проектных данных на базе XML.

Довольно много места  в статье отводится графическим иллюстрациям на тему «заговора капиталистов», однако непонятно какое отношение это имеет к стандарту. Никакой «сверх-новой» технологии стандарт не предлагает и вообще предложение новых технологий к задачам стандартизации не относится. Очень странно звучат рассуждения о неудовлетворенных пользователях, как будто речь идет о потребительском рынке и выборе между Microsoft и Borland. В АСУ ТП со свободой выбора туговато. Никто не будет из-за неудовлетворенного программиста менять свой парк контроллеров Сименс (скорее программиста уволят).

Но самое главное что за 5 лет после статьи предсказанных автором апокалиптических событий не произошло. Стандарт здрарствует и развивается. Кстати в IEC появился еще один стандарт программирования на функциональных блоках с поддержкой событийной модели взаимодействия. Самым показательным подтверждением живучести стандарта является его широкое использование в так называемых Sopft PLC решениях на платформах, где действительно существует выбор «C или IEC-61131-3».

Я далек от мысли идеализировать языки 61131-3, но их востребованность определяется рядом причин, в том числе тем, что программируя на С программист должен сам заботиться о взаимодействии его программы с системным ПО (ОС или ядро реального времени, драйверы и т.п.) и хорошо его знать, а используя 61131-3 программист от этого слоя существенным образом изолирован. Это дает преимущества как программистам так и производителям контроллеров. Первые могут потратить больше времени на изучение технологии вместо изучения особенностей программирования на очередной платформе, а у вторых - развязаны руки на изменение в своих контроллерах как аппаратной платформы так и ядра РВ без затрагивания «интересов» пользователя.

С  Уважением,

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

На самом деле, UltraLogik, а точнее та версия FBD, которая в нем реализования, является "полным" языком. Т.е. языком на котором можно реализовать ЛЮБОЙ алгоритм. Более того, это КОМПИЛЯТОР, а не интерпретатор, и компилятор "прямой", т.е. в ассемблер данного процессора, а не "кросс Си-шный", как во многоих других МЭК-овских языках.

FBD - это отнюдь не "<сурагат>", а язык специально предназначенный для людей, мыслящих не "линейно", как обячно делают программисты на скриптах типа С, а для специалистов-технологов, профессионалов в области Теории Автоматического Управления. Таких людей, говорящих на "языке ТАУ", готовят в основном, все профильные ВУЗы по специальностям "Автоматика и Телемеханика", "АСУ" и проч. И это как раз тот "единый" язык, который они и учат. Причем, язык такой же международный, как и С.

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

Более, того, готов утверждать, что например, ПИД-регулятор, созданный и откомпилированный в UL будет работать в среднем в 1.5-2 раза быстрее, чем такая же система уравнений, "в лоб" написанная на С, (без использования ассемблера), а с использованием типовых библиотек вычислений с плавающей запятой.

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

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

Причем, как это не парадоксально, объем такого кода, несмотря на его линейность, все равно в большинстве случаев редко первышает 64 кБ, а простые проекты типа нескольних контуров управления с десятком переменных - вообше занимают обычно до 10 кБ.

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

Самый типичный вопрос и самая типичная ошибка пользователей UL с не-FBD-шным стилем мышления: в FBD нет стандартного "корня квадратного" - значит мне приходится использовать С. И что самое смешное - люди так и поступают... В результате добавляют С-шный блок с одной срочкой "SQRT" - и программа резко "пухнет" и начинает работать в два раза медленнее.

А человек с "системным" складом ума делает на FBD (из стандартных операторов умножения и сложения) блок типа "полином", на калькуляторе вычисляет коэффициенты, которые на заданном интервале (!) с заданной точностью (!) реализуют корень квадратный, и все! Этот блок, хоть и выглядит "сложнее", но компилируется в оптимальную светрку простых матемачитеских операций (команд процессора) и работает в разы(!) быстрее того же блока, написанного на С.

Таким образом, языки бывают разные, и создают их для решения разных задач. И если, например, написать игрушку типа "ТЕТРИС" тоже можно на UL, но это будет немного сложновато, и лучше все-таки делать это на С, то делать ПИД-регуляторы и сложные логичекие "автоматы" на С - заведомо более сложно, и само главное (!) менее производительно, чем на UltraLogik.

А уж к SCADA-системам UL не имеет совсем никакого отношения... И вообще, делать на SCADA-х какое либо "управление" многие эксперты небезосновательно считают совсем уж "ересью".

С уважением,

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

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

Тут говорилось о ПИД регуляторах на контроллерах но это частная задача, и однажды решив ее в любом языке вы примените ее многократно(это не аргумент).

Я повторюсь я согласен с вами со всеми, когда маленькая задачка с "вялой" реакцией на события, писать на С++ лень, можно и повашему.

Кстати о симантеках один из заказчиков ближнего зарубежья попросил сделать систему на них, ну я скажу очень дорого обошлась по сравнеию с тем что мы предлагали(не хочу чтоб меня обвинили в рекламе или анти рекламе), да и не очень понравился мне и Step7. Пугает неизвестность что он там откомпилит, как реагирует на события, повлиять я немогу, благо задачка была простенькая.

Насчет протоколов встроенных тут писали так это не достоинство а недостаток. Конечно я тут не чем себе помочь немогу, но мне очень не нравитсся маленькая скорость по RS-485 и протокол МОДБАС в преобразователях частоты для двигателей. Как правило говорят а зачем увеличивать больше 19200 для реакции самого преобразователя этого хватит,а если в этой цепи много устройств и все с модбасом да по 10 байт на команду канал забит. Я понимаю что можно использовать и другие порты, и мы так и делаем но этож неудобство.

Может я не знал, но тут недавно появился под Юникс снова язык АДА. Я непонимаю, зачем сейчас разрабатывать новые языки, если по свойствам современные языки похожи. Так и тут пример с С++, вы хотите сказать что другие языки какие онибы небыли изучать ненадо? Это пладит кучу разных специалистов каждого под свой контроллер. Это неправильно,  это маркетинговая политика производителей контроллеров и их продавцов, что бы выкачать деньги у покупателей.

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

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

Я конечно много чего не знаю, но это не мешало мне в свое время делать проекты по 15-20 тыс. строк на С.  Я опять же не вижу в этой конференции никакой огульной критики «нормальных» языков, просто одни предпочитают С, другие – Паскаль, третьи – FBD и каждый из них всегда объяснит почему он считает «свой» язык самым лучшим. Что касается маркетинга и навязывания ПО,  то я не припомню что бы Микрософт бесплатно раздавала свои системы разработки на С++. Может Вам они достались и бесплатно, но Микрософт (Borland и т.п.) продает их за вполне приличные деньги и интенсивно занимается их маркетингом. А в деле «навязывания» Микрософту нет равных (еле отбились от суда в США). И где Вы вообще видели производителя каких либо товаров, которые бы не хотели их продать?

Тут говорилось о ПИД регуляторах на контроллерах но это частная задача, и однажды решив ее в любом языке вы примените ее многократно(это не аргумент).

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

Частая ситуация когда на производстве один участок автоматизирован контроллерами Сименса, а другой скажем контроллерами Роквела. Начнем с того что ни там ни там нет системы программирования на С++. Даже если бы она была, программисту пришлось бы изучать разные библиотеки функций API к операционной системе, разные системы прерываний и т.п. Ну нельзя заставить Сименс и Роквел использовать одни и те же микропроцессоры и операционные системы. Поэтому задачей PLCOpen является хотя бы частичное облегчение жизни программистам путем унификации и стандартизации набора языков рекомендуемых для всех производителей контроллеров.

Я повторюсь я согласен с вами со всеми, когда маленькая задачка с "вялой" реакцией на события, писать на С++ лень, можно и повашему.

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

Что имеется в виду под «вялой»? Не знаю как в Ultralogik, но в типовом контроллере действительно время цикла менее 1 мсек обеспечить сложно. Однако число задач, где нужен более короткий цикл очень невелико.

Кстати о симантеках один из заказчиков ближнего зарубежья попросил сделать систему на них, ну я скажу очень дорого обошлась по сравнеию с тем что мы предлагали(не хочу чтоб меня обвинили в рекламе или анти рекламе), да и не очень понравился мне и Step7. Пугает неизвестность что он там откомпилит, как реагирует на события, повлиять я немогу, благо задачка была простенькая.

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

Тогда Вам надо переходить на ассемблер. Компилятор C так же генерирует наперед неизвестный двоичный код.

Насчет протоколов встроенных тут писали так это не достоинство а недостаток. Конечно я тут не чем себе помочь немогу, но мне очень не нравитсся маленькая скорость по RS-485 и протокол МОДБАС в преобразователях частоты для двигателей. Как правило говорят а зачем увеличивать больше 19200 для реакции самого преобразователя этого хватит,а если в этой цепи много устройств и все с модбасом да по 10 байт на команду канал забит. Я понимаю что можно использовать и другие порты, и мы так и делаем но этож неудобство.

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

Modbus – это логический протокол и он не связан со скоростью последовательного порта. В стандарте на RS-485 допускается максимальная скорость до 10 мбит/сек (серийно выпускаются адартеры со скоростями до 900кбит/сек). Если скорость ограничивается исполнительным устройством, то можно вместо топологии «шина» использовать топологию «звезда» (то есть многопортовые адаптеры), либо в топологии «шина» использовать адресуемые преобразователи RS-485 (например АДАМ-4521 от Адвантек), которые на шину с компьютером работают на максимальной скорости (допусим 115кбит/сек), а со стороны устройств работают на скорости устройств. Кроме того существуют шлюзы с нескольких портов RS-232/485 в Ethernet (АДАМ-4571, EDG-4504 и т.п.).

Может я не знал, но тут недавно появился под Юникс снова язык АДА. Я непонимаю, зачем сейчас разрабатывать новые языки, если по свойствам современные языки похожи. Так и тут пример с С++, вы хотите сказать что другие языки какие онибы небыли изучать ненадо?

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

Кстати, а почему Вы не изучаете Паскаль, Java, Vbasic, Forth или тот же язык АДА? Наверное потому, что не хотите впустую тратить свое время – ведь все Ваши задачи Вы можете решить с помощью С++, который Вы хорошо знаете. Так почему же Вы отказываете в праве другим специалистам не изучать С++, если они могут решить все свои задачи с помощью хорошо знакомого им языка из набора МЭК-61131?

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

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

У Вас же им не удалось ничего выкачать J. На то рынок и существует, что бы каждый делал выбор того или иного продукта исходя из своего опыта и поставленной задачи. Не считаете же Вы, что все, кто программирует контроллеры на языках МЭК-61131-3 являются недоучившимися безграмотными инженерами, и что только их врожденная лень и бестолковость мешает им изучить великолепный язык С++?

С Уважением

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

Нормальные языки, как раз, тут никто не критикует. Ни в C, ни в FBD нет совершенно ничего безумного. :) Критикуют людей, которые не умеют ими пользоваться :)

Здесь Вы, конечно, правы, только в большинстве систем разработки для контроллеров эту задачу и одного раза решать не надо :)

А что Вы скажете, если у Вас в системе 1000 дискретных сигналов? Вы будете описывать это на C++?

Как раз с контроллерами, мне кажется, больше ясности в этом случае. Это инструмент, специально заточенный под конкретные задачи. На универсальных языках нужно много чего писать, не относящегося к проблематике напрямую. Те же таймеры, прерывания, распараллеливание... У Сименса же все ясно, ничего самому придумывать не надо. А насчет того, что дороже он - это правда. За удобство тоже платить приходится.

Если мало, возьмите сеть побыстрее. Profibus, например. 12 Mбит, я надеюсь, хватит?

Повторюсь, вопрос опять упирается в эффективность. За универсальность и мощность C приходится расплачиваться, например, трудностями с отладкой. Не мне Вам объяснять, что бывает, если вместо && написать &, к примеру. Если появится более эффективное средство - почему бы на него не перейти?

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

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

Надеюсь, мы придем-таки к консенсусу:)