Он и не наступит, я вас уверяю. Я первый раз поставил Red Hat в девяносто восьмом. Там я неделю угрохал. пока разобрался что к чему. потом был Виндовс и моя компания меняла ноуты на топовые каждые три года (хорошие Деллы), так вот каждый раз, прежде чем вернуть ноут, я сносил с него виндовс, брал самый свежий дистрибутив Линукса, а то и несколько разных и ставил, просто чтоб посмотреть, куда движется этот мир. SuSe, дебиан, убунту... И каждый раз были проблемы. То нет картинки вообще (ну да NVidia), то нет сети, то звука, ещё что-то. Причём я б не сказал, что у меня совсем уж кривые руки. Все эти подходы к снаряду заканчивались тем, что я бросал это дело. И тут как-то мой знакомый купил ноут от System76, был очень доволен железкой , кстати, ну а там Pop_OS, ну я и подумал. что компания, которая затачивает линукс под своё железо, должна с болячками разбираться. Плюс ещё в том, что там есть дистр с вшитым драйвером NVidia, у меня все ноуты с этой картой. Ну и поставил, и о чудо - всё заработало, ну вообще всё. Второй монитор, док станция, всё без проблем. Я потом ещё Mint туда ставил, но визуально он мне значительно меньше понравился. Они ещё COSMIC десктоп на расте пилят. По части того, что far - это порт, меня как-то не очень волнует. Оно работает себе и работает. Ну да, зависимости, так в линуксе зависимось на зависимости сидит и ею погоняет. Для меня это в общем забавная домашняя игрушка, не основной рабочий комп, а просто чтобы в "тонусе быть. На работе же у меня куча инструментов, которые только под виндовс, там о переходе на линукс вообще речи не идёт. А дома - я постоянно что-то "подкручиваю", один раз уфигачил систему напрочь, ну и нет проблем - переставил и дальше играюсь. Зато старый сканер, что под виндовс через пень колоду работал, в линуксе завёлся с полтычка.
Почему нет? Ещё как есть. Я переехал на Pop_OS (по скти Убунта, но очень приятная), доволен как слон, Far - самое первое, что я ставлю после инсталляции. Ну там нужна пара теложвижений для инсталляции, но в общем без особых без проблем. Даже на хабре где-то статья была.
людей с 35 годами опыта разработки в IT очень тяжело переучить на что-то совсем новое
Вы неправы, у меня двадцать семь лет опыта в активной разработке (машинное зрение в реальном времени + АСУ ТП) и я всегда не только в курсе современных технологий, но и активно ими пользуюсь, при этом каждый день приносит новые знания, а опыт разработки, скажем медианного фильтра на чистом ассемблере с ММХ четверть века назад не только не мешает, но и помогает видеть "применимость" новейших технологий для решения той или иной задачи, благо я их овердофига за это время решил. Когнитивные способности после пятидесяти слегка проседают, но это компенсирует опыт, я всё равно выдам решение быстрее и качественнее чем большинство моих юных коллег.
Ну я имел ввиду, что при наличии камеры, дающей -40, смысл тестирования на -20, да ещё в течение короткого времени непонятен. Если я проверяю программу, которая должна работать 24/7 на предмет утечек памяти, то гоняю тесты несколько дней. Если стресс тестирование, то гружу комп на 100%. Кроме того, интересна именно деградация батареи. Я по работете тестирую рентгеновские детекторы, и они гоняются под рентгеном в 450 киловольт / 10 мА день и ночь до полного умирания, при этом мы снимаем кривые того, как именно они деградируют. Если дохнет электроника, то защита улучшается и тест повторяется, при этом каждый детектор стоит как автомобиль. Тест на минус сорок имело смысл гонять до полного подыхания батареи, при этом интересно, что будет, если там остаточный заряд не 17%, а 3-5% или вообще 1%. Равно как деградация со 100% тоже любопытна. Возможно замороженная батарея вообще заряд терять не будет. Не верю, что у Ниссана нет ресурсов сделать такие тесты.
Минус двадцать на сутки - это вообще ни о чём. Вот минус сорок на недельку, а лучше на две - то был бы реальный тест:
Помимо синтетических тестов важно то, как практически ведёт себя машина. Кроме возможного разряда батареи при низких температурах в теории возможна и необратимая деградация разряженной батареи, если её разряженную надолго в холоде оставить, и софт должен это учитывать. У меня гибридный мини купер, разряд высоковольтной батареи мне не так страшен, так как есть бензин (а стартер там от обычной низковольтной автобатареи запитан), но вот прошлой зимой было забавно. У этой машины по умолчанию приоритет батареи, то есть при полностью заправленной машине, она сначала высаживает батарею почти в ноль, а затем принимается за бензин и использует батарею для рекуперации при торможении. Ну и вот - на выходных я много ездил, приехал на работу с пустым аккумом, днём подморозило (не сильно, до минус десяти примерно), в обед я пошёл переставить машинку на зарядку (у нас работодатель разрешает электромобили бесплатно заряжать), и когда сел в машину, она мне - срочно на зарядку, иначе батарейке капут. Прикол в том, что у неё встроена сим карта и градусник, она получает прогноз погоды с сервера и вроде как видит, что будет холодно, да и вообще зима на дворе, ну не высаживай ты её в ноль, оставь процентов двадцать. Но нет. Такое ощущение, что софт к ней писали несколько отделов, вообще никак не общающихся друг с другом, и эта кривая логика работы в мороз далеко не единственная её проблема.
По поводу "смог завестись" применительно к электромобилю без ДВС уже писали, а вот по поводу "водители могут заранее прогреть салон" - так это сейчас у всех современных машин с электроприводом есть, что гибридных, что чисто электрических. У меня в гибриде кондиционер и обргреватель питаются именно от высоковольтной батареи, я обычно оставляю их работать, когда иду в магазин в жару или холод, ДВС при этом выключен, либо могу включить в заранее заданное время по расписанию (там два времени можно задать), либо через приложение.
Выбрать вариант «Удалить последнее качественное обновление» или «Удалить последнее обновление».
Если там действительно так и написано, то это просто издевательство над пользователем, при том. что единственно правильной формулировки "Удалить последнее некачественное обновление" там нет. Ну да, все обновления либо просто обновления, либо качественные, как же может быть иначе.
И это конечно, тоже. Как говорил Козьма Прутков: "нельзя объять необъятное". Если команда работает с определённым стеком технологий, то, конечно же отдаёт первое предпочтение хорошо знакомым языкам и паттернам, нежели бросается в неизведанные области. Само собой, при выборе определённого стека необходимо в совершенстве владеть всеми, тогда будет понятна применимость и удобство и будет возможность сделать реалистичную оценку трудозатрат на осное ТЗ.
Пример с ST - ну такое, он довольно примитивен сам по себе, ну вот что такого можно сделать на ST, чего невозможно или затруднительно на Си? Я уж не говорю о C++.
Кстати, данная логика работает и в обратную сторону. АСУ программисты порой "зашорены" своими ST/LD/FBD/SFC, поэтому возникает определённое отторжение других стеков, которые кажутся сложными.
В продакшене я использовал Си/С++ трижды.
В первой задаче нужно было сделать хитрый анализ коллизий. Я получал от системы с сервомоторов положение осей (там шестиосный манипулятор), геометрию оборудования, навешанного на этот манипулятор, плюс геометрию детали в виде 3D модели. Задача была в реальном времени анализировать коллизии при ручном перемещении манипулятора джойстиками (это нужно для обучения манипулятора, так-то система автоматическая). Поставить лазерную защиту было затруднительно в силу ограниченности пространства и постоянно меняющейся конфигураии. Если вы программировали роботов типа Kuka или ABB, то знаете, что там это есть. Я же сделал 3D симулятор на LabVIEW и разработал код на Си, который затем просто отдал АСУ программисту, он был интегрирован в проект, который также вначале обкатали на Digital Twin c Industrial Physics. Я б реально помер делать это на чём-то ещё, тем более что все базовые алгоритмы-кирпичики всяких пересечений полигонов и трейсинга для Си сто раз написаны.
Вторая задача была написать универсальную библиотеку конечных автоматов. Походу в конечных автоматах ничего сложного — там просто состояния и переходы, но в нашем случае переход из состояния в состояние сопровождается "перебрасыванием" детали, к которой приаттачен пакет данных (тип, серийный номер, результаты проверки и т.д.). Поскольку мы делаем кастомные системы на заказ, то конфигурация каждый раз разная, и метаданные разные, и нехитрый самодельный тулкит реально экономит время на написание новых автоматов, така как их не нужно делать с нуля, а просто "конфигурировать", грубо говоря. Тут ООП очень помогает.
На рендере одна из систем вот как-то так выглядит, там конвейер, пара лифтов для загрузки/выгрузки, пара роботов да манипулятор внутри, каждая часть работает под управлением своего автомата, они общаются друг с другом, обмениваются данными, при этом они однотипны, просто наследуются от одного класса, там фабрика:
Ну а третья задача была написать OPC UA клиента для B&R для "внешнего" OPC UA сервера. Сервер в ПЛК поднимается парой кликов, а вот для клиента нет, там есть библиотека "сделай сам". И всё бы ничего, но там была куча OPC UA Methods Call с кучей параметров, которые ещё и парсить надо было хитрым образом. Я сделал это на Си, причём на всю катушку используя препроцессор, и он меня очень выручил, сильно упростив код. Я реализовал бы это и на ST, положив, вероятно, втрое больше времени.
Не, я видно не так выразился. Программа на LabVIEW - это фактически СКАДА, причём часть машинного зрения. Она не заменяет в данном случае ПЛК, она работает вместе с ним. ПЛК управляет частью конвейера, общается с роботом, ну там кнопки на пульте, вот это вот всё, ну и всё время критичное крутится в ПЛК, само собой. А наружу торчит OPC, программа на LabVIEW получает оттуда данные "деталь такая-то, робот приехал в позицию", тогда хватает рентгеновскую картинку и говорит ПЛК (а тот уже — роботу) - ехай дальше. В конце проверки сообщает ПЛК - хорошая деталь или плохая, вот и всё. Времякритичных частей в LabVIEW в данном случае нет вообще. Если нужно реальное время, то есть LabVIEW Real-Time и FPGA до кучи, но тут совсем не тот случай.
А в C или C++ любого инженера переплюнет школьник использовав Copilot
Чем я, кстати и воспользовался, пока утром дополнение к статье писал. Ошибок он, правда, накидал знатно, но поправить их мне быстрее оказалось, нежели я б с нуля всё писал. Про библиотеки B&R он в курсе, циклические программы тоже, в общем не всё так плохо.
НО эти фичи становятся чувствительными и значимыми при гораздо больших размерах проекта.
Это так, да. Но если следовать правилу одна диаграмма - один экран, не использовать без нужды диаграммы последовательности и сильно вложенные кейсы, провести разумную функциональную декомпозицию, да воспользоваться ООП, то в общем норм. Опять же есть тулкиты типа Actor или DQMH, они помогают.
Кстати, приложение, что там на видео, оно и написано на LabVIEW от начала и до конца, эти индикаторы ни с чем не спутаешь (хотя нет, времякритичные части там на Си + интеловский компилятор):
Причём это, на секундочку, LabVIEW 7.1.1, аккурат двадцатилетней давности, там классов вообще не было.
что мешает визуалке "под капотом" генерить не странный текст, завязанный строго на одного производителя,
Ну это собственно и не нужно, LabVIEW гонит визуалку прямо в машинный код (точнее по капотом через LLVM гонит), и оно достаточно резво работает.
Попыток привести это к текстовому виду было предприято две, обе провалились. Первая - был такой тулкит "С code generator". То, что там генерялось было предназначено для "роботов", это реально каша была, в которой человеку без поллитра не разобраться. Сейчас закрыт. Вторая попытка называлась LabVIEW NXG (в смысле NeXt Generation), там визуальный код выгонялся в XML (нам же ещё расположение элементов надо хранить и т.п.), но они сделали ставку на .net, переписав это всё на Шарпе с WPF. Сказать, что это тормозило — это ничего не сказать. Запускаешь IDE и идёшь на перекур. Они так и не смогли догнать основную LabVIEW по функционалу, и проект тихо помер.
Беда в том, что на визуальные языки общего назначения сейчас нет стандарта. Как только он выкристаллизуется - всё будет норм.
В общем именно так, "высокоуровневость" языка позволяет выражать всё более сложные конструкции более простым представлением, и по итогу мы в профите.
Но что касается визуалки, то я вот по просьбе одного из читателей добавил немножко (там про сокеты вопрос был, промотайте выше до раздела "Обновление 22 декабря 2024", если любопытно), и вот там есть:
Я за чашкой воскресного кофе набросал пару примеров, и добавил их в конец статьи. Промотайте выше до "Обновление 22 декабря 2024", там пример сокетов и OPC UA на Питоне в том числе.
Преимущество Си может проявиться лишь на узком классе задач. Иногда вычисления удобно оформить именно сишной библиотекой. Тема, которую я хотел раскрыть - это поддержка свежих С++ стандартов, что добавляет определённую скажем так, степень свободы. Ну а использовать или нет - это от задачи зависит, мы ж не используем крестовую отвёртку там, где нужен шестигранник. ПЛК это не всегда тысячи сигналов, в нашем случае их несколько десятков, но временами используются хитрые манипуляторы плюс безопасность.
В общем да, есть библиотеки, ПЛК может быть как сервером так и клиентом, я попробую на досуге набросать примерчик связи между Питоном и ПЛК. Делал такое на Сименсе, положил кучу времени (там был нужен хитрый протокол), тут должно быть попроще. Для доступа к переменным OPC UA вполне себе штатно. Либо если сокет открыт, свой протокол сделать, либо как вариант сдёрнуть и отреверсить протокол обмена между AS и ПЛК (если он не шифрован), но тут я не копал. У Сименса вот сделали реверсинжиниринг, но в продакшн с этим я б не пошёл.
Полностью согласен. Ценник был основной причиной переезда с Сименс, но среда разработки местами раздражает, да и АСУ отдел стал больше. Единственно - Motion мне чуть удобнее показался - если автоматизировать, скажем сырорезку, где режущий нож синхронно с конвейером работает, то там просто пара щелчков и готово, либо если по хитрым траекториям перемещаться. Но я давно Сименс не смотрел, вот свежий двадцатый тиапортал хочу как раз на рожденственских каникулах погонять.
Спасибо за статью, но разве B&R и Siemens сейчас не труднодоступны?
B&R больше не поставляет оборудование, я видел пресс-релиз. У них, кажется, был офис в Москве, сейчас, вероятно, закрыт. Это, безусловно заметно снижает практическую ценность вышеизложенного материала, но тем не менее, мне подумалось, что кому-нибудь будет просто интересно, это так сказать популяризация автоматизации. Я с удовольствием читаю такие обзоры про любой ПЛК.
Что касается "труднодоступности" B&R и Siemens — я смею надеяться, что это не всегда будет так.
Он и не наступит, я вас уверяю. Я первый раз поставил Red Hat в девяносто восьмом. Там я неделю угрохал. пока разобрался что к чему. потом был Виндовс и моя компания меняла ноуты на топовые каждые три года (хорошие Деллы), так вот каждый раз, прежде чем вернуть ноут, я сносил с него виндовс, брал самый свежий дистрибутив Линукса, а то и несколько разных и ставил, просто чтоб посмотреть, куда движется этот мир. SuSe, дебиан, убунту... И каждый раз были проблемы. То нет картинки вообще (ну да NVidia), то нет сети, то звука, ещё что-то. Причём я б не сказал, что у меня совсем уж кривые руки. Все эти подходы к снаряду заканчивались тем, что я бросал это дело. И тут как-то мой знакомый купил ноут от System76, был очень доволен железкой , кстати, ну а там Pop_OS, ну я и подумал. что компания, которая затачивает линукс под своё железо, должна с болячками разбираться. Плюс ещё в том, что там есть дистр с вшитым драйвером NVidia, у меня все ноуты с этой картой. Ну и поставил, и о чудо - всё заработало, ну вообще всё. Второй монитор, док станция, всё без проблем. Я потом ещё Mint туда ставил, но визуально он мне значительно меньше понравился. Они ещё COSMIC десктоп на расте пилят. По части того, что far - это порт, меня как-то не очень волнует. Оно работает себе и работает. Ну да, зависимости, так в линуксе зависимось на зависимости сидит и ею погоняет. Для меня это в общем забавная домашняя игрушка, не основной рабочий комп, а просто чтобы в "тонусе быть. На работе же у меня куча инструментов, которые только под виндовс, там о переходе на линукс вообще речи не идёт. А дома - я постоянно что-то "подкручиваю", один раз уфигачил систему напрочь, ну и нет проблем - переставил и дальше играюсь. Зато старый сканер, что под виндовс через пень колоду работал, в линуксе завёлся с полтычка.
Почему нет? Ещё как есть. Я переехал на Pop_OS (по скти Убунта, но очень приятная), доволен как слон, Far - самое первое, что я ставлю после инсталляции. Ну там нужна пара теложвижений для инсталляции, но в общем без особых без проблем. Даже на хабре где-то статья была.
Вы неправы, у меня двадцать семь лет опыта в активной разработке (машинное зрение в реальном времени + АСУ ТП) и я всегда не только в курсе современных технологий, но и активно ими пользуюсь, при этом каждый день приносит новые знания, а опыт разработки, скажем медианного фильтра на чистом ассемблере с ММХ четверть века назад не только не мешает, но и помогает видеть "применимость" новейших технологий для решения той или иной задачи, благо я их овердофига за это время решил. Когнитивные способности после пятидесяти слегка проседают, но это компенсирует опыт, я всё равно выдам решение быстрее и качественнее чем большинство моих юных коллег.
Ну я имел ввиду, что при наличии камеры, дающей -40, смысл тестирования на -20, да ещё в течение короткого времени непонятен. Если я проверяю программу, которая должна работать 24/7 на предмет утечек памяти, то гоняю тесты несколько дней. Если стресс тестирование, то гружу комп на 100%. Кроме того, интересна именно деградация батареи. Я по работете тестирую рентгеновские детекторы, и они гоняются под рентгеном в 450 киловольт / 10 мА день и ночь до полного умирания, при этом мы снимаем кривые того, как именно они деградируют. Если дохнет электроника, то защита улучшается и тест повторяется, при этом каждый детектор стоит как автомобиль. Тест на минус сорок имело смысл гонять до полного подыхания батареи, при этом интересно, что будет, если там остаточный заряд не 17%, а 3-5% или вообще 1%. Равно как деградация со 100% тоже любопытна. Возможно замороженная батарея вообще заряд терять не будет. Не верю, что у Ниссана нет ресурсов сделать такие тесты.
Минус двадцать на сутки - это вообще ни о чём. Вот минус сорок на недельку, а лучше на две - то был бы реальный тест:
Помимо синтетических тестов важно то, как практически ведёт себя машина. Кроме возможного разряда батареи при низких температурах в теории возможна и необратимая деградация разряженной батареи, если её разряженную надолго в холоде оставить, и софт должен это учитывать. У меня гибридный мини купер, разряд высоковольтной батареи мне не так страшен, так как есть бензин (а стартер там от обычной низковольтной автобатареи запитан), но вот прошлой зимой было забавно. У этой машины по умолчанию приоритет батареи, то есть при полностью заправленной машине, она сначала высаживает батарею почти в ноль, а затем принимается за бензин и использует батарею для рекуперации при торможении. Ну и вот - на выходных я много ездил, приехал на работу с пустым аккумом, днём подморозило (не сильно, до минус десяти примерно), в обед я пошёл переставить машинку на зарядку (у нас работодатель разрешает электромобили бесплатно заряжать), и когда сел в машину, она мне - срочно на зарядку, иначе батарейке капут. Прикол в том, что у неё встроена сим карта и градусник, она получает прогноз погоды с сервера и вроде как видит, что будет холодно, да и вообще зима на дворе, ну не высаживай ты её в ноль, оставь процентов двадцать. Но нет. Такое ощущение, что софт к ней писали несколько отделов, вообще никак не общающихся друг с другом, и эта кривая логика работы в мороз далеко не единственная её проблема.
По поводу "смог завестись" применительно к электромобилю без ДВС уже писали, а вот по поводу "водители могут заранее прогреть салон" - так это сейчас у всех современных машин с электроприводом есть, что гибридных, что чисто электрических. У меня в гибриде кондиционер и обргреватель питаются именно от высоковольтной батареи, я обычно оставляю их работать, когда иду в магазин в жару или холод, ДВС при этом выключен, либо могу включить в заранее заданное время по расписанию (там два времени можно задать), либо через приложение.
Если там действительно так и написано, то это просто издевательство над пользователем, при том. что единственно правильной формулировки "Удалить последнее некачественное обновление" там нет. Ну да, все обновления либо просто обновления, либо качественные, как же может быть иначе.
Короче, я не поленился, скачал tia двадцатую, да поставил за завтраком
Возможности использования С++ там судя по всему сильно ограничены, потребуется мультифункциональный контроллер, вот этот, 1518-4 PN/DP MFP:
Ну и там появится слот С++
Единственно, я хз, куда там собственно код вкорячивать, B&R Automation Studio выглядит простой как пять копеек, а тут вот что:
Надо просто разобраться, я очень давно с Сименсом не работал. Но вроде С++ теперь есть.
И это конечно, тоже. Как говорил Козьма Прутков: "нельзя объять необъятное". Если команда работает с определённым стеком технологий, то, конечно же отдаёт первое предпочтение хорошо знакомым языкам и паттернам, нежели бросается в неизведанные области. Само собой, при выборе определённого стека необходимо в совершенстве владеть всеми, тогда будет понятна применимость и удобство и будет возможность сделать реалистичную оценку трудозатрат на осное ТЗ.
Пример с ST - ну такое, он довольно примитивен сам по себе, ну вот что такого можно сделать на ST, чего невозможно или затруднительно на Си? Я уж не говорю о C++.
Кстати, данная логика работает и в обратную сторону. АСУ программисты порой "зашорены" своими ST/LD/FBD/SFC, поэтому возникает определённое отторжение других стеков, которые кажутся сложными.
В продакшене я использовал Си/С++ трижды.
В первой задаче нужно было сделать хитрый анализ коллизий. Я получал от системы с сервомоторов положение осей (там шестиосный манипулятор), геометрию оборудования, навешанного на этот манипулятор, плюс геометрию детали в виде 3D модели. Задача была в реальном времени анализировать коллизии при ручном перемещении манипулятора джойстиками (это нужно для обучения манипулятора, так-то система автоматическая). Поставить лазерную защиту было затруднительно в силу ограниченности пространства и постоянно меняющейся конфигураии. Если вы программировали роботов типа Kuka или ABB, то знаете, что там это есть. Я же сделал 3D симулятор на LabVIEW и разработал код на Си, который затем просто отдал АСУ программисту, он был интегрирован в проект, который также вначале обкатали на Digital Twin c Industrial Physics. Я б реально помер делать это на чём-то ещё, тем более что все базовые алгоритмы-кирпичики всяких пересечений полигонов и трейсинга для Си сто раз написаны.
Вторая задача была написать универсальную библиотеку конечных автоматов. Походу в конечных автоматах ничего сложного — там просто состояния и переходы, но в нашем случае переход из состояния в состояние сопровождается "перебрасыванием" детали, к которой приаттачен пакет данных (тип, серийный номер, результаты проверки и т.д.). Поскольку мы делаем кастомные системы на заказ, то конфигурация каждый раз разная, и метаданные разные, и нехитрый самодельный тулкит реально экономит время на написание новых автоматов, така как их не нужно делать с нуля, а просто "конфигурировать", грубо говоря. Тут ООП очень помогает.
На рендере одна из систем вот как-то так выглядит, там конвейер, пара лифтов для загрузки/выгрузки, пара роботов да манипулятор внутри, каждая часть работает под управлением своего автомата, они общаются друг с другом, обмениваются данными, при этом они однотипны, просто наследуются от одного класса, там фабрика:
Ну а третья задача была написать OPC UA клиента для B&R для "внешнего" OPC UA сервера. Сервер в ПЛК поднимается парой кликов, а вот для клиента нет, там есть библиотека "сделай сам". И всё бы ничего, но там была куча OPC UA Methods Call с кучей параметров, которые ещё и парсить надо было хитрым образом. Я сделал это на Си, причём на всю катушку используя препроцессор, и он меня очень выручил, сильно упростив код. Я реализовал бы это и на ST, положив, вероятно, втрое больше времени.
Я тоже не встречал, но я программировал на Сименс где-то до 14 версии. Надо смотреть свежую, двадцатую версию, возможно это там добавлено...
Не, я видно не так выразился. Программа на LabVIEW - это фактически СКАДА, причём часть машинного зрения. Она не заменяет в данном случае ПЛК, она работает вместе с ним. ПЛК управляет частью конвейера, общается с роботом, ну там кнопки на пульте, вот это вот всё, ну и всё время критичное крутится в ПЛК, само собой. А наружу торчит OPC, программа на LabVIEW получает оттуда данные "деталь такая-то, робот приехал в позицию", тогда хватает рентгеновскую картинку и говорит ПЛК (а тот уже — роботу) - ехай дальше. В конце проверки сообщает ПЛК - хорошая деталь или плохая, вот и всё. Времякритичных частей в LabVIEW в данном случае нет вообще. Если нужно реальное время, то есть LabVIEW Real-Time и FPGA до кучи, но тут совсем не тот случай.
Чем я, кстати и воспользовался, пока утром дополнение к статье писал. Ошибок он, правда, накидал знатно, но поправить их мне быстрее оказалось, нежели я б с нуля всё писал. Про библиотеки B&R он в курсе, циклические программы тоже, в общем не всё так плохо.
Это так, да. Но если следовать правилу одна диаграмма - один экран, не использовать без нужды диаграммы последовательности и сильно вложенные кейсы, провести разумную функциональную декомпозицию, да воспользоваться ООП, то в общем норм. Опять же есть тулкиты типа Actor или DQMH, они помогают.
Кстати, приложение, что там на видео, оно и написано на LabVIEW от начала и до конца, эти индикаторы ни с чем не спутаешь (хотя нет, времякритичные части там на Си + интеловский компилятор):
Причём это, на секундочку, LabVIEW 7.1.1, аккурат двадцатилетней давности, там классов вообще не было.
Ну это собственно и не нужно, LabVIEW гонит визуалку прямо в машинный код (точнее по капотом через LLVM гонит), и оно достаточно резво работает.
Попыток привести это к текстовому виду было предприято две, обе провалились. Первая - был такой тулкит "С code generator". То, что там генерялось было предназначено для "роботов", это реально каша была, в которой человеку без поллитра не разобраться. Сейчас закрыт. Вторая попытка называлась LabVIEW NXG (в смысле NeXt Generation), там визуальный код выгонялся в XML (нам же ещё расположение элементов надо хранить и т.п.), но они сделали ставку на .net, переписав это всё на Шарпе с WPF. Сказать, что это тормозило — это ничего не сказать. Запускаешь IDE и идёшь на перекур. Они так и не смогли догнать основную LabVIEW по функционалу, и проект тихо помер.
Беда в том, что на визуальные языки общего назначения сейчас нет стандарта. Как только он выкристаллизуется - всё будет норм.
В общем именно так, "высокоуровневость" языка позволяет выражать всё более сложные конструкции более простым представлением, и по итогу мы в профите.
Но что касается визуалки, то я вот по просьбе одного из читателей добавил немножко (там про сокеты вопрос был, промотайте выше до раздела "Обновление 22 декабря 2024", если любопытно), и вот там есть:
Код на Питоне
И ровно тоже самое на LabVIEW, вообще один-в-один:
Мне вот (чисто субъективнo) в данном случае визуальный язык нравится больше.
Я за чашкой воскресного кофе набросал пару примеров, и добавил их в конец статьи. Промотайте выше до "Обновление 22 декабря 2024", там пример сокетов и OPC UA на Питоне в том числе.
Преимущество Си может проявиться лишь на узком классе задач. Иногда вычисления удобно оформить именно сишной библиотекой. Тема, которую я хотел раскрыть - это поддержка свежих С++ стандартов, что добавляет определённую скажем так, степень свободы. Ну а использовать или нет - это от задачи зависит, мы ж не используем крестовую отвёртку там, где нужен шестигранник. ПЛК это не всегда тысячи сигналов, в нашем случае их несколько десятков, но временами используются хитрые манипуляторы плюс безопасность.
В общем да, есть библиотеки, ПЛК может быть как сервером так и клиентом, я попробую на досуге набросать примерчик связи между Питоном и ПЛК. Делал такое на Сименсе, положил кучу времени (там был нужен хитрый протокол), тут должно быть попроще. Для доступа к переменным OPC UA вполне себе штатно. Либо если сокет открыт, свой протокол сделать, либо как вариант сдёрнуть и отреверсить протокол обмена между AS и ПЛК (если он не шифрован), но тут я не копал. У Сименса вот сделали реверсинжиниринг, но в продакшн с этим я б не пошёл.
Полностью согласен. Ценник был основной причиной переезда с Сименс, но среда разработки местами раздражает, да и АСУ отдел стал больше. Единственно - Motion мне чуть удобнее показался - если автоматизировать, скажем сырорезку, где режущий нож синхронно с конвейером работает, то там просто пара щелчков и готово, либо если по хитрым траекториям перемещаться. Но я давно Сименс не смотрел, вот свежий двадцатый тиапортал хочу как раз на рожденственских каникулах погонять.
Я в курсе, выше я коммент написал, но вот тут я просто оставлю скриншот со странички про SIMATIC S7-1500 Software Controller:
Там с места в карьер:
Так что местами плюсплюсы в требования и подходы промышленности вполне себе вписываются. Но всё хорошо в меру, это да.
B&R больше не поставляет оборудование, я видел пресс-релиз. У них, кажется, был офис в Москве, сейчас, вероятно, закрыт. Это, безусловно заметно снижает практическую ценность вышеизложенного материала, но тем не менее, мне подумалось, что кому-нибудь будет просто интересно, это так сказать популяризация автоматизации. Я с удовольствием читаю такие обзоры про любой ПЛК.
Что касается "труднодоступности" B&R и Siemens — я смею надеяться, что это не всегда будет так.