Comments 54
У каждого производителя свои библиотеки.
На самом деле разрабатывать библиотеки не привязанные к железу конкретного производителя в CDS гораздо проще, но работодатель начинает возмущаться "А вот если они с нашей библиотекой пойдут на другой контроллер?".
Ну так сегодня пойдут, а завтра поймут, что у нас инфраструктура лучше и вернуться.
Исключение, наврное, CodeSys. Про него много написано, и много вспомогательных библиотек.
Кроме этого у CODESYS есть магазин, на котором можно кой-чего найти. Иногда даже не за баснословные (по меркам СНГ деньги), и форум у них есть. Не знаю, на сколько он сейчас жив, но года 3 назад ответ можно было получить относительно быстро.
Данная статья нужна для привлечения внимания. Все проблемы решатся быстрее
В чем смысл общения между программистами CODESYS и Simatic, если, по большей мере, вещи написанные в одном не переносимы во второе?
Подходы, применяемые, конечно можно перенять. Но, как показывает практика даже при встрече люди стесняются\боятся говорить о своем опыте и своих ошибках.
Как-то подготавил выступление для конференции и показал коллеге на слайде "Как у нас было" на котором я рассказывал о ошибках, которые мы победили.
Коллега возмутился "УУУ ЭТО КАК ЭТО ТАК? НЕЛЬЗЯ такое говорить".
Про него много написано, и много вспомогательных библиотек.
Есть и всякие штуки без привязки к конкретной среде разработки. Если интересно, на сайте оскат ру ребята выкладывают переводы документации и рекомендаций от PLCOpen. Иногда разбавляют оригинальными статьями.
Может пригодится.
Понятно что библиотеки для поддержки "железа" т.е. драйвера - это минимум, который производитель должен предоставлять.
Я больше говорил о библиотеках которые будут использоваться при разработке бизнес-логики.
Но, в моем представлении, разработка ПО для ПЛК это больше разработка бизнес-логики и здесь есть достаточно возможностей для разработки кода не завязанного на ПЛК конкретного производителя.
Особенно, учитывая что в CODESYS есть полноценный ООП.
"GitHub на моё удивление не знает про существование ST" - знает. Есть опенсорный отличный проект matiec. Разные ПЛК используют разные ОС, не на всех ПЛК есть ОС, некоторые вообще работают на ПЛИС, а компилятор имеет структуру IEC 61131-3 -> LLVM IR -> RTL (Verilog или VHDL), некоторые работают на мк на baremetal, без ОС. "Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл" - многие IDE хранят файлы проекты и сам "код" в формате XML. Использовать систему контроля версий - нужно использовать всегда, 21 век. Неужели, кто до сих пор хранит файлы в архивах и т.п, и формируя бессмысленные названия для файлов.
Заходишь в чат и спрашиваешь, что тебе нужно, потом тебе отвечает человек, который это знает и помогает тебе решить проблему. Форумы отличная тема, но они обычно принадлежат производителям ПЛК, как было сказано выше. На StackOverflow редко можно найти ответ на свою проблему, так как сообщество не самое большое и раздроблено по производителям.
Главные требования к ПЛК: надёжность, низкая стоимость, быстрая реакция на входные воздействия, простота программирования.
Спорно, очень спорно.
На qna.habr.com есть тег "plc", все туда!
Статья во многом некорректная.
Я бы назвал у PLC одно преимущество - масштабируемость.
Легко перейти от 10 входов-выходов к тысяче.
В остальном же они дороже, медленней, больше потребляют энергии, больше требуют объема.
Современные PLC уже не являются однозадачными. Даже в дешевых линейках есть возможность делать несколько задач и обмен вести через события. У задач есть приоритеты.
Т.е. необходимость планирования приоритетов встает в полный рост.
Проблема уложиться в реальное время в PLC также сложна как и на голых микроконтроллерных платформах. В PLC с МЭК сложнее делать детализированный профайлинг.
С другой стороны исходники на языке ST очень качественно генерирует MATLAB.
Поэтому ST и многие библиотеки уже можно не изучать.
Последний проект на PLC делал вообще не читая IEC 61131-3 и спецификации ST.
Я бы назвал у PLC одно преимущество - масштабируемость.
Вы упускаете из виду и низкий порог вхождения благодаря графическим языкам. Это очень большое преимущество: для инженера разбирающегося в процессе не составит труда разработать программу для автоматизации.
Это я бы назвал главным преимуществом.
Все остальное вторично.
Последний проект на PLC делал вообще не читая IEC 61131-3 и спецификации ST.
Тогда, скорее всего, вы не использовали всех возможностей, которые предоставляет платформа и программировали так же, как будто это C, Python и пр.
Работает? Да.
Эффективно ли? Сопровождаемо ли? Хорошие вопросы.
Современные PLC уже не являются однозадачными.
Странная фраза, не пойму зачем здесь.
Даже очень старые ПЛК были многозадачными, многозадачность, только была замещающая.
Но необходимость задавать приоритеты была и тогда. Проблема ли это?
Если да, то пишите все в одной задаче.
Но, честно говоря, не вижу особой проблемы вписаться в цикл ПЛК. Если, конечно, подходить к разработке так, как это принято в ПЛК: не писать блокирующий код.
Для алгоритмов с конечными автоматами на десяток состояний вхождение будет достаточно быстрым. Не спорю. Особенно если алгоритмы типовые.
Но когда автоматы разрастаются до сотен состояний ПЛК c МЭК будет совершенно недееспособен. Тут уже нужны будут языки высокого уровня типа C++.
Библиотеки ПЛК не помогут.
Алгоритмы на MATLAB Stateflow это не Python, не надо путать. Это графическая нотация гораздо более мощная чем графические нотации МЭК.
Многозадачность нужна для того чтобы как раз уложится в жесткие рамки цикла обмена по внешней шине. Если все реализовать в одной задаче то даже простенькие алгоритмы не успевают завершиться за цикл. Просто диаграмма единственного цикла у автора в статье в принципе не верна. И ПЛК сам по себе нечем не поможет если программист не приложит усилий по декомпозиции, профайлингу и оптимизации.
Но когда автоматы разрастаются до сотен состояний ПЛК c МЭК будет совершенно недееспособен.
А вы точно понимаете о чем говорите?
Потому что, на сколько мне известно, в МЭК выполняются только активные состояния. Остальные даже не просчитываются. Поэтому нет разницы будет ли это 10 состояний, 100 или 1000.
Алгоритмы на MATLAB Stateflow это не Python, не надо путать. Это графическая нотация гораздо более мощная чем графические нотации МЭК.
Разрабатываю сейчас на Stateflow. Разницы не замечаю по сравнению с SFC.
Те же состояния, условия, переходы и действия.
Да, в MatLab есть FlowChart, но на ПЛК это может быть код на ST. Суть от этого не меняется.
ЧЯДНТ?
К стати, было бы интересно посмотреть на вашу реализацию StateMachine на C++ (или, не дай Б-г на C) на 100+ состояний. И на читабельность такого кода.
Многозадачность нужна для того чтобы как раз уложится в жесткие рамки цикла обмена по внешней шине.
Обмен по внешней шине, и, тем более соблюдение мили- и микро-секундных таймингов естественно нужно реализовывать на других ЯП.
МЭК это про бизнес-логику, а не про драйвера и BoardSupportPackage. Вряд ли кому-то в здравом уме прийдет в голову писать драйвер RS485 на МЭК.
Просто диаграмма единственного цикла у автора в статье в принципе не верна.
Верна. В том же CODESYS с вытесняющей многозадачностью, в рамках каждой задачи происходит чтение входов - обработка - запись выходов.
И ПЛК сам по себе нечем не поможет если программист не приложит усилий по декомпозиции, профайлингу и оптимизации.
Ваша позиция похожа на "программистами не становятся, ими рождаются". Но большинство задач по автоматизации локальных объектов не требуют ничего из вышеперечисленного.
Работая в техподдержке насмотрелся на программы в которых не было никакой декомпозиции, все было на одном холсте при помощи графических языков. Но программа работала, приносила деньги бизнессу и все были счастливы.
Кроме меня, у которого кровь из глаз шла от созерцания таких картин.
Подводя итог:
* у каждого инструмента свое назначение, и не стоит забивать гвозди микроскопом.
МЭК хорош именно тем, для чего он создан: низкий порог вхождения и визуальное представление кода, которое легко понять как бизнесу, инженерам так и программистам.
* Правильный дизайн софта важен, но не необходим. Бизнес будет рад исправно работающему говнокоду.
Имел дело с CODESYS и с чистым и в форме ребрендинга в PLC от Wago.
Это тормоз каких поискать. IDE очень неудобное и ограниченное.
По гибкости визуальной нотации значительно уступает Stateflow.
Я бы сказал что CODESYS и является тем метафорическим микроскопом.
Я никак не могу связать его популярность с некоей простой.
Там ноги растут из шаблонизации отраслевых задач.
Да и говнокод понятие уловное. После Stateflow получаются такие исходники на C++ что снесет крышу любому. Но сам алгоритм в исходной графической нотации может быть весьма элегантным. Другое дело что на ST в PLC тот же алгоритм не поместится в рамки цикла. Просто потому что МЭК-овские PLC очень медленно исполняют ST.
Добрый день, во первых языки стандарта IEC61131-3 абсолютно нормальные, а самый популярный не ST, а LD, так как самый быстроориентируемый, на больших производствах это очень важно и вТЗ очень часто указывают использовать при разработке только его. Второе это "библиотеки", о, это краеугольный камень всех IT, такое ощущение что большинство итэшников забыли как писать ручками сложные алгоритмы и используют только библиотеки (API), касательно библиотек, все верно сказано было у каждого производителя свой набор, остальное пишешь сам, третье в мире АСУ ТП нет такого комьюнити как у IT, причина проста, у нас уровень зароботка в десятки раз ниже, в IT даже полный 0 в виде джуна будет иметь свои 800-1000 долларов, у АСУ ТП эти цифры достигаются уже у мидлов и то не во всех компаниях, выход фриланс, но тут много нюансов, так как в АСУ ТП ты когда пишешь программу ты отвечаешь за работу механизмов которые могут стоить ну очень дорого, то и не каждый заказачик пойдет на заказ системы автоматизации через фриланс, без подписания договора и открытой оплаты с НДС, это вам не сайтик или приложенице на телефон написать, в АСУ ТП кроме программирования нужно знать как работает тот или иной механизм, уметь работать с ПЧ, сервоприводами, шаговиками, ДПТ, знать как работает гидравлика и пневматика, что то я отешел от зарплат, так вот если ты новичек то твоя ЗП будет не выше 300 долларов, если ты мидл то 500-1000, так зачем мне делиться опытом решения той или иной проблемы с другим инженером если он по факту мой конкурент ?! Я разработал свои библиотеки или FB или addon если это allen bradley и могу решить ту или иную задачу за хорошие деньги (больше чем указал ранее), так зачем мне этим делиться с кем то ? это в ЕС и США инженеры по автоматизации зарабатывают на уровне с IT, а в СНГ к нам относятся как к рядовой профессии и не хотят нормально платить ,поетому и такое отношение друг к другу. Касательно ПЛК аргумент "дешевыми" не совсем правдив, топовые ПЛК у siemens или AB достигают цен до 14000-16000 евро и это без единого входа и выхода, модули ввода вывода покупаются отдельно, по поводу надежности, это да, любой ПЛК в десятки раз надежнее ПК, ПЛК могут стоять на установках по 10,20,30 лет и работать, их не нужно чистить от пыли, менять термопасту, менять оперативку или проц, все в одном камне, который так не греется, который работает все эти годы и хорошо выполняет свои функции ,по поводу протоколов, да все вышеперечисленные протоколы используются, но так же на всех современных ПЛК есть ethernet, который поддерживает разные протоколы Ethernet IP,Modbus TCP, Indastrial Ethernet, у основных производителей свои протоколы, но при этом если нужно то можно поставить дополнительный коммуникационный модуль с нужным протоколом. Подитожу, IT реально лучше не лезть в пром.автоматизацию, у вас нет такого понятия как ответственность, у вас если что то написано криво, то вряд ли что то сломается, у нас же все наоборот, за код без комментариев можно получить по шапке, для вас же один коммент в 50 строк это норм, поетому не нужно влазить туда где ты ничего не понимаешь с аргументами, а не вопросами.
С уважением ко всем разработчикам и автору.
Комментарий как отдельная статья. Спасибо за мнение. Думаю мы дождёмся того момента, когда на ПЛК будет устанавливаться любая ОС и программироваться будет любым ЯП, а ПЛК он будет называться так как будет устанавливаться на дин-рейку и у него будут разьёмы для подключения различных модулей.
Да это так, а куда ты зайдешь с этими ПЛК ? На больших предприятиях есть политика разрешенного оборудования и используемых стандартов, к примеру в металлургии в основном это siemens, AB, Шнейдер Электрик, в атомной промышленности в основном siemens у них очень много решений в данном направлении, в нефтедобычи и переработке GE, нужно понимать что кроме разработки и запуска, есть еще эксплуатация, вышеперечисленные вендоры имеют просто обалденную ТП, так как им важно что именно их оборудование стояло на больших концернах, а какую ТП даст китайский ПЛК без имени и даты выхода, но с возможность прожить на чем угодно ?! на маленьких системах можно использовать чт угодно, хоть ардуинку воткни туда, заказчику пофиг, большие объекты требуют гораздо больше чем просто написать код, а гарантии, чего только стоит дать гарантии на оборудование, домна при остановке теряет в час десятки тысяч долларов, думаю большим дядям это не очень понравиться, дашь ли ты гарантии что из за дешманского ПЛК на linux не произойдет остановки оборудования ?! Опять же, при возникновении проблемы инженер АСУ ТП должен очень быстро в коде найти в чем же проблема и принять решить данную проблему, имнно поетому и используется в основном ЯП LD, так как он для этих задач оптимален, при использовании текстовых ЯП все будет дольше и менее удобно для эксплуатации, LD же построен на базе электрических принципиальных схем, что дает возможность быстро определить в чем неисправность. Нет пока на данный момент нет идеального решения в данной сфере что бы покрыть большие объекты и использовать ПЛК на базе Linux, ни один большой заказчик на это не пойдет, а именно они и диктуют правила игры.
Думаю да, это произойдет, сейчас двигателем развития данной отрасли является желание вендора заработать, в связи с этим затраты на изготовление оборудования уменьшаются, моржа растет, но Китай ломает рынок очень сильно в последнее время, я работаю со многими призводителями, ОВЕН,Siemens, Allen Bradley, Delta Electronics, Omron и скажу так Delta Electronics это китай, хороший качественный китай, который по возможностям не то что не уступает амерам и ЕС, но во многом превосходит, а главное есть возможность писать код на С, макросы для SCADA и HMI так же пишутся в двух вариантах, либо С либо VB, что дает много возможностей для реализации различных "хотелок", Codesys кстати уже является платформой которая объеденяет многих производителей, вполне возможно что именно эта платформа и станет тем к чему прийдут все производители железяк, все таки возможности этой платформы очень велики. чт отут говорить если это на данный момент единственная платформа которая умеет на ПК векторное 12ти координатное управление сервоосями с отрисовкой и изменением парметров в реальном времени при использовании специальных ПЛК для пром.роботов, библиотеки конечно платные, но тут можно понять разрабов, платформу все таки они дают бесплатно, за спец.функции надо платить, людям нужно зарабатывать деньги и кормить семьи. Так же одним из вариантов ухода от ПЛК это использование ПК, через СОМ порт или по ethernet подключаются модули ввода/вывода допустим ОВЕН (modbus rtu/asci,modbus tcp), код пишется на С++ и крутиться на ПК, при этом отображалки можно сделать так же любые, WEB к примеру, на некоторых маленьких объектах это работает, что не сказать что прям сильно удишевляет стоимость оборудования, но возможностей по алгоритмии, архивации, аналитике за счет С++ добавляет точно.
К стати да, по поводу ответственности неистово плюсую.
Перешел из АСУ ТП в IT (embedded + около него), я был удивлен на сколько люди безалаберно подходят к разработке и не понимают слова "надежность".
ASSERT в каждой функции, чтобы не проверять корректность входных параметров. И по любому из assert'ов контроллер ребутается.
Дошло до смешного: при посылке команды по блютузу контроллер ребутался по из-за проваленного assert'a. Внешне выглядело так, как будто все работает как надо (по этой команде должен был происходить переход из режима конфигурации в рабочий режим). Заметили через пол-года.
Тесты?
а зачем, их же поддерживать надо
Переиспользуемый код?
А нужно ли переиспользовать код?
И это дословные комментарии от Senior Developer'a
А в стиме есть TIS-100, похоже? :)
Мне надо будет делать софт для измерителя расхода факельных газов. Заодно и выбрать контроллер для него. Так как я уже имел дело с разными ардуинами и RP pico, я подумал, что можно было бы сделать комбинацию из нескольких контроллеров (один общается с сенсорами, другой – выводит инфу на экран и накапливает данные.) Но мне все время казалось, что подобное решение для нефтегаза может не прокатить – как раз потому, что там, по идее, должны быть свои железки, соответствующие суровым производственным требованиям.
В связи с этим – вопрос: какое железо допустимо (необходимо) использовать в подобных задачах? Где об этом можно почитать (хотя бы какие ключевые слова использовать для поиска)?
Сам софт должен быть достаточно простой – принять данные от сенсоров, обработать по заданной формуле, сохранить на флешке, показать на экране, отослать в центральную диспетчерскую. Ну и какое-никакое меню управления для ввода/коррекции параметров и просмотра данных, если будет нужно.
Еще вопрос – есть ли контроллеры, которые можно ставить непосредственно в газовый поток? Типа измерить на месте давление и отослать данные в центральный блок?
Центральная диспетчерская по какому протоколу опрашивать будет? Там скада какая то?
На объекте GSM канал? К интернету доступ есть по Ethernet?
Датчик давления с развязкой по взрывобезопасности. Остальное промышленный ПК или простой контроллер с интерфейсом.
Температурные условия УХЛ или в здании работать будет?
Много данных выводить нужно на экран?
Бюджет проекта сильно ограничен?
Надо бы над ТЗ покумекать...
С точки зрения промышленной автоматики, задачка не сложная. И оборудование подобрать можно.
А вот со стандартами для НЕФТЬ-ГАЗ придётся поработать.
Расходомер то (первичный измеритель) уже есть или подбирать с нуля нужно?
Опять же исходить надо из критерия масштабируемости.
Если сенсоров может стать внезапно не 2-3, а 200-300 то надо ставить PLC.
Если же всегда будет не больше пары, но объектов десятки, то своя плата на контроллере c поддержкой Product Longevity Program (PLP) чтоб не пришлось потом для ремонта покупать чипы по 300$ как теперь продают некоторые STM32 раньше стоившие 10$.
Если пара датчиков на одном объекте, то конечно ардуино.
Сплотить это токсичное коммьюнити практически невозможно. Часть причин тут уже указали в комментах, часть просто ими же проиллюстрировали. Напоминает игровое ру-коммьюнити, только без открытого мата, потому что репутация фирмы и всё такое.
И я не сильно то исключение, ибо читать статьи с содержанием базового мануала или "как я нашёл меркер в коде", мягко говоря, не интересно, а все реально ценные вещи каждый бережёт для себя, как конкурентное преимущество.
Отдельно я шизею с истерик (вместо "о, вы ещё не пользуетесь ими? Почитайте тут и тут, есть хорошие решения для вашей среды разработки " - товарищи исходят соплями и ругань какие все, кроме них, нехорошие, а они герои и юзают SVC/mathlab/*вставить своё название*) о системах контроля версий и заявлений о генерации кода из матлаба или ещё откуда. Для малых организаций и постоянно меняющихся ТЗ (в комплекте с фатальными ошибками по монтажу железа) и первое и второе смысла не имеют, только сожрут силу и время.
Ок, приведите пожалуйста пример (можно ссылкой на описание/статью) как реализовывается система контроля версий для TIA Portal (кроме v17 с Git-репозитариями, которые тоже довольно убоги). И для электрических схем (AutoCAD/EPlan). Будет интересно ознакомиться и оценить соотношение затрат сил/времени на развёртку+использование по сравнению с обычными бэкапами папок проектов по расписанию на сервер Synology с глубиной лога версий 10+.
PDM
Ну, в смысле PDM, а не то что вы подумали:)
Солид или Компас. Вместе с чертежами и схемами.
У проектировщиков свои системы контроля версий:)
VersionDog
Если в «классических» ЯП (языках программирования) первая программа выводит в консоль «Hello, world!»
Для ПЛК как и для голых микроконтроллеров как аналог Hello, world применяется «подёргать выходом». Чтобы убедиться — да, железка программируется и в принципе работает.
Но главной проблемой я считаю отсутствие площадок для обмена опытом между специалистами данной области.
Есть форумы, в том числе и русскоязычные. Например, https://asutpforum.ru
Главной проблемой является поголовье PLC на промплощадях и их жизненный цикл, а уж потом форумы и сообщества. К примеру там, где нет жестких требований применения стандарта IEC 61131-3 , и все только начинается, IPC как правило выигрывают начиная от применения их в медицине, сельском хозяйстве, логистике и заканчивая космосом.
Всё не то и всё не так — когда твой компьютер ПЛК