Forwarded from Роботы на зарплате
Новое дополнение — глава 6.9 Синхронизация параллельного выполнения на 6 страницах . Соответствующие подразделы показывают, что речь идет о мьютексах и семафорах.
Глава 7.2 Список инструкций (IL) больше не включена в Издание 4. Это означает, что IL больше не является частью IEC 61131-3, но это не обязательно означает, что IL больше не предлагается производителями. Каждый производитель может продолжать решать для себя, хотят ли они предлагать IL в своей среде разработки или нет.
Издание 4 больше не поддерживает восьмеричные литералы (например , 8#267 ). В Издании 3 восьмеричные литералы уже были помечены как устаревшие.
Благодаря двум новым типам данных USTRING и UCHAR теперь также поддерживаются строки символов, в которых каждый символ кодируется в соответствии с UTF-8.
Функции символьных строк описаны в главе 6.6.2.5.12. Функции LEN_MAX и LEN_CODE_UNIT являются новыми дополнениями.
В строке или символьном литерале любой символ может быть указан кодом символа. Он указывается в шестнадцатеричной записи после $ в фигурных скобках.
Рисунок 11 в главе 6.6.1.6 Преобразование типов данных дает обзор неявных и явных преобразований типов данных. По сравнению с изданием 3, здесь есть некоторые корректировки и расширения.
Функции для преобразования типов данных между строками и ARRAY OF BYTE являются новыми дополнениями. Они описаны в главе 6.6.2.5.8 Преобразование типов данных между строковыми типами и массивом байтов.
Функция TRUNC была удалена. Эта нотация уже была помечена как устаревшая в издании 3 и теперь удалена из издания 4.
Издание 4 (наконец) определяет свойства. Свойства являются частью CLASS , FUNCTION_BLOCK или INTERFACE . Методы сеттера и геттера объявляются так, чтобы значение свойства можно было установить или прочитать. Объявление похоже на объявление метода. Однако вместо ключевого слова METHOD используются ключевые слова PROPERTY_GET и PROPERTY_SET.
В главе 6.6.2.5.17 Утверждения 4-го издания определяется функция ASSERT , которая имеет входной параметр IN типа BOOL и не имеет возвращаемого значения. ASSERT используется для проверки допустимости выражений или переменных во время разработки.
Глава 6.9 Синхронизация параллельного выполнения была добавлена в Издание 4 и определяет объекты и функции для синхронизации программного кода, который был разделен на несколько задач. Синхронизация требуется, например, если две параллельные программы обращаются к общей переменной, при этом одна программа также изменяет эту переменную.
В 4-м издании определены мьютексы и семафоры, упрощающие синхронизацию параллельно работающих программ.
Поддержка чисел BCD прекращена. В издании 4 следующие функции отмечены как устаревшие.
Ссылка на полный текст статьи: https://stefanhenneken.net/2025/06/11/iec-61131-3-comparison-of-edition-3-and-edition-4/
#iec61131
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
IEC61131-3_Serebrum.pdf
1.7 MB
Серебрум-IEC - открытие выставки. Вот такого продукта я точно не ожидал увидеть
Давайте начнем по порядку. Компания Серебрум выпускает свои контроллеры, модули расширения, имеет облачную СКАДа и свое окружение для разработки.
YART Studio вы могли видеть на моих стримах пару лет назад вместе с PLC Neon. Тогда среда разработки меня победила, я поставил им 5 из 10 и сказал, что они имеют большие перспективы.
Удивительно как все вышло.
Что же за продукт был представлен на выставке? Если очень просто - Codesys, если капать глубже, то становиться интереснее.
Это полный набор для работы с ПЛК: runtime, toolchain и ide.
Были убраны этапы трансляции кода МЭК в С, потом компилирование и т.д. а был взят LLVM.
Готовый набор для производителей своих ПЛК.
Получается будет свое ядро, с планировщиком задач, что очень важно, но и очень сложно. Свои все драйвера для периферии производитель интегрирует сам.
Планируют в первую очередь довести эту систему до одноплатников и вот тут уже можно будет затестировать полностью.
#АСУТП #IDE #ПЛК #ST #МЭК #Серебрум
"Я вам че - Автоматизатор?!"
Давайте начнем по порядку. Компания Серебрум выпускает свои контроллеры, модули расширения, имеет облачную СКАДа и свое окружение для разработки.
YART Studio вы могли видеть на моих стримах пару лет назад вместе с PLC Neon. Тогда среда разработки меня победила, я поставил им 5 из 10 и сказал, что они имеют большие перспективы.
Удивительно как все вышло.
Что же за продукт был представлен на выставке? Если очень просто - Codesys, если капать глубже, то становиться интереснее.
Это полный набор для работы с ПЛК: runtime, toolchain и ide.
Были убраны этапы трансляции кода МЭК в С, потом компилирование и т.д. а был взят LLVM.
Готовый набор для производителей своих ПЛК.
Получается будет свое ядро, с планировщиком задач, что очень важно, но и очень сложно. Свои все драйвера для периферии производитель интегрирует сам.
Планируют в первую очередь довести эту систему до одноплатников и вот тут уже можно будет затестировать полностью.
#АСУТП #IDE #ПЛК #ST #МЭК #Серебрум
"Я вам че - Автоматизатор?!"
👍8🤔3
Ночная рубрика "Что там по архитектуре"
Представим, что нам требуется выход одного функционального блока передать на вход другого функционального блока.
Пускай будет fb1.Out и fb2.IN.
Так вот как лучше это сделать?
Представим, что нам требуется выход одного функционального блока передать на вход другого функционального блока.
Пускай будет fb1.Out и fb2.IN.
Так вот как лучше это сделать?
Как лучше передать fb1.Out на fb2.In
Anonymous Poll
16%
fb1.Out=>fb2.In
61%
fb2.In:=fb1.Out
17%
Через структуру
6%
Свой вариант(комментарии)
Как один подшипник остановит завод
Специалисты СИБУРа обзорно рассказывают про системы предикативной аналитики, как они работают и как они сделали свою систему.
"Я вам че - Автоматизатор?!"
#АСУТП #СИБУР
Специалисты СИБУРа обзорно рассказывают про системы предикативной аналитики, как они работают и как они сделали свою систему.
"Я вам че - Автоматизатор?!"
#АСУТП #СИБУР
Хабр
Сибур инвестировал в систему диагностики, чтобы предотвратить миллионы убытков от аварий
Каждый день на нефтегазохимических заводах СИБУРа работают тысячи единиц оборудования. Компрессоры, насосы, турбины — все они крутятся, нагреваются, изнашиваются. И рано или поздно...
👎1🤔1
Иногда лучше не слушать подкасты, так как они заставляют вернутся к тому, что не доделал. Возвращаюсь к архитектуре ППО. Целью всех этих изысканий будет лишь формирование правил и подходов, как минимум для себя, для быстрого написания кода, его организации, масштабирования, отладки и сопровождения.
Для себя я хочу точно выделить логические слои и разграничить зоны ответственности между ними, сформировать правила взаимодействия и найти какие-то общие паттерны для упрощения стандартных решений.
Рассматривать все это будут с точки зрения классического подхода, без использования ООП.
В таком нелегком деле буду рад пообщаться по теме вопроса.
Сейчас для себя я выделил 5 основных логических слоев ППО. Слой входных/выходных данных, слой оборудования, слой технологического процесса и два слоя, которые взаимодействуют со всеми - слой пользовательского управления и слой безопасности.
По моим умозаключениям все фб внутри одного логического слоя могут напрямую взаимодействовать друг с другом, но передача между логическими слоями должна происходить только через специальные объекты передачи данных. При чем каждый логический слой вполне может быть самостоятельной программой
Слои пользовательского управления и безопасности могут быть интегрированы в каждый конкретный слой или также выступать самостоятельными сущностями.
Вот отталкиваясь вот от этой диаграммы я буду дальше раскручивать клубок. Так что если есть какие-то мысли, вопросы, предложения, то добро пожаловать.
#АСУТП #ППО #ПЛК #Архитектруа
"Я вам че - Автоматизатор?!"
Для себя я хочу точно выделить логические слои и разграничить зоны ответственности между ними, сформировать правила взаимодействия и найти какие-то общие паттерны для упрощения стандартных решений.
Рассматривать все это будут с точки зрения классического подхода, без использования ООП.
В таком нелегком деле буду рад пообщаться по теме вопроса.
Сейчас для себя я выделил 5 основных логических слоев ППО. Слой входных/выходных данных, слой оборудования, слой технологического процесса и два слоя, которые взаимодействуют со всеми - слой пользовательского управления и слой безопасности.
По моим умозаключениям все фб внутри одного логического слоя могут напрямую взаимодействовать друг с другом, но передача между логическими слоями должна происходить только через специальные объекты передачи данных. При чем каждый логический слой вполне может быть самостоятельной программой
Слои пользовательского управления и безопасности могут быть интегрированы в каждый конкретный слой или также выступать самостоятельными сущностями.
Вот отталкиваясь вот от этой диаграммы я буду дальше раскручивать клубок. Так что если есть какие-то мысли, вопросы, предложения, то добро пожаловать.
#АСУТП #ППО #ПЛК #Архитектруа
"Я вам че - Автоматизатор?!"
👍5🤔3🔥1
Облачные IIoT-решения для промышленной автоматизации от бренда EKF представлены на ведущих отраслевых выставках России
Компания «Электрорешения» (бренд EKF) представила на ключевых отраслевых выставках свои облачные IIoT-решения. Менеджер по развитию Кирилл Коземиров рассказал, как технологии помогают бизнесу решать конкретные задачи.
🎯 Ключевая проблема, которую закрывают решения:
Анализ простоев оборудования в реальном времени для снижения потерь и повышения управляемости производством.
💡 Что дают облачные IIoT-платформы (на примере EKF Connect Industry):
Упрощение: Быстрый запуск проектов по мониторингу удаленных объектов (генераторы, насосные станции, тепловые пункты) без сложных и дорогих SCADA-систем.
Глубокая аналитика: Легкий доступ к энергоменеджменту, анализу качества электроэнергии и прогнозированию сбоев оборудования.
Гибкость: Возможность настраивать оповещения (вплоть до Telegram-уведомлений) и создавать сложные сценарии на Python.
🏭 Примеры готовых решений:
Мониторинг АВР (автоматического ввода резерва).
Управление освещением с анализом эффективности.
Диспетчеризация тепловых пунктов (ИТП).
✅ Уже внедрено:
Платформа EKF работает в реальных проектах, например, для мониторинга 75 компрессорных станций на железной дороге и энергомониторинга на крупном химическом производстве.
Итог: Облачные сервисы EKF — это готовый инструмент для цифровизации, который делает передовую аналитику доступной для предприятий любого масштаба.
"Я вам че - Автоматизатор?!"
#индустрия40 #iiot #ekf
Компания «Электрорешения» (бренд EKF) представила на ключевых отраслевых выставках свои облачные IIoT-решения. Менеджер по развитию Кирилл Коземиров рассказал, как технологии помогают бизнесу решать конкретные задачи.
🎯 Ключевая проблема, которую закрывают решения:
Анализ простоев оборудования в реальном времени для снижения потерь и повышения управляемости производством.
💡 Что дают облачные IIoT-платформы (на примере EKF Connect Industry):
Упрощение: Быстрый запуск проектов по мониторингу удаленных объектов (генераторы, насосные станции, тепловые пункты) без сложных и дорогих SCADA-систем.
Глубокая аналитика: Легкий доступ к энергоменеджменту, анализу качества электроэнергии и прогнозированию сбоев оборудования.
Гибкость: Возможность настраивать оповещения (вплоть до Telegram-уведомлений) и создавать сложные сценарии на Python.
🏭 Примеры готовых решений:
Мониторинг АВР (автоматического ввода резерва).
Управление освещением с анализом эффективности.
Диспетчеризация тепловых пунктов (ИТП).
✅ Уже внедрено:
Платформа EKF работает в реальных проектах, например, для мониторинга 75 компрессорных станций на железной дороге и энергомониторинга на крупном химическом производстве.
Итог: Облачные сервисы EKF — это готовый инструмент для цифровизации, который делает передовую аналитику доступной для предприятий любого масштаба.
"Я вам че - Автоматизатор?!"
#индустрия40 #iiot #ekf
👍3🤨1
Выходной пост, который станет продолжением про Архитектуру ППО.
Сегодня представлю, как я, в первом приближении вижу обработку входного сигнала. Предназначение ФБ входного сигнала - это получить сигнал с «модуля», провести валидацию этого сигнала, сделать минимальные преобразования и выдать его дальше. Я считаю, что на выходе сигнал должен остаться сигналом. Проще всего это объяснить на примере аналогового сигнала.
Если на вход у нас поступают значения от АЦП, а это мы будем получать либо число от 0 до 65535, либо микроампера или милливольты, что не играет роли, то и на выходе мы должны получить что-то что будет связано с сигналом. Это может быть начальное значение, которое мы просто проверили или произошло линейное преобразование в проценты от 0 до 100, но никак не готовое значение давления/расхода/уровня(нужное подчеркнуть).
За сам процесс проверки и преобразования отвечают следующие поля
Signal - забирается с «модуля». На каждый сигнал есть структура Settings, которая будет храниться в Retain памяти ПЛК и иметь возможность ее изменения пользователем.
Далее у нас идет
Control - это тоже структура, которая содержит поля, необходимые для управления ФБ обработки сигнала. Сейчас я туда отношу симуляцию и маскирование, но не уверен, что им там самое место с точки зрения безопасности технологического процесса.
Последнее поле
Состояние «модуля», которое нам необходимо для небольшого контура безопасности, чтобы не обрабатывать заведомо мусорные значение и не пустить их в технологический процесс. Тут будут все наши обрывы линии связи, ошибки протоколов и т.д.
И на выходе остается
InputDataState - структура, которая содержит в себе информацию, необходимую и достаточную для информирования пользователя о состоянии входного сигнала. Value, в свою очередь, - готовый сигнал, которые прошел преобразование, валидацию, и является безопасным для логики системы. Его мы передаем в отдельную структуру для устройства, учавствующего в технологическом процессе.
#АСУТП #ППО #ПЛК #Архитектура
"Я вам че - Автоматизатор?!"
Сегодня представлю, как я, в первом приближении вижу обработку входного сигнала. Предназначение ФБ входного сигнала - это получить сигнал с «модуля», провести валидацию этого сигнала, сделать минимальные преобразования и выдать его дальше. Я считаю, что на выходе сигнал должен остаться сигналом. Проще всего это объяснить на примере аналогового сигнала.
Если на вход у нас поступают значения от АЦП, а это мы будем получать либо число от 0 до 65535, либо микроампера или милливольты, что не играет роли, то и на выходе мы должны получить что-то что будет связано с сигналом. Это может быть начальное значение, которое мы просто проверили или произошло линейное преобразование в проценты от 0 до 100, но никак не готовое значение давления/расхода/уровня(нужное подчеркнуть).
За сам процесс проверки и преобразования отвечают следующие поля
VAR_INPUT
Signal: TYPE;
Settings: TYPE;
END_VAR;
Signal - забирается с «модуля». На каждый сигнал есть структура Settings, которая будет храниться в Retain памяти ПЛК и иметь возможность ее изменения пользователем.
Далее у нас идет
VAR_INPUT
Control: TYPE;
END_VAR;
Control - это тоже структура, которая содержит поля, необходимые для управления ФБ обработки сигнала. Сейчас я туда отношу симуляцию и маскирование, но не уверен, что им там самое место с точки зрения безопасности технологического процесса.
Последнее поле
VAR_INPUT
ModuleState
;
END_VAR;
Состояние «модуля», которое нам необходимо для небольшого контура безопасности, чтобы не обрабатывать заведомо мусорные значение и не пустить их в технологический процесс. Тут будут все наши обрывы линии связи, ошибки протоколов и т.д.
И на выходе остается
VAR_OUTPUT
InputDataState
Value
END_VAR;
InputDataState - структура, которая содержит в себе информацию, необходимую и достаточную для информирования пользователя о состоянии входного сигнала. Value, в свою очередь, - готовый сигнал, которые прошел преобразование, валидацию, и является безопасным для логики системы. Его мы передаем в отдельную структуру для устройства, учавствующего в технологическом процессе.
#АСУТП #ППО #ПЛК #Архитектура
"Я вам че - Автоматизатор?!"
👍3🤔2🏆1
19–21 ноября 2025 года в Санкт-Петербурге, в рамках Российской недели роботизации-2025 состоится VII Международный форум роботизации, который представляет собой уникальную российскую площадку, демонстрирующую передовую робототехническую продукцию, системы программирования и управления высокотехнологическим оборудованием, в том числе с использованием систем искусственного интеллекта.
Место проведения: Санкт-Петербург, КЦ «ПетроКонгресс», Лодейнопольская ул., д. 5 (метро «Чкаловская»).
Формат: очный.
Посещение форума — бесплатное, обязательна предварительная регистрация на сайте.
#роботы #форум
"Я вам че - Автоматизатор?!"
Место проведения: Санкт-Петербург, КЦ «ПетроКонгресс», Лодейнопольская ул., д. 5 (метро «Чкаловская»).
Формат: очный.
Посещение форума — бесплатное, обязательна предварительная регистрация на сайте.
#роботы #форум
"Я вам че - Автоматизатор?!"
Telegram
"Я вам че - Автоматизатор?"
Об OT, новых технология и подходах в АСУТП, интересные новости из мира автоматизации и личный взгляд на все это.
Сайт: https://blog.engcore.ru/
Сотрудничество: [email protected]
Сайт: https://blog.engcore.ru/
Сотрудничество: [email protected]
🔥3
Давайте немного разгоним по одной теме.
Эволюция и стандартизация виртуальных ПЛК
Прошу ознакомиться с оригинальным постом и еще со статьей, а я просто вставлю свои 5 копеек.
Тут первый вопрос, а вы часто сталкивались с Docker и системой виртуализации? Запустить просто образ на локальной машине дело вполне простое, но вот написать конфиг для запуска уже сложнее, а если мы говорим про какие-нибудь pipeline, то сложность будет возрастать. В целом рекомендую ознакомиться с технологией как таковой.
Вот здесь соглашусь. Виртуальный ПЛК - это про портативность и гибкость, а также чуть больше свободы от аппаратной платформы, но мы платим за это надежностью и скоростью работы.
Docker, K8S, pipeline, ingress контролеры... Сомнительно...
Вот это, кмк, самая хорошая сторона виртуальных ПЛК - модернизация производства. И тут как раз и требуется перекидать логику на новые рельсы, чтобы отвязаться от старых решений.
А вообще мы уже с одним решением поигрались, можете ознакомиться.
Эволюция и стандартизация виртуальных ПЛК
Прошу ознакомиться с оригинальным постом и еще со статьей, а я просто вставлю свои 5 копеек.
Стандартизация образов сред выполнения. Ключевым сдвигом стало создание стандартизированных, предварительно сконфигурированных образов Docker, содержащих среду выполнения ПЛК. Это устраняет необходимость вручную настраивать операционные системы, патчи и зависимости, сокращая время развертывания и потенциальные ошибки.
Тут первый вопрос, а вы часто сталкивались с Docker и системой виртуализации? Запустить просто образ на локальной машине дело вполне простое, но вот написать конфиг для запуска уже сложнее, а если мы говорим про какие-нибудь pipeline, то сложность будет возрастать. В целом рекомендую ознакомиться с технологией как таковой.
Разделение аппаратного и программного обеспечения. Виртуальные ПЛК позволяют отделить логику управления от физического контроллера. Один и тот же проект ПЛК может быть запущен на разных вычислительных платформах — от локального сервера до облака или промышленного ПК, обеспечивая портативность и гибкость.
Вот здесь соглашусь. Виртуальный ПЛК - это про портативность и гибкость, а также чуть больше свободы от аппаратной платформы, но мы платим за это надежностью и скоростью работы.
Снижение порога входа для виртуального инжиниринга. Ранние решения требовали глубоких знаний в IT. Современные стандартизированные инструменты делают технологии виртуализации доступными для инженеров-автоматизаторов без специализированной IT-подготовки.
Docker, K8S, pipeline, ingress контролеры... Сомнительно...
Модернизация: Перенос устаревших систем управления на современные виртуальные платформы без переписывания логики.
Вот это, кмк, самая хорошая сторона виртуальных ПЛК - модернизация производства. И тут как раз и требуется перекидать логику на новые рельсы, чтобы отвязаться от старых решений.
А вообще мы уже с одним решением поигрались, можете ознакомиться.
Telegram
Канал Открытые системы автоматизации
Эволюция и стандартизация виртуальных ПЛК
Основной тезис статьи: Виртуальные ПЛК эволюционировали из инструмента для нишевых задач в стандартизированную технологию, доступную для массового применения благодаря развитию контейнеризации и унификации образов…
Основной тезис статьи: Виртуальные ПЛК эволюционировали из инструмента для нишевых задач в стандартизированную технологию, доступную для массового применения благодаря развитию контейнеризации и унификации образов…
👍2🤔1
Приглашаем на вебинар «Модернизация АСУ ТП с помощью АРКС400: эффективные решения на практике».
📆 Дата: 16 октября 2025
⌛️ Время: 11:00 – 12:30 (Мск)
🔗 Участие бесплатное, регистрация по ссылке: https://clck.ru/3Pett5
АРКС400 — промышленные контроллеры, предназначенные для построения распределенных АСУ ТП опасных и особо опасных производств в средних и крупных системах автоматизации. Поддерживают как одиночное, так и резервированное исполнение с возможностью горячей замены модулей. Сертифицированы по уровню SIL3. Соответствуют требованиям законодательства РФ, имеют 150+ внедрений.
В программе:
•Текущая ситуация на рынке АСУ ТП и промышленного программного обеспечения
•Технические характеристики контроллера АРКС400, его особенности и преимущества
•Демонстрация интерфейса и инструментов программирования ПТК АРКС
•Интеграция АРКС400 с ПО MasterPLC от MasterScada: возможности и перспективы
•Практические применения АРКС400 в различных отраслях промышленности
•Успешные кейсы внедрения АРКС400 на реальных производствах
Зарегистрироваться: https://clck.ru/3Pett5
Спикеры:
-Алексей Блудов, Эксперт по ПЛК Консист Констракшн
-Владимир Менделевич, Генеральный директор НВТ-Системы
-Александр Малясов, Менеджер по развитию бизнеса Treolan
#Реклама ERid:2VtzqxgUV4q
ООО "КОНСИСТ КОНСТРАКШН" ИНН:7722486706
📆 Дата: 16 октября 2025
⌛️ Время: 11:00 – 12:30 (Мск)
🔗 Участие бесплатное, регистрация по ссылке: https://clck.ru/3Pett5
АРКС400 — промышленные контроллеры, предназначенные для построения распределенных АСУ ТП опасных и особо опасных производств в средних и крупных системах автоматизации. Поддерживают как одиночное, так и резервированное исполнение с возможностью горячей замены модулей. Сертифицированы по уровню SIL3. Соответствуют требованиям законодательства РФ, имеют 150+ внедрений.
В программе:
•Текущая ситуация на рынке АСУ ТП и промышленного программного обеспечения
•Технические характеристики контроллера АРКС400, его особенности и преимущества
•Демонстрация интерфейса и инструментов программирования ПТК АРКС
•Интеграция АРКС400 с ПО MasterPLC от MasterScada: возможности и перспективы
•Практические применения АРКС400 в различных отраслях промышленности
•Успешные кейсы внедрения АРКС400 на реальных производствах
Зарегистрироваться: https://clck.ru/3Pett5
Спикеры:
-Алексей Блудов, Эксперт по ПЛК Консист Констракшн
-Владимир Менделевич, Генеральный директор НВТ-Системы
-Александр Малясов, Менеджер по развитию бизнеса Treolan
#Реклама ERid:2VtzqxgUV4q
ООО "КОНСИСТ КОНСТРАКШН" ИНН:7722486706
👍2🔥2🤔1💯1