Мы хотели сократить время разработки, чтобы снизить для клиентов стоимость автоматизации их устройств. Как это связано со снижением цен на цифровую электронику за последние 40 лет. Ниже описаны наши мотивы, страдания и их результат.
Мы – это команда разработчиков, которая производит разнообразную электронику для автоматизации. Очень разную. Это и профессиональные холодильники, и бассейны и мини химзаводы и разные другие устройства АСУ ТП, которые выпускаются малыми сериями. Автоматизация обычно идет двумя путями. Первый - это создание одного специализированного набора управляющей электроники, который заказчик будет устанавливать в свое устройство. Заказчик дает ТЗ, по которому и производится разработка. Устройство получается уникальным и при большом тираже дешевым потому, что никаких лишних функций оно не содержит, ничего кроме управляющего контроллера и нужной периферии. Второй путь – это использование свободно программируемых контроллеров, которые через шину работают с периферийными устройствами.
Если устройство будет выпускаться большим тиражом, то путь выпуска специализированной платы выгоден. Стоимость разработки в этом случае высока, но сами устройства получаются дешевыми.
Ну а если заказчик не знает какой будет тираж? Или до конца не уверен во всех функциях своего изделия? Ответ давно известен – применение свободно программируемых контроллеров разных производителей. OMRON, Schneider Electric, HITACHI и множество других фирм выпускают контроллеры, а другие фирмы выпускают датчики, управляющие устройства и другую периферию. Наиболее популярный в мире протокол для связи контроллеров и периферии на сегодня это MODBUS RTU. Википедия утверждает, что стандарт этого протокола был утвержден в 1979 году. В том далеком году цифровая техника стоила крайне дорого и существенных денег стоил каждый бит памяти. А вот аналоговые устройства были дешевы.
Для чего был придуман протокол MODBUS? Для обмена данными между устройствами, обеспечивающими автоматизацию технологических процессов. 40 лет назад речь не шла даже о мегабайтах памяти. Первый IBM PC с гибкими дискетами на 300 кБ появился только через пару лет. И вот как результат тогдашних цен на память и появился этот и поныне самый популярный в мире протокол. Его еще именуют полевой шиной, так как эта шина как бы связывает устройства, находящиеся «в поле» с главным устройством управления.
Мы, как команда разработчиков с опытом в десятки лет, конечно всегда стремимся идти по наиболее технически и экономически выгодному варианту. Нету никакого пафоса и гордости в том, что бы вместо применения комбинации готовых устройств, доступных на рынке с некоторой долей программирования взять и начать собственную разработку. Отладку аппаратной части и написание своих собственных программ. Заказчику же важно соотношение цена/качество или цена/время. У него нет желания потренировать наше знание схемотехники.
Ну и конечно мы неоднократно пробовали вместо собственной разработки использовать готовые свободно программируемые контроллеры. И каждый раз оказывалось, что все не так просто и быстро, как хотелось бы. Сами контроллеры устроены достаточно просто. Но уже первая с ними проблема – отсутствие единой среды программирования и вообще само их программирование на уровне соединения реле, катушек и контактов. Вот например OMRON программируется на языке LD. Или ST. А Schneider Electric имеет свою среду программирования EcoStruxure Machine Expert. Carel тоже имеет свой 1tool.
Каждый производитель стремиться максимально затруднить переход проектировщиков и разработчиков с его оборудования на любое другое. Но поскольку выпустить все, что может понадобиться из периферийных устройств, не может пока ни один производитель, то все они вынуждены все же иметь способы подключения сторонних устройств. Это как я уже писал – протокол MODBUS в его версии MODBUS RTU. Существуют и другие протоколы и полевые шины, такие как CAN, FIELDBUS, PROFIBUS, которые бывают или открытые или частные.
Но даже если отбросить несовместимость сред программирования, все эти протоколы обмена объединяет одно – необходимость работать с битами и регистрами. Причина тому проста – старость протокола. В те годы, когда самый популярный протокол MODBUS RTU был разработан, нормой было работать с битами и регистрами.
Представьте себе, что в 2020 году вам предложили начать программировать в кодах. Даже не в ассемблере, а прямо в кодах и регистрах. Нет никаких библиотек высокого уровня. Нет никакого объектного программирования. Вы не можете программировать на С++ и вообще ни на чем кроме переключателя регистров.
Давайте представим простую систему.
На шине стоит контроллер. К ней подключен термометр в помещении с адресом 01 и к ней же подключен мотор управления форточкой на адресе 02.
Вам надо узнавать какая температура и, если жарко, открывать форточку.
Пример №1
Используем библиотечную функцию от термометра GetTemperature(int Addr) и такую же библиотечную функцию от привода открывания окна OpenWindow(int Addr,int Percent);
if (GetTemperature(01)>24) {OpenWindow(02,20);};
if (GetTemperature(01)>30) {OpenWindow(02,40);};
Мы в программе можем просто запросить у устройства на адресе #01 температуру и потом дать команду другому устройству на адресе #02 на сколько процентов открыть окно.
Пример №2
Те же термометр и привод открывания окна. Но оба устройства «совместимы с MODBUS RTU»
Вы читаете документацию к термометру и приводу и проделываете примерно следующее:
Если вы хотите прочитать значение аналогового вывода, то надо послать команду 0x03. К вам придет PDU. Протокол Дата Юнит. А далее надо вынуть нужную вам информацию.
Что бы ее получить надо как-то понять вот этот текст, который взят со страницы
https://ipc2u.ru/articles/prostye-resheniya/modbus-rtu/#read_analog_out:
Данные в модуле хранятся в 4 таблицах. Две таблицы доступны только для чтения и две для чтения-записи. В каждой таблице помещается 9999 значений. В сообщении Modbus используется адрес регистра.Например, первый регистр AO Holding Register, имеет номер 40001, но его адрес равен 0000. Разница между этими двумя величинами есть смещение offset. Каждая таблица имеет свое смещение, соответственно: 1, 10001, 30001 и 40001. Ниже приведен пример запроса Modbus RTU для получения значения аналогового выхода (holding registers) из регистров от #40108 до 40110 с адресом устройства 17.
Помните чуть выше в примере №1 было как-то все сильно проще? Библиотечная функция просто сразу возвращала физическую величину из устройства, которое имеет свой адрес на шине.
Откуда же такая разница? Корень этой разницы лежит в разницы цены на 1 бит информации в 1970 году и в 2020. Сегодня биты и такты микропроцессоров подешевели в тысячи раз. В 1970 году они стоили настолько дорого, что вся обработка данных от цифровых датчиков и происходила на стороне центрального контроллера. Или даже центрального процессора. Аналоговые устройства на шине не могли обрабатывать данные потому, что это было слишком дорого. Вся обработка данных происходила на стороне Master. Поскольку он обладал наиболее мощной для тех времен вычислительной способностью.
Аналоговые устройства стоили относительно цифровых в 1970 году радикально дешевле. Но в 2020 году ситуация стала абсолютно обратной. 32-х разрядный чип с кучей периферии, с АЦП и таймерами, 4 UART, SPI и прочими интерфейсами стоит всего 200 рублей.
Что нам дает такое переворачивание пропорций цен на «цифру» и «аналог»? Теперь мы можем практически не увеличив цену датчиков и исполнительных устройств поручить им еще и перевод своих внутренних данных в понятные человеку физические величины и вообще перейти от работы с регистрами к работе с данными в нужном нам формате.
Хотите данные с часов реального времени? Ну так ясно же, что самый удобный и быстрый вариант получения его это библиотечная функция GetTime(int Addr), из библиотеки, которая вам выдается при покупке этих часов. Вам надо узнать частоту вращения вала двигателя от цифрового датчика? GetMotorSpeed(int Addr).
Снижение цен на микроконтроллеры дало возможность перенести цифровую обработку на сторону самого устройства на шине. Оно на сегодня без удорожания может обслуживать самые сложные протоколы.
Надо было дать имя наследнику MODBUS RTU.
Intellectual Digital Bus – idiBus
Это шина типа Master-Slave, как и ее предок – MODBUS RTU
Физический уровень сохранился и это RS-485. Но на современном уровне развития электроники скорость этого соединения уже может быть 10 МБ/с.
Какие еще возможности появились в связи с новым соотношением цен digital/analog?
Шифрование. В эпоху, когда злонамеренные лица могут пытаться нарушить работу предприятий, систем или оборудования уже неприлично передавать по шине нешифрованные данные.
Обновление прошивок по шине. Аналоговые устройства не обновлялись. Как можно обновить термопару? Но сегодня разработчики уже произведенных устройств могут увеличивать их точность, добавлять сервисные функции и они хотели бы иметь возможность загружать в свои устройства обновления, не отключая их от шины и не демонтируя. idiBus дает такую возможность.
Одновременное считывание показаний и одновременное включение устройств. На шине idiBusопрашивание устройств последовательное. Но если нужно в разных местах одновременно произвести замер неких величин, то можно объединить устройства в общую логическую группу и затем дать всей группе команду на считывание. Точно также можно давать команду на исполнение. Ну например открыть одновременно все ворота на ипподроме.
Внеочередное обращение к Master. В протоколе имеется временное окно, в которое может обратится Slaveк Мaster, сообщив об экстренной ситуации. Каждое из устройств на шине может прервать последовательность опроса и обратить внимание на себя.
Спящий и безопасный режим. Экономия энергии может достигаться отключением аналоговой части устройств на шине и сохранения только функций обмена. На сегодня экономия энергии это популярный тренд.
Обратная совместимость с MODBUS RTU. Устройства idiBus могут находиться на одной физической шине с устройствами MODBUS RTU и Master idiBus может к ним обращаться.
Стандартная обработка ошибок передачи данных. Существенно более продвинутая, чем в древних протоколах.
Задачей создания новой шины и нового протокола была экономия средств на разработку. В России к нашему общему сожалению не производятся сверх массовые простые устройства. Технологический уровень страны более приспособлен к выпуску не больших партий более дорогих устройств, чем простая микроволновка или стиральная машина. Малые тиражи выпуска техники требуют от разработчиков их систем управления максимального снижения цены и сроков именно разработки. Больше половины стоимости разработки станка/бетономешалки/крана/лифта составляют затраты на программирование.
То есть на программистов. Политика крупных вендоров на предотвращение стандартизации и унификации привела к тому, что программисты, имеющие опыт работы с конкретными средствами разработки конкретных вендоров стоят дорого. И их мало. Поэтому и стоят они дорого.
Наша подход заключается в том, что надо дать возможность программирования на универсальных языках программирования. Прежде всего на С++, так как этому языку обучают сегодня во всех школах и ВУЗах. Это наиболее популярный язык и он имеет самый широкий круг программистов. И этот фактор определяет их цену и доступность – самую лучшую на сегодняшнем рынке программирования.
Набор стандартных библиотек для устройств шины idiBus для C++ обеспечивает еще одно важное качество – отсутствие необходимости программисту иметь знания и опыт работы с микроконтроллерами. Он просто работает с библиотеками от конечных устройств. С физическими величинами. Достаточно указать адрес на шине и установить этот адрес на самом устройстве.
Для еще большего расширения возможного круга программистов мы даже обеспечили совместимость с ARDUINO. А это означает, что любой школьник после кружка робототехники уже может приступать к профессиональной деятельности в качестве разработчика системы АСУТП.
После нескольких лет изысканий наследник MODBUS RTU был разработан и испытан прямо на себе. На устройствах шины idiBus мы разработали установку для производства дезинфекционного состава за 4 недели. Конечно никакая индивидуальная разработка за такое время сделана быть не может. Следующим устройством был профессиональный шкаф акустической заморозки. Время разработки до серийного внедрения – 2 недели.
Добавим еще факт, что разработчиками выступали студенты старших курсов МИЭТ. Откуда такие скорости разработки? Готовые отлаженные библиотеки вообще не требуют знания о периферийном устройстве. Никаких чтений мануалов. Никаких изучений регистров и портов. Просто #inclule и GetData(int Addr).
У самой шины есть и другие плюсы, которые обусловлены тем, что 2022 год это не 1970. В отличие от одной линии MODBUS RTU, idiBus имеет на шине две одинаковые линии RS-485. Каждая из которых может работать с разной скоростью. При скорости 115200 Бит/с дальность связи составит 1,2 км. А при скорости 10 МБит/с – 10метров. Таким образом скоростной вариант можно использовать для работы внутри устройства или установки, а более медленный для работы в масштабе предприятия.
Приглашаем разработчиков к соучастию
Разработав новую современную версию MODBUS мы обнаружили еще один интересный момент в жизни автоматизаторов и разработчиков АСУ ТП. Это все больший отрыв крупных игроков – производителей свободно программируемых контроллеров и всяких устройств автоматизации от тенденций в развитии языков программирования.
Россия как член МЭК – международной энергетической комиссии ввела стандарт МЭК 61784-1:2014 «Промышленные сети. Профили. Часть 1. Профили полевых шин» (IEC 61784-1:2014 «Industrial communication networks — Profiles — Part 1: Fieldbus profiles», IDT).
Как вы думаете, как много компаний в России, кто в курсе, что это за такой стандарт на полевые шины? И есть второй не менее интересный вопрос. А что там с языком программирования устройств для этих полевых шин?
А вот что. Стандарт описывает этот самый язык. Который у нас никому не ведом. И в Иране. И в Африке и в Китае и вообще много где.
Вот цитата из описания «Techno IL это простейший язык мнемонических инструкций, внешне напоминающий ассемблер. Этот язык был включен в стандарт для программирования контроллеров, обладающих низкой вычислительной мощностью.»
Кажется странным, что для каких-то таких задач включить выключить свет и газ требуется один язык программирования, а что бы решить задачу автоматизации мобильного телефона или научных расчетов требуется другой. А в школе и ВУЗе все изучают третий и четвертый.
По нашему убеждению, все большее усложнение языков для АСУ ТП просто приводит их постепенно к некоему подобию старых добрых универсальных языков программирования.
А тем временем уже невозможно найти микроконтроллер, у которого настолько низкая вычислительная мощность, что он не может провернуть программу на С++. Разве что кто-то выпустит микроконтроллер только с двумя ножками – питание и земля.
Сначала в языках АСУ ТП стандарта МЭК не было процедур. Они появились.
Не было объектов и наследования. Вот оно уже на пороге.
Еще немного и все эти недоязыки достигнут уровня C++, Rust или Python и перестанут выглядеть как «простейший язык мнемонических инструкций, внешне напоминающий ассемблер».
Есть еще один важный вопрос, который стоит перед разработчиком нового протокола – это его надежность. Насколько долго может работать протокол без перезагрузки и как он реагирует на появление на шине дефектных устройств.
За 2 года применения idiBus в двух видах установок не было случаев критических сбоев именно по причине дефектов логики протокола. При том, что эти установки работали в разных странах и возможности загрузить новые прошивки мы не имели.
Заключительные слова коллегам - разработчикам устройств автоматизации. О чем мы думаем глядя в будущее.
У нас было два пути, а теперь появился третий. Россия не является производителем и экспортером именно устройств автоматизации. Дисплеев, контроллеров, датчиков, двигателей и наши производители и производства всегда ориентировались на импорт. Россию просто оккупировали Омроны и Шнайдеры. И нам нечего было им противопоставить ввиду существенной раздробленности наших рядов.
Но их старая парадигма и старые протоколы с массой уже выпущеных на рынок устройств могут сыграть нам на руку. Мы можем от их почти аналоговых и почти ассемблерных контроллеров сразу перейти в цифровую эпоху и к цифровому протоколу, радикально упрощающему и удешевляющему время разработки.
Физическая среда протокола idiBus
Новые провода и разъемы мы не изобретали, а взяли максимально доступные на рынке. Это кабель Cat5 и разъемы RJ-45 от кабельной системы Ethernet. Кроме дешевизны есть и еще одно преимущество у этого решения - наличие большого ассортимента patch проводов, которые очень удобно использовать для межплатного соединения.
Спецификация распайки перед вами. Питание передается сразу по линии и 24 вольта взяты для того, что бы по мере удаления от источника питания можно было получить на больших расстояниях стандартные 12 вольт путем установки понижающего DC/DC.
Парные провода питания и земли дают снижение сопротивления на линии питания. Линии 4 и 5 это буквально физическая совместимость с предшественником MODBUS RTU на тех устройствах, на которых стоят разъемы RJ-45. Это наиболее популярный в мире вариант распайки. Скорости указаны условно. Но они не могут быть любыми. Для idiBus выбрали фиксированный набор скоростей, которые могут быть получены применением популярных частот кварцевых резонаторов.
На каждом устройстве предусматривается выбор скорости. Тройным переключателем S2-S1-S0. Великое многообразие вариантов как мы сегодня знаем вообще не требуется. Обычно всем нужен простой набор. В нашем варианте всего 8 скоростей.
Еще один вид стандартизации - размеры плат и расположения монтажных отверстий
Разработчики протоколов ранее не утруждали себя спецификациями геометрии устройств. Каждый крупный производитель имел свой собственный геометрический формат и собственные межплатные разъемы и их расположение. Мы предполагаем, что для общего удобства необходимо дать варианты спецификаций, придерживаясь которых возможно совмещать устройства разных производителей, не имея нужды гадать при разработке своего устройства, будет ли оно совместимо при установке в корпуса приборов и установок или не будет.
Мировая практика показывает, что обычно для АСУ ТП используются три размерны формата. Компактный формат в собственном корпусе для установки на DIN рейку, крупные собственные корпуса для установки вне корпусов установок и третий формат без корпусной. Его стараются избегать.
Глядя на все это и на условия существования наших электронщиков мы решили начать с бескорпусного стандартного формата. Причины этому две. Первая - цена. Плата без корпуса дешевле и когда оборудование устанавливается в корпус устройства или установки, то в сущности корпуса это лишний элемент. Вторая причина это цена корпусов, Увы, Россия это не Китай. При том, что технологически мы уже все можем выпускать печатные платы нужных размеров, мы не можем дешево заказать корпуса. Это всеобщая проблема России - отсутствие индустриальной среды. Наши мелкосерийные производства не могут себе позволить заказать пластиковый корпус, потому что одна пресс форма стоит не менее 500 тыс рублей. И рассчитана она на 100 тысяч копий. А зачем нам 100 тысяч копий? Никто даже не мечтает от таких тиражах устройств AСУ ТП.
Именно поэтому мы выбрали для старта спецификацию без корпусов. Независимые платы привязаны к сетке размера 12х12 см. На основной материнской плате, которая является Master в качестве мезонина устанавливается плата с основным микроконтроллером. И еще есть платы расширения, которые обеспечивают связь, и на которые можно устанавливать платы расширения тоже в качестве мезонинов. На этих платах расширения не нужно ставить микросхемы для работы с RS-485. Интерфейс и выбор скорости обеспечивает плата расширения.
Вот пример нашей "материнской платы" и платы с управляющим чипом:
Размерный ряд плат предусматривают монтаж в виде послойного пирога. Для этого стандартизированы монтажные отверстия. Межплатные соединения используют самые дешевые на рынке разъемы, а фиксацию от вибрации сделали лавсановыми стойками.
Натягивание одеяла на себя или возможность для многих?
Предлагаем всем соучастие и создание национальной системы цифровой автоматизации на базе нашей разработки idiBus, спецификация которого будет бесплатна для всех желающих. Мы пока не думаем о idiBus foundation, но российский рынок не на столько велик, что бы мы могли позволить себе не объединяться на российской открытой платформе.
Дмитрий Балаболин,
Сергей Слепнев
Радиоинженеры,
разработчики электроники
Комментарии (116)
dbalabolin Автор
14.11.2023 14:42-3Если бы в РФ были хоть какие-то свои стандарты, так можно было бы об этом поговорить. Но на сегодня нет даже русского перевода все этого добра от МЭК. А английский оригинал имеет буквально несколько фирм. Так что цифра 14 на сегодня это фактически ноль.
Второй важный аргумент и он важнее всех остальных. Цифровые устройства настолько дешевы, что перенос всех вычислений на сторону устройств на шине вообще ничего не стоит. Но позволяет нанимать буквально любого человека, знающего С++ вместо знатоков проприетарных протоколов. Особенно в те времена, когда устройства сами уже не поставляются.
NutsUnderline
14.11.2023 14:42+7ноне эти речи почти крамольные ;) Назовем тогда и Вашу разработку словом "поделие", и будет их, да не 14, а 114 потому что каждая фирмочка изобретает свое че то, и в общем то главное чтобы работало со своим оборудованием, а чужого никто и не обещал.
Обращает на себя внимание эта Ваша реакция: коллеги (конкуренты?) из WirenBoard на 14 стандартов отреагировали совсем по другому.
dbalabolin Автор
14.11.2023 14:42-5Не хотите свои разработки назвать "поделие"? Поясню свою мысль. Наши изделия установлены уже в реальное оборудование, которое экспортировано в 28 стран. А ваша "фирмочка" что-то уже продала немцам, американцам, итальянцам и прочим? Ну мне чисто любопытно откуда берется такой снобизм и основание давать такие характеристики?
NutsUnderline
14.11.2023 14:42+1Моя фирмочка? Спасибо, звучит интересно. Я в общем то конечный пользователь, которому 114 "стандартов" (хотя Вы же сами отказались таковыми признавать) портят кровь когда нужно скрестить ужа с ежом и чтобы все работало. До абсудра же доходит (реальный случай): в новом поколении оборудования взяли и инвертировали бит статуса в одном модуле c modbus. Сам станок старый, центральный соф никто пилить не будут, а предлгают костыль, за хорошие такие деньги. Это разве не поделие?
dbalabolin Автор
14.11.2023 14:42Ну "ваша" это означает где вы работаете. Ну так что вам как пользователю не нравится? что есть новый стандарт и устройства к нему? Или что система так устроена, что любой школьник может с ней работать имея багаж кружка робототехники?
Нет задачи заставить всех создавать паровозы. Наоборот. Есть задача создать такой паровоз на котором любой ребенок может кататься.
"Поделие" вовсю работает и не ломается.NutsUnderline
14.11.2023 14:42+1пока что создают паровозы которые умеет водить 1 механик на паровозном заводе. И да на нем катается ребенок. Но вот только они еще как ломаются, дети ведь все могут сломать. И бегут к "папа почини". Отрывается паравоз а там все внутри сделано из палок
MiraclePtr
14.11.2023 14:42+12Это все в принципе интересно, очень многие развлекаются подобными "расширениями" и "обновлениями" модбаса, и в итоге все получается в точности как на картинке в комментарии выше: куча разных "улучшенных" ни с чем не совместимых протоколов. Ваш - очередной из них.
Но, честно говоря, во вступлении аргументы вообще высосаны из пальца, а именно:
Вы читаете документацию к термометру и приводу и проделываете примерно следующее.
Помните чуть выше в примере №1 было как-то все сильно проще? Библиотечная функция просто сразу возвращала физическую величину из устройства, которое имеет свой адрес на шине.
То есть в первом случае вы читаете значение из устройства по известному адресу, а во втором случае, с модбасом, вам якобы надо парсить вручную заголовки и побайтово собирать значение... Ну буллшит же. Уже три десятка лет как почти под все популярные языки программирования есть готовые библиотеки модбас-клиентов и модбас-серверов. Не надо ничего плясать, просто делаете что-то типа modbus_get_float(....), указывая адрес устройства, адрес нужного вам параметра и тип данных, и получаете на выходе сразу нужное и правильно преобразованное значение.
garageman
14.11.2023 14:42+6Давным-давно уже даже не просто библиотеки существуют а целые сервера, которые раскладывают значения регистров, собирая при необходимости (многобайтное значение) в целевое в MQTT, например. И вся работа со значениями сводится с "прочитать топик" и "записать топик".
Вот modbus slave на ардуинке. И ее производительности достаточно для подавляющего большиства задач домашней автоматизации: https://support.wirenboard.com/t/druzhim-wirenboard-s-arduino-slave-po-modbus/9034dbalabolin Автор
14.11.2023 14:42-1Да аруинко вообще отличная вещь. Я про саму среду.
Но хочу сказать про всякие датчики. Имеется много разных устройств и датчиков, которые НЕ MODBUS. Они 0-10В, 4-20мА, 1Wire и прочие интерфейсы. В нашем случаем имеется модуль интерфейса, который уже имеет все фунции протокола. И мы берем и добавляем поверх готовой библиотеки только ту часть, которая из этих интерфейсов делает сразу физические величины. Ну или команды если это что-то командное. И такие все цифро-аналоговые датчики типа той же термопары становятся цифровыми устройствами на шине. Вся базовая часть протокола уже написана. Остается кусочек дописать и залить прошивку в готовый уже интерфейсный модуль,garageman
14.11.2023 14:42Вот для той же ардуинки из ссылки. Это готовый шаблон, который позволяет настраивать записью в регистры параметры связи (скрость, стопбиты, modbus id).
Дописать в него работу с 1wire (одним датчиком на шине) - примерно десять строчек.
С 0-10 так же. Для 4-20 - добавляем резистор в 200 Ом.
Цена в рублях получается ~600, из которых 200 -ардуинка, 200 - плата и разъемы 150 - компоненты типа dc-dc преобразователя.У меня например дальномер так сделан.
Mitya78
14.11.2023 14:42Если по деньгам не жмёт, то можно и конверторы ставить.
В наших проектах используем Moxa, вешаем весь зоопарк по Модбас, дальше уже к Сименсу завожу как Профинет.
Очень удобно, вообще не надо ни о чём думать.
dbalabolin Автор
14.11.2023 14:42-3Вы видимо не все прочли коли советуете библиотеки для протокола. Речь идет о библиотеках для устройств на шине. А я их что-то не наблюдаю пока. Вот к примеру мне надо вентилятор подключить через популярный частотник DANFOSS FC-51. Не подскажете где мне взять такую библиотеку, что бы задать скорость 80 процентов от Максимума? Думаю нигде их нет. А включить два насоса одновременно? одной командой?
Или вам надо податься в экосистему DANFOSS если ее достаточно и цены устраивают или открывать документацию и приступать к изучению регистров и к отладке. Мы же не о серии говорим а о разработке.
Ну и передача огромного числа регистров не добавляет скорости обмена.garageman
14.11.2023 14:42Вот: https://wirenboard.com/wiki/Danfoss_VLT_Microdrive_FC51
Выбираем в веб-интерфейсе из списка - профик. Все параметры доступны для работы через MQTT и тот же веб-интерфейс.
Хоть по http управляй.
Markscheider
14.11.2023 14:42+3Разве что кто-то выпустит микроконтроллер только с двумя ножками – питание и земля.
Разработчик беспроводных Wi-Fi датчиков:
- Подержи мое пиво!
igorts
14.11.2023 14:42+5Modbus это протокол доступа к адресуемым регистрам памяти устройства, Modbus RTU обеспечивает контроль передаваемых данных путем передачи контрольной суммы данных в каждом пакете. Более простого протокола сложно придумать.
Не совсем понял необходимости прикручивать еще одного протокола для работы по последовательным каналам связи.
garageman
14.11.2023 14:42+6Кто хочет делать - делает, для этго не нужны никакие "национальные системы". Как пример: https://habr.com/ru/companies/wirenboard/articles/772308/
dbalabolin Автор
14.11.2023 14:42-4Ну тема известная. Приведу одну цитату из этого источника "долгий период опроса одного регистра в устройстве — если на шине много устройств и в каждом по паре сотен регистров, то в зависимости от скорости и расположения регистров, пауза между опросами одного и того же регистра может достигать нескольких секунд. Это в конечном счёте приводит к медленной реакции системы."
Так что для химзавода это не вариант - опрос ОДНОГО Регистра за несколько секунд,
У нас все регистры уже опрошены еще внутри самого устройства и время ответа не зависит ни от чего кроме как просто количества устройств на линии. И оно не умножается на количество регистров.
А необходимости в что-то типа DHCP в приборах нет. Все это нужно для технологического оборудования а оно обычно не не работает в режиме горячего подключения устройств.
wofs
14.11.2023 14:42+4Приведу одну цитату из этого источника
Это о проблеме Modbus RTU речь.
Так что для химзавода это не вариант - опрос ОДНОГО Регистра за несколько секунд,
Ну на самом деле, смотря что там делать. Если рулить химустановкой — это одно, а если всем, кроме неё, то и 10 секунд задержки не проблема.
У нас все регистры уже опрошены еще внутри самого устройства и время ответа не зависит ни от чего кроме как просто количества устройств на линии. И оно не умножается на количество регистров.
Это вы всё ещё рассказываете о преимуществах вашего решения перед Modbus RTU — это отлично! Где можно почитать описание протокола?
dbalabolin Автор
14.11.2023 14:42-5Можно черкнуть письмо на info@idibus.com, представиться и получить документацию. И описание готовых примеров.
dbalabolin Автор
14.11.2023 14:42-2Разница в том, что от проектировщика/программиста скрыто вообще само существование регистров или какие-либо детали устройства. Производитель выдает готовую библиотеку и можно сразу работать с функциями минуя стадию разбиения данных на регистры и адреса сдвигов.
Технически можно написать библиотеки на сторону мастера. к тем же самым устройствам Modbus. И надеть эту оболочку поверх самого протокола связи. Но это решает одну проблему и создает другую - канал забивается трафиком передачи адресов и значений регистров вместо того что бы сразу получить нужные данные в нужном формате. Я уже не говорю о шифровании трафика и о возможности заливать новые прошивки, это будет вечной операцией на MODBUS. Фреймы мелкие и данные мелкие. Это как копировать на дискету тысячи файлов.wofs
14.11.2023 14:42+2...о возможности заливать новые прошивки, это будет вечной операцией на MODBUS. Фреймы мелкие и данные мелкие. Это как копировать на дискету тысячи файлов.
Как-то вы категорично про Modbus говорите. Мы без проблем несколько лет шьём устройства поверх RS-485 и Modbus RTU, пруф: https://github.com/wirenboard/wb-mcu-fw-flasher
dbalabolin Автор
14.11.2023 14:42Так это вы не по ним шьете а поверх. Или я не правильно понял? в idiBus изначально может стоять на шине прибор вообще без прошивки. Только с той частью, что содержит протокол. И можно влить именно по нему прошивку. Причем не прерывая работу самого протокола для всех других устройств.
garageman
14.11.2023 14:42Именно так. В устройстве bootloader который позволяет его прошить. Это уже года 4 как - и устройств таких работают десятки тысяч.
dbalabolin Автор
14.11.2023 14:42Причины изложены в тексте. Основных несколько. Вы когда драйвер принтера ставите то это же драйвер. Все что надо уже есть внутри. Знать внутренние подробности не требуется. Что бы работать сразу с физическими величинами и кодами ошибок вам надо поверх регистрового трафика написать библиотеки и дать их пользователю. Что бы ему не изучать способы извлечения конкретных данных их конкретного прибора или в обратную сторону как ему давать команды. И можно эти библиотеки разместить на стороне мастера, а можно на стороне слейва.
На Мастер можно и ARM поставить для управления и логикой и протоколом. Но регистровый протокол удваивает и утраивает загрузку канала. Я уже не говорю что люди умнеют и исправляют ошибки. А по MODBUS новую прошивку то никак не загрузить.
Таким образом для облегчения труда и сокращения и сроков явно нужны библиотеке. Выбор лишь с какой стороны будет обработка. Мы сложили все факторы и посчитали что уже можно это делать со стороны SLAVE. Нет аргумента по которому выгоднее делать обработку на стороне MASTER.
Есть и еще одна причина. Разработчик конечного устройства на шину всяко лучше знает свое устройство чем разработчик системы. И в как в объектном программировании полезно скрыть от пользователя детали реализации. И также избавить его от трудозатрат на этот процесс.
lamerok
14.11.2023 14:42-4Вся проблема в RS485, питание надо передавать по тем же проводам, что и сигнал, никто не хочет тянуть 4 провода и наблюдать как весь сегмент падает при кз на одном датчик.
Если уж переходить, то на Ethernet APL, и любой протокол поверх, HART IP, ModbusTCP, Profinet, Profibus IP, FielbusIP.
485 это тупик, только зря потратите время и деньги.
igorts
14.11.2023 14:42+1У 485 есть своя ниша, да и гораздо дешевле оборудование, чем для работы с Ethernet и TCP
lamerok
14.11.2023 14:42Есть ниша, но как вы и сказали, это очень нишевая вещь. В ПАЗ системы не поставите, в нормальные управляющие тоже. Так для коммерческого учёта в некритичных системах.
Нужен Real-time Transport Protocol для таких систем управления. Ну либо токовая петля, с возможностью настройки датчиков по ней, например через HART. А 485 вообще для чего нормального то нужен? Для систем управления уровня предприятия, даже заморачиваться с ним не стоит.
P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
Mitya78
14.11.2023 14:42У нас приточки и фанкойлы по Modbus RTU управляются.
Достаточно серьёзно?
lamerok
14.11.2023 14:42-2Нет. Достаточно серьёзно НПЗ, или Тепло электростанция, к примеру. Так для справки, на среднестатистическом НПЗ 100 000 датчиков примерно 600 типов.
Mitya78
14.11.2023 14:42+2У каждого протокола своя область применения.
На конвейер удобно цеплять устройства по ASI, частотник насоса в КНС по Модбас, какой-нибудь шатл по Профинет...
dbalabolin Автор
14.11.2023 14:42-1В нормальные управляющие уже поставили. Это не Realtime система большой дискретизацией. Но управлять оно точно может всем тем для чего используется MODBUS оно может и существенно лучше. И на сегодня MODBUS это максимально популярный протокол
igorts
14.11.2023 14:42еще момент немаловажный, обрыв 485 лечится обычными клеммами, обрыв ethernet уже сложнее
Подключали устройства в шахте, так там даже земли нет и шкафы с контроллерами регулярно перемещают - альтернативы 485 просто нет
lamerok
14.11.2023 14:42А толковая петля, проще же нет вообще ничего, и питание там и сигнал и цифру ещё наложить можно, правда медленную.
igorts
14.11.2023 14:42я потерял нить ваших рассуждений, извините.
dbalabolin Автор
14.11.2023 14:42Токовая петля это интерфейс 4-20 мА. Ток пускают и датчик его регулирует. И поскольку это ток, то оно может на любых расстояниях работать так как ток он один и тот же во всей цепи. Когда дошло до протоколов а не просто замеров тока, то по тем ж проводам пустили еще и переменный ток. И получился протокол HART. Но там частоты такие, что он очень медленный.
https://dzen.ru/a/ZSjeV4NlVBw522z_
dbalabolin Автор
14.11.2023 14:42Ну это уже без нас наложили. Но скорость увы далека от современных норм.
dbalabolin Автор
14.11.2023 14:42-3ПАЗ я уж думал это автобус. При частоте 1Мб и возможности протокола прервать опрос и влезть со своей аварией как раз и можно в отличие от MODBUS где можно много секунд ждать следующего опроса одного следующего регистра. Пакет данных там слишком мелкий. КПД протокола ниже плинтуса
wofs
14.11.2023 14:42+1А 485 вообще для чего нормального то нужен? Для систем управления уровня предприятия, даже заморачиваться с ним не стоит.
Когда я работал в Газпроме на ГПЗ, у нас там по RS-485 соединялись в пределах установки шкафы системы вибромониторинга. От установки до серверной, конечно, шла оптика. Но вот на самой установки RS-485 показывал себя очень-очень хорошо, а источников помех там было предостаточно.
Уровнем ниже, там да — HART или токовая петля, чтобы данные с датчиков собирать.
Siemargl
14.11.2023 14:42+2P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
А еще громадная разница в требованиях к помехозащищенности, питанию и наличию репитеров. Сегмент в 100м vs 1300м например
dbalabolin Автор
14.11.2023 14:42-1проводов в кабеле 8 штук. 4 витые пары. прокладка их несоизмеримо дороже стоимости самого кабеля. В случае 485 репитеры до 1,2 км не требуются. При скорости 115200. Но можно для пущей защиты еще снизить скорость,
В отличие от MODBUS RTU в idiBus доля полезной части протокола выше потому что данные уже сформатированы на стороне slave. Что эквивалентно увеличению скорости.
Физически в кабеле две линии передачи. Но логически это просто две независимые шины
ponikrf
14.11.2023 14:42+1P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
Вы вобще не знаете сколько стоит Ethernet и сколько стоит 485. Зачем вы пишите этот бред. RS-485 стоит раз в 50 дешевле Ethernet. Если вы не согласны предложите мне решение для Ethernet за 20 рублей. Потому что, что бы заработал 485 мне нужен простой драйвер, а что бы заработал Ethernet мне нужно ОЧЕНЬ много. Это касается и программного уровня, так и аппаратного.
dbalabolin Автор
14.11.2023 14:42-1И значительно дешевле и скорость неплохая на сегодня. И в нашем варианте питание подается отдельно. Ибо разницы в цене почти нет по протяжке проводов. Лапшу тянуть или Cat5
wofs
14.11.2023 14:42+1Вся проблема в RS485, питание надо передавать по тем же проводам, что и сигнал, никто не хочет тянуть 4 провода и наблюдать как весь сегмент падает при кз на одном датчик.
Совершенно необязательно. Шина — это 3 провода: A, B и GND для выравнивания потенциалов. Можете локально запитать устройства и объединить GND локального БП с GND шиной.
lamerok
14.11.2023 14:42Сколько устройств вы так запитаете и на какое расстояние сможете передать?
garageman
14.11.2023 14:42+1Закон ома разве отменили? 40 штук, например, на обычной UTP. Две пары - под питание, одна под шину одна - в резерве.
Ну и UTP - не очень и дорог.
dbalabolin Автор
14.11.2023 14:42на тесте было 1,5 км дальность на 115200 и 10 метров при 10Мбит.
Записать можно до 3 ампера тока. При 50 мА на устройство это 60 штук. При 20 мА 150 штук. далее надо добавлять блок поддержки питания.
dbalabolin Автор
14.11.2023 14:42-1Локально конечно можно что угодно питать. Но мы в варианте с контролем питания шины можем применяться во взрывоопасных зонах так как контроль тока с нашей стороны. И можем не усложнять установку если просто на какой-то части устройств на шине не подводить туда еще и 220
fizikdaos
14.11.2023 14:42А есть шины, которые продолжат работать при КЗ на проводах?
lamerok
14.11.2023 14:42Я может неправильно выразился. Но имел ввиду, звмыкание между приёмом и передачей из за разницы потенциалов на устройствах, при использовании разных земель.
fizikdaos
14.11.2023 14:42А есть шины, которые при разных землях работают и без гальванической изоляции?
RS485 так же никто не запрещает оптоизолировать.
lamerok
14.11.2023 14:42Да, но как питание тогда подать по этим же проводам?
fizikdaos
14.11.2023 14:42По линиям A B? никак. Или вы хотите и изоляцию, и питание по проводам от мастера? Блок питания изолирующий можно поставить при желании, но это никогда не нужно на самом деле: если вы запитываете от линии, то и земля общая. Можно нафантазировать, что у вас устройство, которое требует подключение к земле локальной, при этом там сэкономили на изоляции той части которая требует подключения к земле, и вы не можете организовать локальное питание... но это фантазии какие-то, в реальной жизни такого нет.
Sap_ru
14.11.2023 14:42Да. Некоторые разновидности CAN могут работать по однопроводной схеме в качестве аварийного режима, в случа КЗ на одной из линий. Или даже на КЗ шин. Естественно, что нужно правильная схемотехника, чтобы исключить вторичные эффекты и каскадные отказы. Используется во всяких ответственных применениях. При желании и наличии знания повторяется на стандартном CAN при помощи нехитрого и недорого велосипеда.
Для RS-485/422 тоже есть, кстати, отказоустойчивые варианты с работой по одной шине данных.
dbalabolin Автор
14.11.2023 14:42+2Пока 485 тупиком никто не считает кроме вас. Самый популярный интерфейс в приборах на сегодня.
fizikdaos
14.11.2023 14:42+6Если убрать всякое про "русскую национальную систему", поднятие с коленушек и прочее - то был бы интересный студенческий проект.
Goron_Dekar
14.11.2023 14:42+2Если не забыть опубликовать на github.
dbalabolin Автор
14.11.2023 14:42-4нам чужды творения Микрософт.
MiraclePtr
14.11.2023 14:42+1Это не из творения, они его купили спустя много лет после его создания. Да и в любом случае, если не GitHub, то Gitlab, Gitflic - короче, все что угодно, главное чтоб код был открытый и любой его мог изучить и переиспользовать.
dbalabolin Автор
14.11.2023 14:42-2я в курсе. но они имеют тенденцию кого-то выгнать, что-то закрыть и вообще затеять санкции. Это люди из страны агрессора. Поэтому там все российское может прямо завтра пропасть.
dbalabolin Автор
14.11.2023 14:42ясный перец что код будет открытый. готовим документацию и вывалим на какой-то гит
wofs
14.11.2023 14:42+1спецификация которого будет бесплатна для всех желающих
Это хорошо, можно ссылку на спецификацию?
dbalabolin Автор
14.11.2023 14:42-4Можно не ссылку а спецификацию. Надо написать письмо на info@idibus.com, представится и получить спецификацию и примеры.
wofs
14.11.2023 14:42+3То есть это закрытый клуб? Я потом смогу её опубликовать? Или, например, пощупать и написать статью с разбором?
dbalabolin Автор
14.11.2023 14:42-1Открытый клуб) милости просим. Но мы не Хабр и правила можем свои установить. Оно одно и вроде как не злое. Просто просим представиться. И если есть желание написать статью с разбором , то конечно неплохо сравнить с FIELDBUS, PROFIBUS, HART, CAN и самим MODBUS RTU.
Кстати вот ссылка на устройство в котором это все работает: www.aeftrade.eu/a12 - самый продвинутый в мир шкаф для замораживания еды.
И вот тут: www.pradox.info
Уже года три как тестируется.
Мы тут в РФ не можем себе позволить закрытые клубы. Рынок всего 1 процент от мирового и все контроллеры и шины импортные. А тиражи изделий - мелкосерийные. Это вот СВЧ печек китайцы каждой модели выпускают миллионы. А у нас такие тиражи только у счетчиков электричества и воды только.Siemargl
14.11.2023 14:42+3И если есть желание написать статью с разбором , то конечно неплохо сравнить с FIELDBUS, PROFIBUS, HART, CAN и самим MODBUS RTU.
Прежде чем изобретать велосипед, стоило проделать эту работу самостоятельно.
Кстати, перечень существующих протоколов, и их функциональных возможностей, гораздо шире, чем у вас в "возможностях".
Ну и вероятно, протоколы сделаны каждый под свою задачу. А то тут сравнивают НПЗ и фанкойлы =)
dbalabolin Автор
14.11.2023 14:42Прежде чем изобрести велосипед, я вас уверяю были исследованы все имеющиеся тачки, самокаты, велосипеды и протоколы к ним.
И ничего из того что там было полезного не было упущено. Все реализовано или не хуже или лучше. Не сомневайтесь.
Но один взгляд хорошо, а несколько еще лучше.
Главный критерий всего действа - снижение стоимости разработки и стоимости уже готовых изделий. На это нацелена и система плат и система межплатных соединений и кабельная система и питание по кабелю и все остальное тоже.
Взять к примеру всеобразные датчики всего. Они или уже c MODBUS и уже дорогие или 0-10В и дешевые. В нашей версии мы берем модуль 0-10В с четырьмя каналами и подключаем 4 датчика. А не 4 отдельных датчика с MODBUS.
А у всех MODBUS нет стандартного разъема. И стандартной цоколевки, И вот вы уже комбинируете аппаратный зоопарк. Который безусловно гарантирует появление ошибок.
Если все сложить вместе то idiBus в каждом аспекте создания устройства дешевле. А вся сложность устройств на шине переложена на плечи разработчика устройства. Которое лучше него никто не знает. А со стороны АСУ оставлена только логика управления. Каждый занимается своим делом.Siemargl
14.11.2023 14:42+2И ничего из того что там было полезного не было упущено. Все реализовано или не хуже или лучше. Не сомневайтесь.
Неужели?
Навскидку не вижу автоматической синхронизации времени слейвов, отложенной передачи данных (с метками времени) после потери связи, того же комтрейда
dbalabolin Автор
14.11.2023 14:42-2а в слейвах нет времени. вот мы тут все сидим сейчас а где-то проектируют датчик давления. Без времени. Работает по факту запроса.
В базовом протоколе именно поэтому нет синхронизации времени.
Одновременность решена возможностью объединения в группы и отправка групповой команды сразу всем членам группы.
Отложенная передача данных откуда и куда? Если потеря связи то мастер стучит и потом докладывает что не достучался. Это не часть протокола. Это ошибка связи. А отложенной передачи из слейва нет. Есть передача больших пакетов данных (состоящих из более чем одного модуля данных) с подтверждением получения очередного пакета.
Есть в качестве устройства на шине например уже готовый модуль логгирования. Там стоит флешка и часы реального времени.
В нем же можно хранить переводы текстовых значений для кодов ошибок для разных языков. Коды и индексация языков тоже стандартизированы.
Кстати кто такой комтрейд? я приезжий не все слова еще знаю
dbalabolin Автор
14.11.2023 14:42Протокол это некий вид насилия над разработчиком устройства. Возьмем тот же файнкойл с вентилятором который подключен к уже упомянутому частотнику DANFOSS FC-51. А вас есть некая система EMERSON которая имеет MODBUS. Каким образом вы будете ветер регулировать? Начнете читать спецификацию этого конкретного устройства. В котором есть полно всякого не нужного вам мусора. Ибо частотник этот набит функциями которые к вам отношения не имеют. И для вашей, внешней для DANFOSS среды, никаких драйверов не существует. Как говорится "читайте мануал". Но Данфос то хочет что бы вы на него перешли. Ну и вот сиди и разбирайся в документации. И неплохо бы еще и не наделать при этом ошибок.
А вот если DANFOSS некая сила заставит создать отлаженный драйвер (библиотеку), которую можно будет загрузить в EMERSON, то будет красота. Но ее нет и не предвидится.
Мы же решаем задачу унификации и как раз избегаем изобретения велосипеда. а точнее его разработки. Базовый модуль с протоколом уже есть. И он уже все что надо передает и все функции выполняет. Разработчику устройства требуется дописать только то, что относится к его устройству.
Причем даже понимать не надо как устроена транспортная часть.
Производишь датчики с интерфейсом 0-10В ? Минимальные усилия - и ты в цифровой среде idiBus. ЭКОНОМИЯ.Siemargl
14.11.2023 14:42+2Может не стоит лезть в незнакомые понятия? У компании данфосс нет промышленных ПЛК (только климат), потому они наиболее заинтересованы в открытости к сторонним системам.
А о каком Эмерсоне мы говорим? DeltaV, ROC или Ovation (или вновь купленные VersaMax), там все по-разному.
dbalabolin Автор
14.11.2023 14:42-3У меня партнер был 10 лет главным импортером Эмерсона. Теперь вот сложности с импортом.
Мы говорим о том, что данфосс не дает Драйверов. Ибо в мире компов есть линукс яблоко и виндовс. и как-то драйверы люди пишут к этому.
А в мире омронов и эмерсонов даже внутри эмерсонов все по-разному.
Филдбасы придумали новый разъем и новый провод. Который у нас вообще некому произвести.
В РФ явно требуется момент объединения под одну крышу всем.
Рынок наш настолько мал и настолько занят иностранцами, что своего мы никогда не сделаем если не объединимся хотя бы при АСУ хотя бы какой-то большой части устройств.
Пока в РФ никто не готов заменить систему управления вентиляцией очистного здания. Ибо там много устройств.
Можно или уходить к китайцам (корейцы тоже вон санкции устроили) или левый импорт делать.
Но нам больше нравится вариант - откусывать от иностранного АСУ куски в пользу наших разработчиков аппаратуры. и датчиков и Серв и контроллеров.
Наша идея - более простое проектирование с широким кругом программистов на стандартных языках. и более дешевые устройства. совместимость обратная с MODBUS.
Что бы выпустить какие-то датчики давления или влажности или еще чего-то надо и сам датчик и его оцифрить.
Мы даем цифру. Дешево и сердито. И любой студент может программировать все это.
Позже подцепимся к SCADA какому-то открытому.
Если государство довело эту сферу до того, что ни одного ЖК экрана в стране сенсорного не производится и прости господи сотни миллионов тратятся на контроллеры типа "БАГЕТ", то кто-то должен начать процесс объединения национальных разработчиков.
И глупо при этом не воспользоваться тем, что за 40 лет цифра стала такая дешевая, что можно ее в сигареты засовывать.
В РФ промышленное оборудование, которому надо АСУТП всегда малые серии. Рынок такой и никто не умеет ничего экспортировать.
idiBus решает задачу удешевления этой автоматики. От лифтов и станков до теплиц и бетономешалок.
fizikdaos
14.11.2023 14:42+2Вот частотники - хороший пример, что это те же яйца, вид сбоку. У него дохрена параметров - ну штук 150. Из них надо поменять от заводских настроек например 3 - захотелось вот пониженным напряжением питать, время торможения разгона задать, например. Сейчас открываешь документацию, ищешь в этой огромной таблице нужные, читаешь что до как. Как будет в вашем протоколе: открываешь документацию на протокол, ищешь как же там названы нужные параметры, открываешь документацию на частотник, ищешь информацию по ним что да как. Итого нихрена не проще.
dbalabolin Автор
14.11.2023 14:42Отнюдь. список функций всяко проще списка функций плюс таблица адресов и регистров. плюс надо еще написать некую функцию для установки этих регистров и не ошибиться.
вызвать setСкоростьТорможения(%) и удобнее и контроль ошибок доступен. Модуль idiBus выдаcт специальный тип ошибки - что разработчик задал значение вне диапазона.fizikdaos
14.11.2023 14:42+2а в протокол вы запихнете все возможные функции любых частотников?
dbalabolin Автор
14.11.2023 14:42в протоколе только базовый набор функций. В этом наборе вообще нет ничего про передачу конкретных данных. И есть способ для расширения числа функций. Их самих в протоколе нет но процесс их обслуживания уже есть. предусмотрено количество функций от 1 до 219. И есть набор стандартных для всех модулей команд. Init, Shutdown, Sleep.
Набор данных для каждой функции может быть большим. И ответ от частотника тоже.
Приборы которые имеют MODBUS можно непосредственно подключать. И пользоваться как обычно. Регистры и все прочее. Можно миксовать на одной линии. И постепенно менять иностранное на наше.
yury7
14.11.2023 14:42Дмитрий это классная идея. Судя по успеху wirenboard. Главное что бы продуктом можно было пользоваться и тогда успех точно придёт.
Но если речь идёт о сообществе думаю сразу стоит начать вести ТГ канал, что бы вокруг себя собрать единомышленников.
Например Aspia (замена Teamviewr) - https://aspia.org/
dbalabolin Автор
14.11.2023 14:42Благодарю за поддержку. Еще раз повторюсь что идея в том, что бы кучу функций перенести на сторону устройства на шине пользуясь изменившейся ценой на цифру.
VT100
14.11.2023 14:42Экспорт... Обратите внимание, какая надпись на мече у первого в ряду жлоба:
https://images.theconversation.com/files/460800/original/file-20220502-22-lj0on0.png
Сначала - надо будет вытеснить их из своего дома.
wofs
14.11.2023 14:42+1Привет коллегам по цеху, спасибо за статью — интересно, но она породила больше вопросов, чем ответов.
Но если нужно в разных местах одновременно произвести замер неких величин, то можно объединить устройства в общую логическую группу и затем дать всей группе команду на считывание.
Очень интересно про логические группы — расскажите, как вы это реализовали?
В протоколе имеется временное окно, в которое может обратится Slaveк Мaster, сообщив об экстренной ситуации. Каждое из устройств на шине может прервать последовательность опроса и обратить внимание на себя
«Временное окно» — это вы про 3,5 бита тишины? Как вы в этом случае разрешили коллизии? Ведь несколько устройство может начать одновременно отвечать и на шине получится кавардак.
Стандартная обработка ошибок передачи данных. Существенно более продвинутая, чем в древних протоколах.
Что это значит? Расскажите, пожалуйста, подробнее.
В России к нашему общему сожалению не производятся сверх массовые простые устройства. Технологический уровень страны более приспособлен к выпуску не больших партий более дорогих устройств, чем простая микроволновка или стиральная машина.
Ну неправда же — мы выпускаем сотнями тысяч штук простые устройства в РФ. Если надо партию прототипов из 10 штук — тоже нет проблем. И непонятно, как это связано с разработкой нового протокола.
Наша подход заключается в том, что надо дать возможность программирования на универсальных языках программирования. Прежде всего на С++, так как этому языку обучают сегодня во всех школах и ВУЗах.
Не понял в чём разница с программированием устройства под Modbus RTU. Ведь для него есть библиотеки, которые делают всю рутинную работу и программист пишет на языке верхнего уровня, оперируя понятными сущностями — регистрами или группой регистров. Все байтики, тайминги и прочее от него спрятано.
Набор стандартных библиотек для устройств шины idiBus для C++ обеспечивает еще одно важное качество – отсутствие необходимости программисту иметь знания и опыт работы с микроконтроллерами. Он просто работает с библиотеками от конечных устройств. С физическими величинами. Достаточно указать адрес на шине и установить этот адрес на самом устройстве.
Тут речь про визуальное программирование?
Для еще большего расширения возможного круга программистов мы даже обеспечили совместимость с ARDUINO. А это означает, что любой школьник после кружка робототехники уже может приступать к профессиональной деятельности в качестве разработчика системы АСУТП.
О, я пишу код для своих устройств в Ардуино — поделитесь библиотечкой?
На устройствах шины idiBus мы разработали установку для производства дезинфекционного состава за 4 недели. Конечно никакая индивидуальная разработка за такое время сделана быть не может. Следующим устройством был профессиональный шкаф акустической заморозки. Время разработки до серийного внедрения – 2 недели.
Интересно. Обычно делают так: берут контроллер, берут периферию и собирают шкаф управления чем-то. Вы для каждого проекта разрабатываете с нуля свою автоматику?
Откуда такие скорости разработки? Готовые отлаженные библиотеки вообще не требуют знания о периферийном устройстве. Никаких чтений мануалов. Никаких изучений регистров и портов. Просто #inclule и GetData(int Addr).
К сожалению, я не представляю, как не зная железа и техпроцессов сделать продукт. В Modbus RTU это тоже #include и getCoil(ячейка с температурой/состоянием входа и т.п.).
idiBus имеет на шине две одинаковые линии RS-485. Каждая из которых может работать с разной скоростью. При скорости 115200 Бит/с дальность связи составит 1,2 км. А при скорости 10 МБит/с – 10метров. Таким образом скоростной вариант можно использовать для работы внутри устройства или установки, а более медленный для работы в масштабе предприятия.
Как-то сложно, зачем две линии? Тянем далеко, ставим скорость поменьше. Собираем щит, ставим скорость побольше. Ну и 115200 бит/с на 1,2 км не получится — чем дальше, тем медленнее, физика. Как вы решили это?
Наверняка большую часть вопросов снимет подробное описание протокола, но ссылки на него я, к сожалению, не нашёл.
dbalabolin Автор
14.11.2023 14:42+1Придется вставить все вопросы еще раз что бы дать ответы
Добавлю еще что на той же физической шине можно ставить и MODBUS устройства тоже. Протоколы физически и логически обратно совместимы.
И в idiBus две линии связи. Можно при необходимости использовать или обе как главную и резервную линии или можно одну линию использовать внутри прибора как скоростную, а вторую вне прибора для удаленных устройств но с меньшей скоростью. Адреса на каждой линии своиПривет коллегам по цеху, спасибо за статью — интересно, но она породила больше вопросов, чем ответов.
Но если нужно в разных местах одновременно произвести замер неких величин, то можно объединить устройства в общую логическую группу и затем дать всей группе команду на считывание.
Очень интересно про логические группы — расскажите, как вы это реализовали?
Поскольку каждое устройство имеет мозг, то мы ему даем стандартную команду - ты теперь член группы номер 5. Всем кому надо присваиваем номер группы и потом даем команду "группе 5 замерять то, что умеет замерять каждое из устройств". или "всем включать то что задано на включение". Дается команда не по индивидуальному адресу каждого устройства по очереди а команда "исполнить" по адресу группы.
Потом можно группу обратно разобрать. Есть еще групповые команды. Это если в устройстве есть несколько одинаковых каналов то им всем можно дать одну команду если параметры совпадают. Типа "на всех выходах выставить 12В"В протоколе имеется временное окно, в которое может обратится Slaveк Мaster, сообщив об экстренной ситуации. Каждое из устройств на шине может прервать последовательность опроса и обратить внимание на себя
«Временное окно» — это вы про 3,5 бита тишины? Как вы в этом случае разрешили коллизии? Ведь несколько устройство может начать одновременно отвечать и на шине получится кавардак.
Коллизии разрешаются примерно также как других протоколах. Если сунулся в окно более чем один прибор, то все они не получат ответа от Мастера. И тогда каждый сделает паузу случайного размера и когда будет следующая пауза то уже в нее полезут не все одновременно.Стандартная обработка ошибок передачи данных. Существенно более продвинутая, чем в древних протоколах.
Что это значит? Расскажите, пожалуйста, подробнее.
Это смесь ошибок которые уже есть в MODBUS (10 шт) и ошибки обработки данных связанных с тем, что протокол не примитивный. В idiBus может передаваться бинарный пакет данных. Устройства могут исполнять команду по времени более длинную, чем длительность интервала опроса.
Статусы устройств Ошибки 0-9 это буквально от MODBUS RTU
Группы кодов ошибок В России к нашему общему сожалению не производятся сверх массовые простые устройства. Технологический уровень страны более приспособлен к выпуску не больших партий более дорогих устройств, чем простая микроволновка или стиральная машина.
Ну неправда же — мы выпускаем сотнями тысяч штук простые устройства в РФ. Если надо партию прототипов из 10 штук — тоже нет проблем. И непонятно, как это связано с разработкой нового протокола.
Ну я не в математическом смысле сказал что "не выпускаются" а в экономическом.
По сравнению с Китаем у нас подавляющее большинство производств мелкосерийные.Наша подход заключается в том, что надо дать возможность программирования на универсальных языках программирования. Прежде всего на С++, так как этому языку обучают сегодня во всех школах и ВУЗах.
Не понял в чём разница с программированием устройства под Modbus RTU. Ведь для него есть библиотеки, которые делают всю рутинную работу и программист пишет на языке верхнего уровня, оперируя понятными сущностями — регистрами или группой регистров. Все байтики, тайминги и прочее от него спрятано.
А мы предполагаем и дальше спрятать от программиста и регистры тоже. Сразу можно работать с физическими величинами. А есть там регистры или нет их это уже и не важно.Набор стандартных библиотек для устройств шины idiBus для C++ обеспечивает еще одно важное качество – отсутствие необходимости программисту иметь знания и опыт работы с микроконтроллерами. Он просто работает с библиотеками от конечных устройств. С физическими величинами. Достаточно указать адрес на шине и установить этот адрес на самом устройстве.
Тут речь про визуальное программирование?
Нет. Мы даем программисту набор устройств на который можно установить. их адрес. Это АЦП, Термометры, Амперметры, Счетчики и т. д. И программист обращается через библиотечную функцию к устройству с указанным адресом. И по этому адресу может запросить данные или дать команду.
Никаких сведений об устройстве ему не требуется кроме как что оно может и как это получить используя библиотеку. Все остальное скрыто внутри протокола.
Ему и ошибки все тоже выдаст протокол.Для еще большего расширения возможного круга программистов мы даже обеспечили совместимость с ARDUINO. А это означает, что любой школьник после кружка робототехники уже может приступать к профессиональной деятельности в качестве разработчика системы АСУТП.
О, я пишу код для своих устройств в Ардуино — поделитесь библиотечкой?
Она одинаковая для Microchip Studio и Arduino. Сейчас реализация чипа на мастере это ATMEGA 2560 или 1280. Сейчас делаем то же под STM32.На устройствах шины idiBus мы разработали установку для производства дезинфекционного состава за 4 недели. Конечно никакая индивидуальная разработка за такое время сделана быть не может. Следующим устройством был профессиональный шкаф акустической заморозки. Время разработки до серийного внедрения – 2 недели.
Интересно. Обычно делают так: берут контроллер, берут периферию и собирают шкаф управления чем-то. Вы для каждого проекта разрабатываете с нуля свою автоматику?
И так тоже делаем если есть заказчик на прямо разработку своей платы. Если тираж изделий позволяет.
Но сейчас идем другим путем. Имеется базовый набор idiBus. Все это без корпусов потому что все и так внутри корпуса собирается. Имеется материнская плата с чипом в виде мезонина. и к ней подключаются уже по проводу платы расширения. на которых ставятся модули разных типов. Например есть модуль термопар. На 3 термопары К типа. Можем мерять три канала температуры. Если надо еще три то ставим еще модуль. Это если речь идет о непосредственном измерении. А есть модуль iWire, к которому например можно подключить термометры 18B20. И тогда к базовому драйверу этого модуля дописывается маленький кусок именно касающийся получения температуры. Остальное все что связано с протоколом уже стоит на модуле.
То же самое например модуль счетчика. Мы к нему прикручиваем расходомер и дописываем ту часть которая переводит импульсы счетчика в литры.
То же с модулем АЦП. 0-10В. Любой датчик с этим протоколом можно подключить и дописать минимальную часть, которая переведет эти вольты в физическую величину , которую датчик измеряет.
Сейчас уже есть модули памяти, часы, реле, UART.Откуда такие скорости разработки? Готовые отлаженные библиотеки вообще не требуют знания о периферийном устройстве. Никаких чтений мануалов. Никаких изучений регистров и портов. Просто #inclule и GetData(int Addr).
К сожалению, я не представляю, как не зная железа и техпроцессов сделать продукт. В Modbus RTU это тоже #include и getCoil(ячейка с температурой/состоянием входа и т.п.).
Увы наша практика показала, что производители не торопятся делать универсальные библиотеки. Даже надо сказать и физически все устройства MODBUS RTU как в зоопарке.
Везде свои разъемы и распаковки. Мы же принудительно ограничили все обычным RJ-45idiBus имеет на шине две одинаковые линии RS-485. Каждая из которых может работать с разной скоростью. При скорости 115200 Бит/с дальность связи составит 1,2 км. А при скорости 10 МБит/с – 10метров. Таким образом скоростной вариант можно использовать для работы внутри устройства или установки, а более медленный для работы в масштабе предприятия.
Как-то сложно, зачем две линии? Тянем далеко, ставим скорость поменьше. Собираем щит, ставим скорость побольше. Ну и 115200 бит/с на 1,2 км не получится — чем дальше, тем медленнее, физика. Как вы решили это?
Это мы и решили двумя линиями. Одна рассчитана на скорость и работу внутри установок, а вторая - внешняя на длинные линии. Есть еще разветвитесь 1/4. Можно шину удлинить или разветвить. 115200 на лапше на 1,2 км не получается, а на витой паре работает.Наверняка большую часть вопросов снимет подробное описание протокола, но ссылки на него я, к сожалению, не нашёл.
wofs
14.11.2023 14:42+1Добавлю еще что на той же физической шине можно ставить и MODBUS устройства тоже. Протоколы физически и логически обратно совместимы.
То есть внутри у вас те же Modbus-фреймы?
И в idiBus две линии связи.
Странная фраза. Линии связи это физический уровень и он мало имеет отношение к протоколу. Например, Modbus может работать через RS-485, а может по Ethernet с помощью шлюза, который завернёт пакеты протокола в пакеты TCP/IP.
Если сунулся в окно более чем один прибор, то все они не получат ответа от Мастера... каждый сделает паузу случайного размера и когда будет следующая пауза то уже в нее полезут не все одновременно.
А как устройство понимает, что оно не одно передаёт? Слушать шину в RS-485 в момент передачи нельзя — вы услышите сами себя, а другие что-то случайное.
А мы предполагаем и дальше спрятать от программиста и регистры тоже. Сразу можно работать с физическими величинами.
Вы какого программиста имеете ввиду? Если Embedder, то он работает с периферией по I2C и SPI. А регистры для него способ отобразить информацию с периферии наружу или получить информацию извне. Не очень понятно, зачем тут ещё один слой абстракции. И что делать, если у меня есть своя физическая величина, например, попугаи на см2.
Нет. Мы даем программисту набор устройств на который можно установить. их адрес. Это АЦП, Термометры, Амперметры, Счетчики и т. д.
А, то есть речь о программисте софта верхнего уровня. А кто делает эти устройства — вы сами? Тогда выглядит как способ подсадить пользователя на ваше оборудование и чтобы он никогда не слез.
115200 на лапше на 1,2 км не получается, а на витой паре работает.
Чем длиннее линия, тем больше затухание сигнала и помех, что заваливает фронты сигнала и приходится увеличивать длительность импульсов. А значит мы уменьшаем скорость. Поэтому интересно, как вы обошли физику.
Ещё интересна позиция «поднимем с колен, вражеское железо, национальное...», а качестве своих работ вы привели два сомнительных лендинга на английском языке, где продаются устройства (www.aeftrade.eu/a12, https://pradox.info/). В них если и нужен Modbus, то только для связи с внешним миром и никак не для создания самого устройства. Ещё процессы там очень инерционные и нет никакой надобности гонять данные на огромной скорости.
В целом складывается впечатление, что вы сделали решение, но оно никогда не было внедрено в реальных проектах. Об этом косвенно свидетельствуют и утверждение про 115200 бит/с на 1.2 км и про то, что вместо четырёх функций и таблички modbus-регистров лучше иметь талмут с развесистым деревом функций на каждый чих.
Можно не ссылку а спецификацию. Надо написать письмо на info@idibus.com, представится и получить спецификацию и примеры.
Написал письмо, посмотрим, насколько вы честны с аудиторией Хабра и самим собой.
dbalabolin Автор
14.11.2023 14:42"А как устройство понимает, что оно не одно передаёт? Слушать шину в RS-485 в момент передачи нельзя — вы услышите сами себя, а другие что-то случайное."
Оно не понимает что одно. Оно не получит подтверждение, что его сообщение дошло.
115200 на 1,2 км это реальная скорость при использовании экранированной витой пары Cat5e. Если прямо через ядерный реактор протянуть кабель, то наверно нужно будет снизить скорость.
"Сомнительные" лендинги? С чего вдруг сомнительные? Внутри этих устройств все и работает. Все управление как раз и сделано на idiBus. Буквально как и описано в статье. Вместо разработки новой специфичной электроники все собрано на готовых модулях idiBus. Есть АСУ внутри аппарата а есть АСУ размера предприятия или производственной линии.
В этом случае все внутри.
Инерционности кстати никакой нет. Если вдруг давление скакнуло, то надо немедленно что-то делать. Пока не разорвало все. Управление инерционным процессом требует крайне быстрой реакции на аварии.
Программиста я имею ввиду того, который станок автоматизирует. Или теплицу. Или прокатный стан. Вот он в системе idiBus это просто любой программист.
Иногда создается ощущение, что АСУшники считают себя некоей высшей кастой.
А заказчикам как раз требуется ровно обратную задачу решить - иметь возможность нанять на рынке сотрудника, выбирая из максимально широкого круга кандидатов.
И тогда идеология, когда любой С++ программист может делать эту работку очень устроит заказчиков. А сейчас он вынужден выбирать (а в его городе может и вовсе не быть) из тех, кто изучил проприетарную систему какого-то производителя.
А ему надо обустроить свою бетономешалку. И вообще не нужен человек для этого на постоянную зарплату.
Я стою в логике решений на стороне заказчика. То есть на стороне экономики.
"А, то есть речь о программисте софта верхнего уровня. А кто делает эти устройства — вы сами? Тогда выглядит как способ подсадить пользователя на ваше оборудование и чтобы он никогда не слез."
Мы делаем устройства и любой другой тоже может делать устройства.
В чем разница между регистрами и функциями? В том что функции у всех одинаковые. Логика, обработка ошибок и функций и протокола. А регистры у каждого свои и своя логика конвертации внутренней структуры в эти регистры.
Да это более высокий уровень абстракции, вынесенный на уровень протокола.
Но уже давно никто не придерживается сетевой модели OSI.
Даже ему дадим базовые библиотеки от протокола, на которые он допишет только свою специфику. О монополии речь не идет. Наоборот. Это возможность для производителей датчиков и других устройств очень дешево их "оцифрить".
В конкуренции протоколов и систем АСУ выиграют тот у кого цены ниже и ниже себестоимость. А те у кого оно все дороже пытаются всякими путями защитить свои цены.
А государство тем временем уже не первый год импортозамещает
"Тендер на проведение ОКР был опубликован 27 октября 2022 г. в формате открытого запроса предложений с начальной ценой договора в 284,9 млн руб. Претендентами, помимо РАСУ выступили НТЦ «Интернавигация» с предложением в 235,5 млн руб. и НИИ «Солитон», готовый выполнить работы за 196,6 млн руб., однако их заявки были отклонены." Даже вот люди хотели на 100 млн дешевле сделать да им не дали. Развивают кота в мешке и монополию на этого кота.
https://www.cnews.ru/news/top/2023-02-28_promyshlennye_kontrollery
С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)wofs
14.11.2023 14:42+1Оно не понимает что одно. Оно не получит подтверждение, что его сообщение дошло.
Это всё ещё не ответ. Расскажите, как вы смогли организовать доставку ответа устройства до мастера, если на шине одновременно начали передавать несколько устройств. Как вы обошли физические ограничения шины?
С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)
Не смешно. Доверие надо заслужить. Я написал письмо, ответа нет. Странная открытость.
dbalabolin Автор
14.11.2023 14:42я ответил на одно письмо уже с приложением спецификаций. с какого адреса было Ваше? не дошло пока.
Если Слейву надо обратиться к мастеру, то он в специальном окне выставляет запрос со своим адресом.
Мастер видит, что есть сообщение типа ALARM и знает от кого. И уже начинает со своей стороны выяснять что там произошло прямо следующим обращением к слейву. И слеву дает информацию, что его сообщение дошло.
Если слейвов несколько то сообщения они накладывают одно на другое Так как формат сообщения одинаковый но отличается адрес и CRC то мастер ничего им не отвечает и продолжает свой цикл опроса.
Все слейвы, которые не получили немедленного к себе запроса, но находящиеся в состоянии ALARM будут повторять свой выход на линию. Но каждый из них сделает случайную паузу от нуля до нескольких пакетов. То есть они разойдутся по времени. Такой же механизм и в других протоколах используется.wofs
14.11.2023 14:42с какого адреса было Ваше
С @wirenboard.com писал от своего имени, оно есть в профиле на Хабре.
mvkozyrev
14.11.2023 14:42+1Пробежал заголовок по диагонали. Не увидел ключевое слово "драйвер".
dbalabolin Автор
14.11.2023 14:42Видимо попалась не та диагональ ) Но "драйвер" это больше термин из операционок. А в нашем случае это скорее библиотека. Хотя драйвер звучит конечно круче.
mvkozyrev
14.11.2023 14:42+1Я не о том. MODBUS не перепиливал только ленивый. Я о возможности подключения вашей библиотеки к чему-то стандартному, что есть на рынке.
dbalabolin Автор
14.11.2023 14:42Мы реализовали некий подход в этом вопросе. На шину idiBus можно насажать наши готовые модули для работы с датчиками и устройствами с интерфейсами 0-10В, 4-20мА, iWire и другими. И это все по своему протоколу. Что-то даже можно по шине обеспечить и питанием. Но на эту же физическую линию можно прикрутить и любые готовые устройства которые работают на MODBUS RTU и с ними тоже работать. У них адреса отличаются и размеры фреймов. Это специально сделано, что бы можно было любыми готовыми изделиями с рынка пользоваться используя те же кабели и те же библиотеки.
wofs
14.11.2023 14:42+1Мы реализовали некий подход в этом вопросе. На шину idiBus можно насажать наши готовые модули для работы с датчиками и устройствами с интерфейсами 0-10В, 4-20мА, iWire и другими. И это все по своему протоколу. Что-то даже можно по шине обеспечить и питанием.
Вы так говорите, как буд-то это ноу-хау какое. Но ведь так делают все: есть контроллер, есть периферия и к периферии подключаются контакторы, лампочки, датчики с аналоговым выходом и т.п.
imsushka
14.11.2023 14:42+1А сколько и каких датчиков вы сделали ?
Или мне надо нужные мне датчики переделывать под ваш протокол ?
vk6677
14.11.2023 14:42Интерфейс 485 вполне не плох. Протоколов по нему огромное количество. Ваш протокол - не плохая задумка. К сожалению, куча производителей лепят что хотят. Встречал такие варианты, когда не было контрольной суммы и не использовались даже биты четности (приходилось данные прогонять через медианный фильтр для исключения некорректных данных, вызванных помехами).
Создавал свой протокол, который мог пройти через трансформаторную развязку. Приходилось подмешивать дополнительные биты, что бы искусственно создать "перемену" (но умудрились в эти избыточные биты фактически поместить аналог контрольной суммы). Позже перешли на оптику.
Качество реализации 485 тоже разное. Для проверки используем мощный пускатель, плохой (крайне шумный) частотник и сломанную пьезозажигалку (бьём по контактам). Бывает именитые фирмы не выдерживают проверок, а "самоделки" отделываются испугом (отбрасывают сбойный пакет).
belav
14.11.2023 14:42Но в 2020 году ситуация стала абсолютно обратной...
На складах исчезли контроллеры, а жадные продавцы подняли цены 10х
sav13
14.11.2023 14:42+1Вспоминается жуткий протокол от Шнайдер - Modbus Plus. Работать с ним можно только через фирменный интерфейсный модуль за бешеные деньги.
hooperer
14.11.2023 14:42+2достаточно спорная статья.
какие вопросы описано в статье решает предлагаемый новый протокол:
Шифрование.
Обновление прошивок по шине..
Одновременное считывание показаний
Внеочередное обращение к Master.
Спящий и безопасный режим.
Обратная совместимость с MODBUS RTU.
Стандартная обработка ошибок передачи данных.
ну для начала шифрование данных в modbus возможно. Для этого наверно стоит смотреть не на описание на ipc2.ru а брать исходный текст на modbus.org.
Оффтопом - тогда, кстати и не будет этого бреда из серии "регистров всего 9999". потому что в спецификации от 1996 года этот подход уже тогда был признан устаревшим и предлагалось в Той спецификации так больше не делать, а использовать для каждого типа функций модбаса при необходимости по 65534 регистра каждая. и да, крайняя версия протокола от 2012 года.
второй пункт - в modbusrtu вполне можно передавать файлы и ими обновлять прошивки.
20-я функция модбаса вам в помощь, то-есть проблемы нет как таковой
Пункт третий - одновременное. Групповые посылки это конечно интересно, но вот необходимость в этом... Если это один модуль - зачастую этот вопрос решается битовыми масками. Если это разные модули, то тут наверно вопросов больше чем ответов - к примеру что будет если послать команду допустим включения реле на три модуля сразу и один модуль его включил, второй не включил потому что ошибочно прочитал пакет, и в ответ выдаёт ошибку, а третий модуль вообще выключен и не отвечает.
Возможно эти коллизии и разрулены, но Все ли они разрулены и нужно ли их Так разруливать, или лучше опрашивать всё таки Последовательно, вопрос достаточно интересный и не однозначный.
Четвертый пункт - а зачем обращатья к Мастеру? в чём сермяжный смысл? если можно скажем программно на линии сделать ещё одно " подчинённое устройство" которое и будет как бы " отвечать. НО это как бы ну совсем какие то узкие применения, не мильно понятно вообще для куда.
Пятый пункт - Это вообще не понятно для чего. Хотите в модулях отключить аналоговый тракт - ну так стандартными методами этот вопрос решается достаточно просто, конфигурированием устройства так же по модбасу.
Шестой пункт- Совместимость - судя по описанию предлагается какой то странной и не однозначной.
Седьмой пункт - Обработка ошибок. Наверно для того, чтобы лучше понимать этот вопрос - стоит обратиться к Спецификации на Протокол Модбаса. Там есть ОЧЕНЬ МНОГО интересного, в 2012-м году, что может решить наверно 98% вопросов, котоыре даже не так очевидны, как кажется.
Ну а отдельно вообще про новый протокол и модбас:
1) Стандартных библиотек предлагающих Разные формы абстракции - для Модбаса реализовано Очень много.
И на python и на С и, что более важно, для Большинства ( если не для всех за малым исключением) Scada систем.
Для более высокого уровня абстракции всё таки принято использовать OPC серверы,
которые опросив данные по модбасу могут выдавать данные в более приятном виде - и в виде физических величин, и с датой актуальности и качества данных. И могут иметь Нормальное плюс-минус шифрование и защиту , OPC_UA к примеру.
И эта архитектура зарекомендовала себя весьма и весьма хорошо.
И да, потуги были у иридиума сделать свой протокол и у вайронборда.
ну как то оно не выходит широко за пределы одного-двух производителей. Наверно отчасти и потому что Уровень проработки вопросов в Modbus всё таки существенно шире и более объёмен.
И да, протокол Modbus это не только библиотеки опросчиков, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
dbalabolin Автор
14.11.2023 14:42Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf
Обновление прошивок возможно как и вовсе передача любых данных в пакетах. Однако есть разница между единым механизмом и чисто теоретической возможностью которую каждый реализует по-разному. В idiBus вы можете узнать у устройства оно вообще имеет прошивку или нет? это обязанность устройства так как часть протокола.
Выдачу данных через сервер конверсии бит в физические величины можно применять вообще с любым устройством. Взяли слева биты и послали направо. и справа пришли значения. Но тут то речь идет о том, что само устройство уже вполне может это делать и само цена этой функции - ноль так как в любом устройстве уже стоит чип как в телефоне.
Можно уже в тетрис играть на датчиках давления.
Коллизии разруливаются как в других протоколах.
К мастеру можно обращаться вне очереди. В случаях повышения или снижения давления, температуры или по любой срочной надобности что бы не ждать своей очереди в опросе.
Групповые опросы масками не решить. Это механизм для разных устройств. Любого типа. В физических процессах часто надо мерять не один параметр а несколько но нужны их значения именно в один момент времени. Когда они динамичны. Например давление и температура. Измерение происходит в один момент, а получение этих данных может быть и последовательное.
Безопасный режим это способ сохранения системы если имеются сбои и надо ввести систему или ее часть в состоянии когда она своими действиями не может себя разрушить.
Совместимость по линии это означает что логика протокола такова, что к стоящим на линии устройствам MODBUS можно от мастера обращаться без изменения логики и без изменения физики. Устройства MODBUS просто не замечают траффика idiBus.hooperer
14.11.2023 14:42+2хм...
"""Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf"""
Сначала наверно стоит ознакомиться со Всеми Спецификациями, чтобы не выдёргивать из конеткста. Благо сайт modbus.org известен, и раздел Технических спецификаций там один. Чтобы понимать что шифрование по необходимости есть.
Ну а самые большие проблемы с протоколом описаны в конце, и собственно лишают новые протоколы всякого смысла - цитата
"""
И да, протокол Modbus это не только библиотеки опросчиков на абсолютно разных языках, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
"""
dbalabolin Автор
14.11.2023 14:42Всегда что-то начинается и заканчивается. Пока мы видим путь внедрения в устройства, а не в большие системы. Станки и теплицы. Зарядные станции и вообще всякое оборудование.
За последние годы появился далеко не один протокол и строить прогнозы об успешности явно рано. Проблема российских протоколов и вообще всех разработок это русский язык. Потому что его никто не знает и весь мир пользуется английским.
Наши кое=как выучили английский, но заставить иностранцев учить русский невозможно. А для целого протокола одной России маловато. И это более важно чем новизна чего бы то ни было из РФ.
А со всеми спецификациями мы ознакомились по всем наиболее популярным протоколам. И CAN и HART и прочие FIELDBUS.
Взяли все лучшее постарались снизить влияние природных недостатков таких как Master-Slave например.
А "по необходимости" поверх любого протокола можно натянуть что угодно. Хоть шифрование хоть передача видео. Можно даже в протоколы туннели включать. В мастер-слейвы элементы peer-to-peer. Только управлять этой бедой крайне сложно.
На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы.hooperer
14.11.2023 14:42+1"""На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы. """
это ещё и обучение и постоянный, наработанный годами штат поддержки.
и тут вообще каждое слово можно написать с большой буквы.
А так то не понятно, ну допустим у Вас умные устрйства с большими процессорами. ну так положите на них opc_ua и не надо ничего нового изобретать. возьмите любой другой уже подходящий протокол. Изобретение нового это дело достаточно неблагодарное. Потому что у Вас видение какого то маленького, достаточно узкого участка АСУ- ТП. я к примеру вот не могу даже представить себе где нужно одновременное начало измерения температуры, передавать по 485-му. а Вы не можете представить к примеру количество опс приборов с опросом 24/7/385, по отношению к асу-тп.
dbalabolin Автор
14.11.2023 14:42Как раз наоборот. Наши устройства с самыми дешевыми контроллерами 8 бит и этого достаточно и на преобразование форматов и на поддержку протокола. Это в заголовке статьи. Цена на цифру сегодня буквально ноль. В отличие от какого-нибудь встраиваемого датчика давления.
Огромная масса дачников выпускается сейчас с интерфейсами 0-10 или 4-20.
И коробочка с цифровизацией добавляет к цене 10 процентов. И пожалуйста уже можно пользовать. И в приборах внутри корпуса и удаленно.
Скажу даже, что излучался вопрос о том, что бы на этом всем управление судами сделать.
И никаких противопоказаний не обнаружилось.
Другой протокол по сумме затрат на все части процесса - от проектирования до обслуживания и от изготовления самих контроллеров до их корпусов дороже. Прибавим еще затраты на монтаж устройств в каждом из которых своя распиновка подключения вместо унифицированных разъемов. Зарплаты программистов отличаются на разных языках. Соберется общая цена.
Количество приборов я вполне могу представить. Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий.
Вот там кстати надо температуру знать. И разницу давлений при открытии заслонок и влажность. Потому что это такой огромный PID регулятор по факту.
А изобретения вообще дело неблагодарное. У меня есть международный патент к примеру. Так и денег и сил это стоит неразумных.hooperer
14.11.2023 14:42и при управлении приточкой желательно измерять температуру и управлять кзр-ом как можно медленней.
dbalabolin Автор
14.11.2023 14:42Чисто для информации. Я - дипломированный магистр по климатической технике. Кроме того что радиоинженер.
hooperer
14.11.2023 14:42+1вот поэтому и интересно, где в климатической технике, даже теоретически - может возникнуть требование запроса измерений, выполняемых одновременно.
В моей вселенной это вот что что, но климатика настолько инерционна, что некоторые параметры измерять даже раз в секунду - это весьма и весьма быстро. а уж управлять кзр-ом так вообще.
Поэтому такое требование - в виде одновременных измерений - звучит Диссонансом с климатическими системами.
Чисто для информации к примеру сигнетикс не свои алгоритмы не сами писали а списывали с некоторых давно выпускаемых серийно контроллеров. Это не существенней дипломов, зато уровень компетенций не пропиваемый.
Siemargl
14.11.2023 14:42Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий.
Ну с таким бэкграундом надо было наверное еще посмотреть EIB/KNX, BACNet, Lonworx, Carel. Там совсем другие подходы и требования.
ponikrf
Вы вобще не знаете сколько стоит Ethernet и сколько стоит 485. Зачем вы пишите этот бред. RS-485 стоит раз в 50 дешевле Ethernet. Если вы не согласны предложите мне решение для Ethernet за 20 рублей. Потому что, что бы заработал 485 мне нужен простой драйвер, а что бы заработал Ethernet мне нужно ОЧЕНЬ много. Это касается и программного уровня, так и аппаратного.