Мигриране на коментари за стъпки в 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.

Най-добрият режим на прикачване е този, който запазва смисъла при редакциите, които заводът действително извършва. Проверена базова версия, ясни правила за избор, тестване на партиди и сравнение след запис предотвратяват превръщането на козметичен проблем в базата данни в риск при диагностика.