Сегодня для вас 7 СОВЕТОВ ПРОГРАММИСТУ ПЛК.
ВНЕДРИТЕ МОДУЛЬНУЮ СТРУКТУРУ ПРОГРАММЫ.
Программы ПЛК должны быть организованы осмысленно, например, путем выделения каждого из устройств и использования структуры, которую можно использовать повторно и легко понять. При использовании модульной структуры программист может вносить изменения во все устройства одного типа, а не вносить изменения в каждое отдельное устройство.
Тут мне добавить нечего. Действительно очень здорово делить код на функции и функциональные блоки, но это очень непростая задача, когда мы говорим о каких-то условиях управления. Вот функциональный блок насоса должен обрабатывать команду от оператора на включения или это должен сделать сторонний блок, котоый потом просто изменит состояние?
СТРУКТУРИРУЙТЕ КОД КАК УКАЗАНО КЛИЕНТОМ.
Конечный пользователь должен указать среду программирования для ПЛК, чтобы она соответствовала типу оборудования на объекте, обеспечивая правильную работу всех функций и функций. На этапе разработки проекта программист должен повторно использовать любые стандартные блоки кода или другой код, который уже был разработан для существующих интерфейсов. Хотя программисту может потребоваться немного больше времени, чтобы освоить эти блоки кода, персонал конечного пользователя уже знаком с ним и может поддерживать его легче, чем изучение нового интерфейса.
Спорный момент. Особенно при использовании наработок персонала. Другой момент это конечно через библиотечки обменяться интерфейсами, что не всегда возможно.
«ПРАВИЛЬНЫЙ» ЯЗЫК НЕ ВСЕГДА ЯВЛЯЕТСЯ «ЛУЧШИМ».
Программисты не всегда могут использовать «лучший» язык для приложения; они должны следовать тому, что указывает конечный пользователь. Как упоминалось выше, команда заказчика будет ежедневно обращаться с оборудованием на заводе, и если они не знакомы с используемым языком программирования и не могут его поддерживать, программист получит Звонок в 2 часа ночи, когда оборудование выходит из строя.
Наверно стоит научиться создавать правильные черные ящики. Все же внутрь функционального блока с какой-то логикой технологического процесса лучше не лезть. Какие-то крупные элементы можно написать на “правильном” в конкретной ситуации языке, но все же диагностика и изменения тех.процесса должны быть доступны с панели. Так же как и перевод системы в изначальное стартовое или безопасное состояние.
ПОНИМАНИЕ ПОТРЕБНОСТЕЙ ОБРАБОТКИ ДАННЫХ
Если у пользователя есть системы управления рецептами, основным средством анализа данных должен быть ПК, а не ПЛК, в зависимости от размера рецептов. Если есть прерывистые процедуры поиска или процедуры с высокой нагрузкой, они могут увеличить время сканирования и могут пропустить датчики. Эти ситуации могут сильно повлиять на работу ПЛК.
Дааааа. Отдайте ПЛК работу ПЛК. Хватит вешать на него миллионы ненужного функционала.
УБЕДИТЕСЬ ЧТО КОД ХОРОШО ПРОКОММЕНТИРОВАН.
Убедитесь, что код хорошо прокомментирован. Очевидно, что программист понимает детали и тонкости кода, когда он пишется, но код уже не будет свеж в памяти пользователя, когда его вызовут для устранения неполадок на сайте через несколько недель или месяцев. Если в коде есть необычные разделы, выходящие за рамки обычных, дополнительные комментарии помогут следующему программисту понять, почему код выглядит не так, как ожидалось. Это может помешать будущим программистам вносить изменения, чтобы «исправить» код, что может привести к ухудшению ситуации.
Бомба замедленного действия. Давайте писать самокомментируемый код, а если вы пишите комментарий, то пускай он будет действительно важным, а не просто объясняет что делает строчка. Опишите в комментарии что делает функциональный блок или какая-то функция, н избегайте комментариев из серии //сравниваем два числа и если меньше то…
Продолжение