[Makrel]

Сообщение от Arsie

Хотелось бы вести диалог с человеком, который понимает разницу между ПЛК и "программным пакетом для работы с трёхмерной графикой" и в курсе существования IEC61131. А также в каких условиях применяется первое и второе.

Извиняюсь, если у Вас сложилось такое впечатление.
Давайте чтобы не было недопонимания немного расскажу о себе и почему я считаю, что могу сравнить удобство применения FBD-программирования или программирования в виде "ST - структурированный текст" (как это называется по IEC61131/МЭК 6-1131) в одном конкретном реальном случае общепромышленного использования.

В 2005 году я закончил БГУИР (бывший МРТИ - минский радиотехнический институт) по специальности "автоматическое управление в технических системах". По распределению попал на завод по производству синтетических алмазов. До прошлого года работал там и основной задачей было как раз обеспечивать работу АСУ. Там использовались ПЛК B&R System 2005 ( http://www.owen-spb.ru/catalog/br/ma...system2005.php ). Так вот за 15 лет работы мне много раз приходилось доделывать и переделывать ПО этого контроллера и встраивать разное новое оборудование в систему.
Какое-то время назад бывшие коллеги организовали в другом месте производство на таких же установках для синтеза алмазов. На старте у них всё управление было в ручном режиме.
Потом они прикупили контроллеры Segnetics, поскольку с ними могли начать что-то делать уже сами. И сделали некоторый полуручной режим управления нагревом. А потом пригласили меня, что бы сделать полноценную автоматизацию этих установок синтеза.
Так и состоялось моё знакомство с контроллерами Segnetics. За полгода неспешной работы (заниматься надо было далеко не только автоматизацией, и в связи со спецификой производства тестирование версий ПО невозможно было проводить часто - только раз в неделю, максимум два, а отсутствие эмуляции не позволило делать это без оборудования). Какое-то время назад доделал стабильную версии автоматизации этих установок со всем нужным базовым функционалом. И уже несколько раз кое-что доделывал/переделывал.

Именно поэтому я как раз могу сравнить "удобство и эффективность" программирования на практически одном и том же оборудовании контроллера с программированием на базе "ST - структурированный текст" (B&R System 2005) и контроллера с программированием на базе "FBD" (Segnetics SMH4).
И, увы, в моём конкретном случае сравнение далеко не в пользу FBD. Этим я с Вами и поделился выше. Написал какие именно неудобства возникли при использовании FBD в моём случае (необходимо реализовывать множественные ветвления в алгоритме работы оборудования) и как можно было бы эти недостатки устранить, сделав тем самым контроллеры Segnetics SMH4 нормально применимыми и для тех задач, которые надо было решать в моем случае.

И вот сейчас почитал про МЭК 61131-3 (IEC61131/3) и там именно это и пишут. То есть "жалобы" с которыми Вы сталкивались от других пользователей скорее всего связаны с тем же.

Сообщение от Arsie

вы далеко не первый, кто заблуждается в своих желаниях "хочу как в CAD/CAM-системах" - перетирать всё заново у меня нет ни малейшего желания.

Вот обратите внимание на выделенные жирным фрагменты:

Сообщение от Энциклопедия АСУ ТП

Языки МЭК 61131-3 (IEC61131/3) появились не как теоретическая разработка, а как результат анализа множества языков, уже используемых на практике и предлагаемых рынку производителями ПЛК. Стандарт устанавливает пять языков программирования со следующими названиями:

структурированный текст (ST - Structured Text);
последовательные функциональные схемы (SFC - "Sequential Function Chart");
диаграммы функциональных блоков (FBD - Function Block Diagram);
релейно-контактные схемы, или релейные диаграммы (LD - Ladder Diagram);
список инструкций (IL - Instruction List).
Графическими языками являются SFC, FBD, LD. Языки IL и ST являются текстовыми.

В стандарт были введены несколько языков (а не один) для того, чтобы каждый пользователь мог применить наиболее понятный ему язык. Программисты чаще выбирают язык IL (похожий на ассемблер) или ST, похожий на язык высокого уровня Паскаль; специалисты, имеющие опыт работы с релейной логикой, выбирают язык LD, специалисты по системам автоматического управления (САУ) и схемотехники выбирают привычный для них язык FBD.

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

Языки МЭК 61131-3 базируются на следующих принципах [Lewis]:

- вся программа разбивается на множество функциональных элементов - Program Organization Units (POU), каждый из которых может состоять из функций, функциональных блоков и программ. Любой элемент МЭК-программы может быть сконструирован иерархически из более простых элементов;
- стандарт требует строгой типизации данных. Указание типов данных позволяет легко обнаруживать большинство ошибок в программе до ее исполнения;
- имеются средства для исполнения разных фрагментов программы в разное время, с разной скоростью, а также параллельно. Например, один фрагмент программы может сканировать концевой датчик с частотой 100 раз в секунду, в то время как второй фрагмент будет сканировать датчик температуры с частотой один раз в 10 сек;
- для выполнение операций в определенной последовательности, которая задается моментами времени или событиями, используется специальный язык последовательных функциональных схем ( SFC);
- стандарт поддерживает структуры для описания разнородных данных. Например, температуру подшипников насоса, давление и состояние "включено-выключено" можно описать с помощью единой структуры "Pomp" и передавать ее внутри программы как единый элемент данных;
- стандарт обеспечивает совместное использование всех пяти языков, поэтому для каждого фрагмента задачи может быть выбран любой, наиболее удобный, язык;
- программа, написанная для одного контроллера, может быть перенесена на любой контроллер, совместимый со стандартом МЭК 61131-3.
Взято с: https://bookasutp.ru/Chapter9_3.aspx

Вот, представьте, у Вас задача просверлить что-то. Вы покупаете дрель. У неё в комплекте свёрла по дереву. Если надо сверлить дерево, то всё отлично. Но если у Вас стоит ЗАДАЧА просверлить металл? Если алюминий или другой мягкий метал, то в принципе можно и просверлить.
А если вам надо просверлить твердный металл? Наверно тоже можно просверлить и сверлом по дереву, но это будет сделать сложно. Очевидно, что в таком случае вы пойдете в магазин и захотите купить сверло по металлу... Но вдруг оказывается что производитель купленной дрели не делает свёрла по металлу и даже не планирует, а свёрла других производителей не подходят. Производитель считает, что "если вы привыкли сверлить металл свёрлами по металлу, то это проблема ваших привычек. Нашей дрелью и сверлом по дереву прекрасно можно сверлить и металлы...". Вы ведь вряд ли с этим согласитесь? Если надо просверлить несколько дырок, то можно и помучиться, раз уж дрель уже куплена. Но если много, то ведь правильным решением будет купить "нормальную" дрель со сверлами по металу и сделаеть свою работу не мучаясь.


Так вот. Для меня контроллер - это инструмент, с помощью которого мне надо решить определенные задачи. У этого "инструмента" могут быть, а могут и не быть разные "насадки", которые "заточены" под определенные задачи. Ведь не просто так в IEC61131 есть все 5 вариантов способов программирования контроллеров.

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

Если бы было одно универсальное сверло, которое прекрасно справлялось бы и с деревом, и с металлами, и с бетоном, и со стеклом. То очевидно, что если бы оно не было сильно дороже "специализированных", то оно рано или поздно осталось бы единственным стандартным сверлом.

Если бы был универсальный язык программирования, которым было бы удобно решать АБСОЛЮТНО ВСЕ задачи, то он бы остался один в стандарте.

Для моей задачи "чистый" FBD очень плохо подходит. Вот и всё. Если бы была возможность реализовывать свои блоки FBD на базе "ST Структурированный текст", то проблемы не было бы. Сложные/разветвленные места реализовал бы отдельными блоками, которые написаны на "структурированном тексте", остальное на FBD.


Естественно, это только решение Вашей организации - целесообразно реализовать такое или нет.


Но для примера - в Нашей организации уже 3 раза серьезно обсуждался вариант перехода на другие контроллеры, которые поддерживали бы программирование "структурированным текстом". Как раз буквально вчера директор поднял этот вопрос третий раз. Но поскольку стабильная базовая версия уже есть, а свободного времени нет, сейчас переход не целесообразен. Но в будущем если возникнет необходимость автоматизировать что-то со "сложными разветвленными алгоритмами работы", мы однозначно не выберем контроллеры Сегнетик (просто из-за неэффективновности FBD для таких задач, сами контроллеры по-моему отличные).