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

Поскольку со стороны г.Зюбина звучали упреки в том, что соответствие программного пакета МЭК стандарту не является гарантией чего бы то ни было при том унтер-пришибеевском понимании роли стандартов, которое указанному г.  присуще, интересно было бы оценить, так ли все хорошо "в стане С/C++".

Статья http://www.cuj.com/documents/s=8193/cuj0104sutter/  освещает этот вопрос. Особенно забавна таблица http://www.cuj.com/documents/s=8193/cuj0104sutter/tab1.htm

Первоначально опубликовано Максим Ананских Первоначально опубликовано Владимир Е. Зюбин Но с форматом графики действительно нервотрепка не пообщаешься даже по-человечьи... Кстати, LD есть и в текстовом варианте. Выразительность, конечно, страдает, зато переносимость есть. Первоначально опубликовано Владимир Е. Зюбин ПРОЦ ОТКР_НАТ_АВД1_VE1{ ИЗ ПРОЦ Инициализация К_VE1,                             // ссылка на                         Т_НА_СРАБАТЫВАНИЕ_УСТРОЙСТВ_ГВС,    // описание глобальных Тэк-с, посмотрим, что Вы тут написали... Читабельность на уровне, о закрытии клапана речи не было, о сбросе команды на открытие тоже,

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

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

Могу пояснить: когда проходит время равное Т_НА_СРАБАТЫВАНИЕ_УСТРОЙСТВ_ГВС - оператору передается сообщение об отказе клапана и процесс завершается с ошибкой.

ТАЙМАУТ Т_НА_СРАБАТЫВАНИЕ_УСТРОЙСТВ_ГВС

Первоначально опубликовано Максим Ананских да и как выполняется данный алгоритм - параллельно или циклически? Непонятно....

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

Первоначально опубликовано Максим Ананских Короче, вот аналог того, что Вы здесь привели, на LD (изобразил, как смог): | Команда_открыть  Управление |--------| |-----------(S) |                                +-----+ |     Управление  Датчик_откр    | TON |       Отказ |--------| |-----------|/|-------+In  Q+--------( ) |                                |     | |                       Timeout--+Pt Et+ |                                +-----+ |     Управление  Датчик_откр                 Открыто |--------| |-----------| |----------------------( ) | Раз уж начали мы длиной меряться - по-моему, короче получилось. И понятнее.

Наверное вот так все-таки

| Команда_открыть Управление
|--------| |-----------(S)
|                                  +-----+
|        Управление Датчик_откр    | TON |       Отказ
|--------| |-------------|/|-------+In Q+--------( )
|                                  |     |
| Т_НА_СРАБАТЫВАНИЕ_УСТРОЙСТВ_ГВС--+Pt Et+
|                                  +-----+
|     Управление Датчик_откр                 Открыто
|--------| |-----------| |----------------------( )
|

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

Ремарки:
1. Не вошел (по длине) идентификатор спецификации времени таймаута, пришлось все сдвинуть вправо
2. Сигнал "Датчик_откр" - входит у Вас два раза.
3. В случае нормального срабатывания клапана выдается не сигнал "Открыто", а сообщение оператору "Клапан в норме"
4. В оригинальном описании нет сигнала "Команда Открыть"..

Вопросы:
Таким образом в программе можно различать "Отказ Открытия клапана NN" от всех других отказов?
от Отказа _Закрытия_ клапана NN? От Отказов других
клапанов II, KK, LL, MM? Отмечу, что в оригинальном тексте эти вещи различаются.

Да! Кстати, этот же вопрос касается сигналов "Команда_открыть", "Управление" и
"Датчик_откр"...

Первоначально опубликовано Дмитрий Милосер Это не запорно регулирующий клапан. Ааа..так бы и сказали, что это отсечной. Тогда пояснений не буду делать.

В общем случае с отсечным клапаном в LD проблем больше...
не говоря уже о всяких там люфтах и прочих тонкостях...

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

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

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

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

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

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

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

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

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

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

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