Не нужно додумывать. Я инженер, который почти всю карьеру пишет документы. Все описано, задокументировано. Проекты лежат в репозитории gitlab. Имеются описания каждого проекта и все необходимые инструкции в компании лежать на дисках битрикс.
В нашей задаче весь смысл был не замена ПЛК с переписыванием проекта (а в нашем проекте весь код на чистом Си), а замена ПЛК на мини-ПК с сохранением кода ПЛК, так как никто не хотел и не мог лезть в проект и разбираться с ним и в нем, а тем более переписывать на другую платформу ПЛК.
Ну мы тоже не коленом деланы. Изначально компания с 2015 года была дилером автомоек из Германии. Оборудование шло с автоматикой B&R. И так как в России очень хорошая поддержка этой компании на уровне ПО, то когда фирма от дилерства стала сама производить и собирать мойки, то логичным было применять отработанные решения. Тем более, что спрос на это оборудование был, и не маленький. Когда же применили санкции против России, мы тут же переделали проект B&R для работы со сторонними модулями ввода/вывода (китайской линейки GCAN) для всех новых заказов. Это было в 2022 году. И так мы и делаем по сей день. Речь же в статье про те мойки, которые остались на старом оборудовании. Тех поддержка в моем лице, просто, решила проблему с поломкой B&R ПЛК, заменив их обычным мини-пк.
За жизнь понял, что мы сами ограничиваем и свои свободы и свой кругозор. Все проблемы человека от ограничивающих убеждений. Сам такой. Попробуйте рискнуть и сосредоточьтесь на результате, а не на том, как написано. Отлаживайте код вместе с ИИ. И тогда код будет писать только ИИ. И ваша производительность на порядок увеличится.
Испробовал все известные ИИ для программирования. Остановился на claude opus и claude fable. С другими (gemini, grok, DeepSeek, ChatGPT и др) постоянно был в контрах и срался с ними. Пользуюсь только MAX подписками (240 баксов)
Слушайте, но ИИ то сам себе не ставит задачи! Зачем вы себя хороните? Ну, хотя бы, пройдите курс промпт-инжиниринга. В целом, DevOps это не плохое развитие и "повышение" в IT, чтобы не потерять работу и во всю пользоваться ИИ
Когда я начинал свой картерный путь, программирование было простое: ассемблер, C, Pascal. Никаких фреймворков, пакетных менеджеров... И всё новое приходилось осваивать по ходу, по мере того как оно появлялось, и тащил в работу. Сейчас то же самое, просто новое теперь это ИИ, который во многом пишет код сам, и если вы учились только программированию, придётся доучивать то, что вокруг него. Меня тут выручает то, что я учился на системотехника: нас учили в первую очередь тому, как устроены и живут реальные объекты, а программирование было просто инструментом. У каждого направления свой объект. У меня это железо и физика процессов, у веба это человек и то, как до него доходит информация, эргономика, инженерная психология, плюс то, как живёт система за экраном, сети, базы, нагрузка, отказы. Я бы выбрал одну предметную область рядом с софтом и погрузился в неё со всех сторон, железо, человек, требования, лучше рядом с кем-то опытным. А когда понимаешь, как там всё устроено, тогда уже можно и придумывать что-то своё, и нормально ставить задачу ИИ, и проверять, что он сделал.
В автоматике каплер, это контроллер шины, объединяющий модули ввода/вывода с ПЛК, по одному из промышленных протоколов. При этом внутренняя шина модулей может быть какой угодно (зависит от производителя).
Ну да, и код, и статью. Я про это и написал вообще-то. Или вы ждали, что я буду это скрывать? Без ИИ вообще бы никогда ничего не написал для других. У меня нет писательских талантов. Я могу только устно в разговоре что-то излагать, более менее внятно.
Мысли и факты мои. А вот прогонять готовый текст через ИИ, это уже рефлекс. Я так работаю каждый день, исправляю с помощью него ошибки и формулировки, и на комментарии это перенеслось на автомате. Не из пренебрежения к читателю, а по привычке инструмента. Смысл то от этого не меняется. То есть по делу возражений нет, есть только к тому, как написано.
Со стороны это выглядит как спуск: от кораблей к домофонам и автомойкам. На самом деле это движение в другую сторону. На кораблях я делал приборы — один контроллер, одна задача, жёсткое реальное время. Дальше задачи становились системами: домофон оказался компьютерным зрением на embedded Linux, мойка — платформой из двухсот объектов с облаком, платёжным железом и реальным временем сразу. Объект попроще, система на порядок сложнее. Программировать один прибор я умел в 2005-м. Держать сеть из сотен приборов, каждый со своим железом, один — этому пришлось учиться уже здесь.
Спасибо. Третья часть про работу в паре с ИИ — интерес понял, подумаю. Там есть что рассказать, но пока не обещаю.
Про сложность — вопрос правильный, и я его сам себе задавал. Только сравнивать надо не «сложно или просто», а «с чем сравниваем». Контроллер B&R я не выбирал. Он уже стоит на сотнях объектов, вместе со стойками, проводкой и проектом, который годами работает. Простой вариант — выбросить стойки, поставить Modbus-модули и переписать проект — на бумаге выглядит проще. Но это перемонтаж двух-трёх сотен точек на каждой мойке, новая проверка всей логики, и главное — простой объекта, который каждый день принимает деньги. На одной мойке это ещё можно, на двух сотнях — нет.
То, что описано в статье, сложно сделать один раз. Зато потом это ставится скриптом за час, стойки не трогаются, проект не переписывается, мойка не останавливается. Вся сложность живёт в одном мини-ПК, а на объекте ничего не меняется. Для парка это единственный вариант, который сходится по деньгам и срокам. С нуля я бы, конечно, всё это так не строил — но с нуля никто и не строит.
Про мировую десятку спорить не буду, в топе они не были, доля в ПЛК около 4%. Но «морская свинка» и «экзотика» — это не про них. B&R делала машинную автоматику для BMW, Volkswagen, Nestle, P&G, 4000 машиностроителей по миру, 600 млн долларов оборота на момент покупки ABB. Это стандарт для тех, кто делает машины, а не заводы.
А для России важнее другое. B&R массово ставили в оборудование, которое собиралось здесь: мойки самообслуживания, упаковка, пищевое, вендинг. Только в моей отрасли на B&R сотни объектов, и они не исчезли — они стоят и работают, просто контроллеров к ним больше не купить. То, что мировая доля скромная, ничем не помогает владельцу, у которого встала линия. Ему нужен не рейтинг вендора, а работающий способ её поднять. Про него и статья.
Это звучит только грустно. На самом деле это рост. Одно дело вы винтик на маленькой ЗП и пишите для приборов и приборных комплексов, и совсем другое авторский надзор с высокой ЗП и пишите для систем и инфраструктур.
Не вижу связи. Вне трудовых споров термин используют как осуждающее определение для человека, который предает интересы своей группы, нарушает профессиональную или командную солидарность ради личной выгоды. Я остался, потому занимался поддержкой архитектуры ПО. И так как производство закрылось, а тех поддержка нет, то было логично уволить всех тех, кто не приносит прибыли. Это потом я уже понял, что мне либо увольняться, либо осваивать смежные проекты, чтобы полноценно заниматься поддержкой. И я рискнул прибегнуть к помощи ИИ. И понеслось... Благодаря этому, возобновилось производство.
Так это и есть вопрос человеческих компетенций. Я же не утверждал, что когда ИИ написал драйвер, все сразу заработало. Нет, отрабатывали метрики и критерии. Следовательно, только компетенции могу формировать запросы к ИИ в случае отказов. Об этом в статье так же указано!
Не нужно додумывать. Я инженер, который почти всю карьеру пишет документы. Все описано, задокументировано. Проекты лежат в репозитории gitlab. Имеются описания каждого проекта и все необходимые инструкции в компании лежать на дисках битрикс.
В нашей задаче весь смысл был не замена ПЛК с переписыванием проекта (а в нашем проекте весь код на чистом Си), а замена ПЛК на мини-ПК с сохранением кода ПЛК, так как никто не хотел и не мог лезть в проект и разбираться с ним и в нем, а тем более переписывать на другую платформу ПЛК.
Ну мы тоже не коленом деланы. Изначально компания с 2015 года была дилером автомоек из Германии. Оборудование шло с автоматикой B&R. И так как в России очень хорошая поддержка этой компании на уровне ПО, то когда фирма от дилерства стала сама производить и собирать мойки, то логичным было применять отработанные решения. Тем более, что спрос на это оборудование был, и не маленький.
Когда же применили санкции против России, мы тут же переделали проект B&R для работы со сторонними модулями ввода/вывода (китайской линейки GCAN) для всех новых заказов. Это было в 2022 году. И так мы и делаем по сей день.
Речь же в статье про те мойки, которые остались на старом оборудовании. Тех поддержка в моем лице, просто, решила проблему с поломкой B&R ПЛК, заменив их обычным мини-пк.
За жизнь понял, что мы сами ограничиваем и свои свободы и свой кругозор. Все проблемы человека от ограничивающих убеждений. Сам такой.
Попробуйте рискнуть и сосредоточьтесь на результате, а не на том, как написано. Отлаживайте код вместе с ИИ. И тогда код будет писать только ИИ. И ваша производительность на порядок увеличится.
Испробовал все известные ИИ для программирования. Остановился на claude opus и claude fable. С другими (gemini, grok, DeepSeek, ChatGPT и др) постоянно был в контрах и срался с ними.
Пользуюсь только MAX подписками (240 баксов)
Слушайте, но ИИ то сам себе не ставит задачи! Зачем вы себя хороните? Ну, хотя бы, пройдите курс промпт-инжиниринга.
В целом, DevOps это не плохое развитие и "повышение" в IT, чтобы не потерять работу и во всю пользоваться ИИ
DevOps-инженер будет достаточно.
Когда я начинал свой картерный путь, программирование было простое: ассемблер, C, Pascal. Никаких фреймворков, пакетных менеджеров... И всё новое приходилось осваивать по ходу, по мере того как оно появлялось, и тащил в работу. Сейчас то же самое, просто новое теперь это ИИ, который во многом пишет код сам, и если вы учились только программированию, придётся доучивать то, что вокруг него. Меня тут выручает то, что я учился на системотехника: нас учили в первую очередь тому, как устроены и живут реальные объекты, а программирование было просто инструментом. У каждого направления свой объект. У меня это железо и физика процессов, у веба это человек и то, как до него доходит информация, эргономика, инженерная психология, плюс то, как живёт система за экраном, сети, базы, нагрузка, отказы. Я бы выбрал одну предметную область рядом с софтом и погрузился в неё со всех сторон, железо, человек, требования, лучше рядом с кем-то опытным. А когда понимаешь, как там всё устроено, тогда уже можно и придумывать что-то своё, и нормально ставить задачу ИИ, и проверять, что он сделал.
DevOps-инженер будет достаточно.
В автоматике каплер, это контроллер шины, объединяющий модули ввода/вывода с ПЛК, по одному из промышленных протоколов. При этом внутренняя шина модулей может быть какой угодно (зависит от производителя).
Ну да, и код, и статью. Я про это и написал вообще-то. Или вы ждали, что я буду это скрывать?
Без ИИ вообще бы никогда ничего не написал для других. У меня нет писательских талантов. Я могу только устно в разговоре что-то излагать, более менее внятно.
Мысли и факты мои. А вот прогонять готовый текст через ИИ, это уже рефлекс. Я так работаю каждый день, исправляю с помощью него ошибки и формулировки, и на комментарии это перенеслось на автомате. Не из пренебрежения к читателю, а по привычке инструмента. Смысл то от этого не меняется.
То есть по делу возражений нет, есть только к тому, как написано.
Спасибо!
Я бы и рад, но с моими адекватными запросами не берут. )
И, потому что создаю конкуренцию менеджменту по уровню компетенций.
Со стороны это выглядит как спуск: от кораблей к домофонам и автомойкам. На самом деле это движение в другую сторону. На кораблях я делал приборы — один контроллер, одна задача, жёсткое реальное время. Дальше задачи становились системами: домофон оказался компьютерным зрением на embedded Linux, мойка — платформой из двухсот объектов с облаком, платёжным железом и реальным временем сразу. Объект попроще, система на порядок сложнее. Программировать один прибор я умел в 2005-м. Держать сеть из сотен приборов, каждый со своим железом, один — этому пришлось учиться уже здесь.
Спасибо. Третья часть про работу в паре с ИИ — интерес понял, подумаю. Там есть что рассказать, но пока не обещаю.
Про сложность — вопрос правильный, и я его сам себе задавал. Только сравнивать надо не «сложно или просто», а «с чем сравниваем». Контроллер B&R я не выбирал. Он уже стоит на сотнях объектов, вместе со стойками, проводкой и проектом, который годами работает. Простой вариант — выбросить стойки, поставить Modbus-модули и переписать проект — на бумаге выглядит проще. Но это перемонтаж двух-трёх сотен точек на каждой мойке, новая проверка всей логики, и главное — простой объекта, который каждый день принимает деньги. На одной мойке это ещё можно, на двух сотнях — нет.
То, что описано в статье, сложно сделать один раз. Зато потом это ставится скриптом за час, стойки не трогаются, проект не переписывается, мойка не останавливается. Вся сложность живёт в одном мини-ПК, а на объекте ничего не меняется. Для парка это единственный вариант, который сходится по деньгам и срокам. С нуля я бы, конечно, всё это так не строил — но с нуля никто и не строит.
Про мировую десятку спорить не буду, в топе они не были, доля в ПЛК около 4%. Но «морская свинка» и «экзотика» — это не про них. B&R делала машинную автоматику для BMW, Volkswagen, Nestle, P&G, 4000 машиностроителей по миру, 600 млн долларов оборота на момент покупки ABB. Это стандарт для тех, кто делает машины, а не заводы.
А для России важнее другое. B&R массово ставили в оборудование, которое собиралось здесь: мойки самообслуживания, упаковка, пищевое, вендинг. Только в моей отрасли на B&R сотни объектов, и они не исчезли — они стоят и работают, просто контроллеров к ним больше не купить. То, что мировая доля скромная, ничем не помогает владельцу, у которого встала линия. Ему нужен не рейтинг вендора, а работающий способ её поднять. Про него и статья.
Это звучит только грустно. На самом деле это рост. Одно дело вы винтик на маленькой ЗП и пишите для приборов и приборных комплексов, и совсем другое авторский надзор с высокой ЗП и пишите для систем и инфраструктур.
Не вижу связи.
Вне трудовых споров термин используют как осуждающее определение для человека, который предает интересы своей группы, нарушает профессиональную или командную солидарность ради личной выгоды.
Я остался, потому занимался поддержкой архитектуры ПО. И так как производство закрылось, а тех поддержка нет, то было логично уволить всех тех, кто не приносит прибыли.
Это потом я уже понял, что мне либо увольняться, либо осваивать смежные проекты, чтобы полноценно заниматься поддержкой. И я рискнул прибегнуть к помощи ИИ. И понеслось...
Благодаря этому, возобновилось производство.
Так это и есть вопрос человеческих компетенций. Я же не утверждал, что когда ИИ написал драйвер, все сразу заработало. Нет, отрабатывали метрики и критерии. Следовательно, только компетенции могу формировать запросы к ИИ в случае отказов. Об этом в статье так же указано!