Средство для программирования контроллера: Си или МЭК 61131?
Указатели великая вещь, только они никак не связаны с архитектурой целевой платформы.
Если хотите опровергнуть тезис, приведите операцию Си,
которая зависит от архитектуры выч.платформы. Скажем,
для 32-х разрядного Пентиум и 8-ми разрядного 8080.
Можно, конечно, ссылаться на различие длины int, но это
вопрос традиции, а не архитектуры.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Язык Си всегда является языком высокого уровня, т.е. языком, не связанным с архитектурой вычислительной
платформы.
А вот здесь я позволю себе встать на защиту C. Если бы он был языком высокого уровня, вроде Паскаля или Ада, он никому бы не был нужен. Прелесть C как раз и состоит в том, что он обеспечивает некоторый уровень переносимости, оставаясь при том хорошим средством для взаимодействия с оборудованием. Более того, если языки, подобные Паскалю, оперируют с абстракциями, реализацию которых оставляя разработчикам компилятора, то C не просто делает возможным, но даже и поощряет использование аппаратных особенностей конкретной системы. Далеко за примером ходить не надо - использование указателей в C позволяет вытворять такое, что в принципе не возможно при использовании большинства языков высокого уровня.
1. Никто на Паскаль не нападал. Критиковался его выбор в
качестве базы для одного из языков МЭК-стандарта. Выбор
в качестве основы Си выглядит куда более
предпочтительным... и именно в силу специфики Си.
Позволю себе не согласиться. Дать пользователю в распоряжение язык относительно низкого уровня - это противоречит самой идее PLC: скрыть от пользователя детали внутренней реализации, предоставляя ему лишь средства для решения его прикладной задачи.
Вы прежде чем не соглашаться, читали бы лучше
внимательно. Разговор идет не о Си, а о языке
на базе Си. Прочувствуйте разницу. Также и в сам МЭК
61131.3 посмотрите внимательно. На тот же IL.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Более того, не побоюсь высказать крайне
дискуссионную мысль: факт использования Си как языка
трансляции Паскаля говорит о том, что Паскаль это,
скорее, уже умирающий язык. :-(
Бог с ним, с Паскалем - это просто пример языка высокого уровня, но мысль, действительно, более чем спорна. На мой взгляд, наоборот, этот факт лишь подтверждает правило, что транслятор языка более высокого уровня пишется на языках более низкого уровня. Просто потому, что это удобнее.
Да, а теперь на базе этой с потолка взятой идеи
поясните, почему это десять лет назад трансляторы Паскаля
на Паскале писались... ;-)
МЭК-языки ориентированы на низкоквалифицированных пользователей и крайне простые алгоритмы. Может таких простых задач и большинство, но сложные задачи это тоже реальность. МЭК 61131-3 создает искусственный барьер между простыми и сложными задачами, а также между узкоспециализированными задачами.
Если МЭК об этой проблеме молчит, то он не прав и его
нужно поправить... что и сделано в статье.
Еще раз по поводу сложности задач. Мне совершенно понятно стремление программиста, реализовавшего некий достаточно навороченный вычислительный алгоритм, называть простой задачей, к примеру, автоматизацию фабрики по производству жевательной резинки. Несмотря на то, что дальше многочисленных AND, OR, IF и огромного
количества промежуточных переменных здесь программистской мысли негде развернуться, задача от этого проще не становится. Это гарантированные несколько месяцев кропотливой работы. Именно для таких задач и предназначены языки типа LD/FBD/CFC.
Автоматизация фабрики по производству жевательной
резинки задача несомненно сложная. В такой постановке
это типичная АСУ, а может быть и не одна АСУ, а две.
Чтобы узнать, что за АСУ стоит, кроме релейных схем -
рекомендую посмотреть ГОСТы 24.ХХХ.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Мы занимаемся выращиванием монокристаллов кремния методом Чохральского.
Наслышан об этом методе. Совершенно искренне, мне будет крайне интересно прочесть Ваш труд о данной работе. Это действительно сложная задача.
Тем не менее, хочу Вас несколько огорчить. При рассмотрении МЭКовского стандарта совершенно не принималась в расчет необходимость его применимости для реализации метода Чохральского. Более того, члены комиссии, по-видимому, даже и слыхом не слыхивали о существовании данной проблемы, что явно свидетельствует не в их пользу. Так что Ваша неудовлетворенность стандартом совершенно справедлива. Надеюсь, что участники МЭК осознают свое досадное упущение и наверстают упущенное в следующей версии стандарта. А пока же остается лишь признать, что установка Чохральского - это классический пример задачи, в которой МЭКовские языки использовать не рекомендуется. Хотя я и не могу отрицать возможность их применения в данном контексте.
[...]
Ну откуда сторонний человек может понять, что МЭК
61131.3 придуман для "автоматизация фабрики по
производству жевательной резинки"? Спасибо,
просветили...
Кстати, про это тоже говорится: имеется непонимание
целей и области применимости стандарта МЭК 61131.3. Это
положение нужно исправлять, в частности, я попытался
сделать это через статью.
1. Мультиязыковое программирование - это минус.
В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования) До
шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в
области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была
полностью программа на релейных схемах...
2. И как это интересно на релюшках можно среднее считать?
Иначе, как вводя инородные сущности в язык, этого
делать нельзя... слишком опасно для мозга.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Если, скажем, LD что-то и упрощает, то нужно понимать, что он упрощает, и за счет чего, и где у этого подхода ограничения наступают... да, LD достоточно просто изучить, но запрограммировать на нем что-то серьезное - практически невозможно... да и несерьезное невозможно
тоже: скажем, тот же ПИД-регулятор... или расчет
среднего... и т.п.
Абсолютно согласен с Вашим давнишним утверждением о том, что IEC 1131 поощряет многоязыковое программирование. Более того, он подразумевает его. С расчетом среднего Вы несколько погорячились - это вполне реализуемо на LD, но, как Вы верно заметили - нужно четко понимать, где кончаются его возможности и на каком из МЭКовских языков можно реализовать необходимые функциональные блоки.
Я про LD говорю, а не про FBD... чего все в
кучу-то мешать?
Первоначально опубликовано Максим Ананских
[...]
Первоначально опубликовано Владимир Е. Зюбин
Давайте, начнем с простого и будем программировать на LD
включение клапана... а потом рассмотрим практические
проблемы LD c фиксацией отказов, с повторным
использованием, с модифицируемостью...
Мне будет очень интересно рассмотреть этот вопрос. Пока что я не вижу разумных объяснений тому, что Вам не удалось создать нужный функциональный блок и, модифицируя его, использовать повторно...
1. Мультиязыковое программирование - это минус.
В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования) До
шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в
области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была
полностью программа на релейных схемах...
Я не знаю и не желаю знать ни о каких исследованиях, которые заявляют о понижении надёжности (и т.д.) систем на базе многоязыкового программирования -- туфта всё это и непрофессионализм.
Я знаю, что на практике в ISaGRAF и в *nix системах многоязыковое программирование уменьшает общий объём кода, улучшает качество отладки.
И это абсолютно неоспоримый факт.
Многоязыковое программирование -- гарантия оптимального, хорошо отлаженного кода.
С уважением,
Бессонов Ян.
Первоначально опубликовано Владимир Е. Зюбин
1. Мультиязыковое программирование - это минус.
В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования) До
шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в
области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была
полностью программа на релейных схемах...
Если есть набор интструментов, то будет ли дом более надежен, если мы будем пользоваться только молотком? Лично для меня, ответ очевиден. Нет не будет. Каждой вещи свое применение. Хотя некоторые продолжают забивать шурупы молотком, вместо того, чтобы взять дрель с битой (насадка на дрель). Пусть это их дело. Стучите молотком. МЭК предлагает использовать 5 языков, в соответствии с необходимостью, для решения тех или иных задач, они используются как описание алгоритма и/или самого управления оборудованием. То что работает на оборудовании, это уже не МЭК. Где-то это исполняемый код адаптированный к ОС, где-то ТИК код исполняемый VM. К МЭК это уже обычно не относится. Неужели вы считаете, что ФБД исолняется на контроллере???? :))) ISaGRAF реализовал все пять языков МЭК и в этом нет ничего шизанутого. Вы же не считаете что Си шизонут только из-за того, что в нем можно реализовать задачу различными путями. :)) Вы и Microsoft обзовите шиз. на кой в Офисе все офисные пакеты включены, а Линух по вашему вобще должно быть Шиз.
Столько ядер, столько пакетов причем дублирующихся??? И накой эти две ОС можно настроить для решения различных задач.
Первоначально опубликовано Владимир Е. Зюбин
2. И как это интересно на релюшках можно среднее считать?
Иначе, как вводя инородные сущности в язык, этого
делать нельзя... слишком опасно для мозга.
Считать на релюшках среднее, в наше время это шиз. конкретный. Причем шиз. на уровне постановки задачи. Это как спичкой шурупы закручивать. :)
Скорее всего последний сообщение, так как общение с некоторыми людьми не имеет конструктивной состовляющей.
Каждой вещи свое место.
С уважением, VSerg.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Но, увы, этого в сложных системах мало. Нужна
расширенная диагностика отказов, интерфейс оператора,
журналы событий, архивы параметров, возможность
оперативной модификации алгоритма [...]
Я что-то не пойму - Вы всерьёз полагаете, что эти задачи должны решаться на уровне контроллеров?
Судя по всему, Вы полагаете, что для этого контроллер не нужен. И для диагностики, и для формирования исходных данных, и для фиксации событий в системе, и для упреждения аварийных ситуаций... без контроллера тут, увы не обойтись...
Что касается модифицируемости алгоритма, то во многом
это свойство зависит от выбранного языкового средства...
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
надежность ПО и т.д.
Вот-вот... мы все о том же говорим.
А о чем еще? Надежность, устойчивость, верифицируемость, сопровождаемость... О чем еще можно говорить, когда дело касается ПО? О релюшках что ли? :-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
А в простых системах и LD сойдет, а может и реле нужно оставить... может и надежнее будет...
И действительно, кчему все это придумали... Назад, к ENIACу !!!! :-)))
А я Вам скажу, в чем корень - в экономической
эффективности. Это очень просто запомнить. Не сложнее и
на практике применять... Если вся логика - это пара
релюшек, крайне глупо для этого ISaGRAF покупать, надо
прямо релюшки и покупать. Дешево и сердито. :-)
Я именно про логику говорю, а не про драйверы.
Про контроль ошибок, про уровень качества реализации...
и про LD, а не про FBD.
Так и я вам про логику, про логику управления клапаном, драйвер это лишь интерфейс. Мы еще говорим о МЭК или только о LD(смотрите тему форума).
Нет такого языка "МЭК". МЭК 61131.3 - это стандарт,
который описывает пять ОТДЕЛЬНЫХ языков
программирования. В частности, LD.
Вот я и спрашиваю, про LD. Могу и про FBD спросить.
Может и спрошу, но в следующий раз. Не можете/не желаете
отвечать - так и скажите.
Первоначально опубликовано VSerg
Тем более я сказал, что LD позволяет реализовать логику на уровне конечного автомата, если операнды булевские, тем более LD позволяет включать блоки FBD, по крайней мере в ISaGRAF.
В том-то и дело, что по "крайней мере в ISaGRAF",
мы же не про ISaGRAF говорим, а про языки МЭК 61131.3.
Я не о вольных интерпретациях МЭК 61131.3 с Вами говорю,
а об LD из этого стандарта.
Первоначально опубликовано VSerg
Выдирая один язык из стандарта, мне кажется, что вы не представляете картины в целом. Стандарт МЭК разработан и предоставляет инструменты для реализации большого спектра задач автоматизации. Ну так и используйте все его инструменты, а не только LD. Вы же когда в CИ пишите используете не только stdio.h.
Вы транслируете мифологемы. Стандарт не предполагает
реализацию ВСЕХ пяти языков в "одном флаконе".
И хедеры Си в ранг языков не возводите...
Первоначально опубликовано VSerg
Надеюсь вы поняли, что включить клапан, как в FBD так и LD ОЧЕНЬ ПРОСТО.
[VSerg]
Нет, не понял. И Вы перестанете себя понимать, если
вспомните, что кроме ISaGRAF существует еще более
десятка реализаций.
[QUOTE=VSerg]
Я не понимаю, зачем на контроллере интерфейс оператора. Да и для интерфейсов и многого другого используют SCADA системы, которые позволяют резервировать управление, сеть да и весь процесс (горячее резервирование) + ведение трендов и алармов, хранение данных в различных бд и многое другое. Как вы себе представляете контроллер, который хранит данные за пару суток, сам себя по горячему резервирует, да еще отслеживает алармы????? Это уже вопросы к уровням управления.
Одним из критериев надежности ПО является требования
локализации обработки событий. У нас в системах это
требование выполняется, а у Вас, как я вижу, нет.
(это не про графику интерфейса оператора, а про
отслеживание "алармов" и их отработку)
Вы, по-видимому про системы супервизорного контроля
говорите, а я про автоматизированные и автоматические
системы управления...
1. Мультиязыковое программирование - это минус.
В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования) До
шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в
области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была
полностью программа на релейных схемах...
Я не знаю и не желаю знать ни о каких исследованиях, которые заявляют о понижении надёжности (и т.д.) систем на базе многоязыкового программирования -- туфта всё это и непрофессионализм.
То, что Вы не желаете ничего знать из области надежности
ПО, очень прискорбный факт. Ничем помочь не могу.
Первоначально опубликовано bessonov
Я знаю, что на практике в ISaGRAF и в *nix системах многоязыковое программирование уменьшает общий объём кода, улучшает качество отладки.
И это абсолютно неоспоримый факт.
Многоязыковое программирование -- гарантия оптимального, хорошо отлаженного кода.
Несомненно оптимальность этим можно достичь, например,
используя ассемблер в Си-программе для повышения
быстродействия... а вот в рамках МЭК 61131.3 говорить об
оптимальности смешно.
А в общем случае мультиязыковое программирование - это
всегда снижение таких качеств программы как надежность и
сопровождаемость. Даже когда речь идет об использовании
ассемблера в Си.
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме
