Средство для программирования контроллера: Си или МЭК 61131?
Первоначально опубликовано Владимир Е. Зюбин
Мне непонятно, о каком сбросе команды на открытие идет речь... это событийная архитектура... т.е. возникает необходимость открыть клапан, он открывается и все.
Прошу прощения, я уже понял, что это не двухходовый клапан.
Первоначально опубликовано Владимир Е. Зюбин
алгоритм выполняются и параллельно (относительно других подобных алгоритмов - процессов) и циклически (как любой автомат, тот же SFC)... Если Вы работали с SFC, то состояния (СОСТ/state) процесса (ПРОЦ/proc) алгоритмически эквивалентно паре "шаг+переход"...
То есть, вы изобрели аналог SFC? А не разумнее ли было взять стандартный SFC в текстовом варианте (STEP... END_STEP, TRANSITION... END_TRANSITION)
Первоначально опубликовано Владимир Е. Зюбин
2. Сигнал "Датчик_откр" - входит у Вас два раза.
Действительно. Мне показалось, что так понятнее.
Первоначально опубликовано Владимир Е. Зюбин
3. В случае нормального срабатывания клапана выдается не сигнал "Открыто", а сообщение оператору "Клапан в норме"
В PLC это делается обычно либо панелью оператора, либо SCADA системой.
Первоначально опубликовано Владимир Е. Зюбин
4. В оригинальном описании нет сигнала "Команда Открыть"..
В языке LD нет понятия "событие", его роль играет изменение состояния переменной - что оправдано, поскольку отпадает необходимость транслировать изменения входных сигналов в события.
Первоначально опубликовано Владимир Е. Зюбин
Таким образом в программе можно различать "Отказ Открытия клапана NN" от всех других отказов?
Ответ очевиден - путем использования для этой цели разных переменных. Если вы реализуете этот алгоритм в виде функционального блока - в этом случае каждый его экземпляр будет иметь собственные входы и выходы.
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Только вот адепты FBD того же самого, да и LD, в частности, скорее всего не знают, что экспериментальные данные (подчеркиваю, строгие экспериментальные данные) говорят о том, что существуют достаточно распространенный класс случаев, когда читаемость графических языков оказывается гораздо ниже, чем текстовых.
Не буду спорить, такие случаи бывают. Однако гораздо чаще случается ситуация, когда программист злоупотребляет возможностями языка, вследствие чего алгоритм становится плохо читаемым. Я хочу сказать, что в гораздо большей степени читабельность зависит от подготовки человека, написавшего программу. В этом и текстовые, и графические языки похожи.
Да. Читабельность исходного зависит и от класса задачи,
и от квалификации разработчика, и от квалификации
читающего, и от языка описания.
Но это не значит, что читабельность не поддается
измерению. Поддается и измеряется. Причем эксперимент
показывает, что читабельность т.н. "графических" языков
вещь весьма проблематичная, не однозначная, а зачастую и
просто недопустимо низкая.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
С языками типа FBD и LD парадоксальная ситуация - их достаточно просто изучить, но при этом они накладывают
жесткое ограничение на допустимую сложность программируемого алгоритма, текстовая же форма представления потенциально несколько сложнее для изучения, однако она позволяет создавать программы
повышенной сложности...
Я бы не стал говорить, что графические языки вообще проще в изучении, чем текстовые. Совсем нет - эквивалентные по выразительным свойствам языки изучить одинаково легко. Возможно, некоторую роль играет простота использования неподготовленным пользователем, когда можно нажать кнопку мышью на панели инструментов вместо того, чтобы вспоминать тот или иной оператор. Это снимает один из психологических барьеров перед использованием языка, и человеку кажется, что использовать его проще.
Увы, но "совсем да"... "Графические" языки, такие как LD
и FBD очевидно проще в изучении. Это обусловлено
метафоричностью языка.
Первоначально опубликовано Максим Ананских
Основное преимущество графических языков состоит в наглядности программы и отладочной информации. Впрочем, это преимущество легко может быть нивелировано усилиями программиста, получающего большую свободу действий (блоки можно расположить в разных местах экрана, соединить как угодно и т.п.) в запутывании собственной программы. Чем болше ограничений накладывает графический язык, тем труднее сделать программу нечитаемой, и тем труднее её писать. Так что это, скорее, является возможностью графического представления, недоступной текстовым языкам, а вовсе не его общим свойством.
Я уже устал повторять. Читабельность метафорических
языков не подтверждается экспериментально. Но на них
проще научиться программировать новичку...
с большой вероятностью заполучить при этом небольшие
отклонения в сознании, т.н. "метафорические артефакты". :-)
1. LD - это язык в основании которго лежит метафора реле. Все другие блоки - инородны для LD. Произвольный (алгоритмически произвольный) блок на LD записать ПРАКТИЧЕСКИ невозможно.
С тем же успехом можно утверждать, что в основе языка Си лежит использование фигурных скобок и оператора присваивания в виде знака "равно". А все другие элементы инородны (натасканы из Паскаля, Алгола, Фортрана...) :-)
Так утверждать нельзя. Фигурная скобка - это не метафора.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Я же Вам говорю, наиболее гибкое средство в МЭК 61131.3 - это SFC+ST. Все остальные средства можно смело исключить.
Наиболее гибкое не означает автоматически наиболее удобное. Да, все можно написать на этих двух языках, но я бы не хотел заниматься поддержкой такой системы.
Для профессионалов, ST+SFC - это, несомненно,
единственно подходящий выбор из МЭК 1131-3.
Я уже сказал почему: в МЭК подходе отсутствует необходимый уровень гибкости, модифицируемости, и структурируемости. Ссылка на документ тоже приводилась.
Даже если бы это было правдой, как это связано с безопасностью?
Напрямую. Это составные части (не все, конечно)
безопасного, да, и просто, качественного ПО.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Тему LD поднял МЭК и производители, желающие на этом получить прибыль. Они же и на IL предлагают программировать.
Из двух схожих продуктов проще продать более качественный. Следовательно, поддержка продуктом языков МЭК - показатель качества, иначе бы на этом не пытались заработать.
Мифы. По законам рынка лучше продается не более качественный, а более рекламируемый продукт. :-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Я уже устал повторять: любая программа транслируется в набор команд DEC и JZ... и любая программа транслируется в машинный код 0/1. В курсе? Транслируется, только человеку работать с ней после этого невозможно.
Это лишь означает, что LD по сравнению с SFC - язык более низкого уровня, то есть, SFC обладает меньшими возможностями. Кроме того, SFC не самодостаточен, в отличие от LD, то есть на нем вообще нельзя написать произольную программу, не пользуясь другими языками. В самом деле, он выполняет роль CASE-средства для более удобного описания переходов между состояниями программы. Для описания же самих состояний программы наиболее удобны LD и FBD.
Я уже вкратце описал проблемы графических языков, не буду повторяться.
Мне непонятно, о каком сбросе команды на открытие идет речь... это событийная архитектура... т.е. возникает необходимость открыть клапан, он открывается и все.
Прошу прощения, я уже понял, что это не двухходовый клапан.
Это обычный отсечной клапан, его можно открыть, а можно
и закрыть. Внутри у него есть напряжения форсажа и
удержания. Один вход (управляющий), один выход
(контролирующий).
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
алгоритм выполняются и параллельно (относительно других подобных алгоритмов - процессов) и циклически (как любой автомат, тот же SFC)... Если Вы работали с SFC, то
состояния (СОСТ/state) процесса (ПРОЦ/proc) алгоритмически эквивалентно паре "шаг+переход"...
То есть, вы изобрели аналог SFC? А не разумнее ли было взять стандартный SFC в текстовом варианте (STEP... END_STEP, TRANSITION... END_TRANSITION)
Нет. Это не аналог SFC. Это что-то покруче будет. :-)
А, во-вторых, зачем мне улучшать тупиковую ветвь
Паскаля? Гораздо больше программистов, которые знают
Си...
которым проще свои знания о Си расширить, чем Паскаль
изучать. :-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
2. Сигнал "Датчик_откр" - входит у Вас два раза.
Действительно. Мне показалось, что так понятнее.
Так менее надежно. Хотя, может, быть на LD это и
наиболее понятно... Понятность за счет надежности, так
сказать... ;-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
3. В случае нормального срабатывания клапана выдается не сигнал "Открыто", а сообщение оператору "Клапан в норме"
В PLC это делается обычно либо панелью оператора, либо SCADA системой.
Вот я и говорю, те вещи которые могут и должны делаться
на уровне контроллера переносятся в ИО. А там чем эти
вещи описываются? На Си, что ль? :-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
4. В оригинальном описании нет сигнала "Команда Открыть"..
В языке LD нет понятия "событие", его роль играет изменение состояния переменной - что оправдано, поскольку отпадает необходимость транслировать изменения входных сигналов в события.
Изменения входных сигналов - это и есть события. Тут
ничего никуда транслировать не надо...
То, что LD не предназначено для работы с событиями - это
проблема LD, а не событийной природы объекта...
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Таким образом в программе можно различать "Отказ Открытия клапана NN" от всех других отказов?
Ответ очевиден - путем использования для этой цели разных переменных. Если вы реализуете этот алгоритм в виде функционального блока - в этом случае каждый его экземпляр будет иметь собственные входы и выходы.
Вот и я про это же...В LD начинают множиться
переменные... Самое минимальное следствие из этого -
увеличение длины идентификаторов, что для графической
формы смерти подобно... :-)
А кроме того, мне вот так кажется, что если Вы введете
и блок "закрытие клапана", то Ваша схема приобретет
более запутанный характер... в любом случае, было б
интересно посмотреть, как это выглядит...
Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. ... Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее
Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. ... Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее
Ой держите меня за задние ноги...
"Excel использует паскалевские строки внутри себя, поэтому строки во многих местах в Excel не могут быть длиннее 255 байт, и это одна из причин, почему Excel так быстро работает."
Кроме того, если в одном месте убудет [геммороя], то в другом - добавится. Например, при распарсивании паскалевских строк.
Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. ... Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее
Ой держите меня за задние ноги...
"Excel использует паскалевские строки внутри себя, поэтому строки во многих местах в Excel не могут быть длиннее 255 байт, и это одна из причин, почему Excel так быстро работает."
Кроме того, если в одном месте убудет [геммороя], то в другом - добавится. Например, при распарсивании паскалевских строк.
Z-строки - однозначно анахронизм, паскалевский подход культурнее, просто байта маловато. В Java, например, строки скорее паскалевские (длина 32 бита + юникодный массив), и геморроя никакого нет.
Другое дело, что этот
анахронизм не имеет никакого отношения к самому языку C, в котором понятия "строки" вообще нет, это анахронизм традиционных библиотек. Никто не мешает создать правильный класс String, хоть "паскалевский".
А насчет парсить - не факт, что паскалевскую строку парсить труднее, тем более, что обычно пишется один раз токенайзер, и затем уже никто не вспоминает, как он устроен.
С уважением,
Дмитрий Теркель
Владимир Е. ЗюбинЧитабельность метафорических (??? бред...) языков не подтверждается экспериментально (??? фантазии Зюбинa)
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:
Programs have the fewest loops (i.e. those which most closely resemble a tree diagram)
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.
Первоначально опубликовано Доктор Q
<SPAN class=bold>Владимир Е. Зюбин</SPAN>Читабельность метафорических (??? бред...)
языков не подтверждается экспериментально (??? фантазии Зюбинa)
Выходите из бредового состояния и начинайте повышать
свой профессиональный уровень... для начала разберитесь,
что такое метафора и что такое языки, основанные на
метафоре
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме