Comments 51
Очень любопытно было почитать :)
Интересно, почему патентный поверенный предложил переквалифицировать полезную модель в изобретение. При всём уважении к Вашему труду, доказать критерий изобретательского уровня (т.е., грубо говоря, что для другого специалиста в сфере автоматизации, которому поставили бы аналогичное ТЗ, не было бы очевидно найденное Вами решение) тут будет проблематично. Полезная модель тем и лучше, что этого критерия нет, только новизна.
Предположу, что описание "аппаратно-программного комплекса" оказалось слишком широким для полезной модели, которая должна описывать единое устройство, а не систему из нескольких. Ну и наличие программной части - отдельная история. Тут очень тонкий момент, как на это Роспатент смотрит, и его практика меняется, Ваш поверенный может лучше знать заморочки, актуальные на данный конкретный момент.
По поводу ПЛК и "релейных схем" - ну есть же ПЛК на Linux (да простят меня суровые АСУТПшники, которые считают, что это вообще не ПЛК), Wirenboard тот же. Лучшее из двух миров. Ну и даже в классических ПЛК с языками МЭК есть ST, хотя этот недопаскаль - тоже та ещё боль и страдание :)
хотя этот недопаскаль - тоже та ещё боль и страдание
Всё не так плохо (и даже хорошо) если делать на нём только технологический процесс, а также минимально необходимый апи конфигурации и контроля. Это нижний уровень. А пользовательский интерфейс - верхний уровень со всеми этими дисплеями, менюшками и вебами - делается отдельно на чём удобнее.
Языки ПЛК как раз и заточены на предсказуемую работу в глобальном цикле. Если не прибегать к расширениям, то там отсутствует динамическое выделение памяти и рекурсия, и по большому счёту можно выстрелить себе в ногу только неправильными условиями выхода из локальных циклов (for, while).
Обычные языки программирования слишком много позволяют из коробки. Даже простой Си.
У меня много раз опускались руки после проявления очередных багов. Много экспериментировал, менял библиотеки и их настройки, оптимизировал работу с памятью, уменьшал частоту опроса там где можно. Ну и Chat GPT в некоторые моменты помогал, получилось улучшить некоторые участки кода.
ПЛК удобны тем, что уже из коробки есть развязки, защиты, много свободных портов и есть удобные решения для подключения панели оператора, а не вот это вот всё с программированием экранов TFT.
Так что изучение ПЛК - однозначно следующий шаг.
Всё же гляньте на Wirenboard и аналоги. Все плюсы (развязки, порты, доп. модули, поддержка кучи протоколов из коробки) есть, но программируйте при этом на чём угодно.
Посмотрел, интересно. Годится для мониторинга и диспетчирезации. Но цена опять же как у Siemens. Ну и C++ там не нашёл, только JS-подобный скриптовой язык. А тут важна цена.
Контроллер на ESP32 со всей обвязкой по себестоимсти выходит существенно дешевле.
Другое дело какой-нибудь Kincony A16, но там немного свободных GPIO, которых мне нужно минимум 15
На WB же вполне себе линукс, можно прямо на нём писать.
https://wirenboard.com/wiki/Cpp
Присматриваюсь в ним, нужен контроллер для управления контурами тёплого пола и котлом, а собирать из ESP32 и релюшек уже как-то неохота (хочется чтобы "прикрутил кабели и кодишь и сразу всё красиво выглядит").
Если у нас не атомная станция и в целом не опасный производственный объект, то последствия выстрела в ногу не фатальные. Ну вот в случае пресса из статьи - ну что случится? Пропадёт немного семян или масло прольётся на пол. Ради удовольствия программировать на современном языке можно этот риск принять. Тем более если выбрать не Си, а язык, который сам по себе выстреливанию в ногу препятствует.
А интерфейс удобнее не просто отдельно писать, но и на отдельной машине размещать. Потому как будет у нас завтра не один пресс, а пять штук в ряд - что, на статус каждого, что он делает, отдельно заходить смотреть? А статистику общую собирать и т.п.? Так что тут я делал бы опции - либо, скажем, для одиночного пресса в комплекте простенький одноплатник для UI/веба, либо возможность тот же софт поставить на отдельный сервер и подключить к нему хоть дюжину прессов. Ну и MQTT / OPC UA какой-нибудь, если у заказчика и так SCADA есть под другое оборудование и надо просто интегрировать в неё.
Хорошая идея, думал примерно в таком ключе. Правда, с одноплатниками ещё не работал.
Такая система будет стоить подороже, чем решение для одного аппарата. Можно было бы сделать, если бы была потребность. Но рынка нет. За всё время было только 3 клиента с несколькими прессами, и они заказывали один комплект автоматики для одного пресса. Ну и MQTT тут не нужен, так как процесс отжима масле предполагает какое-то внимание: заложить семена, выпрессовать жмых по окончании. Я сначала реализовал управление через ТГ бот, но в реальности важнее удобство управления - выбор программы, настройка параметров отжима, а не возможность удалённого управления. Хотя оно тоже реализовано в пределах домашней сети.
А вот подключить дисплей HMI, какой-нибудь DWIN со своей системой построения интерфейсов, было бы интересно. Но опять же вопрос цены. Средний маслопресс стоит 170 тыс., и не каждый готов выкладывать ещё за автоматику 36 тыс.
Где это Вы такие дешёвые прессы берёте?.. Посмотрел на Всехинструментах - 50-тонник с электрическим насосом стóит плюс-минус 400, и это без спецбочонков для масла, чисто сам станок. И я бы предположил, что автоматика ещё этак на 100 - совершенно безболезненный для покупателя ценник. А если даже 36 много - то это очень грустно.
Вот тут например https://organicpress.ru/ - цены от 150 тыс. за комплект. Это самые бюджетные, в среднем 180-200 стоит 50-тонник.
И да, это действительно грустно. Многие маслоделы получают гранты, и экономят каждый рубль. За 100 никто автоматику для маслопресса не купит )
Интересно, видимо для масла достаточно менее массивной конструкции, чем для пресса общего назначения.
Ну а кто не готов платить за автоматику - чего же они тогда маслостанции с электронасосами берут? Ручкой-то качать ещё дешевле :) А время у них, видимо, бесплатное, можно сидеть сутками у пресса с секундомером...
Кстати, Вам же прямая дорога с производителями прессов законтрактоваться, чтобы те сразу Вашу автоматику и предлагали как опцию. И им конкуретное преимущество и доп. процент, и Вам расширение рынка сбыта. Ну и можно техподдержку первой линии на производителя пресса скинуть, чтобы тратить время только если правда есть Ваш косяк. Не пробовали?
Конечно, давно сотрудничаю с производителями прессов, они и являются основными заказчиками.
Без автоматики раньше всё прекрасно работало, даже не вручную - маслопресс обычно комплектуется маслостанцией, которая по кнопочке нагнетает давление в гидроцилиндр. Только в процессе отжима нужно жить рядом с этой кнопкой. А мой контроллер к этой кнопочке как раз и подключается, то есть Фиксики нажимают и отпускают кнопочку по алгоритму, заложенному в контроллере.
Процесс оформления заявки и формулы был довольно кропотливым. Для меня это первый опыт, было много странных вещей в описании, но такова сложившаяся практика. Описывался конкретный контроллер, а также пример применения в составе всего комплекса.
И как мне объяснили, ПО патентуется отдельно, быстрее и дешевле.
В общем, сказали что в таком виде могут завернуть, так как по описанию и функционалу тянет скорее на полезное изобретение. Ну и 19 тыр. придётся доплатить пошлину )
Изобретение не "полезное" - оно просто изобретение :) А ПО не патентуется (у нас), на него по факту написания возникает авторское право (которое можно зарегистрировать, но это только красивая бумажка, ни на что не влияющая)
Да, наверное всё-таки имелось ввида авторское право. Смысл его получения в том, чтобы продавать лицензию на своё ПО законным образом.
Ещё позанудствую :) Его не надо "получать" - оно возникает автоматически. И Вы с момента написания софта уже можете законным образом продавать на него лицензии, ничего нигде не регистрируя. Регистрация носит добровольный характер и ничего не гарантирует - точно так же Ваше право может быть оспорено, даже если Вы получите свидетельство в Роспатенте, поскольку, в отличие от патентов, в данном случае Роспатент ничего не проверяет. Так что обычно эти свидетельства получают чтобы повесить на сайт/стену и добавить солидности бизнесу :)
покажите мне "настоящий" ПЛК не на линуксе...
Интересно было почитать, давно не было Ардуино-Лифт :)
Понятно, что сейчас "все так делают", но всё же ожидаешь увидеть какие то минимальные защиты на входах с датчиков, хотя бы RC цепи там и тд. Какое-то разделение цифровых жгутов от силовых, использование сигнальных пар.
Про программную часть думаю ещё кто-то распишет :)
Что даст RC-цепь на входе АЦП? Защиту ставят для кого-то или для чего-то. Сам контроллер и датчик давления запитываются от 12 В, от контроллера идут 2 провода с 12В на вход реле, которое в отдельной коробочке. То есть цифровая часть от силовой разделены, значит человек уже защищён (если не будет лезть куда не следует).
Сам датчик выдаёт до 5В, и через делитель 3.3В подаются на АЦП, которое в свою очередь выполнено в виде модуля. Значит, микроконтроллер тоже защищён )
Я не претендую на законченность конструкции, всегда есть что улучшать.
Когда я сделал всю конструкцию в одном корпусе, там да, и силовая и цифровая часть рядом, и мне это не нравится, в аком корпусе больше не буду делать.
При такой мощной нагрузке паралельно электронному реле ставят обычное реле. Электронное реле срабатывает первым и через контакты механического реле, включившегося через мгновение позже, не будет большого импульсного тока включения. А дальше ток идёт через механическое реле и электронное реле не греется и не требует радиатора.
Как по мне то туда устройство плавного пуска просится. И движку легче и гидроаппаратуре.
А реле и так не греется. Специфика такова, что оно включается на 1-2 секунды 1 раз в несколько минут. Но это в конце цикла. В начале включается чаще, поэтому сразу ставил твердотельное во избежание подгорания контактов электромагнитного реле.
Чем меньше компонентов и соединительных проводов, тем выше надёжность устройства.
Из примерно 50 клиентов 3 раза выходили из строя трвердотелки, но как я писал, в том случае изначально были поставлены некачественные реле с недостаточным номиналом.
И 2 раза выходил из строя датчик давления, после чего поменял поставщика, и брака больше не было.
И 2 раза ломался энкодер. Просто тупо переставал крутиться ) Чем его заменить, так и не нашёл. Разве что тремя кнопками.
Для работы с нагревателями по температуре рекомендую использовать ПИД регулятор
И тут пришлось осваивать C++, который терпеть не мог в универе.
для ESP32 в принципе есть microPython и lua, но я лично не видел чтобы на них делали что то серьезное. под arduino - полно. и главное, работает, как говорится, вопреки "научному" подходу, в т.ч. потому что автор лично, морально и физически заинтересован чтобы оно работало хорошо.
Когда вы основную работу делаете?
Однозначно плюс.
Тоже как-то на местном форму взялся в качестве хобби - контроллер для сушильного шкафа, сушить вещи у работяг. Со слов заказчика шкафы они делают, в шкафу вешалка для одежды и тепловентилятор. работники со смены вернулись, повешали /поставили вещи (обувь, верхняя одежда) как в обычный шкаф, нажали кнопку и нужно 2 часа держать температуру 40 градусов, а потом полчаса только вентилятор.
Из готового куча терморегуляторов в корпусе и задешево, но таких чтобы сразу с таймером или нагрев+вентилятор на тот момент не нашли в принципе.
На атмеге 8 тогда за пару дней плату накидал с двумя семисторами и х строчным дисплеем и кнопками - все на одной плате вместе с питанием. Заказчик испытал сказал что все работает как ему нужно, оплатил.
Но потом пришел и сказал, что начальник просит на ардуино все делать и даже принес сам UNO-1 с шилдом дисплей+кнопки. Вроде как чтобы не заказывать платы, детали, сборку - все это долго и дорого, а собирать из готовых плат! Я его отправил купить пару твердотельных реле си датчик температуры. Написал прошивку для ардуины - даже красиво получилось с конфигурационным меню, настроками там всякими, недельным таймером и т.п. Запаять нужно было только один резистор для работы датчика температуры. Заказчик испытал - сказал что все круто, оплатил.
Потом пришел с вопросом - а не знаешь где-бы корпус красивый задешево с кнопками нормальными, чтобы на шкаф поставить? На этом мы с ним и расстались.
Хорошая история! Только красивый корпус задёшево скорее трудновыполнимая задача. Если устройство серийное, можно приловчиться, но честно говоря, я от этого подустал немного, довольно сложно устанавливать дисплей, например. Сначала клею пистолетом, потом отмечаю посадочные отверстия, затем на них клею пластиковые стойки, примеряю, выравниваю, только потом модуль с дисплеем прикручиваю.
Хороший корпус с контроллером это уже ПЛК, но это не всегда экономически обосновано.
Есть ПЛК и на ESP32, но там ценник в пару раз дороже того же Siemens 1200.
А какой датчик давления использовали и как подключали?
Я как-то возился с GS01525 и постоянно имел проблемы с тем, что он выдаёт чепуху (то-ли из-за помех, то-ли потому что делаю что-то не так).
Был бы признателен за схему.
Большинство датчиков имеют токовый сигна на выходе (4..20mA), так называемая токовая петля.. если вы подключает такой датчик не правильно, в теории вы можете неправильно интерпретировать его показания.. т.е. по факту вы можете слушать напряжение, а не ток.. может быть из-за этого, и нелинейность краевых характеристик сигнала, что указал автор выше..
По своей сути, большинство датчиков давления, именно 4..20mA, и подключаются они следующим образом к измерителю (как пример):
В другом случае, обычно все подробно указывается в паспорте на датчик.. как запитывается, как подключается, а также могут указываться так называемые коэффициенты нелинейности, которые необходимо учитывать при вычислении действительного значения показаний датчика..
Беру такие https://aliexpress.ru/item/1005005565265491.html?sku_id=12000033571337738
Эх, дорожают, когда-то за 2300 покупал.
Недёшево, зато надёжные и точные, и брак не обнаружил, купил у этого селлера штук 30-40, не меньше.
Питание 12В, выход 0-5В
Очень похожи на Овен ПД100, которые я использую для воды (и тоже доволен, но они ещё раза в 2 дороже, если не поймать на Авито за полцены "остатки с проектов"). Но Овен вроде реально сами делают, а не перемаркировывают китайцев.
И тоже есть в исполнении 4...20 мА, что мне куда больше 0...5 В нравится. Сохраню на случай, если при очередной потребности дешёвых Овенов не найду.
Да, похоже на то. Только в доке не нашёл время отклика, это важный параметр. У китайских менее 8 мс
Я бывал на выставках, посвящённых автоматизации, видел отечественные датчики давления. Дороже, да, но зато подойдёт тем, кто должен с НДС закупать.
Насчёт времени отклика Вы меня озадачили. Чисто физически - это же абсолютно аналоговая система, где все изменения передаются мгновенно. Измеряемая среда давит на мембрану датчика, та давит на тензорезисторы, изменяя их сопротивление, что в свою очередь приводит к изменению силы тока в петле. Задержка здесь может взяться только из-за того, как наш контроллер опрашивает свой аналоговый вход, и от датчика никак не зависит. Или я чего-то не понимаю?
Спасибо! Попробую
Прочитал с большим интересом! Спасибо за статью!
Об АЦП ЕСП32. Он действительно далеко не идеальный и имеет участок нечувствительности внизу и полку вверху и заметную нелинейность.
1. Нелинейность купируется использованием функции analogReadMilliVolts, которая купирует нелинейность АЦП.
2. Полка сверху купируется уменьшением допустимого напряжения с 3.3 до 2.9 или сколько там в мануале описано, т.е. входной делитель надо рассчитать в предположении, что 5 вольт переходят в 2.9 вольта.
3. Зона нечувствительности внизу либо игнорируется (это зона неинтересных очень малых давлений), либо, если уж безумно хочется таки видеть эти участки - подпереть сигнал на эти 150-200 милливольт. Для этого я земляной провод датчика подсоединял не к земле, а к выводу одного их ЦАПов. Записывал нужное число в ЦАП, так чтобы на выходе ЦАПа были нужные 150-200 милливольт.
И о точности измерений и нужности АЦП на 14 бит... Мне инженерно-интуитивно кажется, что точность аналогового датчика с учетом нестабильностей питания и наводок на соединяющие провода - вряд ли более 8 бит... Использование ADS1115 явно избыточно. Точности АЦП ЕСП32 реально вполне достаточно.
Здесь ADS1115 успешно применяют с тремя датчиками давления https://github.com/anas-ivs/ESPHome-Water-Meter
Спасибо, попробую!
Автоматизация процессов в гидравлических системах