К сожалению на данный момент нет Работа связана с эпизодическими поездками в г. Киржач, Владимирская Область. Там находится основное производство. Такси от Москвы или топливо оплачивается. Мой коллега решил круто сменить сферу деятельности и увольняется, мне надо вырастить ему замену
Комментарии: 40
Aleksandr
Кузница звёзд автоматизации прям)
Alexey
Мы выпускаем единственное изделие, схемотехника устоявшаяся. Схемами и конструкциями шкафов вы не занимаетесь, только чистое программирование. В настоящий момент я заканчиваю универсальный проект для ПЛК Овен, Fastwel, Crevis и НИЛАП. Мы используем Crevis, остальные бренды подстраховка. По сути после окончания проекта ваша работа будет заключаться в незначительной модификации этого проекта в зависимости от незначительной модификации установки. Это пряник. Кнутом примерно 5 первых работающих установок еще крутятся на CDS 2.3 но я сейчас буду давить чтобы на них бошку ПЛК сменили на CDS 3.5 Ну я 20 лет в этой сфере, треть времени работал заграницей. Могу выучить до уровня лучших программистов ОВЕН. Для ценителей прекрасного можем весь день на английском общаться В общем кому интересно пишите в личку
Aleksandr
Очередь откуда начинается? Кто крайний?
Alexey
HR пока не размещала объявление на HH. В понедельник обсужление будет требований и т.п. Так что есть возможность встать в первые ряды. Просто 95% с HH будут идиотами или чепухой. Поэтому я и решил тут написать, вдруг кому интересно будет Зарплата так же обсуждаема. Если человек профи, то не 150К
Maksim
Crevis это гуд. Брали их на тест. По итогу обработка в нем быстрее 1500х, но таки медленнее XPact. Бенчмарк писал для целочисленных, real и bool операций. А.. ну ещё тригонометрия для них сложна И модули быстрые тоже есть. А чем обусловлен Ваш выбор? Тоже придерживаюсь принципа кросплатформенности, так что моё почтение за подход к разработке. Такие тут редко появляются.
Alexey
Исключительно форм фактором. Изначально все было на Fastwel. Потом сроки поставки у них улетели в космос. Перешли на Beckhoff. Ну дальше история всем известна. На Западе в основном в ООП разработка. Это понятно новому поколению и вписывается в концепцию гибких производств. Я пишу абстрактно без привязки к железу, так что перенос с одного бренда на другой в codesys заключается в copy-paste Поэтому интерфейсы, методы и свойства. Динамическое создание и уничтожение классов при помощи NEW и DELETE я не использую
Maksim
у нас не было ооп, были только объекты и инкапсуляция, никаких наследований и реализаций интерфейсов. Сам доходил. Но было сквозная разработка от механиков и гидравликов в sap'е, а затем портирование motor&component list в генератор объектов, что раньше ручками сами делали. А кревис в текущих реалиях зашел только по скорости обработки, жаль нет данных по наработке на отказ и нет мультипроцессорности. в топовом исполнении для softplc оставалось только одно ядро, что не густо для клети, например.
Ilya
Хорошо только если серийные вещи делаете, пользовали на TwinCAT 3 ооп для машин, которые электронику делают, там было гуд, но - там была модульность, были библиотеки, был plcopen. Если разовые проекты, применение ООП невыгодно, дольше просто будет. А на Западе кто во что горазд, много немцев ооп то пишут, только дичь лютую.
Bogdan
Всегда было интересно - какие преимущества у методов/интерфейсов/свойств перед структурами данных/функциями? Лет 10 занимаюсь ООП ПЛК на ст/сцл и так и не понял сакрального смысла использовать методы/интерфейсы) что с ними можно сделать такого, чего нельзя реализовать используя структуры и функции?)
Alexey
Ну да у нас серийное изделие. Вообще проект крайне простой и был изначально написан на процедурке, но потом ввели санкции и пошла "череда увечий" от которых Альбатрос не страхует. Ну типа был один бренд газоанализатора, стал другой. Причем планирование как обычно совковое - берем любой бренд что есть на складе лишь бы собрать и сдать. Я решил переписать в ООП чтобы меньше времени тратить и уже заранее стал писать блоки под все что есть на рынке Инкапсуляция. У меня один FB тащит в себе все свои данные, функции, методы и т.п.
Bogdan
Разделение файлов проекта по папкам несёт в себе, фактически, ту же функцию (очень многие среды поддерживают разделение на папки внутри ИДЕ).
Alexey
Что касается интерфейса например у Crevis нет FB для работы с RS-485 модулем на шине. Зато в Codesys есть стандартная библиотека работы с COM портом. Шлепаем интерфейс универсальный и пишем драйвер для порта. В конечном счете когда конструктора и закупщики начинают свое задротство с поиском железа или перенос портов, то поменять один порт на другой у меня занимает ровно 1 строчку кода Нет. Функция всегда глобальна Метод может быть Private или Protected
Bogdan
Это то понятно, Но что это даёт? Программист сам решает в каком месте использовать функцию - сделать ее глобальной для нескольких объектов, или же только в одном месте.
Aleksandr
3 часа только что потыкал интерфейсы и методы, но особого удобства перед структурами так и не понял
Alexey
Вы путаете функциональный вызов с данными. Метод может возвращать ссылку на структуру данных спрятанную внутрь класса.
Robert
Вы все уже за*Бали, езжайте на Бали. Давайте строго по теме группы
Aleksandr
Да я толком и видосов/мануалов не нашел за эти 3 часа. Просто мое мнение, на основе того что успел понять сам
Alexey
По этой теме приходится прямо по крупицам искать информацию. Я хотел записать пару роликов на YouTube, но реально нет сил для этого
Aleksandr
Было бы неплохо
Bogdan
Вот и я не понял, ещё несколько лет назад, когда начал активно чередовать степ7 и кодесис) вроде функционал какой то они несут - но я все то же самое делаю через структуры/функции/списки переменных (как замена ДБ)
Alexey
Если вы хоть раз сталкивались с требованием передать оригинал проекта, при этом хотите сохранить свою интеллектуальную собственность скрытой от заказчика, то ООП помогает https://help.codesys.com/api-content/2/codesys/3.5.14.0/en/_cds_pragma_attribute_hide_all_locals/
Bogdan
Опять же, за последние 2 года пришлось потестить много различных кодесисоподобных ИДЕ - и во многих из них нет методов/интерфейсов, зато есть структуры и функции. Так что если говорить про кроссплатформенность - то методы и т.п. скорее препятствие, нежели помощь
Alexey
Вот эта прагма скрывает всю начинку вашего блока. Если перенести функции в методы то FB превращается в черный ящик
Bogdan
Как правило, заказчик хочет открытый код... На моей практике не было случаев, чтобы заказчика который просил исходники устроили ты залоченные блоки (на Сименсе предлагал такое)
Alexey
В моем случае платформа codesys, но разное железо. Даже в рамках Codesys некоторые производители изгаляются и допустим пишут свои библиотеки Modbus, а не используют готовые от 3S Как договоритесь. У нас например свой протокол общения с оборудованием и он закрытый
Bogdan
Я исполнитель и в такие дебри стараюсь не влезать больше одного раза) мое дело предложить руководству - а дальше пусть договариваются о чем хотят)
Bogdan
Ну, железо влияет только на обработку входов/выходов. Вернее даже не на обработку, а именно на чтение/запись. Фактически, если вывести это в отдельную функцию(метод) то смена железа приведет к небольшой корректировке одной функции(метода) без остального кода. Поэтому, собственно, и спросил про преимущества) пока что из того что вы перечислили увидел только залочить код - да, прикольно, если такое допускается. Все остальное вроде реализуемо стандартными средствами
Alexey
Входа выхода могут быть на шине как у Crevis или на Modbus-TCP / RTU или CANOpen. Совершенно разный подход Диагностика связи, скорость работы, методы обращения, тайминги, все разное Fb_init используете? Знаете для чего он нужен?
Bogdan
Безусловно для разных источников данных разный подход чтения записи. Но этот момент никак не должен влиять (по моему мнению) на обработку этих данных. Условно говоря - есть функция управления насосом, она опирается на данные сигналов управления/обратной связи. И абсолютно не важно откуда я беру эти данные, если в своей функции я ссылаюсь на одно и то же место. Нет, вообще фб не использую практически - только в очень редких случаях
Alexey
Все именно так. Насосы бывают вкл-выкл, плавного регулирования, звезда-треугольник. Использование интерфейса помогает работать с насосом как устройством не вдаваясь в детали А у меня весь проект только из них состоит Надо всеж видосик записать какой-нибудь Шоб глубинарии из хрущей крысой не обзывали
Bogdan
Роль интерфейса выполняет пользовательская структура данных, в которой есть все необходимые параметры. Например - ссылки на индексы сигналов, если индекс есть - сигнал используется, а далее в зависимости от используемых сигналов определяется тип и способ управления этим насосом. Массив переменных типа этой структуры хранится в глобал списке. Вместо фб использую подпрограммы/функции (в зависимости от среды). Так гораздо удобнее в больших проектах, требующих управления, например, сотней задвижек - просто в цикле прописал вызов функции и всё. Не надо сотню фб прописывать
Alexey
Можно вызывать массив ФБ
Bogdan
Чтобы вызвать фб - надо указать его входы и выходы) как это сделать массивом - плохо представляю. Объявить массив можно, но в теле программы то все равно надо указать какие переменные на входе и какие на выходе
Alexey
Вот видите, а в ООП ничего не надо указывать https://beckhoff-au.teachable.com/courses/1204788/lectures/30170060 Рекомендую посмотреть видео https://beckhoff-au.teachable.com/courses/1204788/lectures/30173203 https://beckhoff-au.teachable.com/courses/coding-bytes-twincat-3/lectures/27390910 Это чтобы получить представление начальное Я вообще не использую входные и выходные переменные
Bogdan
Бегло глянул. В целом, у меня аналогичный функционал реализуется через структуры и функции. Вместо десятка фб и их методов/свойств - одна структура. Глобальное отличие - связь с этой структурой прописывается внутри, а не через методы и свойства.
Berkeman
Массив структур. Индекс динамически меняешь.
Bogdan
Так я примерно об этом же - получается, что все сводится к использованию все тех же структур, которые представляют собой набор заданных свойств.
Berkeman
Йеп, структуры как интерфейсы