Статья указывает на особенности разработки для промышленных контроллеров. Написана для объеденения программистов данного направления.
Кто такой этот ваш ПЛК
ПЛК (программируемый логический контроллер) – компьютер с особенностями развития. Главные требования к ПЛК: надёжность, низкая стоимость, быстрая реакция на входные воздействия, простота программирования. Данные требования привели к тому, что большинство производителей для своих ПЛК выпускают нативные среды исполнения и разработки. Но нельзя не отметить CodeSys – общеизвестный разработчик ПО для программирования ПЛК.
Несмотря на многообразие сред исполнения и разработки, программы пишутся на языках стандарта IEC 61131-3:
-
Графические языки программирования:
LD (Ladder diagram)
FBD (Function Block Diagram)
-
Текстовые языки программирования:
IL (Instruction list)
ST (Structured Text)
Реализации стандарта у разных производителей могут несущественно отличаться. Единый стандарт позволяет без особых проблем переносить код из одной среды программирования в другую.
Не как все
Самый "нормальный" язык из IEC 61131-3 – ST, который считается высокоуровневым языком программирования. Хочу обратить внимание, что под языком программирования подразумевается спецификация – правила написания кода. Время выполнения одного кода может меняться в зависимости от компилятора.
Самый важный момент, который стоит изучить, перед тем как писать код – это понимание принципов работы ПЛК. На рис. 1 изображена максимально упрощённая схема работы ПЛК.
Рисунок 1 -- Принцип работы ПЛК
Из рис. 1 нужно понять, что ваш код будет выполняться каждый цикл. Время цикла -- это время, которое нужно ПЛК для считывания входов, выполнения своих системных вызовов, выполнения вашей программы и формирования выходных значений. Обычно время цикла измеряется в микро- или миллисекундах.
Если в "классических" ЯП (языках программирования) первая программа выводит в консоль "Hello, world!", то в средах разработки программ для ПЛК вы консоли не увидите. Отладка происходит обычно во время выполнения программы, путём постановки точек останова, значения переменных в режиме отладки обычно накладываются на код, где они используются, причём значения можно изменять при отладке.
Прежде чем отлаживать проект – его нужно написать. И тут можно столкнуться со многими проблемами.
Сперва придётся ознакомиться со структурными единицами проекта: program organization units (POUs). POU может быть представлен как программа, функциональный блок или функция. У каждого элемента свои особенности. Типы данных такие же как и в других ЯП. Объявление переменных происходит в отдельной области перед кодом программы.
Следующая проблема – это подключение библиотек. Разные ПЛК используют разные ОС, устройства и протоколы. GitHub на моё удивление не знает про существование ST. В связи с этим остаётся надеяться на наличие нужных вам библиотек у производителя ПЛК. В случае наличия нужной библиотеки вам в редких случаях придётся ещё заплатить за её использование.
Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл – проследить изменения будет сложно, не говоря уже про слияние проектов. Иногда производители предусматривают нативные инструменты для сливания(сравнивания проектов).
Все знают про самый используемый стек протоколов TCP/IP, но в промышленной автоматизации есть игроки поважнее, связано это с тем, что сетевые карты для Ethernet/IP/TCP стека довольно дорогие и требовательные к ресурсам устройства и устанавливать её в простенький блок питания или расходомер нерационально. На сцену выходят RS-232, RS-485, ModBus, CAN, ProfiBus, EtherCAT etc. Кроме знания протокола придётся "поковыряться" с мануалом, чтобы понять как формировать сообщения и какие ждать ответы.
Нормальные люди под frontend-ом понимают HTML, CSS, JS, у автоматизаторов это SCADA или HMI. Если кратко, то это ПО для разработки пользовательского интерфейса. Подавляющее число SCADA взаимодействуют с ПЛК посредством OPC-сервера.
При возникновении ошибок или если не знаете как реализовать ту или иную функцию, то Stack Overflow вам навряд ли поможет – скорее всего вам придётся "ковыряться" в документации производителя ПЛК.
Пора кончать
Получилось много текста, но это меньше капли в океане промышленной автоматизации. Каждой проблеме можно посвятить отдельную статью.
Но главной проблемой я считаю отсутствие площадок для обмена опытом между специалистами данной области. Данная статья нужна для привлечения внимания. Все проблемы решатся быстрее, если о них будут все знать, если решения будут проверены множеством специалистов.
Для дальнейших дискусий и связи предлагаю telegram чат и канал.
Ну и не забываем оставлять свои мысли и замечания в комментах. Надеюсь устроить хоть небольшой движ в этой сфере.
Комментарии (49)
XopHeT
02.09.2021 09:09Понятно что библиотеки для поддержки "железа" т.е. драйвера - это минимум, который производитель должен предоставлять.
Я больше говорил о библиотеках которые будут использоваться при разработке бизнес-логики.
Но, в моем представлении, разработка ПО для ПЛК это больше разработка бизнес-логики и здесь есть достаточно возможностей для разработки кода не завязанного на ПЛК конкретного производителя.
Особенно, учитывая что в CODESYS есть полноценный ООП.
mcu_by
01.09.2021 15:20+5"GitHub на моё удивление не знает про существование ST" - знает. Есть опенсорный отличный проект matiec. Разные ПЛК используют разные ОС, не на всех ПЛК есть ОС, некоторые вообще работают на ПЛИС, а компилятор имеет структуру IEC 61131-3 -> LLVM IR -> RTL (Verilog или VHDL), некоторые работают на мк на baremetal, без ОС. "Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл" - многие IDE хранят файлы проекты и сам "код" в формате XML. Использовать систему контроля версий - нужно использовать всегда, 21 век. Неужели, кто до сих пор хранит файлы в архивах и т.п, и формируя бессмысленные названия для файлов.
Efi-fi Автор
01.09.2021 15:27Вот пытаюсь найти репозитории на ST, но всписке его нет. Это имелось ввиду, под словами что GitHub не знает про ST.
И, согласен с вами, что сегодня без систем контроля версий сложно сделать что-нибудь стоящее. Думаю со временем код ST будет у всех производителей храниться в виде простого текста.
VolodjaT
01.09.2021 15:20+6Но главной проблемой я считаю отсутствие площадок для обмена опытом между специалистами данной области. Данная статья нужна для привлечения внимания. Все проблемы решатся быстрее, если о них будут все знать, если решения будут проверены множеством специалистов.
Для дальнейших дискусий и связи предлагаю telegram чат и канал.И как телеграм канал поможет находить другим решения? Они уже индексируются в гугле? (как форумы)
Efi-fi Автор
01.09.2021 15:32-7Заходишь в чат и спрашиваешь, что тебе нужно, потом тебе отвечает человек, который это знает и помогает тебе решить проблему. Форумы отличная тема, но они обычно принадлежат производителям ПЛК, как было сказано выше. На StackOverflow редко можно найти ответ на свою проблему, так как сообщество не самое большое и раздроблено по производителям.
EwgenW
01.09.2021 16:05+1Главные требования к ПЛК: надёжность, низкая стоимость, быстрая реакция на входные воздействия, простота программирования.
Спорно, очень спорно.
Tujh
01.09.2021 16:30+2Зависит от того, с чем сравнивать. Если брать комплекс из нескольких измерительных приборов и регистраторов, плюс какой-нибудь регулятор, против одного простенького PLC с двухстрочным экраном, то действительно может выйти дешевле.
hahenty
01.09.2021 16:40+1"Накатать программу с архивацией и отображением показаний" выравнивает суммарную стоимость.
F0iL
01.09.2021 19:02+2Это до тех пор, пока вам нужно сделать не штучный объект, а целую серию из 100-500 шкафов в рамках одного проекта, и так каждый год. Тогда сэкономить можно очень и очень хорошо.
Indemsys
01.09.2021 17:08Статья во многом некорректная.
Я бы назвал у PLC одно преимущество - масштабируемость.
Легко перейти от 10 входов-выходов к тысяче.
В остальном же они дороже, медленней, больше потребляют энергии, больше требуют объема.
Современные PLC уже не являются однозадачными. Даже в дешевых линейках есть возможность делать несколько задач и обмен вести через события. У задач есть приоритеты.
Т.е. необходимость планирования приоритетов встает в полный рост.
Проблема уложиться в реальное время в PLC также сложна как и на голых микроконтроллерных платформах. В PLC с МЭК сложнее делать детализированный профайлинг.
С другой стороны исходники на языке ST очень качественно генерирует MATLAB.
Поэтому ST и многие библиотеки уже можно не изучать.
Последний проект на PLC делал вообще не читая IEC 61131-3 и спецификации ST.XopHeT
01.09.2021 18:43Я бы назвал у PLC одно преимущество - масштабируемость.
Вы упускаете из виду и низкий порог вхождения благодаря графическим языкам. Это очень большое преимущество: для инженера разбирающегося в процессе не составит труда разработать программу для автоматизации.
Это я бы назвал главным преимуществом.
Все остальное вторично.Последний проект на PLC делал вообще не читая IEC 61131-3 и спецификации ST.
Тогда, скорее всего, вы не использовали всех возможностей, которые предоставляет платформа и программировали так же, как будто это C, Python и пр.
Работает? Да.
Эффективно ли? Сопровождаемо ли? Хорошие вопросы.Современные PLC уже не являются однозадачными.
Странная фраза, не пойму зачем здесь.
Даже очень старые ПЛК были многозадачными, многозадачность, только была замещающая.
Но необходимость задавать приоритеты была и тогда. Проблема ли это?
Если да, то пишите все в одной задаче.
Но, честно говоря, не вижу особой проблемы вписаться в цикл ПЛК. Если, конечно, подходить к разработке так, как это принято в ПЛК: не писать блокирующий код.Indemsys
01.09.2021 22:53+1Для алгоритмов с конечными автоматами на десяток состояний вхождение будет достаточно быстрым. Не спорю. Особенно если алгоритмы типовые.
Но когда автоматы разрастаются до сотен состояний ПЛК c МЭК будет совершенно недееспособен. Тут уже нужны будут языки высокого уровня типа C++.
Библиотеки ПЛК не помогут.
Алгоритмы на MATLAB Stateflow это не Python, не надо путать. Это графическая нотация гораздо более мощная чем графические нотации МЭК.Многозадачность нужна для того чтобы как раз уложится в жесткие рамки цикла обмена по внешней шине. Если все реализовать в одной задаче то даже простенькие алгоритмы не успевают завершиться за цикл. Просто диаграмма единственного цикла у автора в статье в принципе не верна. И ПЛК сам по себе нечем не поможет если программист не приложит усилий по декомпозиции, профайлингу и оптимизации.
XopHeT
02.09.2021 11:57Но когда автоматы разрастаются до сотен состояний ПЛК c МЭК будет совершенно недееспособен.
А вы точно понимаете о чем говорите?
Потому что, на сколько мне известно, в МЭК выполняются только активные состояния. Остальные даже не просчитываются. Поэтому нет разницы будет ли это 10 состояний, 100 или 1000.Алгоритмы на MATLAB Stateflow это не Python, не надо путать. Это графическая нотация гораздо более мощная чем графические нотации МЭК.
Разрабатываю сейчас на Stateflow. Разницы не замечаю по сравнению с SFC.
Те же состояния, условия, переходы и действия.
Да, в MatLab есть FlowChart, но на ПЛК это может быть код на ST. Суть от этого не меняется.
ЧЯДНТ?
К стати, было бы интересно посмотреть на вашу реализацию StateMachine на C++ (или, не дай Б-г на C) на 100+ состояний. И на читабельность такого кода.Многозадачность нужна для того чтобы как раз уложится в жесткие рамки цикла обмена по внешней шине.
Обмен по внешней шине, и, тем более соблюдение мили- и микро-секундных таймингов естественно нужно реализовывать на других ЯП.
МЭК это про бизнес-логику, а не про драйвера и BoardSupportPackage. Вряд ли кому-то в здравом уме прийдет в голову писать драйвер RS485 на МЭК.Просто диаграмма единственного цикла у автора в статье в принципе не верна.
Верна. В том же CODESYS с вытесняющей многозадачностью, в рамках каждой задачи происходит чтение входов - обработка - запись выходов.
И ПЛК сам по себе нечем не поможет если программист не приложит усилий по декомпозиции, профайлингу и оптимизации.
Ваша позиция похожа на "программистами не становятся, ими рождаются". Но большинство задач по автоматизации локальных объектов не требуют ничего из вышеперечисленного.
Работая в техподдержке насмотрелся на программы в которых не было никакой декомпозиции, все было на одном холсте при помощи графических языков. Но программа работала, приносила деньги бизнессу и все были счастливы.
Кроме меня, у которого кровь из глаз шла от созерцания таких картин.Подводя итог:
* у каждого инструмента свое назначение, и не стоит забивать гвозди микроскопом.
МЭК хорош именно тем, для чего он создан: низкий порог вхождения и визуальное представление кода, которое легко понять как бизнесу, инженерам так и программистам.
* Правильный дизайн софта важен, но не необходим. Бизнес будет рад исправно работающему говнокоду.Indemsys
02.09.2021 12:44Имел дело с CODESYS и с чистым и в форме ребрендинга в PLC от Wago.
Это тормоз каких поискать. IDE очень неудобное и ограниченное.
По гибкости визуальной нотации значительно уступает Stateflow.
Я бы сказал что CODESYS и является тем метафорическим микроскопом.
Я никак не могу связать его популярность с некоей простой.
Там ноги растут из шаблонизации отраслевых задач.
Да и говнокод понятие уловное. После Stateflow получаются такие исходники на C++ что снесет крышу любому. Но сам алгоритм в исходной графической нотации может быть весьма элегантным. Другое дело что на ST в PLC тот же алгоритм не поместится в рамки цикла. Просто потому что МЭК-овские PLC очень медленно исполняют ST.
Ar4uk_EI
01.09.2021 19:59+3Добрый день, во первых языки стандарта 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 строк это норм, поетому не нужно влазить туда где ты ничего не понимаешь с аргументами, а не вопросами.
С уважением ко всем разработчикам и автору.Efi-fi Автор
01.09.2021 20:12Комментарий как отдельная статья. Спасибо за мнение. Думаю мы дождёмся того момента, когда на ПЛК будет устанавливаться любая ОС и программироваться будет любым ЯП, а ПЛК он будет называться так как будет устанавливаться на дин-рейку и у него будут разьёмы для подключения различных модулей.
F0iL
01.09.2021 20:28+1Уже давно существуют ПЛК на базе WinCE и Linux, которые могут программироваться по сути дела чем угодно, лишь бы был компилятор под архитектуру его процессора.
Ar4uk_EI
01.09.2021 20:56+1Да это так, а куда ты зайдешь с этими ПЛК ? На больших предприятиях есть политика разрешенного оборудования и используемых стандартов, к примеру в металлургии в основном это siemens, AB, Шнейдер Электрик, в атомной промышленности в основном siemens у них очень много решений в данном направлении, в нефтедобычи и переработке GE, нужно понимать что кроме разработки и запуска, есть еще эксплуатация, вышеперечисленные вендоры имеют просто обалденную ТП, так как им важно что именно их оборудование стояло на больших концернах, а какую ТП даст китайский ПЛК без имени и даты выхода, но с возможность прожить на чем угодно ?! на маленьких системах можно использовать чт угодно, хоть ардуинку воткни туда, заказчику пофиг, большие объекты требуют гораздо больше чем просто написать код, а гарантии, чего только стоит дать гарантии на оборудование, домна при остановке теряет в час десятки тысяч долларов, думаю большим дядям это не очень понравиться, дашь ли ты гарантии что из за дешманского ПЛК на linux не произойдет остановки оборудования ?! Опять же, при возникновении проблемы инженер АСУ ТП должен очень быстро в коде найти в чем же проблема и принять решить данную проблему, имнно поетому и используется в основном ЯП LD, так как он для этих задач оптимален, при использовании текстовых ЯП все будет дольше и менее удобно для эксплуатации, LD же построен на базе электрических принципиальных схем, что дает возможность быстро определить в чем неисправность. Нет пока на данный момент нет идеального решения в данной сфере что бы покрыть большие объекты и использовать ПЛК на базе Linux, ни один большой заказчик на это не пойдет, а именно они и диктуют правила игры.
EwgenW
03.09.2021 09:16LD , на мой взгляд годится для небольших проектов . Имел несчастье работать с проектом на ЛД на объекте с 80+ аналоговых каналов и ок 100 дискретных - это тихий ужас. Имхо ST в таких случаях удобнее и читаемее .
Ar4uk_EI
01.09.2021 20:31+1Думаю да, это произойдет, сейчас двигателем развития данной отрасли является желание вендора заработать, в связи с этим затраты на изготовление оборудования уменьшаются, моржа растет, но Китай ломает рынок очень сильно в последнее время, я работаю со многими призводителями, ОВЕН,Siemens, Allen Bradley, Delta Electronics, Omron и скажу так Delta Electronics это китай, хороший качественный китай, который по возможностям не то что не уступает амерам и ЕС, но во многом превосходит, а главное есть возможность писать код на С, макросы для SCADA и HMI так же пишутся в двух вариантах, либо С либо VB, что дает много возможностей для реализации различных "хотелок", Codesys кстати уже является платформой которая объеденяет многих производителей, вполне возможно что именно эта платформа и станет тем к чему прийдут все производители железяк, все таки возможности этой платформы очень велики. чт отут говорить если это на данный момент единственная платформа которая умеет на ПК векторное 12ти координатное управление сервоосями с отрисовкой и изменением парметров в реальном времени при использовании специальных ПЛК для пром.роботов, библиотеки конечно платные, но тут можно понять разрабов, платформу все таки они дают бесплатно, за спец.функции надо платить, людям нужно зарабатывать деньги и кормить семьи. Так же одним из вариантов ухода от ПЛК это использование ПК, через СОМ порт или по ethernet подключаются модули ввода/вывода допустим ОВЕН (modbus rtu/asci,modbus tcp), код пишется на С++ и крутиться на ПК, при этом отображалки можно сделать так же любые, WEB к примеру, на некоторых маленьких объектах это работает, что не сказать что прям сильно удишевляет стоимость оборудования, но возможностей по алгоритмии, архивации, аналитике за счет С++ добавляет точно.
argentumbolo
02.09.2021 21:13> скажу так Delta Electronics это китай, хороший качественный китай
Немного поправлю - Delta Electronics это Тайвань.
И сравнивать их можно скорее с Mitsubishi Electric чем с Siemens.Ar4uk_EI
05.09.2021 09:20Добрый день, по среде разработки нет, ISPsoft не плохо так содрал именно у siemens и allen bradley, у мтсубанов софт сырой очень, для больших проектов вообще не подходит по ряду причин.
XopHeT
01.09.2021 21:38К стати да, по поводу ответственности неистово плюсую.
Перешел из АСУ ТП в IT (embedded + около него), я был удивлен на сколько люди безалаберно подходят к разработке и не понимают слова "надежность".
ASSERT в каждой функции, чтобы не проверять корректность входных параметров. И по любому из assert'ов контроллер ребутается.
Дошло до смешного: при посылке команды по блютузу контроллер ребутался по из-за проваленного assert'a. Внешне выглядело так, как будто все работает как надо (по этой команде должен был происходить переход из режима конфигурации в рабочий режим). Заметили через пол-года.
Тесты?
а зачем, их же поддерживать надо
Переиспользуемый код?
А нужно ли переиспользовать код?
И это дословные комментарии от Senior Developer'a
F0iL
02.09.2021 10:58Тесты?
> а зачем, их же поддерживать надо
Переиспользуемый код?
> А нужно ли переиспользовать код?Embedded все-таки очень сильно отличается от остального IT-мира, и да, наплевательское отношение к коду, архитектуре, отсутствию тестов, я неоднократно наблюдал своими глазами как раз на стыке АСУТП и embedded, о чем написал в своей вчерашней статье.
В то время как в "остальном IT" даже в какой-нибудь веб-разработке на захудалой галере за такое обычно очень больно бьют по рукам и подобный говнокод даже не пройдет ревью.
michael108
02.09.2021 16:45Народ, может, кто чего посоветует.
Мне надо будет делать софт для измерителя расхода факельных газов. Заодно и выбрать контроллер для него. Так как я уже имел дело с разными ардуинами и RP pico, я подумал, что можно было бы сделать комбинацию из нескольких контроллеров (один общается с сенсорами, другой – выводит инфу на экран и накапливает данные.) Но мне все время казалось, что подобное решение для нефтегаза может не прокатить – как раз потому, что там, по идее, должны быть свои железки, соответствующие суровым производственным требованиям.
В связи с этим – вопрос: какое железо допустимо (необходимо) использовать в подобных задачах? Где об этом можно почитать (хотя бы какие ключевые слова использовать для поиска)?
Сам софт должен быть достаточно простой – принять данные от сенсоров, обработать по заданной формуле, сохранить на флешке, показать на экране, отослать в центральную диспетчерскую. Ну и какое-никакое меню управления для ввода/коррекции параметров и просмотра данных, если будет нужно.
Еще вопрос – есть ли контроллеры, которые можно ставить непосредственно в газовый поток? Типа измерить на месте давление и отослать данные в центральный блок?F0iL
02.09.2021 17:49Кмк, тут нужна железка как минимум промышленного исполнения. Те же Arduino или RPi вам просто ну никак не гарантируют стабильную работу, например, при наличии рядом источников электромагнитных помех, при нестабильном питании или при скачках температуры окружающей среды.
shnegs
03.09.2021 09:36Центральная диспетчерская по какому протоколу опрашивать будет? Там скада какая то?
На объекте GSM канал? К интернету доступ есть по Ethernet?
Датчик давления с развязкой по взрывобезопасности. Остальное промышленный ПК или простой контроллер с интерфейсом.
Температурные условия УХЛ или в здании работать будет?
Много данных выводить нужно на экран?
Бюджет проекта сильно ограничен?
Надо бы над ТЗ покумекать...
С точки зрения промышленной автоматики, задачка не сложная. И оборудование подобрать можно.
А вот со стандартами для НЕФТЬ-ГАЗ придётся поработать.
Indemsys
03.09.2021 15:23Опять же исходить надо из критерия масштабируемости.
Если сенсоров может стать внезапно не 2-3, а 200-300 то надо ставить PLC.
Если же всегда будет не больше пары, но объектов десятки, то своя плата на контроллере c поддержкой Product Longevity Program (PLP) чтоб не пришлось потом для ремонта покупать чипы по 300$ как теперь продают некоторые STM32 раньше стоившие 10$.
Если пара датчиков на одном объекте, то конечно ардуино.
F0iL
03.09.2021 15:58Я бы начал подбор с более детального анализа требований. Например, какие именно будут сенсоры, а именно, как они будут отдавать информацию: аналоговый сигнал, стандартный протокол (например Modbus RTU), или какой-то свой кастомно-упоротый протокол? По какому протоколу отдавать данные в диспетчерскую -- опять же, что-то стандартное, или как?
Если нужны аналоговые или дискретные сигналы для сенсоров или чего-то еще -- то нужно смотреть контроллер, у которого есть встроенные входы или модули расширения для таких сигналов. Если стандартный протокол -- то смотреть, чтобы в стандарной библиотеке контроллера были готовые функции/блоки для работы с ним, и чтобы портов ввода-вывода хватило на всё требуемое (минимум один порт на сенсоры, и то если они все работают под одинакаковому протоколу, один на связь с панелью/экраном оператора, один на связь с диспетчерской).
Если протокол нестандартный, либо не поддерживается из коробки -- смотреть, чтобы была возможность работать с портом напрямую и разрабатывать свои кастомные реализации (если контроллер на МЭКовских языках), либо выбирать что-то программируемое на C или C++, но обычно такое нужно согласовывать предварительно с зкаказчиком, такое не все любят.Я бы для такого взял какой-нибудь современный SCADAPack, они весьма надежные (лично видел как такой пахал в незакрытом шкафу, засыпанный снегом на половину), они поддерживают разработку и на мэковском LD, и на C/C++, богатая стандартная библиотека, можно работать с файлами на встроенной и на внешней usb-флешке. Но это может быть оверкилл, да и цена сильно кусается, конечно.
Либо что-то сильно попроще, типа ОВЕН, некоторые из них идут как панельные контроллеры (ПЛК и экран оператора в одном корпусе) или CILK.
EnerelStain
03.09.2021 13:52Сплотить это токсичное коммьюнити практически невозможно. Часть причин тут уже указали в комментах, часть просто ими же проиллюстрировали. Напоминает игровое ру-коммьюнити, только без открытого мата, потому что репутация фирмы и всё такое.
И я не сильно то исключение, ибо читать статьи с содержанием базового мануала или "как я нашёл меркер в коде", мягко говоря, не интересно, а все реально ценные вещи каждый бережёт для себя, как конкурентное преимущество.
Отдельно я шизею с истерик (вместо "о, вы ещё не пользуетесь ими? Почитайте тут и тут, есть хорошие решения для вашей среды разработки " - товарищи исходят соплями и ругань какие все, кроме них, нехорошие, а они герои и юзают SVC/mathlab/*вставить своё название*) о системах контроля версий и заявлений о генерации кода из матлаба или ещё откуда. Для малых организаций и постоянно меняющихся ТЗ (в комплекте с фатальными ошибками по монтажу железа) и первое и второе смысла не имеют, только сожрут силу и время.
F0iL
03.09.2021 16:02Системы контроля версий для малых организаций и для постоянно меняющихся ТЗ с ошибками проектирования имеют смысла даже больше, чем для больших и предсказуемых.
EnerelStain
03.09.2021 16:53Ок, приведите пожалуйста пример (можно ссылкой на описание/статью) как реализовывается система контроля версий для TIA Portal (кроме v17 с Git-репозитариями, которые тоже довольно убоги). И для электрических схем (AutoCAD/EPlan). Будет интересно ознакомиться и оценить соотношение затрат сил/времени на развёртку+использование по сравнению с обычными бэкапами папок проектов по расписанию на сервер Synology с глубиной лога версий 10+.
juray
06.09.2021 00:41+1Если в «классических» ЯП (языках программирования) первая программа выводит в консоль «Hello, world!»
Для ПЛК как и для голых микроконтроллеров как аналог Hello, world применяется «подёргать выходом». Чтобы убедиться — да, железка программируется и в принципе работает.
leon78
14.10.2021 10:35Но главной проблемой я считаю отсутствие площадок для обмена опытом между специалистами данной области.
Есть форумы, в том числе и русскоязычные. Например, https://asutpforum.ru
anonymous
XopHeT
На самом деле разрабатывать библиотеки не привязанные к железу конкретного производителя в CDS гораздо проще, но работодатель начинает возмущаться "А вот если они с нашей библиотекой пойдут на другой контроллер?".
Ну так сегодня пойдут, а завтра поймут, что у нас инфраструктура лучше и вернуться.
Кроме этого у CODESYS есть магазин, на котором можно кой-чего найти. Иногда даже не за баснословные (по меркам СНГ деньги), и форум у них есть. Не знаю, на сколько он сейчас жив, но года 3 назад ответ можно было получить относительно быстро.
В чем смысл общения между программистами CODESYS и Simatic, если, по большей мере, вещи написанные в одном не переносимы во второе?
Подходы, применяемые, конечно можно перенять. Но, как показывает практика даже при встрече люди стесняются\боятся говорить о своем опыте и своих ошибках.
Как-то подготавил выступление для конференции и показал коллеге на слайде "Как у нас было" на котором я рассказывал о ошибках, которые мы победили.
Коллега возмутился "УУУ ЭТО КАК ЭТО ТАК? НЕЛЬЗЯ такое говорить".
Есть и всякие штуки без привязки к конкретной среде разработки. Если интересно, на сайте оскат ру ребята выкладывают переводы документации и рекомендаций от PLCOpen. Иногда разбавляют оригинальными статьями.
Может пригодится.