Последовательность поиска ошибки в программе ПЛК
Изучая профессиональную литературу, я часто сталкивался с разбором ошибок и описанием их классификаций по виду. На практике мне никогда не помогало знание типа ошибки. Оно нужно разве что для того, чтобы разобраться с проблемой и потом рассказать, как ее решить, другим. А вот то, как специалисты обнаруживали эти самые ошибки и устраняли их – всегда любопытно.
Данные об ошибках в системе
С компьютера на программируемый логический контроллер подаются уставки и различные команды. Контроллер же передает компьютеру сведения о статусе устройства и времени, оставшегося до конца действия команды. Для экономии памяти и быстрой передачи сигналы подаются словами. Из контроллера на устройство поступают команды. А устройство передает на контроллер свои статусы.
Сначала все было хорошо, но позже появились проблемы. При отправлении команд сигналы о статусах на компьютере в SCADA работали некорректно. Проблема присутствовала лишь на одном объекте, и на одном и том же месте. Но эти неполадки наблюдались постоянно, появлялись при каждой команде – это уже облегчило задачу.
Поиск проблемы
Цифры в скобах указывают на места, где были выполнены проверки, они соответствуют цифрам на нижеприведенной схеме.
Сразу понять, почему моргают сигналы, и по какому принципу, не получилось. Может быть, из-за усталости, а может быть, потому что никакого определенного принципа нет.
Удалось установить, что ошибка есть не только в SCADA (1), где я ее и обнаружил сначала, но и в ОРС (2).
При изучении проблемы стало понятно, что ошибка есть и в контроллере, как минимум формируется неправильное слово сигнала для компьютера (3).
Проверив статус, который поступает от устройства, неполадок в нем не обнаружил.
При замене статуса вручную ошибки сохранились. Принудительная замена статуса от устройства тоже не решила проблему. Следовательно, это не импульсы, незаметные во время мониторинга (4).
После сравнения с кодами на других объектах, где все работает нормально, никаких отличий не выявил, все одинаково. Поэтому шансы на то, что ошибка кроется в программе контроллера, снижались (5).
Компьютер, как потенциальный источник неполадок, отключился, но ошибка все еще была. Поэтому неисправность в компьютере тоже практически исключается. Следовательно, проблема кроется все-таки в контроллере (6).
Пояснение: отключив контроллер, можно поменять статусы в ОРС вручную. Но с технической точки зрения такой вариант довольно сложный. И оба способа проверки дают практически одинаковые результаты.
Ошибка сохранилась и после перенесения слова статуса от контроллера в другую область его памяти.
После перенесения части проблемного кода в другой блок также ничего не поменялось. Это значит, что какая-либо посторонняя команда не может быть причиной неисправности. Дело именно в этой части кода.
После постепенного удаления кода по частям остался небольшой кусок, в нем и была проблемы (7).
1. Запуск команды (без нее проверить не получается)
2. Таймер, показывающий время до окончания действия команды
3. Составление слова из статуса и времени с таймера
После удаления таймера команду спросить нельзя, и проблема все еще присутствует, и статусы работают неправильно.
Выставляется другой таймер, внимательно проверяется на наличие неточностей. Таймер примитивный, в системе аналогичных пару сотен. Но ошибка все еще есть (8).
После рассмотрения создания сигнала от контроллера, как потенциального источника неисправности, он упаковывается в одно слово. В старшем байте при этом находятся биты, а время переносится в младший. Используется 3 команды:
1. Перенос статусов в область младшего байта
2. Замена мест байтов с помощью командой SWAP_WORD (теперь статусы находятся в старшем)
3. По AND время переносится в младший
По сути ничего сверхъестественного, такая же система ладит с множествами других устройств. Но проблема все еще не решена.
После замены команд упаковки сигналов выбирается аналогичная работающая последовательность команд. Только теперь она состоит из следующих операторов (9):
1. Перемещение времени в младший байт
2. Умножение статусов в промежуточной переменной на 256, перенос их в старший байт
3. Перенос статусов в старший байт с использованием OR
Проблема устранена.
Проделав все эти операции, понял причину проблемы.
В чем же была проблема?
Обычное время таймаута было увеличено операторами с 1.5 до 10 минут. Полторы минуты – 90 секунд, а 10 – это 600. Младший байт может уместить максимум 256, поэтому время, которое не поместилось, записывалось в старший.
Сначала записывается время, а потом статус. Поэтому статус занимал все биты, которые пришли от времени. Если последовательность команд противоположная, биты заняты временем.
Устранение проблемы
Статусы и время были помещены в два отдельных слова. В качестве решения проблемы было предложено выполнить техническое обслуживание или поменять элемент с таймаутом на иной, который превышает стандартное время больше, чем в пять раз.
Подведем итоги
Представленная проблема не критичная, и решается не очень сложно. Но ее описание и способ решения будет полезен в качестве примера.
В результате не так важно, в чем именно кроется неисправность, в электронике, контроллере, на компьютере. Основные способы решения одни и те же:
1. Собрать максимальное количество данных о существующей проблеме, установить, где и как часто она наблюдается. В этом случае можно пользоваться снифферами, утилитами, осциллографами, всеми существующими инструментами. Необходимо понять, когда именно появляется ошибка, от чего зависит.
2. Исключить максимум составляющих. Сделать это можно отключением тяги, перерезанием дорожек на печатных платах, выводом из системы отдельных устройств. Плохо, если наблюдаются какие-либо обратные связи. В таких случаях стоит попробовать провести проверку, учитывая отсутствие отдельных элементов системы, или проэмулировать элемент, например, подав сигнал на вход обратной связи искусственно. Здесь нужно хорошо подумать.
3. Желательно, чтобы каждая проверка выполнялась от начала до конца, даже если появились сомнения и внезапные «гениальные» мысли. Если осенило, не значит, что это сработает, на практике, как правило, не срабатывает. А вот результаты прерванной проверки буду утеряны.
4. В оставшейся части кода нужно поменять все, что потенциально может выдавать ошибку. Если это ПО, стоит переустановить или выбрать другое, аналогичное. С этого пункта вообще можно начать свои действия. Я лично знаком с инженером, который, ремонтируя плату на 40-50 микросхем серии К155, заменил все микросхемы на новые. Но, я считаю, что так делать не нужно. Даже если способ сработает, понять, в чем конкретно была ошибка, все равно не получится. К тому же, в описанном случае этот вариант не сработал. Можно забыть про эту историю.
Конечно, не во всех случаях эти принципы будут полезны. Но все ошибки всегда имеют конкретную причину, и ее всегда можно определить. Однажды, к примеру, причиной стал тракторист, проехавший над кабелем. Трудностей с устранением этой проблемы не было, но их было достаточно при описании рекомендаций по устранению неполадки во избежание подобных случаев.
Прошу меня простить, если все написанное читается и воспринимается сложно. Сама тема непростая, к тому же, я пытался сократить описание, выбросив все несущественные мелочи, например, вынужденный отказ от BreakPoint'ов по причине цикличности выполнения программы в контроллере и наличия таймера.