Приветствую подписчиков моего блога.
Это блог про автоматизацию и про меня. Здесь я делюсь новостями, опытом, решениями и мыслями.
Подписывайтесь, приглашайте друзей, у меня здесь уютно и назидательно!

Веду разработку проекта, который уже давно обещали сделать. Но вначале это делал студент-выпускник курса С++. Он проект недоделал и пошел на работу, модернизировав свою программу для диспетчеризации. Затем это делал другой программист, который ничего до конца не доводит. Намудрил там и перемудрил)
Приходится делать самому. Примерно половина программы уже готова.

Я начал работу над новым курсом, который будет посвящён компьютерной науке - компьютерологии или компьютероведению.
Вот вступление:
В современном мире существует множество языков программирования и ещё больше существует программистов. Однако, эти языки разрабатываются для решения конкретных задач и более того, сейчас всё больше программистов возвращаются к тому, от чего ушли – это язык С или С++. Об этом говорит статистика использования языков программирования, которая становится ещё более наглядной, если убрать из неё языки разметки веб-страниц, языки запросов к базам данных и скриптовые языки, созданные для работы с операционными системами. Всё больше приоритета при приёме на работу отдаётся тому, что в западном мире называют Computer Science – компьютерная наука или компьютерология.
CS (Computer Science) изучает то, как устроен компьютер, как он работает и как выполняет программы. Глубокое понимание этих принципов позволяет вам писать более эффективные программы.
В этом курсе вы изучите, как работает компьютер. Я объясню, как работает центральный процессор и память, как программа хранится и обрабатывается, как выполняются операции над данными и как можно научиться составлять программы на любом языке программирования. Самое важное, что следует запомнить: язык программирования – это лишь инструмент, один из многих. При помощи любого языка программирования можно решить (почти) любую задачу, связанную с компьютерами.
Мы разберёмся с системами счисления и зачем они нужны, научимся оперировать в уме двоичными данными и прописывать различные цепочки преобразования данных, строить алгоритмы. Всё это значительно повысит ваш уровень программирования и самое главное – поможет вам научиться решать рабочие задачи значительно быстрее и на более высоком уровне качества/производительности.
Изучайте эти уроки внимательно, а возникающие вопросы задавайте в техническую поддержку на нашем сайте. Желаю успехов!

Пишу я тут новый курс по Computer Science (информатика по-нашему, ну или компьютерология/компьютероведение). Рассказываю о двоичной системе счисления и чтобы показать, откуда это пошло - решил привести пару примеров механических программируемых устройств - автоматонов. Если честно - автоматоны меня не особо впечатляли, поскольку есть представление, как это можно сделать. И при достаточном количестве времени и мотивации - я бы мог спроектировать такое. Но что меня впечатлило - это часы в форме яйца, которые сделал Кулибин. Вот, что я о них написал:

Иван Кулибин создал эти «часы» за три года, с 1764 по 1767 годы. Эти часы заводные и заводятся один раз в сутки. Эти часы не только показывали время. Кроме этого они отбивали каждый час, каждые пол часа и каждые 15 минут различными звуками, а также в них был спрятан автоматический театр, воспроизводящий миниатюру сцены воскресения Христа. Открываются створки, показывающие сцену, где у подобия «гроба Господня» находятся воины с копьями, через полминуты после открытия является ангел, камень от двери отваливается и гроб открывается. Воины падают в поклоне. Ещё через пол минуты приходят «жены мироносицы» и часы три раза играют мелодию молитвы «Христос Воскрес». Кроме того, раз в сутки в полдень часы исполняли мелодию, написанную самим Кулибиным специально в честь приезда императрицы в Нижний Новгород. А во вторую половину суток каждый час исполнялась мелодия «Воскрес Иисус от гроба». На этом функции не заканчиваются: каждую из трёх мелодий как и автоматическое театральное представление можно было воспроизвести в любое время. Эти часы Иван Петрович Кулибин изготовил в подарок императрице Екатерине II.

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

Это "гуманизация" компьютеров. Очеловечивание. Приписывание компьютеру свойств человеческого разума.
Поймите правильно, можно сколько угодно сравнивать и находить аналогии, почему компьютер похож на мозг или мозг похож на компьютер, но это всё остаётся лишь аналогиями. Компьютер работает совершенно иначе, и вот почему:
1. Скорость. Говоря о производительности целого человеческого мозга - мы можем называть цифры в эксафлопсах и заявлять, что мозг работает в 10, 100, 1 000, 1 000 000 раз быстрее того или иного компьютера/суперкомпьютера, при этом потребляя всего лишь около 20 ватт энергии. Это пространство для спекуляций. Но это только потому, что мозг занят поразительно большим количеством параллельных задач. Если же взять скорость, с которой вы будете получать информацию, складывать два числа и выводить информацию - это будет несоизмеримо медленнее, чем это может делать компьютерная система. Для человека секунда - почти нисколько. Для компьютера секунда - это океан времени. Думаю, если бы искусственный интеллект мог бы нам пояснить свои ощущения, то сравнил бы секунду, как примерно две рабочих недели обычного человека.
2. Эмоциональность. Компьютерная программа (не оснащённая алгоритмами машинного обучения) будет повторять одну и ту же ошибку бесконечное количество раз. Компьютер не испытывает боли или угрызений совести когда ошибается. У него нет никакого мнения по личному вопросу. У компьютера не бывает настроения. Эти вещи свойственны людям (ну и очень большим искусственным интеллектам). И если вы наблюдаете разное поведение компьютера в одних и тех же условиях - значит условия меняются, а вы что-то упускаете из виду.
3. Исполнительность. Компьютер исполнит программу всегда в точности. Никогда не возникает ситуаций, когда часть инструкций "случайно" не выполнится. Если вы прописали в программе запись числа в определённую ячейку памяти (регистр), то эта запись произойдёт обязательно. Результат логических операций всегда будет соответствовать таблице истинности. Результаты арифметических операций никогда не будут отличаться от истины.

Можно много чего ещё добавить, но основными считаю эти три пункта. В плане скорости работы компьютерных систем (в частности, электроники и компьютеров), чаще всего люди вообще не способны осознать скоротечность процессов. Приведу пример: современный центральный процессор натурально ЖДЁТ, пока электрический импульс дойдёт со скоростью света до располагающейся рядом оперативной памяти и вернётся обратно. Можете посчитать, какое количество времени для этого нужно. Ошибочная оценка скорости работы компьютера может приводить к попыткам найти странные решения ваших задач. В плане эмоциональности - может быть так, что при написании кода вы будете надеяться, что компьютерная система сработает как надо, даже если у вас нет уверенности в стабильности алгоритма. Заметив одну ошибку вы можете надеяться, что она не повториться вновь. Не нужно так делать, нужно искать решение и делать программу сразу стабильной. Ну и исполнительность - недооценка этого фактора приводит к тому, что вы пишете код, проверяющий работу другого кода. Иногда такие подходы имеют смысл, но это не касается выполнения каких-то операций внутри программы. Например, имеет смысл проверить, записались ли данные, передаваемые удалённому устройству, потому что здесь сказывается влияние помех. Но нет смысла проверять, правильно ли сложились два числа внутри одной программы.

Если вы полностью понимаете и учитываете эти вещи во время разработки программ - то вы убережёте себя от большого количества ошибок начинающих программистов. Это то, о чём не пишут в книгах и то, что приходит с опытом. Это то, через что проходил и я.

Профессиональная деформация.

Сегодня хочу рассказать вам о деформациях психики, которые возникают у программистов. Конечно, у меня нет диплома психолога, но есть большой опыт наблюдений. Думаю, все понимают, что профессия - это то, чем человек занимается большую часть своей жизни. Если вы живёте обычную жизнь, то вы бодрствуете где-то 16 часов в сутки, ну плюс/минус. Из них минимум 8 вы отдаёте работе - профессиональной деятельности. А чаще даже и больше, потому что в большинстве случаев ваша работа продолжается в ваших мыслях. Поэтому любые профессии оказывают влияние на психику этих профессионалов. Не исключение и программисты.
В прошлом посте я написал немного о том, чем компьютер отличается от человека и как с этим быть. Есть ещё одна штука, напрямую следующая из описанного выше: компьютер никогда не обманывает и никогда не шутит.
Пример: как-то пришел к другу-программисту, ну и его жена пожаловалась, что он очень странно себя ведёт иногда. Не может найти какую-то вещь, хотя она на виду или всегда на одном и том же месте. Открыв холодильник, он спрашивает "а где колбаса?" и она ему отвечает "в ванной!" Он не задумываясь идёт в ванну, со словами "а как она туда попала???". И вроде бы можно было бы посмеяться, но дело в том, что именно так решаются проблемы при программировании. Если компьютер тебе говорит, что ошибка там-то, то иначе быть не может, нужно идти туда и разбираться, почему эта ошибка там оказалась, что она там делает, как сделать так, чтобы этого не происходило.

Программист во время работы берёт техническое задание (или сочиняет его себе сам) и пытается заставить компьютер делать то, что нужно. В случае с ПЛК - это ещё более лёгкий уровень, потому что в ПЛК нет слишком большой свободы, когда что-то может пойти не так. Но в случае, например, с С++ - таких возможностей хоть отбавляй. В попытках заставить компьютер делать требуемое - возникают ошибки. Где-то не так работает память, где-то что-то забыл создать или удалить, где-то удалил лишнего и так далее. Всё это приводит к ошибкам во время компиляции и во время работы. Приходится разбираться и постоянно искать, где что не так. И если не верить компьютеру абсолютно - будет получаться плохо.

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

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

Ещё один аспект - это усиливающиеся внимание к деталям. Чем больше у вас программистского опыта, тем более детально вы будете воспринимать все явления вокруг вас. За каждым событием вокруг стоят какие-то предшествующие действия и какие-то последствия. Это также свойственно и инженерам.

Плохо ли это? Не знаю. Приходится с этим жить. Иногда это мешает, иногда помогает.

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

"С волками жить - по волчьи выть" - есть такая поговорка. И вроде бы в обществе таких людей меньше чем обычных, как это в обществознании называют, "обывателей", но эти вот личности всё равно заставляют задумываться, всё ли делается правильно. Вот ещё пример менее токсичный, но тоже странный:
Узнал я тут про одного человека, который зарабатывает очень дофига много денег, при этом он продаёт людям гадания на таро. Он автоматизировал процесс, после оплаты заказа автоматически формируется запрос к искусственной нейронной сети, которая синтезирует "расклад" и что-то там расписывает, а затем информация отправляется к клиенту - profit!. Человек этот не то что бы гениальный, ну типа, обычный. Просто заморочился и сделал такую систему. Является ли он обманщиком? Даже сложно сказать, он даёт людям то, чего они хотят.

Последние пол года я почти каждый день думаю о том, что может быть я всё-таки не прав, и может быть нужно просто сделать финансовую пирамиду? Придумать инновационный способ отъёма денег у населения. А не заниматься всякими там изобретениями, пытаться что-то запрограммировать или написать полезный учебник, который даст людям знания. Аргументов и за и против достаточно. Самый сильный - это "я не хочу так поступать". Мне кажется, я в полной мере осознаю цену, которую платят люди, идущие этим путём, если, конечно, они не беспросветно тупые (а такие там тоже бывают). Я не хочу развивать в себе паранойю, ждать подвоха от всех окружающих, переживать за законность действий и прочее-прочее. Я хочу построить дом и спокойно жить. Желательно, вообще без врагов, хотя без них не всегда получается.

А между тем, я продолжаю работу над курсом по информатике и только что закончил писать черновик учебника к 9 уроку из 18 запланированных. Вот вам мой рабочий план по темам уроков.

Этот курс нужен в составе остальных для того, чтобы было легче учиться тем, кто от компьютеров далёк и кто не знает, как это всё работает и зачем.

Раскрытие тем получается очень глубоким. Пока что промежуточным результатом я удовлетворён!

Оверинжиниринг.
В разработке инженерных решений часто встречается "перепроектирование". На всякий случай, уточню, что я имею в виду: это когда инженеры-проектировщики закладывают избыточные технические решения.
Пример из тепловой энергетики: установка слишком большого количества аналоговых датчиков. Температура подачи, температура обратки, давление подачи, давление обратки - по каждому тепловому контуру. Температура до насосов, температура перед котлом, после котла и так далее. И можно обосновать размещение каждого датчика, но для регулирования большая часть из них не требуется. Каждый датчик - это плюс один аналоговый канал управления, плюс программирование, плюс монтаж, плюс место на экране диспетчеризации, плюс "тэг" скаду, плюс чек в кассу. Собственно, в последнем и кроется истинная причина этих действий.
Пример из автопрома: оптоволоконная линия связи между электронным блоком управления двигателем и блоком управления комфортом (привет, бентли/фольксваген).
Примеров можно найти из любой отрасли и их будет много.
Всё это удорожает обслуживание, удорожает разработку, диагностику и ремонт.
Встречается это и в механических решениях, хотя в меньшем количестве.
До недавнего времени, образцы стрелкового вооружения не имели такой проблемы, сейчас и в них это приходит (привет, штурмовая винтовка G11).

Короче говоря - проблема есть.
По моему мнению, дело в организации бизнес-процессов и, конечно, квалификации инженеров. Встречал такое, когда инженер просто делает всё, что знает и умеет, даже если этого всего не требуется в конкретной задаче.
Но ладно, оставим инженерную тему. Здесь я многое могу сказать, как считаю правильным и всё такое, но это ничего не поменяет, так как у меня нет власти повлиять на умы тех людей, которые внедряют такие решения.
НО(!) у меня есть власть повлиять на программистов. Поэтому завтра расскажу вам про это же явление в программировании, откуда оно появляется. И если в случае с инженерами - это, чаще всего, всё-таки обдуманные решения, то в случае с программированием перепроектирование или "оверкодинг", зачастую является стихийным бедствием. То есть то, что получается, как бы "само собой".

Оставайтесь на связи, скидывайте меня друзьям и коллегам. Буду делиться опытом.

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

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

Есть такое мем: У меня абстрактные фабрики генерят абстрактные классы, которые вызывают абстрактные методы, чтобы все уровни приложения были расширяемыми.

И опять же, такой подход бывает необходим в особых задачах, но уж точно не в задачах автоматизации.

Один мой друг говорит «главное, чтобы код работал» (привет, Роман!). И с этим я согласен. Хочу только уточнить один момент: ещё лучше, чтобы код выполнял свою задачу с минимальными затратами ресурсов. Речь не про оптимизацию ради оптимизации, это другая крайность, а про решения на уровне условного автомата Калашникова, где нет лишних деталей и всё работает ради общей цели.

Хорошее проектирование очень сильно помогает в этом вопросе. Определите сложность задачи и вырабатывайте решения соответствующего уровня. Если опыта много - можно и перемудрить немного, но с этим надо проявлять осторожность!

📌 БОНУСЫ В ЗАКРЕПЕ 👨‍💻

«GROMOV-PLC.RU» — платформа практической подготовки инженеров к современным методам программирования ПЛК по авторской методике Дмитрия Громова. Выбирайте свой формат участия 🦾

1️⃣ ПОДАРОК: ВЕБИНАР-ОБЗОР ПРОФЕССИИ 🎁
Как инженеру получать 100–300 тыс. руб. не выходя из дома, через системный подход программирования ПЛК?
Приглашаю Вас на открытый онлайн-разбор профессии и технологий промышленной автоматизации. Без воды и «успешного успеха» — только инженерный подход. 📈

👨🏻‍💻 Ведущий Дмитрий Громов - автор курсов, основатель и практикующий эксперт.
— Инженер-робототехник и эксперт по ПЛК (17 лет опыта на производствах).
— Автор методики X10.
— Подготовил 4000+ специалистов (в т.ч. сотрудников Ростеха, Роскосмоса, Русгидро, РосАтома, Segnetics и др.).
— Основатель крупнейшего комьюнити программистов ПЛК в РФ.

На вебинаре разберем:
✅ Технологии: Что такое современное программирование ПЛК и где оно применяется в 2026 году.
✅ Карьера и деньги: Почему одни сидят на окладе до 100 тыс., а другие забирают проекты на 300 тыс.+, разбор свежих вакансий.
✅ Практика: Разбор реальных проектов, архитектуры кода и кейсов моих выпускников.
✅ Дорожная карта: Пошаговая инструкция для старта новичков и роста опытных.
✅ Авторский метод X10: Покажу изнутри, как устроены мои программы подготовки.
📅 Когда: 19 февраля (Четверг) 19:00 по МСК.
📍 Регистрация и подробности здесь: 👉 https://gromov-plc.tilda.ws 🔗

2️⃣ БЫСТРЫЙ СТАРТ: КЛУБНАЯ ПОДПИСКА X10 (2900 ₽) ⚡️
Идеальный «тест-драйв» для тех, кто хочет проверить методику на практике прямо сейчас, не покупая большой курс. 🛡
Что внутри за 2900 ₽/мес?
✅ Доступ к КУРСУ X10: Вводный, но очень насыщенный курс, который познакомит Вас с основами авторской методики. Вы поймете, насколько вам подходит это направление, и освоите базовые навыки. ⌨️
✅ Доступ к ЧАТУ: Доступ к закрытому сообществу, где можно задать вопрос напрямую Дмитрию Громову или коллегам. 💬
✅ Доступ к ЖИВЫМ ВЕБИНАРАМ: Еженедельные разборы ваших вопросов и кейсов. 📽
✅ Гарантия окупаемости: Зачтем стоимость при переходе на любой курс или комплект курсов! 💎
📍 Стать участником Клубной подписки X10: 👉 https://gromov-plc.ru/x10 🔗

3️⃣ БОНУС ЗА ПОДПИСКУ: УРОКИ ПО ПИД 📽
Для тех, кто уже в канале — забирайте серию из 5 видео по настройке ПИД-регулятора на FBD (SMLogix): 👉 https://t.me/Gromovcode/17 📥

Всегда на связи: 📞 🌐 Сайт: gromov-plc.ru 📱 Приложение Android/iOS: https://gromov-plc.ru/pl/chatium/school/enter 📨 Почта: edu@gromov-plc.ru

Первая часть из пяти про ПИД-регулятор. Для кого-то эта тема уже "избитая", для кого-то "сложная". На одном из вебинаров студент задал вопрос "как сделать на FBD?" Данное видео (как и 4 последующих) - это нарезка с регулярного вебинара.
Каждую неделю я провожу вебинары для студентов и у каждого есть возможность задать свой персональный вопрос и получить такой же развёрнутый ответ!

Вторая (из пяти) часть видео про программирование ПИД-регулятора на FBD. Делаем всё последовательно.
Голосуйте реакциями! Больше реакций - больше подобного контента. У меня есть ещё много хороших тем с прошедших вебинаров.

Третья (из пяти) часть видео про программирование ПИД-регулятора на FBD. В этом видео затрагивается немного теории регулирования.
Такие вебинары проходят каждую среду. Студенты имеют доступ к таким вебинарам и на каждом из них задаются разные вопросы, поэтому темы для них никогда не заканчиваются!

А это четвёртая часть (из пяти) про программирование ПИД-регулятора. На самом деле, процесс не сложный, если держать в уме основную логику его работы - вычитание показаний из задания, многократное сложение этой разницы, умножение на коэффициенты, определение скорости изменения величины. Я даже считаю, что название "пропорционально-интегрально-дифференциальный" - это для математики. А для программистов стоило бы назвать такой регулятор "вычитательно-слагательно-умножительным", что намного меньше пугает.

Итак, презентация прошла. Дальше в обычном режиме! Видео про пид-регулятор, пятая часть! Здесь всё собирается и испытывается.

Вот такая вот серия видео. Надеюсь, было для вас полезно. Думаю, буду ещё периодически выкладывать видео с вебинаров. Кроме того, есть с самых новых вебинаров, бывают очень интересные темы поднимаются!

Продолжаем полезные темы. Это очередное видео с вебинара, который прошел совсем недавно (в среду 27 числа). Мне понравился этот вопрос.

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

В видео - ответ на этот вопрос