Миграция комментариев к строкам RSLogix 500: привязка комментариев к адресу выхода

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

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

Поймите, что именно перемещается

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

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

Защитите исходный файл перед редактированием

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

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

Выбирайте привязку с учётом инженерного назначения

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

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

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

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

Переносите комментарии контролируемыми пакетами

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

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

Проверяйте результат при смене версии ПО и архива

По возможности открывайте отредактированную копию в той же версии RSLogix 500, которая используется на объекте. Затем снова откройте сохранённый файл и повторите тесты со вставкой и перемещением образцов. Преобразования между версиями и импорты баз данных следует рассматривать как отдельные миграции. Официальное справочное руководство по набору инструкций SLC 500 остаётся основным источником информации о поведении инструкций, однако привязка документации относится к работе программной базы данных и должна проверяться в установленной среде RSLogix.

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

Сделайте соглашение удобным для сопровождения

Добавьте правило привязки в стандарт программирования и контрольный список проверки кода. Требуйте актуальный архив RSS для каждого утверждённого изменения и поддерживайте синхронизацию комментариев с символами, электрическими схемами и текстом аварийных сообщений HMI. Для машин, которые остаются на платформе SLC, согласуйте ответственность за документацию с общим планом жизненного цикла систем PLC и PAC и принятыми на объекте правилами онлайн-редактирования RSLogix 500.

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