Хороший программист программируемых логических контроллеров (ПЛК) всегда должен помнить о конечном пользователе и писать понятный и пригодный для повторного использования код. Применение эффективных методов и подходов может облегчить жизнь как программисту, так и клиенту. Ниже дано семь советов, о которых должен знать каждый программист и которые помогут использовать систему управления на базе ПЛК в полной мере.
Внедрение модульных систем
В модульной системе ПЛК использование нескольких дополнительных модулей обеспечивает гибкость при разработке устройств. Благодаря легкой замене модулей такая система поддерживает масштабируемость, возможность размещения большего количества линий ввода/вывода (I/O), упрощает устранение неполадок и ускоряет работу системы в целом.
Программы ПЛК должны быть разумно организованы, например путем разделения выполняемых функций по модулям и создания понятной и пригодной для повторного применения структуры.
При использовании модульной структуры программист может одновременно вносить изменения во все устройства одного типа, а не работать с каждым отдельным устройством.
Сохранение модульности кода позволяет всем сторонам понимать, кто несет ответственность за каждый раздел кода. Например, код, управляющий колонкой световой сигнализации, должен поступать из структуры колонки световой сигнализации, а не из структуры управления режимами.
Структурирование кода с учетом требований клиента
Программист анализирует спецификацию конечного пользователя и на ее основе разрабатывает код со стандартной (типовой) структурой. Это позволяет группам технического обслуживания и техническому персоналу иметь дело со стандартной компоновкой и структурой, что облегчает понимание оборудования и поддержку его работоспособности.
Конечный пользователь должен указать среду программирования ПЛК, соответствующую типу оборудования на объекте, чтобы все функции и возможности осуществлялись должным образом. На этапе разработки проекта программист должен повторно использовать любые стандартные блоки кода или другой код, уже разработанный для существующих интерфейсов. Хотя программисту может потребоваться несколько больше времени, чтобы освоиться с этими блоками кода, персоналу конечного пользователя будет легче работать с уже знакомым интерфейсом, чем изучать новый.
Правильный язык программирования — не всегда лучший
Программисты не всегда могут использовать наиболее подходящий для конкретной задачи язык программирования; они должны следовать указаниям конечного пользователя. Как уже упоминалось, обслуживанием оборудования на заводе будет заниматься команда клиента, и если персонал не знаком с используемым языком программирования и не может его поддерживать, программисту позвонят в 2 часа ночи, когда оборудование выйдет из строя.
Обычно на производстве распространены только языки стандарта IEC 61131. Отдельные производители могут использовать другие языки, но все они обладают общими чертами. Отличия же заключаются, как правило, в работе конкретных функций, например в процедуре поиска или сортировки (рисунок). Процедуры поиска или сортировки, написанные с помощью циклов for или while, не так понятны и просты при использовании релейной логики по сравнению с языком более высокого уровня, таким как структурированный язык управления (SCL). Там, где код SCL будет состоять всего из нескольких строк, для выполнения той же функции с помощью релейной логики может потребоваться 10–15 строк.
Понимание задач по обработке производственных данных
Какая обработка данных будет выполняться? Если для работы оборудования требуется система управления производственными процессами (MES), но ее нет, это создает огромную нагрузку на ПЛК по хранению и управлению данными. Такие функции должны выполняться внешним ПК.
Если программист работает с системой управления параметрами техпроцесса, то в зависимости от размера наборов данных основное средство анализа данных должно размещаться на ПК, а не на ПЛК. Если необходимо использование прерывистых процедур поиска или других процедур с высокой нагрузкой, то они могут увеличить время цикла, из-за чего сигналы от датчиков могут оказаться пропущенными. Это может кардинально нарушить выполнение задачи, поставленной перед ПЛК.
Комментарий к коду
Программист, скорее всего, разберется в деталях и тонкостях написанного кода, но когда недели или месяцы спустя программиста попросят устранить неполадки, возникшие на производстве, код для него будет уже как чужой. Если код содержит необычные разделы, выходящие за привычные рамки, дополнительные комментарии помогут следующему программисту, работающему с кодом, понять, почему он выглядит не так, как ожидалось. При последующей работе с кодом комментарии могут уберечь нового программиста от «исправлений» специального кода, которые потенциально могут привести к нарушению работы оборудования.
Стандартизация сообщений о неисправностях
При программировании системы убедитесь, что все сообщения о неисправностях являются конкретными и единообразными для одних и тех же типов устройств. Если датчик может выйти из строя определенным образом, убедитесь, что сообщение о такой неисправности будет одинаковым для всех датчиков этой системы. Это же справедливо и, например, для камеры или любого другого устройства, подключенного к ПЛК, для которых также характерны определенные типы ошибок. Узнайте у конечного пользователя, с какими типами ошибок он сталкивался, и запланируйте действия на случай их возникновения.
Программная среда и бренд ПЛК
Для того чтобы обеспечить максимальную стабильность и избежать любых неожиданных проблем, по возможности используйте ту среду, которая рекомендована производителем ПЛК. Это позволяет максимально упростить работу с кодом и приложениями.
На протяжении всего процесса разработки кода помните о конечном пользователе и следуйте этим простым советам, способствующим повышению эффективности, стабильности и удобства работы.
Источник: Control Engineering
