Codesys 3.5 Обучение программированию.
265 subscribers
38 photos
13 videos
1 file
63 links
Download Telegram
Всем привет 👋

Вышло новое видео по Codesys 3.5. Битовые операции. Преобразование массива ARRAY в WORD. Это видео входит в курс по обработке аналоговых сигналов.

🎥 Смотреть видео:
https://www.youtube.com/watch?v=0PWJorN8rUY

📊 Курс по обработке аналоговых сигналов:
https://codesys3-5.skillspace.ru/l/obrabotka-analogovyh-signalov-plk-0b9b92

📘 Курс по программированию в Codesys 3.5:
https://codesys3-5.skillspace.ru/l/programmirovanie-v-srede-codesys-3-5
Всем привет 👋

Опубликовал урок 5 из курса по обработке аналоговых сигналов. Тема урока - Преобразование кода АЦП в инженерные единицы.

🎥 Смотреть видео на Youtube:
https://youtu.be/8MEjrAHxfHE

🎥 Смотреть видео на Rutube:
https://rutube.ru/video/34a89df4dc78eb1a845ef44a4dace771/

📊 Курс по обработке аналоговых сигналов:
https://codesys3-5.skillspace.ru/l/obrabotka-analogovyh-signalov-plk-0b9b92

📘 Курс по программированию в Codesys 3.5:
https://codesys3-5.skillspace.ru/l/programmirovanie-v-srede-codesys-3-5
👍4
🤖 Создал ООП-проект ПЛК в CODESYS 3.5 с помощью искусственного интеллекта

Я записал видео, в котором с нуля создаю полноценный учебный проект на языке Structured Text с применением ООП.

Начинаем с пустого проекта, продумываем архитектуру и последовательно создаём:

— абстрактный базовый класс устройства;
— интерфейсы, наследование и методы;
— функциональный блок обработки аналоговых сигналов;
— обработку дискретных входов;
— управление пятью насосами;
— управление пятью электроприводными задвижками;
— защиты, блокировки и контроль обратных связей;
— автоматический выбор рабочего и резервного насоса;
— технологический алгоритм насосной станции;
— симуляцию оборудования для проверки без физического ПЛК.

Главная идея видео — проверить, способен ли искусственный интеллект помочь инженеру АСУ ТП создать архитектуру проекта и написать рабочий код для CODESYS 3.5.

Получилось интересно: ИИ действительно заметно ускоряет разработку, но его код всё равно необходимо понимать, проверять и дорабатывать.

🎬 Смотреть видео:
https://youtu.be/-j8io3dqLOQ

Полезные материалы:

📊 Курс «Обработка аналоговых сигналов ПЛК в CODESYS 3.5»:
https://codesys3-5.skillspace.ru/l/obrabotka-analogovyh-signalov-plk-0b9b92

📘 Курс «Программирование в CODESYS 3.5. Основы»:
https://codesys3-5.skillspace.ru/l/programmirovanie-v-srede-codesys-3-5

💬 Telegram-чат специалистов по CODESYS 3.5:
https://t.me/codesys35

🎓 Telegram-канал по обучению программированию в CODESYS 3.5:
https://t.me/codesys4

Как считаете, сможет ли ИИ в будущем самостоятельно создавать промышленные проекты ПЛК или он останется только помощником инженера? Пишите своё мнение в комментариях.
🤖 Этот пост создан с помощью ИИ. Причём тему мы разбирали не в формате «подтверди моё мнение», а специально искали аргументы и за, и против.

🔌 «Выключи и включи питание ПЛК» — хороший совет или инженерное шаманство?

Наверняка многие инженеры АСУ ТП сталкивались с ситуацией:

ПЛК работал.
Что-то изменили.
И внезапно начинается какая-то чертовщина.

Модуль не выходит на связь.
Modbus перестал отвечать.
Вход показывает непонятное состояние.
Конфигурация вроде правильная.
Ошибок в программе не видно.

И тут появляется универсальный совет:

«А питание передёргивал?»

Звучит примерно как совет системного администратора:

«А компьютер перезагружать пробовали?» 😄

Самое интересное — иногда это действительно помогает.

Но почему?

🟢 Аргументы ЗА перезапуск по питанию

ПЛК и современные модули ввода-вывода — это вычислительные устройства: процессор, память, firmware, коммуникационные интерфейсы, внутренние состояния.

При включении питания оборудование проходит процедуру инициализации.

Условно:

POWER ON → загрузка firmware → самодиагностика → инициализация I/O → запуск интерфейсов → загрузка конфигурации → RUN

Полное снятие питания заставляет оборудование пройти эту последовательность заново.

Поэтому перезапуск действительно может помочь, если:

⚡ завис коммуникационный модуль;

⚡ после помехи некорректно работает RS-485;

⚡ модуль I/O оказался в состоянии Fault;

⚡ после изменения hardware-конфигурации оборудование нормально не переинициализировалось;

⚡ ПЛК потерял связь с модулем и не смог её восстановить;

⚡ после кратковременной просадки питания устройство осталось в некорректном состоянии;

⚡ внешний Modbus Slave завис и перестал отвечать.

И это не просто народная магия наладчиков.

В документации промышленного оборудования действительно можно встретить рекомендацию:

Cycle power to the module.

То есть иногда старое доброе:

«Выключи и включи»

— вполне нормальный инженерный инструмент.

Но здесь возникает гораздо более интересный вопрос.

Допустим:

Modbus не работал → передёрнули питание → заработал.

Означает ли это, что мы действительно устранили неисправность?

Или мы просто временно убрали её проявление?

Об этом — во второй части.
🔌 Сброс питания ПЛК. Часть 2

В первой части мы выяснили, почему старое доброе:

«Выключи и включи»

иногда действительно работает.

Теперь посмотрим на другую сторону.

Представим:

Modbus перестал работать → передёрнули питание → заработало.

Можно сказать:

«Проблема решена!»

А можно задать другой вопрос:

«Почему она вообще возникла?»

Возможно, настоящая причина была совсем в другом:

— плохое питание 24 В;
— помехи на RS-485;
— неправильное заземление;
— ошибки termination/bias;
— конфликт адресов;
— ошибка firmware;
— переполнение внутреннего буфера;
— ошибка программы;
— неправильная последовательность запуска устройств;
— аппаратная неисправность модуля.

Перезапуск мог просто устранить следствие, не устранив причину.

Через неделю проблема появится снова.

⚠️ Более того, перезапуск может уничтожить улики

До отключения питания у нас могли оставаться:

код ошибки → состояние LED → диагностические регистры → состояние коммуникации → значения переменных → журналы событий.

Передёрнули питание —

и часть информации исчезла.

Получается парадокс:

установку восстановили, а информацию, которая могла помочь найти причину остановки, потеряли.

Поэтому при повторяющейся неисправности правильнее:

сначала зафиксировать диагностику → потом перезапускать.

❌ Иногда питание вообще лучше не трогать

Очевидный пример — обновление firmware.

Но есть и более важный момент.

На реальном технологическом объекте после power cycle нужно понимать:

Что произойдёт с выходами?
Что произойдёт с приводами?
Сохранятся ли RETAIN-переменные?
Запустится ли программа автоматически?
В каком состоянии окажутся исполнительные механизмы?

Поэтому:

«Давайте просто передёрнем питание»

на работающей установке — не всегда безобидное действие.

🟡 Так когда всё-таки перезапускать?

Если произошёл единичный непонятный сбой, диагностика зафиксирована, перезапуск технологически безопасен и производитель оборудования его допускает — почему бы и нет?

Но если получается:

понедельник — зависло → перезапустили;
среда — зависло → перезапустили;
пятница — зависло → перезапустили...

то это уже не устранение неисправности.

Это ритуал обслуживания неисправности. 😄

Поэтому правило я бы сформулировал так:

Сначала диагностика. Потом перезапуск.

А если после перезапуска всё заработало, не считать вопрос закрытым, а спросить:

«Почему снятие питания вообще помогло?»

Потому что именно ответ на этот вопрос иногда и приводит к настоящей причине неисправности.

А как поступаете вы?

Сначала передёргиваете питание или сначала пытаетесь докопаться до причины?
🤖 Вышло новое видео: создаём проект CODESYS 3.5 с помощью ИИ
Друзья, опубликовал новое большое практическое видео о том, как использовать искусственный интеллект при программировании ПЛК в CODESYS 3.5.
На этот раз мы не ограничиваемся генерацией нескольких строк ST-кода. Я показываю процесс создания проекта практически с нуля и постепенно усложняю его.
━━━━━━━━━━━━━━━━━━━━
⚙️ Что делаем в видео:
🔹 создаём функциональный блок обработки дискретных сигналов DI;
🔹 создаём несколько экземпляров ФБ и вызываем их в программе;
🔹 добавляем обработку аналоговых сигналов AI;
🔹 выполняем преобразование RAW → инженерные единицы;
🔹 добавляем тестовый режим, диагностику и аварийные состояния;
🔹 переносим данные DI и AI в структуры и массивы;
🔹 обрабатываем несколько каналов через циклы;
🔹 создаём функциональный блок управления электродвигателем;
🔹 генерируем с помощью ИИ файлы для последующего импорта в CODESYS.
━━━━━━━━━━━━━━━━━━━━
🎓 И самое интересное — показываю, как таким способом можно изучать CODESYS вместе с ИИ.
Можно попросить ИИ создать функциональный блок, затем разобрать каждую переменную и строку программы, изменить алгоритм, добавить новую функцию, найти ошибку и сразу проверить всё непосредственно в CODESYS.
То есть ИИ становится не просто генератором кода, а своеобразным персональным помощником при изучении программирования ПЛК.
━━━━━━━━━━━━━━━━━━━━
🎥 Смотреть видео:
https://www.youtube.com/watch?v=h8OLwQy5PqU
━━━━━━━━━━━━━━━━━━━━
📚 Мои курсы для тех, кто хочет изучить тему подробнее:
💻 Программирование в среде CODESYS 3.5. Основы
https://codesys3-5.skillspace.ru/l/programmirovanie-v-srede-codesys-3-5
📊 Обработка аналоговых сигналов ПЛК в CODESYS 3.5
https://codesys3-5.skillspace.ru/l/obrabotka-analogovyh-signalov-plk-0b9b92
⚡️ Основы чтения принципиальных электрических схем
https://codesys.skillspace.ru/l/osnovy-ctenia-principial-nyh-elektriceskih-shem-fb9316
👍2
👋 Новым подписчикам и участникам чата — добро пожаловать!
Меня зовут Андрей, я автор курсов «Школы АСУ ТП». Для тех, кто хочет разобраться в программировании ПЛК и применять знания на практике, расскажу о двух моих курсах.
📘 Основы программирования ПЛК в CODESYS 3.5
Открыли CODESYS, а дальше непонятно: с чего начать проект, где писать код и как проверить, что программа работает?
Этот курс — для знакомства со средой и освоения основ. Разбираем структуру проекта, переменные, программы и функциональные блоки, запуск на виртуальном контроллере и проверку работы в онлайн-режиме.
Цель — не просто повторить пример, а понять, как устроена и выполняется программа ПЛК.
👉 Программа курса и запись: https://codesys3-5.skillspace.ru/l/programmirovanie-v-srede-codesys-3-5⁠�
🤝4
📊 Обработка аналоговых сигналов ПЛК в CODESYS 3.5
Датчик подключён. Но как превратить его сигнал в понятные значения температуры, давления или уровня? Как задать уставки и обработать ошибки?
В этом курсе разбираем сигналы 0–10 В и 4–20 мА, преобразование исходных значений в инженерные единицы, масштабирование, пороги и уставки, сигнализацию, ручной режим и визуализацию.
Практическая часть — разработка функционального блока в CODESYS 3.5 на языке ST.
От сигнала датчика — к его обработке и использованию в программе.
👉 Программа курса и запись: https://codesys3-5.skillspace.ru/l/obrabotka-analogovyh-signalov-plk-0b9b92⁠�
💡 Только начинаете? Начните с основ CODESYS. Уже знакомы со средой и хотите разобраться в работе с датчиками — переходите к курсу по аналоговым сигналам.
CODESYS 3.5: от первых программ ПЛК до обработки сигналов датчиков

Работаете с автоматикой или начинаете изучать программирование контроллеров? В «Школе АСУ ТП» есть два курса под разные задачи.

📘 Основы программирования ПЛК в CODESYS 3.5

Начните с основ: разберитесь в программировании контроллеров и освойте работу в среде CODESYS 3.5. Курс подойдёт для первого знакомства с программированием ПЛК и систематизации базовых знаний.

👉 "Посмотреть программу курса и записаться" (https://codesys3-5.skillspace.ru/l/programmirovanie-v-srede-codesys-3-5)

📊 Обработка аналоговых сигналов ПЛК в CODESYS 3.5

Разберитесь с сигналами 4–20 мА и 0–10 В, масштабированием и обработкой показаний датчиков. Для тех, кто хочет понимать, как входной сигнал превращается в значение давления, температуры или уровня в программе контроллера.

👉 "Посмотреть программу курса и записаться" (https://codesys3-5.skillspace.ru/l/obrabotka-analogovyh-signalov-plk-0b9b92)

Знакомьтесь с материалами и присоединяйтесь к сообществу:

📣 "Telegram-канал о CODESYS — материалы по программированию ПЛК" (https://t.me/codesys4)

💬 "Telegram-чат CODESYS 3.5 — вопросы, обсуждения и обмен опытом" (https://t.me/codesys35)
​⚡ Почему IF срабатывает много раз, хотя кнопку нажали только один раз?

Разберём простую, но очень важную особенность работы ПЛК.

Нужно увеличивать счётчик на 1 при каждом нажатии кнопки.

Пишем:

IF xButton THEN
iCounter := iCounter + 1;
END_IF


На первый взгляд всё логично:

🔘 нажали кнопку
➕ счётчик увеличился на 1

Но после одного нажатия вдруг получаем:

iCounter = 73


😳 Почему не 1?

━━━━━━━━━━━━━━

🔄 Всё дело в цикле ПЛК

ПЛК выполняет программу не один раз.

Он повторяет её циклически — снова и снова.

Допустим, время цикла задачи:

10 мс

А кнопку оператор удерживал примерно:

1 секунду

За это время программа выполнится примерно:

1000 мс / 10 мс = 100 циклов


И всё это время:

xButton = TRUE

Значит, в каждом цикле снова выполняется:

iCounter := iCounter + 1;


📈 Поэтому одно физическое нажатие может привести к десяткам или даже сотням выполнений одной и той же команды.

━━━━━━━━━━━━━━

🎯 Нужно ловить не состояние, а событие

Нас интересует не то, сколько времени xButton находится в состоянии TRUE.

Нам нужен только момент перехода:

FALSE → TRUE

Это называется передним фронтом сигнала.

В CODESYS для его обнаружения есть стандартный функциональный блок:

R_TRIG

━━━━━━━━━━━━━━

✅ Правильный вариант

VAR
xButton : BOOL;
fbTrig : R_TRIG;
iCounter : INT;
END_VAR

fbTrig(CLK := xButton);

IF fbTrig.Q THEN
iCounter := iCounter + 1;
END_IF


Теперь выход fbTrig.Q становится TRUE только на один цикл ПЛК — в момент появления переднего фронта.

Получаем:

🔘 нажали → +1
⏳ держим кнопку → ничего
🔘 отпустили → ничего
🔘 нажали снова → +1

━━━━━━━━━━━━━━

🧠 Главное различие

Когда мы пишем:

IF xButton THEN

мы спрашиваем:

«Сигнал сейчас активен?»

А R_TRIG отвечает на другой вопрос:

«Сигнал появился именно в этом цикле?»

Это две совершенно разные задачи.

━━━━━━━━━━━━━━

🏭 Где это используется на практике?

Обработка фронта постоянно встречается в программах ПЛК:

• команды с HMI
• квитирование аварий
• переключение режимов
• изменение уставок
• подсчёт событий
• запуск последовательностей
• обработка кнопок оператора

То есть везде, где действие должно выполниться один раз по событию, а не каждый цикл ПЛК.

━━━━━━━━━━━━━━

💡 Запомните

IF проверяет состояние.

R_TRIG ловит момент появления сигнала.

Небольшая разница в коде — огромная разница в поведении программы.

━━━━━━━━━━━━━━

💬 А как вы обрабатываете фронты в своих проектах?

Используете стандартные R_TRIG / F_TRIG или пишете свою логику через запоминание предыдущего состояния?

#CODESYS #ПЛК #АСУТП #StructuredText #ПрограммированиеПЛК
👍3
🧠 РАЗБОР КОДА

На картинке — простая ситуация из программы ПЛК.

xButton = TRUE в течение 5 циклов подряд.

Начальное значение:

iCounter = 0

❓ Какое значение будет у iCounter после пятого цикла?

Сначала попробуйте ответить самостоятельно.

👇 Разбор и правильный ответ — в следующем посте.

#CODESYS #ПЛК #StructuredText #ПрограммированиеПЛК
🧠 РАЗБОР КОДА

Исходный код:

IF xButton THEN
iCounter := iCounter + 1;
END_IF


Начальное значение:

iCounter = 0

Сигнал:

xButton = TRUE

в течение 5 циклов ПЛК подряд.

❓ Что будет в iCounter после пятого цикла?

А) 1
Б) 5
В) 0
Г) Зависит от времени цикла

Сначала выберите вариант, потом откройте ответ 👇

🔎 Открыть правильный ответ

✅ Правильный ответ — Б: iCounter = 5.

Почему?

Условие xButton = TRUE выполняется во всех пяти циклах.

Поэтому команда:

iCounter := iCounter + 1;

тоже выполняется пять раз.

Получаем:

0 → 1 → 2 → 3 → 4 → 5

Время цикла здесь не влияет на результат, потому что в условии уже сказано: xButton оставался TRUE ровно 5 циклов.


💡 Главная мысль

IF проверяет состояние сигнала в каждом цикле.

Если действие нужно выполнить только один раз при переходе:

FALSE → TRUE

нужно использовать определение переднего фронта, например R_TRIG.

💬 Получилось ответить правильно до открытия спойлера?

#CODESYS #ПЛК #StructuredText #ПрограммированиеПЛК