Меню Закрыть

Как документировать программу ПЛК

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

Обложка статьи "Как документировать ПЛК"

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

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

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

Что нужно определить?

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

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

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

Что и куда можно записывать? ПЛК?

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

Внутри программы также можно внедрять документацию. Многие контроллеры теперь могут хранить и отображать описания алгоритмов и устройств. Дни потерянной документации прошли. И, естественно, если есть способы сделать программу более читабельной – так сделай её таковой!

Работа со старыми и новыми ПЛК

В прошлом память ПЛК была структурирована иначе. Производитель контролировал именование переменных и часто ограничивал количество переменных. Имена переменных Inputs (I), Outputs (O), Bits (B), Integer (I), Float point (F) и String (S) начинались с идентифицирующей буквы, например I: 0/1, O: 1 / 0, B3: 0/15. Тип переменной указывался в имени, но не в функции. В этом случае добавляется описание для определения функции переменной, например, «Температур воздуха в комнате в норме».

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

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

Примеры

Например, в системе с тремя станциями имя переменной, локальной для каждой станции, может начинаться с L10, L20 и L30. Эти префиксы позволяют легко копировать и вставлять в программы, а затем выполнять поиск и замену при необходимости. Это форма кода многократного использования. Другим примером является робот, имеющий несколько движений захвата и размещения, которые устанавливают локальный бит «Занят», когда движение находится в цикле. Может быть полезно иметь слово «Занят» в первой части имени переменной. В этом случае функция автозаполнения отображает все занятые биты вместе.

Суть в том, что названия переменных должны быть определены так, чтобы другие могли понять используемое соглашение об именах. И, независимо от соглашения о присвоении имен, если имя тега переменной не является самоопределяемым, добавьте дескриптор, такой как «Робот 1 занят поливом» или любой другой. Эти самоопределяющиеся имена и дескрипторы будут жизненно важны для человека, который будет работать с продуктом после вас. Будьте вежливым программистом и документируйте свою работу!