Современные технологии автоматизации» («СТА») —  журнал для квалифицированных специалистов по промышленной автоматизации Форум СТА — современные технологии автоматизации Домашняя страница
Домашняя страница форума CTA Домашняя страница форума CTA > II. АСУТП и SCADA > Архив
  Активные темы Активные темы
  FAQ FAQ  Искать в форуме   Зарегистрироваться Зарегистрироваться  Вход в систему Вход в систему

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

 Ответить Ответить Страница  <1 4647484950 53>
Автор
Сообщение
Максим Ананских Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 14 Май 2003
Online Status: Offline
Публикации: 770
Свойства публикации Свойства публикации   Ответить, цитируя автора - Максим Ананских Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: Средство для программирования контроллера: Си или МЭК 61131?
    Опубликовано: 27 Октябрь 2003 23:54

Первоначально опубликовано Владимир Е. Зюбин

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

Прошу прощения, я уже понял, что это не двухходовый клапан.

Первоначально опубликовано Владимир Е. Зюбин

алгоритм выполняются и параллельно (относительно других подобных алгоритмов - процессов) и циклически (как любой автомат, тот же SFC)... Если Вы работали с SFC, то
состояния (СОСТ/state) процесса (ПРОЦ/proc) алгоритмически эквивалентно паре "шаг+переход"...

То есть, вы изобрели аналог SFC? А не разумнее ли было взять стандартный SFC в текстовом варианте (STEP... END_STEP, TRANSITION... END_TRANSITION)

Первоначально опубликовано Владимир Е. Зюбин

2. Сигнал "Датчик_откр" - входит у Вас два раза.

Действительно. Мне показалось, что так понятнее.

Первоначально опубликовано Владимир Е. Зюбин

3. В случае нормального срабатывания клапана выдается не сигнал "Открыто", а сообщение оператору "Клапан в норме"

В PLC это делается обычно либо панелью оператора, либо SCADA системой.

Первоначально опубликовано Владимир Е. Зюбин

4. В оригинальном описании нет сигнала "Команда Открыть"..

В языке LD нет понятия "событие", его роль играет изменение состояния переменной - что оправдано, поскольку отпадает необходимость транслировать изменения входных сигналов в события.
Первоначально опубликовано Владимир Е. Зюбин

Таким образом в программе можно различать "Отказ Открытия клапана NN" от всех других отказов?
Ответ очевиден - путем использования для этой цели разных переменных. Если вы реализуете этот алгоритм в виде функционального блока - в этом случае каждый его экземпляр будет иметь собственные входы и выходы.

Инженер-системотехник
+7 (916) 477 3925
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 08:11
Первоначально опубликовано Максим Ананских

Первоначально опубликовано Владимир Е. Зюбин

Только вот адепты FBD того же самого, да и LD, в частности, скорее всего не знают, что экспериментальные данные (подчеркиваю, строгие экспериментальные данные) говорят о том, что существуют достаточно распространенный класс случаев, когда читаемость графических языков оказывается гораздо ниже, чем текстовых.


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




Да. Читабельность исходного зависит и от класса задачи,
и от квалификации разработчика, и от квалификации
читающего, и от языка описания.

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

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

С языками типа FBD и LD парадоксальная ситуация - их достаточно просто изучить, но при этом они накладывают
жесткое ограничение на допустимую сложность программируемого алгоритма, текстовая же форма представления потенциально несколько сложнее для изучения, однако она позволяет создавать программы
повышенной сложности...


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




Увы, но "совсем да"... "Графические" языки, такие как LD
и FBD очевидно проще в изучении. Это обусловлено
метафоричностью языка.

Первоначально опубликовано Максим Ананских


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



Я уже устал повторять. Читабельность метафорических
языков не подтверждается экспериментально. Но на них
проще научиться программировать новичку...
с большой вероятностью заполучить при этом небольшие
отклонения в сознании, т.н. "метафорические артефакты". :-)
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 08:26
Первоначально опубликовано Максим Ананских

Первоначально опубликовано Владимир Е. Зюбин

1. LD - это язык в основании которго лежит метафора реле. Все другие блоки - инородны для LD. Произвольный (алгоритмически произвольный) блок на LD записать ПРАКТИЧЕСКИ невозможно.


С тем же успехом можно утверждать, что в основе языка Си лежит использование фигурных скобок и оператора присваивания в виде знака "равно". А все другие элементы инородны (натасканы из Паскаля, Алгола, Фортрана...) :-)




Так утверждать нельзя. Фигурная скобка - это не метафора.

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

Я же Вам говорю, наиболее гибкое средство в МЭК 61131.3 - это SFC+ST. Все остальные средства можно смело исключить.


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



Для профессионалов, ST+SFC - это, несомненно,
единственно подходящий выбор из МЭК 1131-3.
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 08:41
Первоначально опубликовано Максим Ананских

Первоначально опубликовано Владимир Е. Зюбин


Я уже сказал почему: в МЭК подходе отсутствует необходимый уровень гибкости, модифицируемости, и структурируемости. Ссылка на документ тоже приводилась.


Даже если бы это было правдой, как это связано с безопасностью?




Напрямую. Это составные части (не все, конечно)
безопасного, да, и просто, качественного ПО.

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

Тему LD поднял МЭК и производители, желающие на этом получить прибыль. Они же и на IL предлагают программировать.


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




Мифы. По законам рынка лучше продается не более качественный, а более рекламируемый продукт. :-)

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

Я уже устал повторять: любая программа транслируется в набор команд DEC и JZ... и любая программа транслируется в машинный код 0/1. В курсе? Транслируется, только человеку работать с ней после этого невозможно.


Это лишь означает, что LD по сравнению с SFC - язык более низкого уровня, то есть, SFC обладает меньшими возможностями. Кроме того, SFC не самодостаточен, в отличие от LD, то есть на нем вообще нельзя написать произольную программу, не пользуясь другими языками. В самом деле, он выполняет роль CASE-средства для более удобного описания переходов между состояниями программы. Для описания же самих состояний программы наиболее удобны LD и FBD.



Я уже вкратце описал проблемы графических языков, не буду повторяться.
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 09:05
Первоначально опубликовано Максим Ананских

Первоначально опубликовано Владимир Е. Зюбин

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


Прошу прощения, я уже понял, что это не двухходовый клапан.




Это обычный отсечной клапан, его можно открыть, а можно
и закрыть. Внутри у него есть напряжения форсажа и
удержания. Один вход (управляющий), один выход
(контролирующий).

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

алгоритм выполняются и параллельно (относительно других подобных алгоритмов - процессов) и циклически (как любой автомат, тот же SFC)... Если Вы работали с SFC, то
состояния (СОСТ/state) процесса (ПРОЦ/proc) алгоритмически эквивалентно паре "шаг+переход"...


То есть, вы изобрели аналог SFC? А не разумнее ли было взять стандартный SFC в текстовом варианте (STEP... END_STEP, TRANSITION... END_TRANSITION)



Нет. Это не аналог SFC. Это что-то покруче будет. :-)

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

Первоначально опубликовано Максим Ананских

Первоначально опубликовано Владимир Е. Зюбин

2. Сигнал "Датчик_откр" - входит у Вас два раза.


Действительно. Мне показалось, что так понятнее.


Так менее надежно. Хотя, может, быть на LD это и
наиболее понятно... Понятность за счет надежности, так
сказать... ;-)
Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

3. В случае нормального срабатывания клапана выдается не сигнал "Открыто", а сообщение оператору "Клапан в норме"


В PLC это делается обычно либо панелью оператора, либо SCADA системой.



Вот я и говорю, те вещи которые могут и должны делаться
на уровне контроллера переносятся в ИО. А там чем эти
вещи описываются? На Си, что ль? :-)

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

4. В оригинальном описании нет сигнала "Команда Открыть"..

В языке LD нет понятия "событие", его роль играет изменение состояния переменной - что оправдано, поскольку отпадает необходимость транслировать изменения входных сигналов в события.


Изменения входных сигналов - это и есть события. Тут
ничего никуда транслировать не надо...
То, что LD не предназначено для работы с событиями - это
проблема LD, а не событийной природы объекта...

Первоначально опубликовано Максим Ананских


Первоначально опубликовано Владимир Е. Зюбин

Таким образом в программе можно различать "Отказ Открытия клапана NN" от всех других отказов?
Ответ очевиден - путем использования для этой цели разных переменных. Если вы реализуете этот алгоритм в виде функционального блока - в этом случае каждый его экземпляр будет иметь собственные входы и выходы.



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

А кроме того, мне вот так кажется, что если Вы введете
и блок "закрытие клапана", то Ваша схема приобретет
более запутанный характер... в любом случае, было б
интересно посмотреть, как это выглядит...
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Доктор Q Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 29 Сентябрь 2003
Категория: Isle Of Man
Online Status: Offline
Публикации: 119
Свойства публикации Свойства публикации   Ответить, цитируя автора - Доктор Q Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 12:06

Безоглядным любителям С предлагаю ознакомиться с http://russian.joelonsoftware.com/Articles/BacktoBasics.html, где рассматривается такая характерная допотопная фича С, как z-строки. 

Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. ... Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее

 

Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 12:57
Первоначально опубликовано Доктор Q

Безоглядным любителям С предлагаю ознакомиться с http://russian.joelonsoftware.com/Articles/BacktoBasics.html, где рассматривается такая характерная допотопная фича С, как z-строки.


Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. ... Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее



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

Кроме того, если в одном месте убудет [геммороя], то в другом - добавится. Например, при распарсивании паскалевских строк.
SY,
EK
Наверх
Дмитрий Теркель Смотреть выпадающим
Новичок
Новичок


Присоединился: 26 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 22
Свойства публикации Свойства публикации   Ответить, цитируя автора - Дмитрий Теркель Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 28 Октябрь 2003 14:06
Первоначально опубликовано evgen

Первоначально опубликовано Доктор Q

Безоглядным любителям С предлагаю ознакомиться с http://russian.joelonsoftware.com/Articles/BacktoBasics.html, где рассматривается такая характерная допотопная фича С, как z-строки.


Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. ... Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее



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

Кроме того, если в одном месте убудет [геммороя], то в другом - добавится. Например, при распарсивании паскалевских строк.

Z-строки - однозначно анахронизм, паскалевский подход культурнее, просто байта маловато. В Java, например, строки скорее паскалевские (длина 32 бита + юникодный массив), и геморроя никакого нет.
Другое дело, что этот
анахронизм не имеет никакого отношения к самому языку C, в котором понятия "строки" вообще нет, это анахронизм традиционных библиотек. Никто не мешает создать правильный класс String, хоть "паскалевский".
А насчет парсить - не факт, что паскалевскую строку парсить труднее, тем более, что обычно пишется один раз токенайзер, и затем уже никто не вспоминает, как он устроен.
С уважением,
Дмитрий Теркель
Наверх
Доктор Q Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 29 Сентябрь 2003
Категория: Isle Of Man
Online Status: Offline
Публикации: 119
Свойства публикации Свойства публикации   Ответить, цитируя автора - Доктор Q Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Октябрь 2003 04:26

Владимир Е. Зюбин Читабельность метафорических (??? бред...)
языков не подтверждается экспериментально (??? фантазии Зюбинa)

http://www.computer.org/conferences/vl95/html-papers/koike2/koike.htm

One of the most important advantages of iconic programming language is its readability

Compared with conventional textual programming languages, iconic programming languages have two major advantages: non-expert users friendliness, and ease of program customization and maintenance. The latter advantage depends on the languages' readability. Though readability in iconic programming depends largely on the individual application involved, the most "readable" programs are generally as follows:

  1. Programs have the fewest loops (i.e. those which most closely resemble a tree diagram)
  2. Programs have the fewest intersections of wires

As long as these features are maintained, programs are readable. When a program becomes large and complicated, however, it becomes difficult to maintain these features and the program readability rapidly decreases. This lowering of readability is one of the essential factors of the scalability problem. Therefore, to solve the scalability problem, it is necessary to describe large and complicated applications with high readability.

Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 29 Октябрь 2003 07:56
Первоначально опубликовано Доктор Q

<SPAN class=bold>Владимир Е. Зюбин</SPAN> Читабельность метафорических (??? бред...)
языков не подтверждается экспериментально (??? фантазии Зюбинa)




Выходите из бредового состояния и начинайте повышать
свой профессиональный уровень... для начала разберитесь,
что такое метафора и что такое языки, основанные на
метафоре
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
 Ответить Ответить Страница  <1 4647484950 53>

Переход на форум Права доступа на форуме Смотреть выпадающим

Bulletin Board Software by Web Wiz Forums® version 9.64
Powered by Web Wiz Forums Free Express Edition
Copyright ©2001-2009 Web Wiz