Ну и на последок "6 советов по эффективному наставничеству"
1. Начните с перечисления навыков, которыми должен обладать «полноценный» инженер/техник. Это руководство для остальной части процесса и простой способ держать всех на одной волне.
2. Запланируйте окончание официального наставничества. Список навыков очень поможет здесь. Убедитесь, что люди знают, когда «новый парень» уже не «новый парень». Это может быть просто объявление на собрании компании, изменение названия или любой другой публичный жест, который соответствует культуре вашей компании. Если корпоративная культура сосредоточена на утилитарных дискуссиях (как это делают инженеры), это тоже нормально. Частью нашего обряда посвящения является объявление, что человек «X» теперь готов взять на себя срочную работу для клиентов, что часто не дает места для участия наставника.
3. Если наставник посещает обучение, то отправьте с ним подопечного. Хорошо, когда сотрудники со временем поддерживают друг друга как равные, а не как наставники-подопечные навсегда. Совместные тренировки дают им возможность развить эту динамику.
4. Сообщите наставнику и подопечным, что ошибки являются частью процесса обучения и не являются признаком неудачи. Наставляемый будет учиться и работать лучше, если не будет бояться за работу, а наставник с меньшей вероятностью отдалится от подопечного, если будут допущены ошибки.
5. Ежемесячно связывайтесь с наставником и подопечным по отдельности, чтобы узнать, как идут дела. Вы узнаете много нового о программе наставничества, о том, насколько хорошо она работает и что нужно этим конкретным людям для достижения успеха.
6. Держите подопечного вовлеченным в процесс. Позвольте им высказаться в своих собственных целях обучения, темпе и выборе наставника настолько, насколько это разумно.
------------
От себя могу добавить, что стоит быть менее токсичными в плане обучения и ответов на вопросы как новых специалистов в автоматизации так и опытных специалистов. Все всегда с чего-то начинают, часто приходится изучать новые предметные области. Разумеется есть вопросы, которые решаются чтением документации, но есть вопросы, в которых ответ уже опытного специалиста поможет сориентироваться быстрее, а иногда требуется очень большая оперативность. Создание хорошего сообщетсва и взращивнаие здоровой конкуренции делает нас сильнее как профессионалов.

Теперь немного о программировании ПЛК. Я тут немного начал на стримах писать проект совмещая FactoryIO и Codesys 3.5, пытаясь углубиться в ООП. В репозитории буду хранить изменения в проекте. На данном этапе там всего лишь один интерфейс и функциональный блок , реализующий данный интерфейс, плюс реализации нескольких методов и обработка сигналов с кнопок.
https://github.com/sudak-91/CodesysOOP-FactoryIO

Словосочетание дня - Corner case ну или граничный случай. Ситуация, которая возникает за пределами нормальных условий. Из всего делаем два вывода: 1) Использовать в программе цикл While Do следует очень осторожно. 2) Стоит убедиться, что цикл закончится до того как отработает сторожевой таймер. А теперь ситуация. Требовалось мне число с плавающей точкой привести в удобочитаемый вид - экспоненциальный. И первую половину дня все было хорошо. Во вторую половину дня один из датчиков немного взбрыкнул и отвалился. Система записала в регистр 0.0 и пожелала мне хорошего пути. сколько бы времени я 0.0 не умножал на 10 значение больше единицы я так и не увидел, а сторожевой таймер ПЛК раз в 30 секунд начинал цикл сначала.
Как выйти из такой ситуации, ибо ПЛК уходит в бесконечный цикл, перезагружается раз в 30 секунд и не отвечает ни на один внешний запрос с любого порта(если что это ПЛК210 от ОВЕН). Дождитесь начала загрузки проекта в плк. Об этом будет свидетельствовать мигающая лампочка проекта на плк. В этот момент переведите переключатель в режим СТОП и перезагрузите путем зажимания кнопки СБРОС более чем на 3 секунды. После перезагрузки ПЛК загрузится, но не запустит проект. Что позволит вам прогрузить новую версию прошивки, или сделать откат на старую.
Как я могу избежать подобную ситуацию? 1) Подумать больше чуть больше 5 минут над условиями. 2) Провести юнит тесты. В целом взять за практику писать юнит тесты всегда.
Из этого вопросы. Знаете вы то такое Юнит тесты? Пишите ли юнит тесты? Хотели бы узнать про юнит тесты и написание тестируемого кода?

Еще немного кода. https://github.com/DanaEng/DNEUnitLib
Это библиотека, разрабатываемая мной, которая непосредственно и используется в проектах. Так что если есть желание можете ознакомится, также накидать вопросов ну и указать на недостатки, недочеты и рассказать как бы вы сделали.
P.S. Там нет ООП(пока еще)

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

СТАНДАРТИЗИРУЙТЕ СООБЩЕНИЯ ОБ ОШИБКАХ
При программировании системы убедитесь, что все сообщения об ошибках являются целевыми и стандартными для устройств одного типа. Если датчик может выйти из строя определенным образом, убедитесь, что неисправность сконфигурирована одинаково для всех датчиков в этой системе. Точно так же камеры или устройства любого типа, подключенные к ПЛК, будут иметь определенные режимы отказа. Спросите конечного пользователя, с какими режимами отказа он столкнулся, и запланируйте также действия в таких непредвиденных ситуациях.
А вот в эту магию я не могу. Если у кого есть хорошие примеры, то поделитесь пожалуйста.
СОПОСТАВЬТЕ ПРОГРАММНУЮ СРЕДУ С БРЕНДОМ
Чтобы обеспечить максимальную стабильность и избежать непредвиденных проблем, по возможности используйте среду, рекомендованную производителем ПЛК. Это позволит сделать код и работу с приложением максимально бесшовными.
Ага, чтоб потом не задавать вопросы, а какой средой программируется конкретный плк.
Еще больше новостей: https://t.me/wtfcontrolsengineer
Источник: https://www.controleng.com/articles/7-tips-every-plc-programmer-should-know/

Если вы устали скучать на эксплуатации или стоит как-то убить время, ожидая приход ПЛК, то вот материал.
Как неконтролируемое машинное обучение приносит пользу промышленной автоматизации
Неконтролируемое машинное обучение предназначено для работы с немаркированными данными с использованием алгоритмов, которые превосходно выявляют шаблоны и аномалии в данных, начиная от мониторинга состояния и тестирования производительности и заканчивая кибербезопасностью и управлением активами.
Статья написана при поддержке A3
Нам предлагают познакомится с такой вещью, как обучение без учителя, немного про алгоритмы такого обучения и где это можно применить.
1)Кластеризация
Как следует из названия, кластеризация включает в себя анализ наборов данных для выявления общих характеристик среди данных и группировки похожих экземпляров вместе. Поскольку кластеризация — это неконтролируемый метод машинного обучения, алгоритм, а не человек, определяет критерии сортировки.
И примеры использования кластеризации:
-Клиентская аналитика для OEM производителей, которые мониторят свои парки
-Операция обработки изображения
-Подготовка данных перед контролируемым обучением
2)Обнаружение аномалий
Обнаружение аномалий может иметь решающее значение для различных вариантов использования, от обнаружения дефектов до мониторинга состояния и кибербезопасности. Это ключевая задача в неконтролируемом машинном обучении.
И тут список применения увеличился в размерах и по значимости:
-Профилактическое обслуживание.
-Обеспечение качество/проверка
-Идентификация аномалий изображения
-Анализ тестовых данных.
3)Снижение размерности
Это может помочь идентифицировать подмножества данных, которые ортогональны друг другу, т. е. их можно удалить из набора данных, не влияя на основной анализ.
В самой статье еще чуть подробнее за алгоритмы, но общими словами, а также ряд вопрос для понимания, а надо ли это тебе.
https://www.controleng.com/articles/how-unsupervised-machine-learning-benefits-industrial-automation/

@wtfcontrolsengineer

Если честно, то очень не хватает хотя бы каких-нибудь CI инструментов, которые бы помогали в ПНР. В связи с этим вопрос. Как вы прогружаете ПЛК при удаленном ПНР и как собираете баг репорты?

Не могу найти еще одну статейку про Индустрию 5.0, где говорилось, что на базе индустрии 4.0 можно будет сделать очень легкую кастомизацию для конечных пользователей путем развитой 3D печати и хорошей логистики производства. Но тут уже размышляют на тему непрерывных процессов. Отличие непрерывных процессов от производства штучных продуктов заключается в использовании более сложных формул для расчетов и очень разнообразной рецептуры. Выдавить заготовку по шаблону будет отличаться от автоклавное выщелачивания.
О чем нам предлагают подумать. Это о взаимодействии людей, роботов и интеллектуальных систем, где большую часть монотонных работ надо делегировать роботам. А человек будет отвечать за творчество и решение нестандартных ситуаций.
Отличие 5.0 и 4.0 заключается в том, что 4.0 фокусируется на взаимодействия машины с машиной. IIoT, различные озера данных, интеллектуальные системы с предсказательной аналитикой или экспертные системы, граничные вычисления и облачные вычисления, которые должны предоставить оптимальные режимы работ для машин на основании данных от машин. А если нам взглянуть на взаимодействия ИИ и людей, то можно заметить, что такой симбиоз позволяет быстрее выходить новому продукту на рынок.
В конечном итоге это все должно как-то прийти у интеллектуальному управлению производства. Вот такой вот материальчик для почитать.
Разумеется это все еще очень фантастические размышления, так как требуется преодоление как технологических проблем, так и технических проблем. Налаживания связей внутри производства и между производствами. Проблема в сборе и обработке данных, проблема сбора и передачи человеческого опыта. И определение места человека в этой прекрасной индустрии будущего.
А пока можем просто фантазировать.
https://www.controleng.com/articles/industry-5-0s-role-in-process-manufacturings-evolution/

Я принес вам немного новой поисковой системы, которая заточена на поиск именно кода и около программистских тем.
https://code.you.com

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

Если кто-то не знал, то я тут не просто перевожу новости на интересные темы вокруг OT, но еще иногда катаю статейки, который можно почитать в блоге
Там можно найти ускоренный курс введения в ООП для ПЛК. Есть разбор работы таких типов как BIT и BOOL или рассказ о ссылках и указателях. И что-то еще по мелочи.
Для связи можно воспользоваться почтой: info@engcore.ru и туда можно засылать вопросы, предложения, возможно интересные новости(бота мы допишем чуть позжэе) или просто вы хотите поделиться и пообщаться на профессиональные и около темы.

Так как сегодня суббота, то думаю можно немного поспамить. На просторах reddit наткнулся на интересный пост, который назывался: "ПЛОХИЕ ПРАКТИКИ СИСИТЕМНОГО ИНТЕГРАТОРА"
И вот что он пишет:
-Нет производства стандартных библиотек, каждый раз приходится что-то переписывать с нуля.
-Очень плохой шаблон ПО
-Очень плохой дизайн HMI и отсутствие шаблона, поэтому каждый раз с нуля и каждый раз чего-то не хватает.
-Очень плохая документация (какой-то дерьмовый ворд файл, лол).
-Плохое знание физики и механики
-Каждый проект не может быть выполнен одним человеком, всегда приходится менять человека из-за других работ и нехватки времени.
-Плохой контроль версий
-Нет знаний в области ИТ
С чем-то я согласен, с чем-то нет. В прошлом году я уже писал о проблемах в АСУТП, на мой взгляд. Теперь могу поделиться плохими практиками от себя, с чем я сталкивался, а что иногда и сам делаю(простите), а также предлагаю вам в комментариях поделиться
1)Документация не всегда соответствует реальности. И если про всякие руководства я беспокоюсь в последний момент, так как их все равно переписывать после ПНР, то вот электрические принципиальные схемы, которые отличаются от реальности создают много проблем.
2)Отсутствие пункта про рабочее место на территории заказчика в договорах. (Ага, это про стул, стол, свет и минимальные удобства)
3)Наименование объектов в коде соответствует наименованию в проекте. Конечно HL1 - это здорово, но RedLamp - это чуть более понятно.
4)Бесполезные комментарии. Опасность комментариев заключается в том, что они не всегда изменяются с изменением логики. Так что комментировать каждую строчку с условием и циклом - перебор, а вот в паре строчек указать что делает эта функция полностью - норм.
5)Отсутствие переговоров и совещаний. Раньше сам не любил эти процессы, считая, что они только забирают время, мол в почте все проще и быстрее. Переговоры и совещания действительно забирают много времени, если их правильно не организовать, указав время, продолжительности и цели к которым надо прийти к концу этого совещания.
6)Отсутствие общего ТЗ на СУ. Оно всегда требуется. ВСЕГДА. Именно в нем указывать что надо сделать, а если заказчик говорит, что не надо, то указывайте в ТЗ, что это делать не надо.
7)Дизайн рисуют программиста. Давайте признаемся, что мы не умеем рисовать дизайн. И ни какие 101 нам не помогут.
8)Отсутствие бюджетов и сроков для разработки библиотеки СУ для всего парка устройств.
9)Цифровые двойники или макеты. Ох, сколько же нервов это могло сэкономить. Отладка большей части логики управления в спокойных условиях.
10)Плохая структурная организация проекта в среде разработки. Это когда мы все накидали в рандомные папки с какой-то непонятной структурой. Сначала у меня в одной папке были данные в другой FB, но без экземпляров в третьей Экемпляры FB и их вызовы. Потом я как-то еще пересобирал структуры проектов, пока не дошел до структуры, которая уже понятна для меня с каким-то постоянными названиями.