Как диагностировать программу plc

Последовательность поиска ошибки в программе ПЛК

Достаточно часто в литературе мне попадались описания ошибок и даже классификации их по типам.
Хотя, признаться, у меня не получается толком вспомнить ни одного случая, когда мне бы помогло знание того, к какому именно типу относится конкретная ошибка. Разве что уже после выяснения причин, для обьяснения их окружающим.
А вот как люди вычисляли место и докапывались до сути ошибки — мне всегда было интересно.

Сведения о системе и ошибке

С компьютера на ПЛК подаются уставки (времена, флаги режимов) и команды на устройство.
Из ПЛК на компьютер выдаются сигналы статуса устройства и времени до конца команды на это устройство. Сигналы пакуются в слова, для минимизации объемов приема и передачи.
Из ПЛК на устройство выдаются команды.
Устройство выдает на ПЛК свои статусы.

Изначально все работало, но через какое-то время при подаче команд, статусы на компьютере в SCADA начали моргать не по делу и вообще вести себя крайне недружелюбно. Причем только в одном месте, на одном объекте.

Но «танцы с саблями» появлялись стабильно, при каждой команде, что очень порадовало.

Поиск

Цифрами в круглых скобках показаны места проверок, соответствующие цифрам на схеме ниже.

Принципов и зависимостей моргания понять сходу не удается. Возможно из-за усталости, возможно по причине отсутствия таковых.

Было установлено, что ошибка присутствует не только в SCADA (1) (там, где она собственно была обнаружена), но и в OPC сервере (2).

Дальнейший разбор показал, что ошибка присутствует и в ПЛК, как минимум в слове, формируемом для компьютера (3).

Проверка наличия ошибки в статусе, приходящем от устройства – отметает устройство, как возможный источник проблемы.

Изменения статуса от устройства вручную ничего не меняют. При изменении статуса от устройства форсированием (принудительно, постоянно) ошибка все равно сохраняется.
Соответственно это и не импульсы, которых не видно при мониторинге (4).

Сравнение с кодами других объектов, на которых этой ошибки нет – различий не выдает. Полная идентичность. Вероятность ошибки в программе ПЛК уменьшается (5).

Отключается компьютер, как возможный источник ошибки, записывающий что-то в данную область памяти. Ошибка сохраняется. Вероятность ошибки из-за компьютера стремится к нулю. Соответственно, не смотря ни на что, проблема все-таки в ПЛК (6).

Ремарка: Также можно было, отключив ПЛК, руками менять статусы в OPC. Но такой вариант был сложнее технически, а в целом эти две проверки практически равнозначны.

Перенесение слова статуса, передаваемого из ПЛК на компьютер, в другую область памяти ПЛК ничего не дает. Ошибка сохраняется.

Перенесение куска кода с ошибкой в другой блок (условно функцию) тоже не влияет на ошибку. Соответственно вероятность того, что это влияет какая-то еще посторонняя команда, пишущая туда-же что-то свое – незначительна. Дело в этом куске.

1. Подача команды (без нее не понятно как проверять).
2. Таймер, с которого берется время до сброса команды.
3. Формирование слова на компьютере из статуса и времени до сброса команды.

Удаляется таймер. Команда не сбрасывается, но ошибка пропадает и статусы перестают прыгать.

Взамен вставляется новый таймер. Тщательно осматривается на предмет нелепостей. Таймер самый заурядный, ничего необычного. Таких в программе еще штук 200. Но ошибка появляется (8)

1. Запись статусов устройства в младший байт слова.
2. Замена старшего и младшего байт местами командой SWAP_WORD (статусы переносятся в старший байт)
3. По AND запись времени в младший байт слова

Вроде ничего необычного, причем полностью идентичная система работает с десятками идентичных устройств вокруг. Мозг скрипит и отказывается помогать.

1. Запись времени устройства в младший байт слова.
2. В промежуточной переменной статусы умножаются на 256, сдвигаясь в старший байт слова.
3. По OR производится запись статусов в старший байт слова.

После разбора — ситуация становится окончательно понятной.

Причина ошибки:

Операторы увеличили стандартное время таймаута с 1,5 до 10 минут.
И если 1,5 минуты это 90 секунд, то 10 минут это 600 секунд.
600 секунд не влезали в младший байт (максимум 256), и часть времени писалась в старший.

Суть последней проверки:

При записи сначала времени, и лишь затем статуса – статус забивал биты переполнения, приходившие от значения времени. А при обратной последовательности команд, время наоборот забивало своими битами статус.

Решение:

Время и статусы были разбиты на 2 слова. Местным инженерам было предложено провести техобслуживание или заменить устройство с таймаутом, превышающим стандартное время более чем в 5 раз.

И они работали они долго и счастливо, и сломались в один день.

Выводы

Описанная ошибка не особо сложна, но по-моему довольно симпатична с точки зрения показательности.

По сути не очень важно, где именно ищется ошибка — в электронике, в ПЛК, на компьютере или где-то еще. Общие принципы всегда примерно одинаковы:

1. По максимуму собрать информацию о проблеме — где и как она проявляется. Осциллографы, снифферы, утилиты от Русиновича, логи, градусники, в общем всё, что можно использовать в данном случае. Не зависит ли она от времени года, прихода уборщицы, или барометрического давления.
2. Вывести из-под подозрения как можно большую часть. Перерезая дорожки на печатных платах, отключая теги, выводя из системы отдельные компьютеры. Хуже, если есть какие-нибудь обратные связи и прочие хендшейки. Тогда можно попытаться либо организовать проверку приняв во внимание отсутствие части системы, либо пробовать проэмулировать часть, например искусственно подавая сигнал на вход обратной связи. В общем думать.
3. По возможности доводить каждую проверку до конца, даже если вдруг появилась «мысль!». Потому-что «мысль!» может и не сработать (и до обидного часто не срабатывает), а результатов проверки лишаешься.
4. В оставшемся куске — менять всё, что вызывает подозрения. Если это ПО — попробовать переустановить или заменить на аналогичное. В принципе есть вариант начать с этого пункта. Лично видел инженера, при ремонте платы на 40-50 микросхем К155 серии, выкусившего их все и впаявшего новые. Но это на мой взгляд скорее пример того, как не надо делать. Потому-что даже если все заработает, конкретики не получишь. Тем более, что в описанном случае этот вариант не прошел и неисправность сохранилась. В общем — я этого не говорил.

Хотя разумеется рецепты для одних ситуаций могут быть совершенно бесполезны по отношению другим.
Но у всех ошибок есть конкретная причина, и эту причину всегда можно выяснить.
Например как-то причиной был тракторист с бороной, проехавшийся над кабелем. И хотя сложностей в ее устранении не возникло, их хватило в процессе написания рекомендации, для избежания повторов…

Извиняюсь за вероятную сложность чтения.
Тема не очень художественная, плюс к этому попытался сократить, пропуская не очень существенные моменты, вроде вынужденного отказа от BreakPoint’ов, из-за цикличности выполнения программы в ПЛК и наличия таймера.

Методические указания по программированию ПЛК методическая разработка на тему

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

• Нано контроллеры, имеющие менее 16 каналов ввода-вывода;
• Мини контроллеры имеют до 100 каналов ввода-вывода;
• Средние контроллеры имеют уже до 500 каналов;
• Гиганты являются рекордсменами обладая более чем 500 каналами ввода-вывода.

Промышленные ПЛК можно разбить на виды по расположению модулей ввода-вывода.

• Моноблочные- модуль ввода-вывода и контроллер являются единым целым;
• Модульные- собираются в корзину сменными модулями в зависимости от задачи;
• Распределительные- имеют разные корпуса и соединяются контроллером по сети.

Для увеличения общего количества каналов типы контроллеров могут комбинироваться, скажем модульный или моноблочный ПЛК можно дополнить удаленным модулем ввода-вывода сри помощи интерфейса RS-485.

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

• Панельные ПЛК;
• Монтажные ПЛК;
• Настенные ПЛК;
• Стоечные ПЛК;
• Бескаркасные ПЛК.

Область применения промышленных контроллеров также можно классифицировать на:

• Универсальные;
• Робототехника;
• Перемещение и позиционирование;
• Коммуникационные;
• Специализированные;
• ПИД – ПЛК.

И последние два вида классификации это язык программирования промышленных контроллеров и способ программирования.

• Алгоритмические языки- Basic, C#, C++, C.
• Машинный язык программирования МЭК 61131-3.

Классифицировать по способу программирования контроллеров можно так:

• Контроллер программируемый с лицевой стороны;
• Контроллер программируемый специальным программатором;
• Контроллер программируемый с помощью клавиатуры, мыши и дисплея;
• Контроллер программируемый с помощью переносного ПК.

На этом виды и классификация промышленных контроллеров заканчивается.

Промышленные языки для программирования ПЛК

Язык релейных диаграмм (LD, LAD, Ladder)

Язык позволяет вести разработку в графическом режиме, т.е. формировать программу из визуальных блоков, а не писать ее в виде текста. Недостаток: большие и сложные алгоритмы, выраженные в графическом виде посредством LAD, становятся еще менее понятными, чем текст.

Functional Block Diagram FBD

Язык FBD также изображает проектируемую прошивку не в виде текста, а в виде схемы, напоминающую принципиальную электрическую схему. Диаграмма FBD состоит из соединенных линиями блоков (functional flocks, FBs). Связи символизируют собой переменные, через которые передается информация между блоками. Блоки символизируют арифметические и логические операции. Входные и выходные линии могут быть при этом связаны с физическими входами/выходами контроллера.

Рисунок 1. Пример Functional Block Diagram. Автор24 — интернет-биржа студенческих работ

Задай вопрос специалистам и получи ответ уже через 15 минут!

Sequential Function Chart

Язык SFC (используется обычно в связке с языками ST и IL) — еще одно средство визуализации, описывающее программу в виде последовательности шагов и переходов. В SFC используется принцип конечного автомата. На этом языке удобно описывать параллельно выполняемые последовательности технологических шагов с возможностью ветвления и слияния.

Рисунок 2. Пример Sequential Function Chart. Автор24 — интернет-биржа студенческих работ

Structured Text

Язык ST обладает синтаксисом, напоминающим универсальные языки программирования Pascal и Basic. С его помощью легко реализуются математические и логические операции, переходы, циклы. Имеется возможность задействования библиотечных и пользовательских функций. Язык легок в освоении, хотя и уступает по наглядности языкам с графическим выражением алгоритмов.

Instruction List

Язык IL по синтаксису напоминает ассемблер, хотя и не слишком сложен, благодаря небольшому количеству команд процессора в контроллерах (сравнительно с компьютерными). Его достоинством является высокое быстродействие написанных на нем программ, недостатком — относительная сложность, отпугивающая персонал, имеющий отношение к составлению программ для контроллеров (например, технологов), но не являющихся специалистами в области программирования.

Continuous Flow Chart

Язык CFC — еще один язык визуального программирования, который можно считать расширением языка FBD. Разработка представляет собой по большей части выбор из готовых решений, оформленных в виде функциональных блоков, рассчитанных на использование технологическими объектами: моторами, насосами, осветительными приборами. Такие блоки умеют обрабатывать исключительные ситуации (перегрев, короткое замыкание, затопление и т. п.) и сигнализировать о них.

Рисунок 3. Пример Continuous Flow Chart. Автор24 — интернет-биржа студенческих работ

Неисправности и ошибки ПЛК

К сожалению, по незнанию основных принципов работы ПЛК одна из самых распространенных ошибок на оборудовании – это подсевшие аккумуляторные батареи, при отключенном питании на ПЛК приводящие к удалению или потере данных находящихся в памяти контроллера. В случае если у заказчика отсутствует копия проекта программы, то придется производить работы по написанию, программированию и отладке программы на оборудовании заказчика, это достаточно долгий процесс, занимающий от 2-ух до 3-ех месяцев.

Отсутствие связи между контроллером ПЛК и панели оператора также является достаточно распространенной ошибкой, которая может быть устранена только в сервисном центре, в лабораторных условиях и в авральном режиме займет от 1 до 2 дней. В процессе ремонта восстанавливается потерянная связь между ПЛК и панелью оператора.

Ошибка питания контроллера, как и ошибка входов требует ремонт ПЛК в сервисном центре, подобные ошибки на территории заказчика исправить не удастся.

Видео инструкции и примеры

1.	Установка Target-файла	download
2.	Запуск CoDeSys, создание проекта	download
3.	Установка соединения со средой программирования по RS-232	download
4.	Установка соединения со средой программирования по Ethernet	download
5.	Подключение модуля в PLC_Configuration	download
6.	Задание значений в PLC_Configuration	download
7.	Работа в PLC_Browser	download

Схема подключения контроллера

Схема контроллера зависит от производителя и типа, сколько существует ПЛК столько же и схем, вот лишь несколько схем ПЛК на примере контроллера Siemens S7-300.

CPU 312C: Назначение встроенных DI/DO	Принципиальная схема встроенной цифровой периферии CPU 312C
CPU 313C/313C-2/314C-2: назначение встроенных цифровых входов и выходов	Принципиальная схема встроенной цифровой периферии CPU 313C/313C-2/ 314C-2

Действующая программа обновления встроенного ПО контроллеров ОВЕН ПЛК версии 2.14.0

Контроллер	Прошивка	Таргет файл
ПЛК110-30	Скачать (1 МБ)

Установщик Target файлов для следующих моделей ПЛК: ПЛК110, ПЛК160

Автоматический установщик (400 КБ)

Установщик Target файлов для всех моделей ПЛК: ПЛК110, ПЛК160, ПЛК100, ПЛК150, ПЛК154

Автоматический установщик (500 КБ)

Прошивка с помощью команды UpdateCore .

Драйвер порта usb для программирования ПЛК с ПК

Драйвер для ОС Windows 2000/XP/Vista/W7 скачать здесь

Диск ПЛК

DVD V.3 для ОВЕН ПЛК (CoDeSys v 2.3). (440 Мб).

Параметрирование, программирование контроллера

Возможны два варианта программирования контроллеров.

1. С выездом на производственную площадку заказчика;
2. Программирование ПЛК в сервисном центре.

В каждом ПЛК установлена программа управления промышленным оборудованием, к примеру станком или роботом. Контроллер программируется на заводе изготовителе при покупке станка, линии. В некоторых случаях покупается оборудование с ПЛК без установленного программного обеспечения (ПО). После покупки данного оборудования потребуется квалифицированные специалисты для запуска данного промышленного оборудования.

Для запуска оборудования с контроллером ПЛК потребуется выполнить следующие работы:

• Разработка проекта программы контроллера;
• Написание программы контроллера;
• Запись программы в ПЛК;
• Пуско-наладка контроллера на оборудовании.

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

Действующая программа обновления встроенного ПО контроллеров ОВЕН ПЛК версии 2.14.0

Контроллер	Прошивка	Таргет файл
ПЛК100	Скачать (1 МБ):

Установщик Target файлов для следующих моделей ПЛК: ПЛК100, ПЛК150, ПЛК154

Автоматический установщик (400 КБ):

Установщик Target файлов для всех моделей ПЛК: ПЛК110, ПЛК160, ПЛК100, ПЛК150, ПЛК154

Автоматический установщик (500 КБ):

Прошивка с помощью команды UpdateCore .

Драйвер порта usb для программирования ПЛК с ПК

Драйвер для ОС Windows 2000/XP/Vista/W7 скачать здесь

Программы калибровки аналоговых входов

Для target файла версии 2.14 скачать здесь (590 Kb).

Диск ПЛК

DVD V.3 для ОВЕН ПЛК (CoDeSys v 2.3). (440 Мб).

Производители промышленных контроллеров

С момента своего появления ПЛК прочно заняли свое место во всех промышленных отраслях благодаря простоте и способности продолжительно и безаварийно работать в самых агрессивных средах. А как говорится спрос рождает предложение, промышленные контроллеры на сегодняшний день не делает только ленивый. Вот список самых известных производителей ПЛК в России.

• Advantech;
• Delta;
• Bocsh Rexroth;
• Lenze;
• Pilz;
• Jetter;
• Mitsubishi;
• Omron;
• Siemens;
• Hitachi;
• Агава;
• Овен.

Список далеко не полный, продолжать можно еще достаточно долго. Российский производитель также широко представлен на рынке промышленных контроллеров.

Диагностика, ремонт и программирование ПЛК в сервисном центре

производит ремонт промышленной электроники и оборудования с 2002 года. За это время мы накопили колоссальный опыт в том числе опыт в ремонте промышленных контроллеров.

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

На ровне с выездной диагностикой ПЛК мы также предлагаем услуги по диагностике в сервисном. В случае если точно известен нерабочий блок производится внутри-блочная поэлементная диагностика. После определения неисправного элемента производится замена на аналогичный, и обязательная проверка на специализированном стенде.

Специалисты нашего сервисного центра уделяют максимальное внимание к качеству исполнения ремонта промышленного оборудования. Именно поэтому мы смело даем гарантию на все выполненные работы шесть месяцев.

Ремонт промышленных контроллеров производится исключительно с использованием оригинальных запасных частей, на компонентном уровне с применением высокотехнологичного оборудования, квалифицированным персоналом с инженерным образованием.

Если на вашем производстве вышел из строя ПЛК, обращайтесь в сервисный . Специалисты нашей компании в минимальные сроки проведут глубокую диагностику и последующий ремонт промышленного контроллера.

Как с нами связаться

Если вы заинтересованы в ремонте ПЛК, оставьте заявку на ремонт с помощью специальной формы на сайте, либо связавшись с нашими менеджерами несколькими способами:

• Заказав обратный звонок (кнопка в правом нижнем углу сайта)
• Посредством чата (кнопка расположена с левой стороны сайта)
• Либо позвонив по номеру; +7(917) 121-53-01
• Написав на электронную почту

Далеко не полный список производителей промышленной электроники и оборудования, ремонтируемой в нашей компании.

CS-CS.Net: Лаборатория Электрошамана

Тестовый стенд для ОВЕН ПЛК 110

Ну что? Я продолжаю рассказывать базовые понятия ПЛК и то, как их программировать. Сегодня я расскажу про свои дальнейшние приключения с ОВЕНом и тем, как я его программировал. Как я уже говорил, программирование ПЛК — это совсем другая религия! Это вам не схемки или кубики в логическом реле двигать! Тут всё значительно мудрее и очень важен грамотный выбор железа, грамотное физическое подключение линий IO и внешних модулей.

Для ПЛК обычно есть два варианта сред разработки: CodeSys и собственные. CodeSys — это бесплатная среда разработки, которая делится на компилятор и ядро. Ядро CodeSys производители ПЛК загружают в него при производстве. И всё, что надо для программирования такого ПЛК — скачать CodeSys и специальные файлы, которые описывают конкретную модель ПЛК.

Второй вариант — это собственное ядро и собственная среда разработки. Тут уже каждый производитель извращается как нравится. Я вот хотел повозиться с Сименсами, но мне рассказали, что их среда разработки требует очень мощный комп и жрёт много ресурсов. Мне это не нравится, и я лучше подберу что-нибудь такое что работает с CodeSys, потому что мне проще поставить один раз хорошую среду, вылизать её настройки и заниматься только программированием.

ПЛК, который заказчик купил под свой щит работает на ядре CodeSys v2. Сейчас везде используется ядро CodeSys v3, а вторая версия ядра является устаревшей. Но так как принципы программирования всё равно одинаковые, то этот пост будет полезен всем начинающим. Да и мне охота поделиться информацией, которую я собирал по крупицам, неделю обложившись документацией. Блин! Мне кажется, что мне уже надо или учебные курсы вести, или посты продавать, гыгы =)

Первое, с чего начинается работа по программированию — это создание тестового стенда. У меня валялись кнопки на DIN-рейку от ABB, и я собрал из них четыре линии ввода: три на бортовом IO ПЛК, а одну — на внешнем модуле для того, чтобы проверить как работает опрос модулей по ModBus.

Кнопки для подачи сигналов на входы ПЛК

Настройка внешних модулей и ModBus

Первое, с чего начинается наше программирование — это с конфигурации железа. Любой внешний модуль имеет на шине RS-485 свой адрес. А ещё модулю надо указать правильные настройки обмена: скорость, чётность и тип протокола обмена.

Каждый модуль или внешнее устройство настраивается по своему. У кого-то надо будет зайти в меню и поменять там цифирки. У кого-то поставить перемычки. А у других устройств для их настройки предусмотрена специальная программа-конфигуратор. У ОВЕНа сделано именно так.

Их модули подключаются штатно под RS-485 к компьютеру и настраиваются при помощи программы. Для того, чтобы подключить RS-485 к компьютеру, понадобится любой преобразователь интерфейсов. Их на рынке навалом и можно использовать любой. Если хочется — можно RS-485 завернуть даже в обычный Ethernet и общаться с модулями или нашей системой по сетке.

Так как вокруг меня был ОВЕН, то я для личных целей купил преобразователь ОВЕН АС-4. Он у них сделан в корпусе на DIN-рейку, питается от самого же порта USB. Из фич — то, что перемычками можно подключать и изменять сопротивление резисторов-терминаторов шины RS-485.

Мы подаём на модуль питание и подключаем его к преобразователю:

Преобразователь ОВЕН АС-4 и настройка модуля IO

Дальше запускаем программу «Конфигуратор М110». Первым делом программа предложит нам задать настройки для подключения к модулю. Если мы только что купили модуль — то можно смело тыкать кнопку «Заводские сетевые настройки». А если модуль уже настроен на какой-то адрес и другие параметры протокола, то нам надо их знать заранее и ввести в программу:

Подключение к модулю IO в программе

Если по какой-то причине мы забыли все настройки модуля (например нам подарили БУшный модуль), то можно запустить сканирование сети. Программа найдёт всё, что может и предложит подключиться к указанному модулю. Ну а если мы совсем ничего не можем — то сам модуль ввода-вывода можно жёстко сброить на заводские установки, если установить одну из перемычек, которые находятся на нём под крышкой. Это описано в инструкции на модуль.

После того, как мы подключились к модулю, программа выдаёт нам все его настройки, которые можно прочитать и записать в модуль. Нас интересуют настройки сети: скорость обмена, сетевой адрес и всякие таймауты. Напоминаю, что у модулей есть фишка: если его не опрашивали по RS-485 указанное время, то он считает что связь оборвалась и выставляет на выходах аварийные значения, чтобы оборудование не натворило дел (сам не поехал лифт или не включились насосы и прочее). В нашем случае модуль управляет лампочками, поэтому мы выставляем все аварийные значения на ноль.

Настройки модуля релейных выходов МУ110-16Р

А некоторые модули ввода-вывода ещё и могут общаться по разным протоколам. Да и даже у самого ModBus есть парочка модификаций: RTU (устройства обмениваются двоичными даными) и ASCII (все данные гоняются в текстовом виде). Мы будем использовать более быстрый протокол ModBus-RTU.

Настройки модуля входов МВ110-16Д

Обратите внимание, что для модулей ввода есть программный фильтр дребезга контактов. Его мы тоже включаем.

Ещё у этой программы есть возможность контролировать состояние входов-выходов. С помощью этого можно отдельно протестировать каждый модуль на работоспособность.

Изучаем CodeSys

Итак, с помощью программы мы настроили все модули на одинаковые параметры связи и дали им адреса. Теперь их можно физически подключить к ПЛК, а сам ПЛК воткнуть в сетку. ПЛК ОВЕН 110 можно программировать тремя способами: через USB, через RS-232 и по сетке. Самый лучший способ из этого — программировать ПЛК по сетке, потому что в этом случае он не перезапускается, а программа заливается туда в горячем режиме. То-есть написали, загрузили, проверили. Что-то исправили? Сразу же загрузили и проверили. Если же программировать ПЛК по USB — то там надо вынимать USB-кабель после заливки программы, что адски неудобно.

Связь с ПЛК 110 по Ethernet

И теперь начинаем разбираться с CodeSys. Я скачал её прямо с сайта ОВЕНа, где она есть в русском варианте. Вообще я не люблю русские переводы специального софта, потому что переводят его те, кто ни фига не понимает в технике. Например, самый адский перевод был у AutoCad: «Вырезать, Обрезать, Растянуть, Расчленить, Взорвать». Или у P-CAD, где Net (соединение) перевели как «Сеть». Но в случае с CodeSys русский перевод мне помог разобраться в терминологии и в том, где что находится. После этого русский перевод мне уже не нужен, и я могу ориентироваться в английской среде свободно.

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

Среда разработки CodeSys v2 для ПЛК 110

Сама CodeSys поддерживает много языков программирования. В том числе и тех, на которых удобно программировать логические реле.

Пример проекта на CodeSys на нескольких языках одновременно

Например, можно программировать при помощи блок-схем (CFC). Это как нам в школе алгоритмы учили рисовать в стиле «Начало => Ввод данных => Если .. то => иначе => Конец». Тут это рисуется при помощи блоков:

Пример последовательных логических схем (CFC)

А можно програмировать функциональными блоками (FBD), как на логических реле. В этом случае схема исполняется не последовательно как в CFC, а по сигналам, как в обычной цифровой логике на микросхемах:

Пример разработки на функциональных блоках (FBD)

Для тех, кто переходит с обычных релюшек и автоматики есть возможность писать всё в релейной логике LD, LAD. Тогда всякие сигналы описываются контактами, которые включают или выключают реле:

Пример разработки на релейно-контактной схеме (LD)

А ещё есть язык инструкций IL. Он подойдёт тем, кто любит суровый ассемблер. Смотрите, как он похож на него же:

Пример разработки на языке инструкций (IL)

А на мой взгляд самый удобный язык для сложных задач — это обычный текст ST, который похож на смесь СИ и Pascal одновременно:

Пример разработки на редакторе кода (ST)

Тут тебе есть и комментарии, и возможность написать любые условия.

Внутри CodeSys можно совмещать все эти языки и создавать свои функциональные блоки. Например, вы можете на ST написать сложный блок, который чего-нибудь вычисляет и выдаёт на выходе логическое значение 1 или 0. А потом взять язык FBD и из этих блоков составить «простую» логическую схемку.

Распределяем ресурсы ПЛК

Наше программирование, конечно же, тесно связано с железом. И наша среда CodeSys должна знать то, какие железо мы сейчас используем. Это конечно же понятно: в разных ПЛК есть разное количество памяти, портов ввода-вывода и прочих штуковин.

Поэтому новый проект всегда начинается с выбора платформы. На английском это называется Target. Сама среда никогда не будет знать о всяких ОВЕНах и других ПЛК. Изначально она знает только о некоем абстрактном ядре «3S CodeSys». Чтобы она узнала про наши ПЛК, нам надо пойти на сайт разработчика и скачать оттуда Target-файлы для наших ПЛК.

После этого Target’ы загружаются в CodeSys (на версии 2 этот процесс адски мутный, неочевидный и противный), и мы наконец-то можем творить. Выбираем нужный вариант нашего ПЛК:

Выбор железа для разработки программы под ПЛК

Теперь мы сразу вспоминаем то, что ПЛК — это многозадачная система, внутри которой крутятся задачи — программы, которые что-нибудь делают. Задач может быть несколько, но для работы ПЛК нужна хотя бы одна. В CodeSys она обязана называться «PLC_PROG», и именно её нам сразу предлагают создать после выбора платформы ПЛК.

Сразу же при её создании надо выбрать язык, на котором вы будете писать код. Если вы вдруг ошиблись с названием языка (я постоянно путаю IL и ST), то можно просто удалить эту задачу и создать новую с тем же именем.

Создание основной программы по умолчанию

После этого наш проект создан и среда от нас отстала. Если мы пишем на ST, то в коде PLC_PROG достаточно поставить «;» и программа откомпилируется. Но работать ничего не будет. Почему? А потому что ПЛК не знает, как к его ресурсам обращаться и чего у него вообще есть.

И вот чтобы его этому научить — надо аккуратно и внимательно разобраться с его ресурсами и с тем, как туда прописывать внешние модули ввода-вывода. Всё это кажется лёгким только тогда, когда сам всё понял. А когда смотришь на конфигурацию ПЛК в самый первый раз, то от неё взрывается голова. Я разбирался с этим дней пять, потому что ещё и инструкция по работе с CodeSys на сайте ОВЕНа говорит «Сделайте это и то», но не говорит ПОЧЕМУ так надо делать. Я этот недостаток хочу исправить и потом пошлю ОВЕНу ссылку на эти посты.

Для того, чтобы CodeSys знала про все-все ресурсы и ввод-вывод всей системы на базе ПЛК, это всё надо прописать руками. То-есть, вся конфигурация системы прописывается в том же программном коде жёстко. И поэтому когда вы выбираете всякие модули ввода-вывода, назначаете им параметры связи и адреса, вы должны понимать, что это останется навсегда. А если надо будет поменять адрес устройства — то вам надо будет перекомпилировать проект.

Общий концепт ресурсов и обращения к ним сделан при помощи неких адресов. Адреса эти вычисляет сама среда по нашей конфигурации ПЛК. На скриншоте ниже эти адреса начинаются со знаков «AT %». Чтобы программист не мучился с этими адресами, он может создать обычные программные переменные, которые будут использовать вместо адресов понятные имена типа «WaterPump», которая на самом деле будет говорить о внешнем выходе по адресу типа «%QW6.3.0.0».

Поэтому первой нашей задачей будет изучить окошко «Конфигурация ПЛК» и то, что там можно делать. Давайте на него посмотрим:

Конфигурация ПЛК и его ресурсов

Слева у нас есть дерево, в котором будет показываться вся-вся конфигурация нашей системы. А справа от дерева появляются разные параметры, которые можно настраивать. Там же можно задать для самих себя понятные имена и названия всех объектов системы, чтобы не путаться.

Слева у меня сейчас развёрнута конфигурация самого ПЛК. Чего у нас тут есть? Есть два быстрых входа, 16 обычных входов (в сумме — 18). Так же есть четыре быстрых выхода и 10 обычных — в сумме 14. Это соотвествует тому, что у этого ПЛК действительно есть. Дополнительно есть Special Input — это кнопка «F1» на самом ПЛК и Special Output — это пищалка ПЛК. Если туда записать «1», то пищалка будет пищать и привлекать наше внимание к системе.

Около этих ресурсов есть обозначение «[FIX]» или «[SLOT]». Если написано «SLOT», то это означает что программно можно заставить среду воспринимать эти входы или выходы не как дискретные 1..0, а например как энкодер или ШИМ-регулятор. Это сделано для того, чтобы облегчить программирование с заставить ПЛК максимально автоматически обрабатывать данные с IO, не нагружая этим программиста. Соотвественно те ресурсы, которые «FIX» изменять нельзя и они всегда будут теми, какие они и есть.

Около каждого ресурса как раз и указан его адрес, по которому к нему можно обращаться. Вот если мы хотим программно включить быстрый выход 2, то нам нужен адрес «%QX2.0». Про то, как назначать адреса переменным, я расскажу позже.

Для каждого ресурса есть свой набор настроек. Вот например для выходов можно точно так же настроить безопасные значения, как и для внешних модулей ввода-вывода:

Настройка безопасных значений выходов ПЛК

Идём дальше! Это-то мы изучали внутренние ресурсы, которые есть на борту ПЛК. А как же нам добраться до внешних ресурсов? Вот у нас есть аж три модуля ввода-вывода. Но где же они?

А нигде! Их надо добавить ручками. Логика тут простая и технарская: то, что у тебя есть физически должно быть и в программе. Давайте вспомним, чего у нас есть физически? Модули? Неа! У нас есть протокол ModBus!

Поэтому мы кликаем на самом ПЛК и выбираем из меню этот самый ModBus (Master) вот так, как показано ниже. Master — потому что главный у нас в сети ПЛК, и именно он будет управлять всеми другими модулями. Так же там есть ещё и другие протоколы обмена для разных вариантов сети. Например можно было вообще взять собственный протокол «ОВЕН» и построить сетку на нём.

Добавляем внешний интерфейс связи

Обратите внимание, что этот протокол сейчас не привязан к физическим проводам ПЛК! После того, как мы добавим наш ModBus, система просто будет знать что есть некий абстрактный протокол, по которому гоняются байтики. Но через какой порт ПЛК это будет работать — она пока ещё не знает!

Что же делать? Придётся научить нашу систему нужному порту. Для этого мы разворачиваем дерево под нашим ModBus’ом и видим искомое. По умолчанию система подставила самый первый попавшийся интерфейс ПЛК — «Debug RS-232». Мы видим около него волшебную надпись «SLOT». Кликаем по ней правой кнопкой мыши и — вуаля! Мы можем заменить его на нужный на RS-485.

Выбираем тип интерфейса RS-485

Причём список замены будет только из тех вариантов, которые действительно есть в именно этом ПЛК. Например в некоторых ПЛК бывает аж два интерфейса RS-485, на которых можно построить две разные сетки ModBus.

И вот только теперь мы дошли до физического уровня: собственно самого RS-485. Для него у нас есть настройки протокола обмена и параметров связи. Если вы помните, то мы все модули конфигурировали на ModBus RTU и скорость обмена 9600. Теперь вставим эти же настройки в нашем ПЛК:

Настраиваем параметры протокола интерфейса

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

Вот сейчас мы как раз и добавим наши внешние модули. Сам ОВЕН рекомендует добавлять свои модули как «Unversal ModBus Device» — некое абстрактное устройство. Сделаем так:

Добавляем устройство ModBus

Теперь у нас появился некий внешний модуль, который подключен на нашу шину RS-485 и будет работать по ModBus. Но напоминаю вам то, что протокол ModBus — это просто способ читать и записывать байты в и из устройств. И более ничего. А вот что значит каждый байт и та область памяти, куда его надо записать/прочитать — знает разработчик модуля и разработчик системы на базе ПЛК.

Для каждого модуля надо будет задать параметры связи. Для нас это адрес модуля (ModuleSlaveAddress) и время опроса его контроллером. Контроллер будет автоматически общаться с модулем раз в столько миллисекунд, сколько мы укажем.

Настраиваем параметры устройства

Время опроса позволяет снизить нагрузку на шину связи. Например если модуль управляет лампочками освещения, то его можно опрашивать реже, отдавая время шины каким-нибудь более быстрым модулям аналогового регулирования.

Ну добавили мы модуль, и чего? А как система узнает как рулить его входами или выходами? Вообще, откуда она узнает, где они у него находятся? А узнает она это через человека, который достанет и прочитает инструкцию на модуль. Для любого устройства с протоколом ModBus производитель даёт таблицу, в которой указаны все адреса его регистров. Выглядит эта таблица вот таким образом, например:

Пример регистров устройства из документации

Тут нас интересует два момента. Так как это модуль ввода, то нам надо получать значения его входов. Производитель, чтобы не гонять по сети тьму байтов, упаковал все 16 входов в 16 бит — в два байта, в тип WORD. Значит, нас интересует регистр номер 51, который надо будет читать из модуля. Следующий момент, который нам важен — это проверить команду, которая используется для записи-чтения данных в этот модуль. Иногда они могут отличаться от стандартных.

Отлично! Вот теперь мы всё знаем, чтобы добавить это в наш ПЛК. Тыкаем менюшкой на нашем модуле и выбираем, что добавить. типы в CodeSys называются так:

• 8 Bit — BYTE, байт
• Register — INT, WORD — два байта
• 32 Bit — DWORD, четыре байта

Так как в документации видно что мы читаем двухбайтовое слово — то нам нужен тип «Register input»:

Добавляем регистр устройства в конфигурацию

Теперь задаём параметры именно для этого кусочка: адрес регистра, который читаем и команду, которой читаем.

Настраиваем адрес регистра и способ его опроса

Вот теперь (см. скриншот сверху) ПЛК знает что у нас есть протокол MoBus-RTU на основе интерфейса RS-485, на котором висит устройство с адресом «1», из которого мы читаем два байта из ячейки «51».

А вот как выглядит конфигурация ПЛК для моей системы. У меня стоит один модуль ввода на 16 входов и модуль вывода на 16 выходов. И на будущее для диммирования света стоит модуль аналогого вывода.

Полный список внешних устройств и внешних регистров

Назначение переменных в ПЛК

Вот теперь у нас есть все-все адреса наших ресурсов. Чтобы нам было удобно ими пользоваться, мы заведём для них программные переменные. Это тоже ручная работа, в которой требуется внимательность. А ещё её в CodeSys v2 делать не очень удобно, потому что в табличке для ввода переменных не меняется ширина колонок.

Посмотрим на конфигурацию ПЛК и выцепим оттуда адреса всех наших входов и выходов. Я их подчеркнул красным:

Адреса переменных внутреннего ввода-вывода

А теперь создадим переменные для них. Для этого мы идём в раздел «Глобальные переменные» и начинаем заполнять табличку примерно так:

Создаём переменные внутреннего ввода-вывода

Видите? Мы указываем название переменной и прописываем её адрес и тип. И теперь чтобы включить внутренний выход 1, нам надо написать «MOuts0_1 := TRUE;».

Проделаем то же самое с внешними устройствами. Тут адреса становятся длиннее:

Адреса переменных внешнего ввода-вывода

И редактировать их не совсем удобно. Заполняем переменные:

Создаём переменные внешнего ввода-вывода

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

Ну и если теперь залить эту пустую программу (в коде мы ничего не написали) в ПЛК, то он сразу же примется опрашивать наши модули. На фотке ниже я случайно заснял момент, когда ПЛК опрашивает один из модулей.

После запуска ПЛК начинает опрашивать все внешние устройства

Программируем

А дальше начинается колдунство. Мне надо было на тот момент вообще научиться работать с CodeSys. Я тогда не разобратся, можно ли адресовать отдельные биты переменных и написал простые участки кода, которые приводили все переменные внешних ресурсов в удобоваримый для меня код.

Видите, я просто беру значение бита нужной мне переменной (от входа) и заношу его в глобальную переменную, которая уже обозначает конкретную кнопку управления светом.

Код преобразования входных переменных к типу BOOL

То же самое я проделал с выходами:

Код преобразования выходных переменных из типа BOOL

Теперь можно кодить. Для теста я сделал самое простое: нажимаем кнопку — срабатывает выход. То-есть мы просто присваиваем выход входу и наслаждаемся работой мощного ПЛК

Кусочек прошивки для управления освещением на ПЛК

Ещё я нашёл в Сети пример того, как сделать на CodeSys импульсное реле и тоже его протестировал. Кстати, пример лежит на форуме ОВЕНа.

На форуме у них не совсем приятно. Там тусуются ушлые товарищи (не из ОВЕНа), которые в личке каждому новому пользователю сразу предлагают услуги по разработке и поддержке решений на ПЛК. Мне один такой тоже написал. Я ради прикола послал его нафиг и расспросил, почему он это сделал. Ответ был типично маркетологовский: «Ну так если ты тут зарегался, значит ты можешь быть моим клиентом». В итоге товарищ был послан далеко и надолго. Особенно после того, как стал угрожать мне завалить мой блог за посыл нахуй. М-да. Страшно, в общем, на форуме ОВЕНа.

Задачи

Кратко покажу, чего есть из задач и чего с ними можно делать. Напоминаю: задача — это кусок программы, который ПЛК будет выполнять через указанное время. Есть системные события, которые показаны ниже (запуск ПЛК, остановка ПЛК, перед и после сброса):

Настройка задач в ПЛК

А мы хотим навесить на ПЛК свои собственные задачи. Вот у меня их получилось две штуки. Одна считает импульсы со счётчиков воды, а другая обслуживает управление освещением.

Для каждой задачи задаётся время её исполнения. Оно может измеряться в миллисекундах, часах и даже днях.

Конфигурация задачи в ПЛК

Ну а для самой задачи задаётся то, что будет выполняться:

Настройка вызова подпрограммы в задаче

Связь с ПЛК и заливка программы

Ну и теперь нам осталось только залить нашу программу в ПЛК. Для этого мы идём в меню «Онлайн -> Параметры связи» и создаём там подключение по сетке через протокол TCP.

Настройка связи с ПЛК по протоколу IP

После этого достаточно выбрать команду подключения к ПЛК:

Начинаем подключение к ПЛК

CodeSys устанавливает связь с ПЛК и спрашивает нас о том, что нам надо сделать с программой. Если ПЛК только с завода и там нет никакой программы — то CodeSys предложит загрузить новую программу в ПЛК. А если программа в ПЛК уже была, то система предложит загрузить новую или перезаписать программу полностью:

Запрос среды разработки о загрузке программы в ПЛК

У ПЛК и здесь всё отличается от логических реле. В логическом реле программа загружается навсегда и будет работать после выключения и включения питания реле. А у ПЛК программа загружается просто в память и работает только для момента выключения питания ПЛК. Это сделано специально, чтобы можно было отлаживать программу и не испортить рабочую систему и программу. Скажем, можно поиграться с другой версией программы, а потом передёрнуть питание — и ПЛК будет работать по старому.

Если же мы хотим записать нашу программу в ПЛК навсегда (чтобы она работала при следующих включениях питания), то нам надо выбрать пункт «Создание загрузочного проекта». В этом случае программа без запросов записывается в ПЛК и будет выполняться при следующем включении его питания.

Создание загрузочного проекта в ПЛК

Из дополнительных возможностей можно загрузить в ПЛК исходники проекта или любой файл (размером несколько мегабайт). Это полезно, если мы хотим оставить внутри ПЛК архив документации по всему проекту.

При подключенной связи с ПЛК можно наблюдать как и чего работает и производить отладку программы. Вот как выглядит это на нашей:

Работа среды CodeSys в режиме отладки программы

Собственно по программированию всё. Если сказать всё сжато, то для того чтобы начать работать с ПЛК, надо занести в него все его ресурсы и внешние модули. После этого можно назначить переменные по адресам и писать обычный программный код.

Библиотеки

А ещё под CodeSys есть много библиотек с готовыми функцями. Самая известная среди них — библиотека OSCAT. Я её скачал и нашёл там много интересного. Например вот модуль CLICK, который может определять одинарное, двойное и тройное нажатие на кнопку. При помощи него можно делать например так, чтобы если мы погасили весь свет одной кнопкой, то при двойном нажатии на неё весь свет включился там же, где и был включен.

Пример из библиотеки OSCAT: Определение количества нажатий

А вот навороченный диммер с кучей предустановок и возможностей. Сигнал с диммера можно направить на модуль аналогового вывода или на диммер, который управляется по Modbus напрямую и управлять освещением.

Пример из библиотеки OSCAT: Многофункциональный диммер

Ну а я же сделал для заказчика простую программу включения и выключения света и реализацию функции защиты от протечек. Про это я расскажу позже в третьей части статьи.

Критические ошибки проектирования АСУ ТП и программирования ПЛК.

В промышленности внедряются автоматизированные системы управления технологическим процессом (АСУ ТП) на промышленных программируемых логических контроллерах (ПЛК) на объектах модернизации. Вновь поставляемое оборудование, уже по умолчанию содержит АСУ на ПЛК. Но качество проектирования АСУ ТП и программирования ПЛК иногда не соответствует логике и требований к надежной защите управляемого объекта. В этой статье я расскажу о типичной ошибке проектирования и программирования обычного промышленного оборудования.

Введение

Рассмотрим типичный объект, содержащий АСУ на ПЛК в промышленности. В горнообрабатывающей отрасли, на обогатительных фабриках (ОФ) на стадии измельчения полезных ископаемых (руды) применяются различного типа мельницы. Они бывают шаровые, стержневые, вертикальные тонкого измельчения и т.д. Основной функцией данных мельниц является измельчения руды до фракции необходимой в дальнейшем для химического извлечения полезного ископаемого. У такого оборудования есть свои слабые места в процессе эксплуатации. Победитовые коренные подшипники, редуктора и т.д. Они требуют к себе постоянного контроля температуры, наличия смазки и т.д. В случае перегрева или сухого хода АСУ должна отключить агрегат, пока состояние узлов не достигло критической точки. Программные реализации данных защит и блокировок типичны и стандартны для такого рода оборудования.

Какие бывают ошибки?

Давайте рассмотрим две основные ошибки при проектировании и программировании АСУ для оборудования такого типа. Первая ошибка – неправильное проектирование релейной части управления главного привода или критичного механизма. Вторая ошибка – недостаток программы в части обработки фатальных ошибок ПЛК.

Ошибки в схемах.

Рассмотрим случай с релейной частью. На рисунке приведен пример такой ошибки. В схеме показана только часть управления отключения главного привода оборудования.

На первый взгляд обычная релейная схема. Но если присмотреться к ней, то можно определить, что рано или поздно наступит такой момент, когда релейная схема не сможет отключить главный привод в случае возникновения аварийной ситуации. Присмотримся к схеме. Отключение главного привода осуществляется ПЛК дискретным выходом. В данной схеме он релейный, но может быть и транзисторным, суть от этого не поменяется. Так вот, если по какой то причине катушка реле К1 сгорит во время работы оборудования, то при возникновении аварии, контроллер даст сигнал на отключение главного привода, но сигнал дальше сгоревшей катушки реле не пойдет. Но ведь по технологии, при отключении главного привода, требуется и отключение вспомогательного оборудования, в данном случае это маслонасос. Так вод при аварии, маслонасос будет благополучно отключен, а главный привод останется молотить на «сухую». Благо система ко всему еще и оповещение включит, так, что противно кричащий звонок и моргающая красная лампа привлекут к себе внимание обслуживающего персонала и «катастрофы» не произойдет. После этого, местные электрики или КИПовцы, найдут причину сего безобразия, поменяют реле и все станет на свои места, быть может, кто нибудь и задумается, как этого избежать в будущем, но врядли.
Так что в этой схеме реле К1 слабое звено. Что можно сделать чтоб такого не случилось. Элементарно. Сигнал отключения ВВ посадить на нормально-закрытый контакт реле К1, а само реле притягивать во время пуска главного привода и в рабочем состоянии удерживать его притянутым. Кстати, кнопку аварийный стоп, тоже так включать не стоит. Либо контакты кнопки должны непосредственно отключать исполнительный механизм, либо, если таких механизмов несколько, разрывать цепь реле, контакты которого уже отключают исполнительные механизмы. Кстати, такое включение промежуточных реле управления критичными исполнительными механизмами рождает и ошибочную отработку при ошибках программирования ПЛК.

Ошибки программирования ПЛК.

1. Разветвленный алгоритм имел тупиковую ветку, приведшую к срабатыванию сторожевого таймера.
2. Обработка исключений в программе не производилась, тем самым ПЛК перешел в режим «СТОП».

Подведем итоги.

Релейную схему необходимо проектировать так, что бы в любой аварийной ситуации, будь то технологическая авария или ошибка ПЛК, отключение исполнительных механизмов проводилось в обязательном порядке не зависимо от рода возникновения аварии. Подходить к программированию ПЛК со всей ответственностью, ведь оборудование, которое призвано защитить АСУ ТП от критичных условий эксплуатации, приводящим к разрушению механизмов, намного дороже самой АСУ.
В данной схеме необходимо было использовать следующее включение компонентов релейной схемы.

А в программном модуле OB121, выполнять какие-нибудь действия по архивированию случившегося отказа в ПЛК.

Видео, показывающее поведения ПЛК при программных ошибках и их обработках представлено ниже.

Вывод

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

P.S.
Оставлять просто пустые программные блоки обработки аппаратных или программных ошибок тоже не стоит. В них необходимо выполнять какие либо действия на детектирование таких ошибок или для сбора статистики отказов ПЛК и возможных причин.

P.S.S.
Оригинал схемы. Разборчивость вроде нормальная.

, ,

• +4
• 09 января 2016, 11:22

Комментарии ( 159 )

Выдуманная ошибка полного неуча — чтобы её не было достаточно соблюдать правила консистентной (целостно-непротворечивой) загрузки всей программы и всей конфигурации

Такая ситуация возможно у неучей и людей со слабым характером… когда я после 3-х суток НИОКР на ногах говорю «ВСЁ… эксперименты прекращаем… идём спать. » то меня уже не заставишь… я говорю, что если продолжать, то я могу совершить неисправимые ошибки… это вам надо?
Надо ответственно относиться к своей работе — вот ты отнёсся к своей просветительской деятельности халтурно… чего не сделал?
1. Навязал неверную методологию создания программы и загрузки чистого ПЛК.
2. После загрузки не проверил в режиме подключения состояние ПЛК в HW Config.
и соответственно
3. Не посмотрел Буфер диагностики ПЛК
4. Не обратил внимание на индикатор ошибки.

Там как бы… того… СКАДЫ как таковой я не увидел…
замена, глупая очень замена, релейноконтакторной схемы на ПЛК. И все!

Вот Вы опять понятиям смысл другой даете:

SCADA (аббр. от англ. supervisory control and data acquisition, диспетчерское управление и сбор данных) — программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. SCADA может являться частью АСУ ТП, АСКУЭ, системы экологического мониторинга, научного эксперимента, автоматизации здания и т. д. SCADA-системы используются во всех отраслях хозяйства, где требуется обеспечивать операторский контроль за технологическими процессами в реальном времени. Данное программное обеспечение устанавливается на компьютеры и, для связи с объектом, использует драйверы ввода-вывода или OPC/DDE серверы. Программный код может быть как написан на языке программирования (например на C++), так и сгенерирован в среде проектирования.

Иногда SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляют термин SoftLogic.

Термин «SCADA» имеет двоякое толкование. Наиболее широко распространено понимание SCADA как приложения[1], то есть программного комплекса, обеспечивающего выполнение указанных функций, а также инструментальных средств для разработки этого программного обеспечения. Однако, часто под SCADA-системой подразумевают программно-аппаратный комплекс. Подобное понимание термина SCADA более характерно для раздела телеметрия.

Значение термина SCADA претерпело изменения вместе с развитием технологий автоматизации и управления технологическими процессами. В 80-е годы под SCADA-системами чаще понимали программно-аппаратные комплексы сбора данных реального времени. С 90-х годов термин SCADA больше используется для обозначения только программной части человеко-машинного интерфейса АСУ ТП.

Для полного обесточивания используются «Реле Безопасности»
пример PILZ — внутри схема контроля входов от аварийных кнопок и 2 реле, соединённых последовательно

Их можно выключить по размыканию цепи кнопки аварийного стопа и по команде от ПЛК
как на представленной схеме Siemens SK11**

Helix — не рисуй такие схемы в популистких целях — я из твоей схемы ничего не понял

и при этом программа как то будет работать…
Это кабздец…
Как минимум должн быть стопицот предупрждений или невозможность работы не?

зы У нас все не несколько проще оно туда не загрузится если что то не так ну и в худшем случае если не совпадет прошивка — контроллер просто не будет работать

На сайте Сименса есть русская документация «Первые шаги», где по шагам подробно описано как правильно составлять конфигурацию и правильно написать программу и затем правильно её загрузить в контроллер (выбрав в дереве проекта правильное место) и правильно отладить с поиском ошибок.

А теперь по «ошибкам» — надо быть полным неучем, чтобы придумывать такие «ошибки» на пустом месте и затем усугублять их.
В случае возникновения ошибки на морде контроллера или симулятора Сименса начинают светиться соответствующие индикаторы Ошибки программы SF — System Fault или Ошибки связи BF — Bus Fault.
Причина ошибки ищется в буфере диагностики контроллера.

Система продолжает работать не смотря на наличие ошибки… по факту не подключен коммуникационный модуль, который не влияет на выполнение основной программы управления

На форуме Сименса в последнее время появилось много просьб научить «чайников» за 3 дня всем знаниям за курс средней школы и специализированного ВУЗа и курса работы подмастерьем на производстве…
Прошу несведующих не удивляться некоторым домыслам и вымыслам в блогах и форумах… к сожалению в отечественную промышленную автоматику была внедрена группа диверсантов 🙁
Потом диверсанты с умным видом начинают учить других диверсантов.

Честно говоря боюсь представить, что нас ждет в будущем. Уже сейчас с кадрами огромные проблемы: наш университет выпускает каких то бакалавров недоделанных. 15 лет не был в университете, тут пришлось по случаю столкнуться: зп преподавателя на 1 ставку не приличная, вместо процесса обучения нужно заниматься бумажками. Науки нет. Красивые слова, типа территория опережающего развития, бизнес-инкубатор и прочаяя дребедень.
Книжку типа Simatic для чайников нужно будет вместе с автором закопать. Если ее еще нет, то возможно она уже пишется, каким нибудь доцентом. Рано или поздно наверняка подобный труд нарисуют.

Жена врач, если перенести ситуацию на медицину, то получится такая тема на форуме врачей: здравствуйте, я медсестра, докторов нет, но начальство хочет чтобы я могла удалить гланды и сделать операцию на головном мозге.
Дайте пожалуйста книгу Хирургия для чайников.
Температуру я уже научилась измерять, колоть в вену не приходилось, но представление имею.

И уже не до смеха, т к в медецине тоже с кадрами катастрофа

Я начинал работу в КБ… делал от релейки до микропроцессорных систем управления… ещё на 580… затем на 1816
чайником себя никогда не называл

Тут меня возмутило только одно! Чайник, не чайник… все мы в разных областях чайники…
Но когда более опытные люди говорят что так не делается, а чайник в ответ три этажа оспорений что эта система имеет право на жизнь и т.д… вот тут бомболейло…

Работал с фирмой продающей оборудование для железки, испытательное оборудование, вот если выходила деталь из строя подвижного состава и приводило к аварии (не приведи господь человеческие жертвы. ) проводится расследование где выясняется кто что как… результат расследования — сроки большие людям по чьей вине…
Вот там меня научили ответственности! Когда пол месяца все предприятие сидит и кирпичами срет в ожидании вердикта, чтоб это не испытанная нашим оборудованием деталь развалилась, а испытание показало не верные значения…
После нескольких валидольных недель понял, надо делать все по правилам, без отклонения и самоуправства и слушаться более опытных! Иначе шаг в право, шаг влево — расстрел.

И в процессе разработки и пусковой наладке обязательным считается все это проверять и отлаживать.
Ну вот дверь немного отладили… никогда не догадаетесь как…

Ставлю ПИЩАЛКИ и ЗВОНКИ ГРОМКОГО БОЯ, которые разбудят любого оператора
s7detali.narod.ru/Other/Buzer.html

Ещё один учитель-неуч — изучи любую схему Старт-Стоп движка или просто включения силового контактора…
Отключение любого оборудования происходит размыканием нормально-замкнутого контакта схемы управления… при этом цепь разрывается и нагрузка отключается… иначе можно наломать редукторов.
Аналогично Кнопки Аварийного Стопа имеют Нормально-Замкнутые контакты… будь то нажатие на кнопку с фиксатором. или обрыв провода кем то или чем то, то схема не соберётся до устранения причин обрыва цепи

3,5 раза дороже. а тот кто подписывает документы… И т.д и т.п.

Не место в промышленной автоматике не умеющим читать документацию самоучкам — винить надо за то, что показывает неправильную методологию программирования, на основании которой делает ложные выводы.
Зайди на сайт документации Сименса и почитай «Первые шаги» — там всё по полочкам разложено

Примеры поиска причин ошибок ошибок

Я всегда думаю прежде чем перезаписать существующий блок — Степ7 спрашивает уверен ты в том, что ты хочешь сделать?

Галочку не гашу, так как иногда реально устаёшь занимаясь и программированием и монтажом… есть несколько мгновений на «подумать»…
если вспоминаю, что добавил новые подпрограммы, то отменяю загрузку этого блока и перехожу к загрузке ещё незагруженных,
а затем загружаю вызывающий их…
как бы данная последовательность должна быть в мозгах всегда — это гарантирует, что не будет неожиданных неприятностей.
Загрузка изменений происходит на лету без остановки контролера.
Если хочешь быть уверенным в непротиворечивости текущей программы залитому в ПЛК, то делаешь полную заливку с остановкой.
Предложи Сименсу, чтобы в 14-ый Портал они встроили сканер проверки непротиворечивости при загрузке изменений и тогда будет всплывать подобное окно

Ты не можешь понять?
Это пример неправильной методики программирования или способ поиска причин ошибок?
Как ты понял, что именно ОВ121 не хватает?
Почему ты её не заполнил для выяснения причин её вызова, а оставил пустой?
Как ты понял, что именно FC105 не залита?
Посмотрел буфер диагностики на 4-ой минуте?
Зашёл в собственно в контроллер и посмотрел, на его дерево?

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

Пусть мотивируется на повышение уровня навыков и изложения информации! Это уже не первый пост автора в котором я возмущаюсь о главном: Результаты! Адекватное обоснование результатов в выводах!

Нападаю на него потому, что чувствую тёмную друидскую силу. которая вместо пользы может принести много вреда.
он привёл свою неправильную методику написания программ
вместо чёткой методологии поиска причин ошибки

я на панели оператора специально делаю несколько экранов для оперативного и наглядного направления эксплуататора для поиска причин возникновения проблем… и да — с каждым объектом наполнение пополняется, так как не все ситуации не всегда можно заранее предугадать и предуcмотреть как быть в случае чисто механических проблем или отказа части оборудования, возникающих впервые в практике.
знаменитая гирлянда S7… реально критическая ошибка

Причем здесь какие-то друиды, тем более никакой силы у него и нет.

Диагноз был бы ясен, если бы ТС пояснил что о себе: какое он получал образование, каким образом он связан по работе с промавтоматикой, опыт работы.

Манией писанины таких и им подобных (а-ля «Курс по основам… бла-бла-бла „чего-то новомодного (TM)“») статей в инторнет обычно страдают самообучающиеся новички — чем его торкнуло недавно, что вкурил — надо срочно поделиться. Правда через год-полтора (максимум два) это желание у них постепенно пропадает ПОЧЕМУ-ТО, и сия бурная графоманская деятельность спадает вплоть до нуля.

А вообще в ответственных системах нужно ставить как минимум — диодно-конденсаторые накачки, типа этой:

Новичкам на будущее:
— первым делом активируйте меркерный таймер по адресу с умолчанием MB0 — как предлагает Сименс в конфигураторе.
— в МВ1 организуйте служебные биты: Всегда_0, Всегда_1,… аналогично как это сделано по умолчанию в ТИА Портале для S7-1500

Да почему «некоторые» — все допускают ошибки, не только программисты ПЛК, от ошибок нельзя зарекаться.

Меня честно говоря удивило то, что эта (достаточно, как я понимаю, примитивная) ошибка попала в рабочую систему. Понятно, что стиль разработки «хуяк, хуяк и в продакшин» — искоренить тяжело. Но я, честно говоря, думал что хоть в АСУ ТП такого нет. Получается, что код, написанный программистом, никто не ревьювил, никто не тестировал, никто не проверял как это все было залито в ПЛК… Даже для прикладного программирования сейчас такой подход выгладит странным, а для АСУ ТП, где риски намного больше, и подавно.

Может кто то из коллег, кто в теме, напишет как происходит разработка и внедрение программ в АСУ ТП (в плане методологии), а то описанное в топике выглядит как-то слишком странно (или это автор специально привел такой надуманый пример?).

0. Ждёшь поездки на объект…
1. Если подключился на стадии рабочки, то приходится первым делом изучить схему… поплеваться, поматюгаться, перемонтировать схему…
2. Если участвовал на стадии разработки, то переходишь к пункту 3.
3. Не спеша делаешь наклейки на короба с подписанием назначения автоматов и контакторов… а смысл торопиться… механика не собрана, лепездричество обещают дать на следующей неделе…
4. Кинули времянку… монтажники кидают кабели между шкафами и коробками… механизмы ещё не смонтировали…
5. На компе набираешь конфигурацию уже смонтированного оборудования… заливаешь в процессор… если есть ошибки по сети, то проверяешь монтаж…
6. Снаружи всё ещё не смонтирована механика… дырки не те…
Подключаешь датчики прямо в шкаф… набиваешь программу проверки датчиков… бесконтактных и энкодеров

5. Снаружи всё ещё не смонтирована механика… дырки те… механика не та…
отпускаешь монтажников на рыбалку… иначе гарантированы косяки, так как мысли не о монтаже…

6. Снаружи всё ещё не смонтирована механика… дырки те… механика та… но чего то не то между дырками и механикой…
Есть время для души… декриптовал навороченную защиту…

7. Теперь все личные задачи решены… буду щёлкать контакторами и рисовать ЧМО… рабочее многокиловаттное электричество обещают на следующей неделе…
8. Не спеша за пару дней пишешь программу с отображением на ЧМО. Запускаешь симуляцию работы установленных механизмов и срабатывания датчиков… монтажники по команде замыкают железякой бесконтактные датчики и обычные выключатели для освещения взамен отсутствующих… На экране всё нормально — тест прогнан несколько раз.

9. Установили треть оборудования… остальное будет в следующем году… не раньше апреля…
Начинаю угрожать, что уеду если не будет силы…
10. Пока кидают временное силовое электричество монтируем датчики, ставлю проволочные и программные перемычки… и там и там вешаю заметные наклейки — ЖУЧОК.
11. Дали силу…
проверяю движки по одиночке без нагрузки (муфты обеспальчены)
один движок не крутится… программный косяк?
Проверяю подписи на автоматах контакторах, смотрю напругу и ток…
тычу носом

Подпаяли… движок работает.
11. Собралось всё начальство. Нажимаю на пульте «Поехали. » контакторы защёлкали, релюшки заклацали, электроны молча побежали, частотники завентелировались, движки плавно мощно вышли на рабочую скорость с очень приятным звуком уууУУУУУУУ…
Все смонтированные механизмы работают штатно… Рабочий цикл отработан несколько раз… Все довольны…
На поезд… через 5 дней новый год… 3 дня в пути…

То есть после первого объекта приходит понимание, что нет смысла в офисе писать и вылизывать программу, так как по ходу пусконаладки приходится многое менять из-за неготовности объекта в полном объёме… потому что даже себе не всегда понятно, что тут селёдка лежала и поэтому это играть не надо…
На некоторых объектах бывает потруднее, так как механика или гидравлика ведут себя не совсем так, как рассчитывали механики или гидравлики… НИОКР годами может идти пока смежники не найдут решение своих проблем у себя… задача программиста убедить их искать именно у себя, а не в программе.

По нескольким проектам Экспертиза просила представить код… отдаёшь им истинный STL/AWL (текстовый язык) без имён и комментариев… талмут на несколько сотен листов… ещё ни разу никто не звонил и ничего не уточнял 🙂
Почему? Смотри копипасту:

Я например AWL вообще в глаза не видел.
На уроках сказали что есть такой язык но он вам не нужен!
Приехал в Германию, а они только на awl всё делают!
Вот и засада… хотя если чесн по логике мне проще SCL, ничего не выдумывая так и пишешь IF (условие) then (действие) else (не удача) по FUP или даже KOP проще во много раз делать такие вещи как таймеры или такие функции как И ИЛИ и так далее… потому что в AWL я уже после 3 скобки не могу уловить что там за логика типо

и вот эта жесть в FUP выглядела бы в 100 раз проще =) жаль нельзя в FC или FB сразу 3 языка использовать в разных Netzwerk.

там пунктик затерялся как вариация:
— написал программу оттестил все работает, уехал домой в ожидании когда до собирают механики, через месяц звонят с объекта кроя жудкими матами, механники проебались, сказали что пока ты не доделал там чего-то(выдуманое понятие, значение, кусок программы) им монтаж продолжать бессмысленно… шлешь всех на хуй даешь пизды механикам… они продолжают монтаж, проебуют сроки… сваливают всю вину на тебя…

З.Ы. мож мне так везло? но постоянно проебывали механики и спихивали на других! У них движок не там присобачен, а виноват электронщик, редуктор не с тем передаточным числом? алле! отбили датчик планшайбой -ау! течет труба? ну все поняли…

Бывает и такое: мы к тебе в электронику не лезем и ты к нам в механику/гидравлику не лезь…
Приходится вежливо напоминать о своих заслугах по введению объектов, находить общих знакомых, вежливо сказать: «Если объект не пойдёт, то достанется всем — давайте искать варианты проб :)»
вежливо заставить разобрать движки и тормоза/насосы/гидравлику «новые прямо с завода» и выкинуть их на ту же свалку где они были взяты

Был у меня случай с гидравликами — 2 цилиндра — по одиночке работают, вместе только один и сразу в перекос…
программа перепроверена, с монтажниками электрика перепроверена… из шкафов нужные сигналы уходят… на совещаниях гидравлики валят на нас…
вечером когда никого нет рядом закрываю некоторые краны некоторых магистралей… включаю систему… оба цилиндра идут просто идеально…
Переключаю краны в исходное положение и иду спать.
Утром созываю комиссию… включаю систему и демонстрирую, что ничего у меня не работает… перекос…
гидравлики стоят с улыбочкой…
иду и переключаю краны, по рации прошу оператора нажать на кнопку… цилиндры работают идеально…
поднимаю ручки и говорю: а ручки то вот они… дело не в программе и не в электрике.
Приехал автокран, демонтировали распределительную плиту и обнаружили заводской брак — пересверлили и попали в другой канал, при определённом положении кранов масло для из одного цилиндров перетекало сразу на слив.
Больше на объекте гидравлики никогда не выступали.

Хорошо работать, когда все понимают, что у них общее дело и не смысла искать виноватых, а надо обязательно найти решение общей проблемы.

Составление управляющей программы программируемого контроллера

Контроллер — это мозг для машины. Чем сложнее машина, тем функциональнее контроллер. Технически реализация мозга может быть разной – механика, пневматика либо гидравлика, релейные или электронные системы.

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

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

Среда программирования

Стандартом для программирования ПЛК является языки МЕК. В начале 90-х годов для этих задач на рынке появилась ПО «CoDeSys». Продукт соответствует стандарту МЕК 61131-3 для работы с ПЛК. ПО пользуется большим спросом по причине бесплатной лицензии.

Сейчас этот программный пакет серьезно вырос. Кроме стандартных интегрированных в систему редактора кода, отладчика и компилятора также в состав включен конфигуратор для контроллеров, промышленных сетей, редактор для составления мнемосхем, отладочных сервер, серверы OPC и DDE. Многие производители ПЛК предлагают эту среду, как базовый инструмент для работы.

Литература

На прошлой неделе, подачи одного из пользователей GeekBrains, я всерьёз задумался над вопросом “Где можно пройти курсы по программированию микроконтроллеров?”, да и вообще о профильной литературе в целом (и это несмотря на профильное высшее образование и около 10 лет опыта работы). Дело не в том, что их не существует (есть и курсы, и книги), просто главный инструмент разработчика ПО для МК — техническая документация, поставляемая вместе с платформой.

Все универсальные книги могут описать отличия, преимущества и недостатки тех или иных микроконтроллеров, на что обратить внимание при написании кода, обучить “красоте” и основным принципам. Но огромный плюс и он же главный недостаток данной профессии — подробная индивидуальная инструкция по работе с каждым более-менее серьёзным контроллером

Это означает, что абсолютно любой человек может взять, прочитать её и через несколько мгновений организовать стандартное мигание “светодиодами”. Но даже с 50 годами стажа вы не сможете сесть за незнакомый микроконтроллер и, не читая документацию, сделать с ним что-то полезное (придётся, как минимум взглянуть на расположение контактов и их назначение по умолчанию).

Компиляция программы

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

Далее откомпилированный готовый код нужно поместить в микроконтроллер, а точнее записать его в память микроконтроллера или, проще говоря, прошить микроконтроллер.

Для прошивки МК применяется устройство, называемое программатор. В зависимости от типа программатора вход его подключается к COM или USB порту, а выход к определенным выводам микроконтроллера.

Существует широкий выбор программаторов и отладочных плат, однако нас вполне устроит самый простой программатор , который в Китае стоит не более 3 $.

После того, как микроконтроллер прошит, выполняется отладка и тестирование программы на реальном устройстве или, как еще говорят, на «железе».

Теперь давайте подытожим этапы программирования микроконтроллеров.

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

Следует заметить, что отладку и тестирование программы также выполняют до прошивки МК.

Необходимый набор программ

Существует множество полезных и удобных программ для программирования МК. Они бывают как платные, так и бесплатные. Среди них можно выделить три основных:

Все эти программы относятся к IDE – Integrated Development Environment – интегрированная среда разработки. В них можно писать код, компилировать и отлаживать его.

Следует обратить внимание на Code Vision AVR. Эта IDE позволяет упростить и ускорить написание кода

Однако программа платная.

На начальном этапе программирования все программы лучше прописывать вручную, без каких-либо упрощений. Это поможет быстро приобрести необходимые навыки, а в дальнейшем хорошо понимать и редактировать под свои нужды коды, написанные кем-то другим. Поэтому я рекомендую использовать программу Atmel Studio. Во-первых, она абсолютно бесплатна и постоянно обновляется, а во-вторых она разработана компанией, изготавливающей микроконтроллеры на которых мы будем учиться программировать.

Основы программирования ПЛК. Реле и контроллер

Логика загружается в ПЛК при помощи программного обеспечения. Это ПО определяет, какие из выходов будут под напряжением и какие входные условия нужны для любых изменений. Управляющая программа аналогична схеме работы физического реле, но физически нет ни реле, ни проводов, ни катушек. Все эти элементы – мнимые. ПО разрабатывается и просматривается на ПК, соединенном с интерфейсом контроллера.

Есть кнопка, контроллер и индикатор. Когда кнопка не задействована, сигнал на вход контроллера отправлен не будет. ПО, показывающее открытый вход, не отправит сигнал на выход. Так, на выходе ток отсутствует и лампа не будет гореть.

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

Контакты с индикатором соединены физическим способом. А сигнал виртуальный. Однако, все элементы существуют только в компьютерном ПО, а как физические – нет. Но принцип реле здесь используется. Также в программе можно задавать условия, которые будут проверятся и выполнятся контроллером.

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

Управляющие команды на языке релейной логики просты и понятны для инженеров-электриков. На графическом интерфейсе видны все логические операции. Это электрическая ц3епь с замкнутыми либо разомкнутыми контактами. Если по цепи протекает ток, что это истина. Если ток не протекает, тогда состояние – ложь.

Основой управляющей программы служат логические выражения, состоящие из операндов и переменных. Также программа состоит из операторов. Операторы – это команды языка программирования.

Инженер-программист ПЛК – это сегодня больше инженер, чем программист. Сейчас не нужны сложные языки, писать ассемблерные вставки. Достаточно использовать стандартные функциональные блоки.

Входы и выходы

В любом контроллере реализованы входы трех типов – дискретные, аналоговые, специальные.

Дискретный вход

Один вход может принять только один сигнал и он будет бинарным. Вход может быть либо включенным, либо выключенным. Один вход — это 1 бит. К этому входу подключают соответствующее оборудование.

Если состояние приборов не удается описать в 1 бит, тогда для работы такого оборудования применяют несколько дискретных входов.

Системное ПО обязательно оснащено драйвером. Он считает физические значения каждого входа в ОЗУ. За счет этого программистам нет нужды понимать, как устроен контролер внутри. Дискретный вход – биты, которые можно читать и изменять из оперативной памяти устройства.

Аналоговый вход

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

Специальный вход

Обыкновенные входы способны удовлетворить практически все нужды. Необходимость в в спец. входах появляется при трудностях в обработке сигналов.

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

Второй тип таких входов – это входы, которые могут мгновенно запускать команды пользователей с прерываниями на выполнения основного ПО.

Дискретный выход

С одним выходом можно коммутировать только один сигнал. В качестве нагрузки на выходы могут использоваться различные исполнительные устройства.

Возможно, вам также будет интересно

Компания congatec объявляет о поддержке в модулях стандартов Qseven и SMARC новых 64-разрядных процессоров i.MX8 компании NXP Semiconductors. Будучи участником программы раннего доступа к продуктам компании NXP, новые модули от congatec будут доступны одновременно с запуском в производство нового семейства процессоров ARM Cortex A53/A72. Это позволяет OEM-клиентам congatec максимально эффективно реализовывать свои собственные стратегии выхода на рынок, поскольку они могут начать разработку платы-носителя для своих приложений и потом использовать готовые к применению модули congatec на основе …

На сегодняшний момент на российском рынке представлены десятки марок низковольтных преобразователей частоты иностранных и российских производителей. Среди них можно отметить ведущие европейские компании: Siemens, ABB, SEW Eurodrive, Control Techniques (корпорация Emerson), Schneider Electric, Danfoss, K.E.B., Lenze, Allen-Breadly (корпорация Rockwell Automation), Bosch Rexroth. Продукция этих п…

Новые РАС от ICP DAS – XP-8000-Atom, XP-8000-Atom-CE6

12 сентября, 2011ООО «ПЛКСистемы», официальный дилер ICP DAS в России, представляет новое поколение промышленных контроллеров серии XPAC от ICP DAS – XP-8000-Atom. Он комбинирует в себе функциональность и открытость ПК, надежность программируемых логических контроллеров (PLC) и возможности модулей ввода/вывода, что сильно влияет на улучшение показателя цена/производительность.

XP-8000-Atom построен на базе процессора Intel Atom и работает под операционной системой Windows Embedded Standard 2009 (WES) или Windows Embedded CE6. Контроллер оснащён различными типами соединений (VGA, USB, Ethernet, …

Структура и порядок написания программы

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

Следующим этапом после составления алгоритма является непосредственное написание кода программы. Программы для микроконтроллеров пишутся на языке Си или Ассемблере. Только Ассемблер больше относится к набору инструкций, нежели к языку программирования и является языком низкого уровня.

Мы будем писать программы на Си, который относится к языку высокого уровня. Программы на Си пишутся гораздо быстрее по сравнению с аналогичными на Ассемблере. К тому же все сложные программы пишутся преимущественно на Си.

Здесь мы не будем сравнивать преимущества и недостатки написания программ на Ассемблере и Си. Со временем, приобретя некоторый опыт в программировании МК, вы сами для себя сделаете полезные выводы.

Сам код программы можно писать в любом стандартном текстовом редакторе, например в Блокноте. Однако на практике пользуются более удобными редакторами, о которых будет сказано далее.

Структура и устройство ПЛК

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

Сейчас выпускаются контроллеры в различных форм-факторах. Это:

1. Устройство типа «всё в одном». В одном корпусе объединен процессор, память, выходы/входы;
2. Распределенные решения – процессорный модуль с обвязкой сделан в виде отдельного блока, а по шине или через интерфейсы подключатся модули для вывода и ввода.

Первые модели встречаются очень часто, однако, они рассчитаны на эксплуатацию в малых объектах и системах, где нужно обрабатывать малое количество сигналов.

Второй вид контроллеров используют в промышленности гораздо шире – производства с полнофункциональными АСУ требуют значительно большего числа сигналов, которые требуется обрабатывать. Если производство масштабное, то удобнее разнести модули вводы вывода по территории с объединением в единую сеть, которая подчиняется отдельному логическому контроллеру. Такие сети называют полевыми сетями или fieldbus. К этой седи подключаются датчики, исполнительные системы, которые являются интеллектуальными, так как имеют эту возможность.

Существует масса видов полевых сетей. Стандарт IEC61158 (МЭК61158) включает в себя 8 видов сетей. А до введения этого стандарта каждый производитель придумывал и использовал свою полевую сеть.

В структуре ПЛК имеется базовые компоненты:

• Модуль процессора;
• Блок питания;
• Модули для ввода/вывода.

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

В зависимости от того, сколько каналов для ввода и вывода и какой тип процессора, модули ввод/вывод могут быть установлены на одном шасси с ЦП или на нескольких. До конца 80-х годов модули для ввода и вывода данных располагались отдельно от процессора. В стандартном контроллере современного типа модуль входов и выходов находится на одном шасси с микропроцессором. Некоторые ПЛК позволяют устанавливать более одного микропроцессора.

Модели меньших размеров очень часто предназначены под DIN-рейку. Самые компактные микро или даже нано устройства имеют всю систему, включая адаптер питания и систему ввода/вывода в одном корпусе. Микро-контроллеры иногда оборудуются встроенными панелями для настройки и мониторинга. Большинство микро-решений имеют определенное количество каналов входов/выходов и увеличить их не возможно. Как пример — плата ардуино

Прошивка и отладка программы

Прошивать микроконтроллеры мы будем с помощью дополнительной программы .

Если микроконтроллера в наличии нет, то его работу можно эмитировать с помощью программы Proteus. Она значительно упрощает процесс отладки программы даже при наличии МК, чтобы его часто не перепрошивать, ведь любой МК имеет конечное число перезаписей, хотя это число и достаточно большое.

При прошивке и отладке МК его удобно располагать на макетной плате, но это вовсе не обязательно. Поэтому для большего удобства пригодится и макетная плата. Существует большой выбор макетных плат, однако я вам рекомендую брать ту, которая имеет по возможности большее число отверстий. Когда мы начнем подключать семисегментные индикаторы, вы оцените преимущества «больших» макетных плат.

Еще один важный элемент, который нам пригодится – это техническая документация на МК, называемая datasheet. В общем, нужно скачать datasheet на микроконтроллер ATmega8.

Итак, полный набор для программирования МК состоит из таких элементов:

2) Datasheet на ATmega8

5) Программатор USB ASP (+ драйвер на него)

6) Макетная плата

7) Микроконтроллер ATmega8

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

2) Datasheet на ATmega8

Производители ПЛК

Существует масса компаний, которые изготавливают промышленные контроллеры — это:

• Advantech,
• Delta,
• VIPA,
• Mitsubishi Electric,
• WAGO I/O,
• Phoenix Contact
• и многие другие.

Российские производители ПЛК :

• Контар,
• Овен,
• Segnetics,
• Fastwel,
• Текон.

На что обращать внимание при покупке

Все зависит от типа производства и задач, которые нужно будет решать, но существуют и универсальные решения. Важнейшие моменты:

• Универсальность среды программирования для разных платформ;
• Контроллеры с распределенным вводом/выводом;
• Устройства со встроенным вводом выводом;
• Связь с ПК;
• Дублирование ЦП и системы ввода/вывода;
• ПЛК с поддержкой веб-технологий;
• ПЛК с процессором типа PC;
• Переносные устройства для создания программ.

Самый главный пункт здесь – это первый пункт. Не стоит пытаться отыскать самое доступное оборудование на рынке – процесс переподготовки специалистов сведет к нулю всю возможную экономию. Стоить выбрать нескольких производителей и сотрудничать только с их продукций.

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

Принцип действия ПЛК

В отличие от микропроцессорной техники принцип действия ПЛК немного другой. Софт делится на две части. Первая часть представляет собой блок системных программ. Если провести аналогию с ПК, то системное ПО контроллера выступает в роли операционной системы, ответственной за работу низкоуровневых процессов. Системная часть ПО устанавливается в постоянной памяти в любой момент вступает в работу.

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

• Опрос входов;
• Выполнение команд;
• Установка значений для входов;
• Вспомогательные операции.

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

Удаленное управление и мониторинг

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

Операторская панель или HIM – это устройство для визуализации. Она может быть встроенной или подключаться кабелем. Существует масса различных типов таких решений – от простых цифровых с кнопками до серьезных сенсорных с функцией оперативного мониторинга и коррекции параметров.

SCADA – это аббревиатура означает систему диспетчеризации и сбора данных. Это программные пакеты, которые позволяют разрабатывать приложения в режиме реального времени. Также пакет имеет инструменты сбора и обработки данных, архивирования и отображения или управления.

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

Более продвинутое решение реализовано в семействе ПЛК Siemens – встроенный веб-сервер. Он позволяет выполнять мониторинг, а также управлять системой. Сегодня в ПЛК реализованы функции подключения к облакам для осуществления удаленного контроля.

Языки программирования ПЛК

Управляющие программы для контроллеров разрабатывают при языков, которые созданы не для программистов в современном понимании, а для инженеров по АСУ ТП.

Самым простым и популярным инструментом считается набор готовых модулей и конфигуратор, позволяющий собрать модули в управляющую цепь. Еще совсем недавно у каждого производителя ПЛК был свой язык. Но к середине 90-х ситуация изменилась. Языки стандартизировали.

Стандарт IEC 1131.3 определяет пять языков:

• Язык лестничных диаграмм LD – это традиционный язык на базе релейных блокировок, где алгоритмы изображаются в виде схем;
• FBD – представляет собой конфигуратор и типовые подпрограммы;
• SFC — язык последовательных схем. Инструмент, близкий к традиционному программированию и на нем реализуют алгоритмы с последовательным управлением;
• ST – язык структурированного типа. Это язык, напоминающий Pascal с поддержкой структурного программирования;
• IL – язык инструкций. Это низкоуровневый инструмент вроде Ассемблера, но он не ориентирован на микропроцессорную архитектуру. Он преимущественно применяется для создания быстрых программ.

Заключение

Сегмент встраиваемых систем в суммарном годовом объеме применений CODESYS ежегодно увеличивается. CODESYS применяется во встраиваемых контроллерах компаний Bosh, Rolls-Royce Marine, Praxis, CC Systems, Moba и др. Это далеко не опытные прототипы, речь идет о десятках тысяч изделий. Примеры нескольких применений показаны на фотографиях.

Среди МЭК-систем программированиия CODESYS выделяется тем, что, подобно компиляторам С/С++, непосредственно генерирует надежный и компактный машинный код, пригодный для встраиваемых систем. Простые в освоении языки МЭК позволяют привлечь к разработке и сопровождению специалистов прикладной области. Интерес для разработчика встраиваемых систем может представлять богатый функционал комплекса CODESYS. Многозадачность реального времени, обработка событий, встроенная визуализация, развитый набор коммуникаций, «горячее» обновление кода, полевые сети, поддержка управления через Интернет, средства национальной локализации проектов и другие функции CODESYS могут быть не востребованы во встраиваемой системе изначально. Но необходимо учитывать, что все они создавались эволюционно, исходя из практических требований, возникавших у пользователей контроллеров в разных странах, разных условиях и на разных этапах работ. В процессе жизни встраиваемой системы неизбежно возникают аналогичные или близкие задачи. Например, задача настройки и тестирования оборудования заказчиком, интеграция с другим оборудованием, веб-интерфейс и т. п. Во многих случаях CODESYS даст готовое решение.