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

Принципы программирования ПЛК

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

Техническое задание

Создание и утверждение технического задания (ТЗ) – очень важная часть разработки ПО. От грамотно составленного ТЗ зависит, насколько эффективно будет вестись разработка.

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

Периферия

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

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

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

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

Помехоустойчивость

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

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

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

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

Проблемы совместимости программы с аппаратной частью

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

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

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

Языки программирования и среды разработки

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

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

Другой язык, имеющий обширный функционал – FBD (Function Block Diagram), который относится к графическим языкам программирования. В FBD используются законченные блоки, имеющие определенные функции. Блоки поставляются со средой программирования или создаются программистом. Существуют и другие языки (6 стандартных), но их описание выходит за рамки данной статьи.

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

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

Тема: Считывание программы из ПЛК

Считывание программы из ПЛК

Не могу понять алгоритма считывания программы из ПЛК.
PLK100P-M. Пишет: Последний онлайн сервис был завершён некорректно.
Номер сервиса:49, Номер ошибки:80, Файл не читается.
Программа сохраняется в контроллере, и работает исправно.
Что это означает? Если можно подробнее.

19.03.2011, 21:31 #2

Пользователь Регистрация 12.12.2007 Сообщений 71

Видимо проблема не актуальная.
Николаев, может подскажите как прочитать программу из плк?
Это проблема контроллера или Codesys?

20.03.2011, 19:34 #3

• Просмотр профиля
• Сообщения форума
• Личное сообщение
• Домашняя страница
• Просмотр статей

Супер Модератор Регистрация 18.12.2006 Адрес Москва Сообщений 6,009

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

21.03.2011, 13:39 #4

Пользователь Регистрация 12.12.2007 Сообщений 71

К сожалению контроллер сейчас в процессе: трогать нельзя. Пока ждал ответа потребовали срочно установить, так что с логом пока трудности. Вы со своих контроллеров считываете программы? если да, то опишите как.
У меня сложилось впечатление, что я выполняю неправильно последовательность создания загрузочного проекта. В инструкции к Codesys’у сказано скудновато об этом. Как то непосредственно после загрузки мне удалось программу выгрузить, но затем я запустил её в Codesys’е, и после снова попытавшись прочесть, получил ошибку. Т.е. она как бы не фатальная.

21.03.2011, 14:47 #5

• Просмотр профиля
• Сообщения форума
• Личное сообщение
• Просмотр статей

Пользователь Регистрация 25.01.2007 Сообщений 334

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

22.03.2011, 08:45 #6

Пользователь Регистрация 12.12.2007 Сообщений 71

Т.е. если я правильно понял, в меню «Открыть»-команда «Открыть проект из ПЛК» извлекает не программу которая работает, а ту которая хранится в отдельном участке памяти? Если она не была туда загружена специальной командой, то, соответственно, получим искомую ошибку?
Если так, то касается это только ПЛК Овен или всех?
Другими словами: могу ли я не имея проекта, подключится к ПЛК (Овен) и увидеть состояния переменных (в Codesys’е)? Как вы понимаете, это нужно для быстрой диагностики системы. Без этого никак не обойтись.

22.03.2011, 10:26 #7

Пользователь Регистрация 12.12.2007 Сообщений 71

Пробовал, см. начало темы.

22.03.2011, 10:41 #8

• Просмотр профиля
• Сообщения форума
• Личное сообщение
• Домашняя страница
• Просмотр статей

Супер Модератор Регистрация 18.12.2006 Адрес Москва Сообщений 6,009

• Компилируется проект
• Создается исполнительный код (не декомпилируемый)
• Этот код загружается в ОЗУ ПЛК

• Скомпилированный код загружается в ППЗУ. При этом данный код Вы можете скачать из ППЗУ, но смысла в этом никакого нет. Вы с ним ничего не сделаете.

Для того, чтобы не потерять проект (исходный файл с ПК с разрешением *.pro) — его можно записать командой Загрузка исходных текстов, или командой Запись файлов в ПЛК. Вытащить файл можно командой считать файл из ПЛК.

ВАЖНО. Если у Вас утерян исходный файл проекта, и Вы связываетесь с контроллером новым файлом — не делайте запись проекта — сначала скачайте старый.

22.03.2011, 11:43 #9

Пользователь Регистрация 12.12.2007 Сообщений 71

* Скомпилированный код загружается в ППЗУ. При этом данный код Вы можете скачать из ППЗУ, но смысла в этом никакого нет. Вы с ним ничего не сделаете.

Как-раз таки и не могу скачать: ошибка выползает. Возможно первая закрузка проходит «нормально», но после некоторых манипуляций (запуск по новой исправленной программы и т.д.) выдаёт ошибку. Попробуйте исправлять программу и перезаливать раз несколько. Возможно где-то здесь возникает сбой.
И почему не имеет смысла? могу же я получить информацию о состояниях входов/выходов (не только ПЛК, но и всех модулей подключённым к нему)? К примеру как это делается в STEP (Siemens) или в PL7 (Schneider)
Запускаешь среду, нажимаешь соединить, и получаешь программу со всеми внутренностями. Смотришь где-что включено, на чём остановился процесс и делаешь вывод.
И, вообще, что означает фраза «не декомпилируемый» в этом контексте?

Последний раз редактировалось MasterZ; 22.03.2011 в 12:01 .

22.03.2011, 14:38 #10

Пользователь Регистрация 12.12.2007 Сообщений 71

Прочитал инструкцию к ПЛК63-коды ошибок(401-404,500-ошибки EEPROM), могут быть такие ошибки в ПЛК100?

• Навигация
• Кабинет
• Личные сообщения
• Подписки
• Кто на сайте
• Поиск по форуму
• Главная страница форума
• Форум
• НОВИНКИ ОВЕН
  1. В продаже
  2. В разработке
• Оборудование
  1. Подбор Оборудования
  2. Эксплуатация
  3. Разработки
• Программируемые устройства ОВЕН
  1. ПЛК (среда CODESYS V3.5)
     1. ПЛК2хх
     2. СПК1хх [М01]
     3. СПК1хх
     4. СПК2хх
     5. ПЛК3хх
     6. Библиотеки CODESYS
  2. ПЛК (среда CoDeSys V2.3)
     1. ПЛК1хх [М02]
     2. ПЛК1хх
     3. ПЛК63/73
  3. ПЛК (среда MasterSCADA 4D)
  4. Программируемые реле
  5. Модули ввода/вывода
     1. Мх110
     2. Мх210
  6. Панели оператора (HMI)
  7. Среда программирования OWEN Logic
  8. Архив продукции
     1. Модульные контроллеры Модус
        1. Модус 5684-0
        2. Модус 5680
        3. Модули ввода-вывода
        4. Интерфейсные модули
• Датчики ОВЕН
  1. Новинки
  2. В помощь инженеру
  3. Подбор датчиков
  4. Вопросы по эксплуатации датчиков
• Программное обеспечение
  1. Облачный сервис OwenCloud
     1. Облачный сервис OwenCloud
     2. ПМ210
     3. ПЕ210
     4. ПВ210
  2. SCADA
     1. OWEN Proces Manager
     2. Master SCADA 3
     3. Master SCADA 4D
     4. Другие SCADA системы
  3. Телемеханика ЛАЙТ
  4. Сервисное ПО
  5. Помощь Разработчикам
  6. Сетевые технологии
  7. OPC Серверы
• Электротехническое оборудование MEYERTEC
• Приводная техника
  1. Приводная техника ОВЕН
  2. Блоки питания
• Контроллеры для ЖКХ
  1. Контроллеры для систем отопления и ГВС
  2. Контроллеры для систем вентиляции и кондиционирования
  3. Контроллеры для управления насосами
• Разное
  1. Трёп (Курилка)
  2. Метрология сертификация
  3. Сервисное обслуживание приборов ОВЕН
  4. Наши проекты
  5. Твердотельное реле
  6. В помощь специалистам

« Предыдущая тема | Следующая тема »

Ваши права

• Вы не можете создавать новые темы
• Вы не можете отвечать в темах
• Вы не можете прикреплять вложения
• Вы не можете редактировать свои сообщения

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

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

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

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

Изначально все работало, но через какое-то время при подаче команд, статусы на компьютере в 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’ов, из-за цикличности выполнения программы в ПЛК и наличия таймера.

Всё не то и всё не так — когда твой компьютер ПЛК

Статья указывает на особенности разработки для промышленных контроллеров. Написана для объеденения программистов данного направления.

Кто такой этот ваш ПЛК

ПЛК (программируемый логический контроллер) – компьютер с особенностями развития. Главные требования к ПЛК: надёжность, низкая стоимость, быстрая реакция на входные воздействия, простота программирования. Данные требования привели к тому, что большинство производителей для своих ПЛК выпускают нативные среды исполнения и разработки. Но нельзя не отметить CodeSys – общеизвестный разработчик ПО для программирования ПЛК.

Несмотря на многообразие сред исполнения и разработки, программы пишутся на языках стандарта IEC 61131-3:

• Графические языки программирования :
  • LD (Ladder diagram)
  • FBD (Function Block Diagram)
  • IL (Instruction list)
  • ST (Structured Text)

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

  Не как все

  Самый «нормальный» язык из IEC 61131-3 – ST, который считается высокоуровневым языком программирования. Хочу обратить внимание, что под языком программирования подразумевается спецификация – правила написания кода. Время выполнения одного кода может меняться в зависимости от компилятора.

  Самый важный момент, который стоит изучить, перед тем как писать код – это понимание принципов работы ПЛК. На рис. 1 изображена максимально упрощённая схема работы ПЛК.

  

  Рисунок 1 — Принцип работы ПЛК

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

  Если в «классических» ЯП (языках программирования) первая программа выводит в консоль «Hello, world!», то в средах разработки программ для ПЛК вы консоли не увидите. Отладка происходит обычно во время выполнения программы, путём постановки точек останова, значения переменных в режиме отладки обычно накладываются на код, где они используются, причём значения можно изменять при отладке.

  Прежде чем отлаживать проект – его нужно написать. И тут можно столкнуться со многими проблемами.

  Сперва придётся ознакомиться со структурными единицами проекта: program organization units (POUs). POU может быть представлен как программа, функциональный блок или функция. У каждого элемента свои особенности. Типы данных такие же как и в других ЯП. Объявление переменных происходит в отдельной области перед кодом программы.

  Следующая проблема – это подключение библиотек. Разные ПЛК используют разные ОС, устройства и протоколы. GitHub на моё удивление не знает про существование ST. В связи с этим остаётся надеяться на наличие нужных вам библиотек у производителя ПЛК. В случае наличия нужной библиотеки вам в редких случаях придётся ещё заплатить за её использование.

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

  Все знают про самый используемый стек протоколов TCP/IP, но в промышленной автоматизации есть игроки поважнее, связано это с тем, что сетевые карты для Ethernet/IP/TCP стека довольно дорогие и требовательные к ресурсам устройства и устанавливать её в простенький блок питания или расходомер нерационально. На сцену выходят RS-232, RS-485, ModBus, CAN, ProfiBus, EtherCAT etc. Кроме знания протокола придётся «поковыряться» с мануалом, чтобы понять как формировать сообщения и какие ждать ответы.

  Нормальные люди под frontend-ом понимают HTML, CSS, JS, у автоматизаторов это SCADA или HMI. Если кратко, то это ПО для разработки пользовательского интерфейса. Подавляющее число SCADA взаимодействуют с ПЛК посредством OPC-сервера.

  При возникновении ошибок или если не знаете как реализовать ту или иную функцию, то Stack Overflow вам навряд ли поможет – скорее всего вам придётся «ковыряться» в документации производителя ПЛК.

  Пора кончать

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

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

  Для дальнейших дискусий и связи предлагаю telegram чат и канал.

  Ну и не забываем оставлять свои мысли и замечания в комментах. Надеюсь устроить хоть небольшой движ в этой сфере.

  Похожие публикации:

  1. Как посчитать количество отличников в excel
  2. Как представить число в виде квадрата
  3. Как при загрузке компьютера выбрать загрузочный диск
  4. Как снять верхнюю панель газовой плиты ханса