Комментарии 117
P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
Вы вобще не знаете сколько стоит Ethernet и сколько стоит 485. Зачем вы пишите этот бред. RS-485 стоит раз в 50 дешевле Ethernet. Если вы не согласны предложите мне решение для Ethernet за 20 рублей. Потому что, что бы заработал 485 мне нужен простой драйвер, а что бы заработал Ethernet мне нужно ОЧЕНЬ много. Это касается и программного уровня, так и аппаратного.
Если бы в РФ были хоть какие-то свои стандарты, так можно было бы об этом поговорить. Но на сегодня нет даже русского перевода все этого добра от МЭК. А английский оригинал имеет буквально несколько фирм. Так что цифра 14 на сегодня это фактически ноль.
Второй важный аргумент и он важнее всех остальных. Цифровые устройства настолько дешевы, что перенос всех вычислений на сторону устройств на шине вообще ничего не стоит. Но позволяет нанимать буквально любого человека, знающего С++ вместо знатоков проприетарных протоколов. Особенно в те времена, когда устройства сами уже не поставляются.
ноне эти речи почти крамольные ;) Назовем тогда и Вашу разработку словом "поделие", и будет их, да не 14, а 114 потому что каждая фирмочка изобретает свое че то, и в общем то главное чтобы работало со своим оборудованием, а чужого никто и не обещал.
Обращает на себя внимание эта Ваша реакция: коллеги (конкуренты?) из WirenBoard на 14 стандартов отреагировали совсем по другому.
Не хотите свои разработки назвать "поделие"? Поясню свою мысль. Наши изделия установлены уже в реальное оборудование, которое экспортировано в 28 стран. А ваша "фирмочка" что-то уже продала немцам, американцам, итальянцам и прочим? Ну мне чисто любопытно откуда берется такой снобизм и основание давать такие характеристики?
Моя фирмочка? Спасибо, звучит интересно. Я в общем то конечный пользователь, которому 114 "стандартов" (хотя Вы же сами отказались таковыми признавать) портят кровь когда нужно скрестить ужа с ежом и чтобы все работало. До абсудра же доходит (реальный случай): в новом поколении оборудования взяли и инвертировали бит статуса в одном модуле c modbus. Сам станок старый, центральный соф никто пилить не будут, а предлгают костыль, за хорошие такие деньги. Это разве не поделие?
Ну "ваша" это означает где вы работаете. Ну так что вам как пользователю не нравится? что есть новый стандарт и устройства к нему? Или что система так устроена, что любой школьник может с ней работать имея багаж кружка робототехники?
Нет задачи заставить всех создавать паровозы. Наоборот. Есть задача создать такой паровоз на котором любой ребенок может кататься.
"Поделие" вовсю работает и не ломается.
Давным-давно уже даже не просто библиотеки существуют а целые сервера, которые раскладывают значения регистров, собирая при необходимости (многобайтное значение) в целевое в MQTT, например. И вся работа со значениями сводится с "прочитать топик" и "записать топик".
Вот modbus slave на ардуинке. И ее производительности достаточно для подавляющего большиства задач домашней автоматизации: https://support.wirenboard.com/t/druzhim-wirenboard-s-arduino-slave-po-modbus/9034
Да аруинко вообще отличная вещь. Я про саму среду.
Но хочу сказать про всякие датчики. Имеется много разных устройств и датчиков, которые НЕ MODBUS. Они 0-10В, 4-20мА, 1Wire и прочие интерфейсы. В нашем случаем имеется модуль интерфейса, который уже имеет все фунции протокола. И мы берем и добавляем поверх готовой библиотеки только ту часть, которая из этих интерфейсов делает сразу физические величины. Ну или команды если это что-то командное. И такие все цифро-аналоговые датчики типа той же термопары становятся цифровыми устройствами на шине. Вся базовая часть протокола уже написана. Остается кусочек дописать и залить прошивку в готовый уже интерфейсный модуль,
Вот для той же ардуинки из ссылки. Это готовый шаблон, который позволяет настраивать записью в регистры параметры связи (скрость, стопбиты, modbus id).
Дописать в него работу с 1wire (одним датчиком на шине) - примерно десять строчек.
С 0-10 так же. Для 4-20 - добавляем резистор в 200 Ом.
Цена в рублях получается ~600, из которых 200 -ардуинка, 200 - плата и разъемы 150 - компоненты типа dc-dc преобразователя.
У меня например дальномер так сделан.
Если по деньгам не жмёт, то можно и конверторы ставить.
В наших проектах используем Moxa, вешаем весь зоопарк по Модбас, дальше уже к Сименсу завожу как Профинет.
Очень удобно, вообще не надо ни о чём думать.
Вы видимо не все прочли коли советуете библиотеки для протокола. Речь идет о библиотеках для устройств на шине. А я их что-то не наблюдаю пока. Вот к примеру мне надо вентилятор подключить через популярный частотник DANFOSS FC-51. Не подскажете где мне взять такую библиотеку, что бы задать скорость 80 процентов от Максимума? Думаю нигде их нет. А включить два насоса одновременно? одной командой?
Или вам надо податься в экосистему DANFOSS если ее достаточно и цены устраивают или открывать документацию и приступать к изучению регистров и к отладке. Мы же не о серии говорим а о разработке.
Ну и передача огромного числа регистров не добавляет скорости обмена.
Вот: https://wirenboard.com/wiki/Danfoss_VLT_Microdrive_FC51
Выбираем в веб-интерфейсе из списка - профик. Все параметры доступны для работы через MQTT и тот же веб-интерфейс.
Хоть по http управляй.
Разве что кто-то выпустит микроконтроллер только с двумя ножками – питание и земля.
Разработчик беспроводных Wi-Fi датчиков:
- Подержи мое пиво!
Modbus это протокол доступа к адресуемым регистрам памяти устройства, Modbus RTU обеспечивает контроль передаваемых данных путем передачи контрольной суммы данных в каждом пакете. Более простого протокола сложно придумать.
Не совсем понял необходимости прикручивать еще одного протокола для работы по последовательным каналам связи.
Кто хочет делать - делает, для этго не нужны никакие "национальные системы". Как пример: https://habr.com/ru/companies/wirenboard/articles/772308/
Ну тема известная. Приведу одну цитату из этого источника "долгий период опроса одного регистра в устройстве — если на шине много устройств и в каждом по паре сотен регистров, то в зависимости от скорости и расположения регистров, пауза между опросами одного и того же регистра может достигать нескольких секунд. Это в конечном счёте приводит к медленной реакции системы."
Так что для химзавода это не вариант - опрос ОДНОГО Регистра за несколько секунд,
У нас все регистры уже опрошены еще внутри самого устройства и время ответа не зависит ни от чего кроме как просто количества устройств на линии. И оно не умножается на количество регистров.
А необходимости в что-то типа DHCP в приборах нет. Все это нужно для технологического оборудования а оно обычно не не работает в режиме горячего подключения устройств.
Приведу одну цитату из этого источника
Это о проблеме Modbus RTU речь.
Так что для химзавода это не вариант - опрос ОДНОГО Регистра за несколько секунд,
Ну на самом деле, смотря что там делать. Если рулить химустановкой — это одно, а если всем, кроме неё, то и 10 секунд задержки не проблема.
У нас все регистры уже опрошены еще внутри самого устройства и время ответа не зависит ни от чего кроме как просто количества устройств на линии. И оно не умножается на количество регистров.
Это вы всё ещё рассказываете о преимуществах вашего решения перед Modbus RTU — это отлично! Где можно почитать описание протокола?
Разница в том, что от проектировщика/программиста скрыто вообще само существование регистров или какие-либо детали устройства. Производитель выдает готовую библиотеку и можно сразу работать с функциями минуя стадию разбиения данных на регистры и адреса сдвигов.
Технически можно написать библиотеки на сторону мастера. к тем же самым устройствам Modbus. И надеть эту оболочку поверх самого протокола связи. Но это решает одну проблему и создает другую - канал забивается трафиком передачи адресов и значений регистров вместо того что бы сразу получить нужные данные в нужном формате. Я уже не говорю о шифровании трафика и о возможности заливать новые прошивки, это будет вечной операцией на MODBUS. Фреймы мелкие и данные мелкие. Это как копировать на дискету тысячи файлов.
...о возможности заливать новые прошивки, это будет вечной операцией на MODBUS. Фреймы мелкие и данные мелкие. Это как копировать на дискету тысячи файлов.
Как-то вы категорично про Modbus говорите. Мы без проблем несколько лет шьём устройства поверх RS-485 и Modbus RTU, пруф: https://github.com/wirenboard/wb-mcu-fw-flasher
Причины изложены в тексте. Основных несколько. Вы когда драйвер принтера ставите то это же драйвер. Все что надо уже есть внутри. Знать внутренние подробности не требуется. Что бы работать сразу с физическими величинами и кодами ошибок вам надо поверх регистрового трафика написать библиотеки и дать их пользователю. Что бы ему не изучать способы извлечения конкретных данных их конкретного прибора или в обратную сторону как ему давать команды. И можно эти библиотеки разместить на стороне мастера, а можно на стороне слейва.
На Мастер можно и ARM поставить для управления и логикой и протоколом. Но регистровый протокол удваивает и утраивает загрузку канала. Я уже не говорю что люди умнеют и исправляют ошибки. А по MODBUS новую прошивку то никак не загрузить.
Таким образом для облегчения труда и сокращения и сроков явно нужны библиотеке. Выбор лишь с какой стороны будет обработка. Мы сложили все факторы и посчитали что уже можно это делать со стороны SLAVE. Нет аргумента по которому выгоднее делать обработку на стороне MASTER.
Есть и еще одна причина. Разработчик конечного устройства на шину всяко лучше знает свое устройство чем разработчик системы. И в как в объектном программировании полезно скрыть от пользователя детали реализации. И также избавить его от трудозатрат на этот процесс.
Вся проблема в RS485, питание надо передавать по тем же проводам, что и сигнал, никто не хочет тянуть 4 провода и наблюдать как весь сегмент падает при кз на одном датчик.
Если уж переходить, то на Ethernet APL, и любой протокол поверх, HART IP, ModbusTCP, Profinet, Profibus IP, FielbusIP.
485 это тупик, только зря потратите время и деньги.
У 485 есть своя ниша, да и гораздо дешевле оборудование, чем для работы с Ethernet и TCP
Есть ниша, но как вы и сказали, это очень нишевая вещь. В ПАЗ системы не поставите, в нормальные управляющие тоже. Так для коммерческого учёта в некритичных системах.
Нужен Real-time Transport Protocol для таких систем управления. Ну либо токовая петля, с возможностью настройки датчиков по ней, например через HART. А 485 вообще для чего нормального то нужен? Для систем управления уровня предприятия, даже заморачиваться с ним не стоит.
P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
У нас приточки и фанкойлы по Modbus RTU управляются.
Достаточно серьёзно?
В нормальные управляющие уже поставили. Это не Realtime система большой дискретизацией. Но управлять оно точно может всем тем для чего используется MODBUS оно может и существенно лучше. И на сегодня MODBUS это максимально популярный протокол
еще момент немаловажный, обрыв 485 лечится обычными клеммами, обрыв ethernet уже сложнее
Подключали устройства в шахте, так там даже земли нет и шкафы с контроллерами регулярно перемещают - альтернативы 485 просто нет
А толковая петля, проще же нет вообще ничего, и питание там и сигнал и цифру ещё наложить можно, правда медленную.
я потерял нить ваших рассуждений, извините.
Токовая петля это интерфейс 4-20 мА. Ток пускают и датчик его регулирует. И поскольку это ток, то оно может на любых расстояниях работать так как ток он один и тот же во всей цепи. Когда дошло до протоколов а не просто замеров тока, то по тем ж проводам пустили еще и переменный ток. И получился протокол HART. Но там частоты такие, что он очень медленный.
https://dzen.ru/a/ZSjeV4NlVBw522z_
Ну это уже без нас наложили. Но скорость увы далека от современных норм.
ПАЗ я уж думал это автобус. При частоте 1Мб и возможности протокола прервать опрос и влезть со своей аварией как раз и можно в отличие от MODBUS где можно много секунд ждать следующего опроса одного следующего регистра. Пакет данных там слишком мелкий. КПД протокола ниже плинтуса
А 485 вообще для чего нормального то нужен? Для систем управления уровня предприятия, даже заморачиваться с ним не стоит.
Когда я работал в Газпроме на ГПЗ, у нас там по RS-485 соединялись в пределах установки шкафы системы вибромониторинга. От установки до серверной, конечно, шла оптика. Но вот на самой установки RS-485 показывал себя очень-очень хорошо, а источников помех там было предостаточно.
Уровнем ниже, там да — HART или токовая петля, чтобы данные с датчиков собирать.
P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
А еще громадная разница в требованиях к помехозащищенности, питанию и наличию репитеров. Сегмент в 100м vs 1300м например
проводов в кабеле 8 штук. 4 витые пары. прокладка их несоизмеримо дороже стоимости самого кабеля. В случае 485 репитеры до 1,2 км не требуются. При скорости 115200. Но можно для пущей защиты еще снизить скорость,
В отличие от MODBUS RTU в idiBus доля полезной части протокола выше потому что данные уже сформатированы на стороне slave. Что эквивалентно увеличению скорости.
Физически в кабеле две линии передачи. Но логически это просто две независимые шины
P. S. Оборудование для Ethernet и 485 примерно соизмеримы по стоимости, а вот прокладка 4 провод и 2 нет. Заказчик на проводах и питании разориться.
Вы вобще не знаете сколько стоит Ethernet и сколько стоит 485. Зачем вы пишите этот бред. RS-485 стоит раз в 50 дешевле Ethernet. Если вы не согласны предложите мне решение для Ethernet за 20 рублей. Потому что, что бы заработал 485 мне нужен простой драйвер, а что бы заработал Ethernet мне нужно ОЧЕНЬ много. Это касается и программного уровня, так и аппаратного.
И значительно дешевле и скорость неплохая на сегодня. И в нашем варианте питание подается отдельно. Ибо разницы в цене почти нет по протяжке проводов. Лапшу тянуть или Cat5
Вся проблема в RS485, питание надо передавать по тем же проводам, что и сигнал, никто не хочет тянуть 4 провода и наблюдать как весь сегмент падает при кз на одном датчик.
Совершенно необязательно. Шина — это 3 провода: A, B и GND для выравнивания потенциалов. Можете локально запитать устройства и объединить GND локального БП с GND шиной.
Сколько устройств вы так запитаете и на какое расстояние сможете передать?
Закон ома разве отменили? 40 штук, например, на обычной UTP. Две пары - под питание, одна под шину одна - в резерве.
Ну и UTP - не очень и дорог.
на тесте было 1,5 км дальность на 115200 и 10 метров при 10Мбит.
Записать можно до 3 ампера тока. При 50 мА на устройство это 60 штук. При 20 мА 150 штук. далее надо добавлять блок поддержки питания.
Локально конечно можно что угодно питать. Но мы в варианте с контролем питания шины можем применяться во взрывоопасных зонах так как контроль тока с нашей стороны. И можем не усложнять установку если просто на какой-то части устройств на шине не подводить туда еще и 220
А есть шины, которые продолжат работать при КЗ на проводах?
Я может неправильно выразился. Но имел ввиду, звмыкание между приёмом и передачей из за разницы потенциалов на устройствах, при использовании разных земель.
А есть шины, которые при разных землях работают и без гальванической изоляции?
RS485 так же никто не запрещает оптоизолировать.
Да, но как питание тогда подать по этим же проводам?
По линиям A B? никак. Или вы хотите и изоляцию, и питание по проводам от мастера? Блок питания изолирующий можно поставить при желании, но это никогда не нужно на самом деле: если вы запитываете от линии, то и земля общая. Можно нафантазировать, что у вас устройство, которое требует подключение к земле локальной, при этом там сэкономили на изоляции той части которая требует подключения к земле, и вы не можете организовать локальное питание... но это фантазии какие-то, в реальной жизни такого нет.
Да. Некоторые разновидности CAN могут работать по однопроводной схеме в качестве аварийного режима, в случа КЗ на одной из линий. Или даже на КЗ шин. Естественно, что нужно правильная схемотехника, чтобы исключить вторичные эффекты и каскадные отказы. Используется во всяких ответственных применениях. При желании и наличии знания повторяется на стандартном CAN при помощи нехитрого и недорого велосипеда.
Для RS-485/422 тоже есть, кстати, отказоустойчивые варианты с работой по одной шине данных.
Пока 485 тупиком никто не считает кроме вас. Самый популярный интерфейс в приборах на сегодня.
Если убрать всякое про "русскую национальную систему", поднятие с коленушек и прочее - то был бы интересный студенческий проект.
спецификация которого будет бесплатна для всех желающих
Это хорошо, можно ссылку на спецификацию?
Вот да, ну и пример под RTOS или baremetal, интересно в код глянуть.
Можно не ссылку а спецификацию. Надо написать письмо на info@idibus.com, представится и получить спецификацию и примеры.
То есть это закрытый клуб? Я потом смогу её опубликовать? Или, например, пощупать и написать статью с разбором?
Открытый клуб) милости просим. Но мы не Хабр и правила можем свои установить. Оно одно и вроде как не злое. Просто просим представиться. И если есть желание написать статью с разбором , то конечно неплохо сравнить с FIELDBUS, PROFIBUS, HART, CAN и самим MODBUS RTU.
Кстати вот ссылка на устройство в котором это все работает: www.aeftrade.eu/a12 - самый продвинутый в мир шкаф для замораживания еды.
И вот тут: www.pradox.info
Уже года три как тестируется.
Мы тут в РФ не можем себе позволить закрытые клубы. Рынок всего 1 процент от мирового и все контроллеры и шины импортные. А тиражи изделий - мелкосерийные. Это вот СВЧ печек китайцы каждой модели выпускают миллионы. А у нас такие тиражи только у счетчиков электричества и воды только.
И если есть желание написать статью с разбором , то конечно неплохо сравнить с FIELDBUS, PROFIBUS, HART, CAN и самим MODBUS RTU.
Прежде чем изобретать велосипед, стоило проделать эту работу самостоятельно.
Кстати, перечень существующих протоколов, и их функциональных возможностей, гораздо шире, чем у вас в "возможностях".
Ну и вероятно, протоколы сделаны каждый под свою задачу. А то тут сравнивают НПЗ и фанкойлы =)
Прежде чем изобрести велосипед, я вас уверяю были исследованы все имеющиеся тачки, самокаты, велосипеды и протоколы к ним.
И ничего из того что там было полезного не было упущено. Все реализовано или не хуже или лучше. Не сомневайтесь.
Но один взгляд хорошо, а несколько еще лучше.
Главный критерий всего действа - снижение стоимости разработки и стоимости уже готовых изделий. На это нацелена и система плат и система межплатных соединений и кабельная система и питание по кабелю и все остальное тоже.
Взять к примеру всеобразные датчики всего. Они или уже c MODBUS и уже дорогие или 0-10В и дешевые. В нашей версии мы берем модуль 0-10В с четырьмя каналами и подключаем 4 датчика. А не 4 отдельных датчика с MODBUS.
А у всех MODBUS нет стандартного разъема. И стандартной цоколевки, И вот вы уже комбинируете аппаратный зоопарк. Который безусловно гарантирует появление ошибок.
Если все сложить вместе то idiBus в каждом аспекте создания устройства дешевле. А вся сложность устройств на шине переложена на плечи разработчика устройства. Которое лучше него никто не знает. А со стороны АСУ оставлена только логика управления. Каждый занимается своим делом.
И ничего из того что там было полезного не было упущено. Все реализовано или не хуже или лучше. Не сомневайтесь.
Неужели?
Навскидку не вижу автоматической синхронизации времени слейвов, отложенной передачи данных (с метками времени) после потери связи, того же комтрейда
а в слейвах нет времени. вот мы тут все сидим сейчас а где-то проектируют датчик давления. Без времени. Работает по факту запроса.
В базовом протоколе именно поэтому нет синхронизации времени.
Одновременность решена возможностью объединения в группы и отправка групповой команды сразу всем членам группы.
Отложенная передача данных откуда и куда? Если потеря связи то мастер стучит и потом докладывает что не достучался. Это не часть протокола. Это ошибка связи. А отложенной передачи из слейва нет. Есть передача больших пакетов данных (состоящих из более чем одного модуля данных) с подтверждением получения очередного пакета.
Есть в качестве устройства на шине например уже готовый модуль логгирования. Там стоит флешка и часы реального времени.
В нем же можно хранить переводы текстовых значений для кодов ошибок для разных языков. Коды и индексация языков тоже стандартизированы.
Кстати кто такой комтрейд? я приезжий не все слова еще знаю
Протокол это некий вид насилия над разработчиком устройства. Возьмем тот же файнкойл с вентилятором который подключен к уже упомянутому частотнику DANFOSS FC-51. А вас есть некая система EMERSON которая имеет MODBUS. Каким образом вы будете ветер регулировать? Начнете читать спецификацию этого конкретного устройства. В котором есть полно всякого не нужного вам мусора. Ибо частотник этот набит функциями которые к вам отношения не имеют. И для вашей, внешней для DANFOSS среды, никаких драйверов не существует. Как говорится "читайте мануал". Но Данфос то хочет что бы вы на него перешли. Ну и вот сиди и разбирайся в документации. И неплохо бы еще и не наделать при этом ошибок.
А вот если DANFOSS некая сила заставит создать отлаженный драйвер (библиотеку), которую можно будет загрузить в EMERSON, то будет красота. Но ее нет и не предвидится.
Мы же решаем задачу унификации и как раз избегаем изобретения велосипеда. а точнее его разработки. Базовый модуль с протоколом уже есть. И он уже все что надо передает и все функции выполняет. Разработчику устройства требуется дописать только то, что относится к его устройству.
Причем даже понимать не надо как устроена транспортная часть.
Производишь датчики с интерфейсом 0-10В ? Минимальные усилия - и ты в цифровой среде idiBus. ЭКОНОМИЯ.
Может не стоит лезть в незнакомые понятия? У компании данфосс нет промышленных ПЛК (только климат), потому они наиболее заинтересованы в открытости к сторонним системам.
А о каком Эмерсоне мы говорим? DeltaV, ROC или Ovation (или вновь купленные VersaMax), там все по-разному.
У меня партнер был 10 лет главным импортером Эмерсона. Теперь вот сложности с импортом.
Мы говорим о том, что данфосс не дает Драйверов. Ибо в мире компов есть линукс яблоко и виндовс. и как-то драйверы люди пишут к этому.
А в мире омронов и эмерсонов даже внутри эмерсонов все по-разному.
Филдбасы придумали новый разъем и новый провод. Который у нас вообще некому произвести.
В РФ явно требуется момент объединения под одну крышу всем.
Рынок наш настолько мал и настолько занят иностранцами, что своего мы никогда не сделаем если не объединимся хотя бы при АСУ хотя бы какой-то большой части устройств.
Пока в РФ никто не готов заменить систему управления вентиляцией очистного здания. Ибо там много устройств.
Можно или уходить к китайцам (корейцы тоже вон санкции устроили) или левый импорт делать.
Но нам больше нравится вариант - откусывать от иностранного АСУ куски в пользу наших разработчиков аппаратуры. и датчиков и Серв и контроллеров.
Наша идея - более простое проектирование с широким кругом программистов на стандартных языках. и более дешевые устройства. совместимость обратная с MODBUS.
Что бы выпустить какие-то датчики давления или влажности или еще чего-то надо и сам датчик и его оцифрить.
Мы даем цифру. Дешево и сердито. И любой студент может программировать все это.
Позже подцепимся к SCADA какому-то открытому.
Если государство довело эту сферу до того, что ни одного ЖК экрана в стране сенсорного не производится и прости господи сотни миллионов тратятся на контроллеры типа "БАГЕТ", то кто-то должен начать процесс объединения национальных разработчиков.
И глупо при этом не воспользоваться тем, что за 40 лет цифра стала такая дешевая, что можно ее в сигареты засовывать.
В РФ промышленное оборудование, которому надо АСУТП всегда малые серии. Рынок такой и никто не умеет ничего экспортировать.
idiBus решает задачу удешевления этой автоматики. От лифтов и станков до теплиц и бетономешалок.
Вот частотники - хороший пример, что это те же яйца, вид сбоку. У него дохрена параметров - ну штук 150. Из них надо поменять от заводских настроек например 3 - захотелось вот пониженным напряжением питать, время торможения разгона задать, например. Сейчас открываешь документацию, ищешь в этой огромной таблице нужные, читаешь что до как. Как будет в вашем протоколе: открываешь документацию на протокол, ищешь как же там названы нужные параметры, открываешь документацию на частотник, ищешь информацию по ним что да как. Итого нихрена не проще.
Отнюдь. список функций всяко проще списка функций плюс таблица адресов и регистров. плюс надо еще написать некую функцию для установки этих регистров и не ошибиться.
вызвать setСкоростьТорможения(%) и удобнее и контроль ошибок доступен. Модуль idiBus выдаcт специальный тип ошибки - что разработчик задал значение вне диапазона.
а в протокол вы запихнете все возможные функции любых частотников?
в протоколе только базовый набор функций. В этом наборе вообще нет ничего про передачу конкретных данных. И есть способ для расширения числа функций. Их самих в протоколе нет но процесс их обслуживания уже есть. предусмотрено количество функций от 1 до 219. И есть набор стандартных для всех модулей команд. Init, Shutdown, Sleep.
Набор данных для каждой функции может быть большим. И ответ от частотника тоже.
Приборы которые имеют MODBUS можно непосредственно подключать. И пользоваться как обычно. Регистры и все прочее. Можно миксовать на одной линии. И постепенно менять иностранное на наше.
Дмитрий это классная идея. Судя по успеху wirenboard. Главное что бы продуктом можно было пользоваться и тогда успех точно придёт.
Но если речь идёт о сообществе думаю сразу стоит начать вести ТГ канал, что бы вокруг себя собрать единомышленников.
Например Aspia (замена Teamviewr) - https://aspia.org/
Экспорт... Обратите внимание, какая надпись на мече у первого в ряду жлоба:
https://images.theconversation.com/files/460800/original/file-20220502-22-lj0on0.png
Сначала - надо будет вытеснить их из своего дома.
Привет коллегам по цеху, спасибо за статью — интересно, но она породила больше вопросов, чем ответов.
Но если нужно в разных местах одновременно произвести замер неких величин, то можно объединить устройства в общую логическую группу и затем дать всей группе команду на считывание.
Очень интересно про логические группы — расскажите, как вы это реализовали?
В протоколе имеется временное окно, в которое может обратится 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 км не получится — чем дальше, тем медленнее, физика. Как вы решили это?
Наверняка большую часть вопросов снимет подробное описание протокола, но ссылки на него я, к сожалению, не нашёл.
Придется вставить все вопросы еще раз что бы дать ответы
Добавлю еще что на той же физической шине можно ставить и 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-45
idiBus имеет на шине две одинаковые линии RS-485. Каждая из которых может работать с разной скоростью. При скорости 115200 Бит/с дальность связи составит 1,2 км. А при скорости 10 МБит/с – 10метров. Таким образом скоростной вариант можно использовать для работы внутри устройства или установки, а более медленный для работы в масштабе предприятия.
Как-то сложно, зачем две линии? Тянем далеко, ставим скорость поменьше. Собираем щит, ставим скорость побольше. Ну и 115200 бит/с на 1,2 км не получится — чем дальше, тем медленнее, физика. Как вы решили это?
Это мы и решили двумя линиями. Одна рассчитана на скорость и работу внутри установок, а вторая - внешняя на длинные линии. Есть еще разветвитесь 1/4. Можно шину удлинить или разветвить. 115200 на лапше на 1,2 км не получается, а на витой паре работает.
Наверняка большую часть вопросов снимет подробное описание протокола, но ссылки на него я, к сожалению, не нашёл.
Добавлю еще что на той же физической шине можно ставить и 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, представится и получить спецификацию и примеры.
Написал письмо, посмотрим, насколько вы честны с аудиторией Хабра и самим собой.
"А как устройство понимает, что оно не одно передаёт? Слушать шину в 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
С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)
Оно не понимает что одно. Оно не получит подтверждение, что его сообщение дошло.
Это всё ещё не ответ. Расскажите, как вы смогли организовать доставку ответа устройства до мастера, если на шине одновременно начали передавать несколько устройств. Как вы обошли физические ограничения шины?
С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)
Не смешно. Доверие надо заслужить. Я написал письмо, ответа нет. Странная открытость.
я ответил на одно письмо уже с приложением спецификаций. с какого адреса было Ваше? не дошло пока.
Если Слейву надо обратиться к мастеру, то он в специальном окне выставляет запрос со своим адресом.
Мастер видит, что есть сообщение типа ALARM и знает от кого. И уже начинает со своей стороны выяснять что там произошло прямо следующим обращением к слейву. И слеву дает информацию, что его сообщение дошло.
Если слейвов несколько то сообщения они накладывают одно на другое Так как формат сообщения одинаковый но отличается адрес и CRC то мастер ничего им не отвечает и продолжает свой цикл опроса.
Все слейвы, которые не получили немедленного к себе запроса, но находящиеся в состоянии ALARM будут повторять свой выход на линию. Но каждый из них сделает случайную паузу от нуля до нескольких пакетов. То есть они разойдутся по времени. Такой же механизм и в других протоколах используется.
с какого адреса было Ваше
С @wirenboard.com писал от своего имени, оно есть в профиле на Хабре.
Пробежал заголовок по диагонали. Не увидел ключевое слово "драйвер".
Видимо попалась не та диагональ ) Но "драйвер" это больше термин из операционок. А в нашем случае это скорее библиотека. Хотя драйвер звучит конечно круче.
Я не о том. MODBUS не перепиливал только ленивый. Я о возможности подключения вашей библиотеки к чему-то стандартному, что есть на рынке.
Мы реализовали некий подход в этом вопросе. На шину idiBus можно насажать наши готовые модули для работы с датчиками и устройствами с интерфейсами 0-10В, 4-20мА, iWire и другими. И это все по своему протоколу. Что-то даже можно по шине обеспечить и питанием. Но на эту же физическую линию можно прикрутить и любые готовые устройства которые работают на MODBUS RTU и с ними тоже работать. У них адреса отличаются и размеры фреймов. Это специально сделано, что бы можно было любыми готовыми изделиями с рынка пользоваться используя те же кабели и те же библиотеки.
Мы реализовали некий подход в этом вопросе. На шину idiBus можно насажать наши готовые модули для работы с датчиками и устройствами с интерфейсами 0-10В, 4-20мА, iWire и другими. И это все по своему протоколу. Что-то даже можно по шине обеспечить и питанием.
Вы так говорите, как буд-то это ноу-хау какое. Но ведь так делают все: есть контроллер, есть периферия и к периферии подключаются контакторы, лампочки, датчики с аналоговым выходом и т.п.
А сколько и каких датчиков вы сделали ?
Или мне надо нужные мне датчики переделывать под ваш протокол ?
Можно свои датчики подключать к интерфейсным модулям.
Интерфейс 485 вполне не плох. Протоколов по нему огромное количество. Ваш протокол - не плохая задумка. К сожалению, куча производителей лепят что хотят. Встречал такие варианты, когда не было контрольной суммы и не использовались даже биты четности (приходилось данные прогонять через медианный фильтр для исключения некорректных данных, вызванных помехами).
Создавал свой протокол, который мог пройти через трансформаторную развязку. Приходилось подмешивать дополнительные биты, что бы искусственно создать "перемену" (но умудрились в эти избыточные биты фактически поместить аналог контрольной суммы). Позже перешли на оптику.
Качество реализации 485 тоже разное. Для проверки используем мощный пускатель, плохой (крайне шумный) частотник и сломанную пьезозажигалку (бьём по контактам). Бывает именитые фирмы не выдерживают проверок, а "самоделки" отделываются испугом (отбрасывают сбойный пакет).
Но в 2020 году ситуация стала абсолютно обратной...
На складах исчезли контроллеры, а жадные продавцы подняли цены 10х
Вспоминается жуткий протокол от Шнайдер - Modbus Plus. Работать с ним можно только через фирменный интерфейсный модуль за бешеные деньги.
достаточно спорная статья.
какие вопросы описано в статье решает предлагаемый новый протокол:
Шифрование.
Обновление прошивок по шине..
Одновременное считывание показаний
Внеочередное обращение к 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 системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf
Обновление прошивок возможно как и вовсе передача любых данных в пакетах. Однако есть разница между единым механизмом и чисто теоретической возможностью которую каждый реализует по-разному. В idiBus вы можете узнать у устройства оно вообще имеет прошивку или нет? это обязанность устройства так как часть протокола.
Выдачу данных через сервер конверсии бит в физические величины можно применять вообще с любым устройством. Взяли слева биты и послали направо. и справа пришли значения. Но тут то речь идет о том, что само устройство уже вполне может это делать и само цена этой функции - ноль так как в любом устройстве уже стоит чип как в телефоне.
Можно уже в тетрис играть на датчиках давления.
Коллизии разруливаются как в других протоколах.
К мастеру можно обращаться вне очереди. В случаях повышения или снижения давления, температуры или по любой срочной надобности что бы не ждать своей очереди в опросе.
Групповые опросы масками не решить. Это механизм для разных устройств. Любого типа. В физических процессах часто надо мерять не один параметр а несколько но нужны их значения именно в один момент времени. Когда они динамичны. Например давление и температура. Измерение происходит в один момент, а получение этих данных может быть и последовательное.
Безопасный режим это способ сохранения системы если имеются сбои и надо ввести систему или ее часть в состоянии когда она своими действиями не может себя разрушить.
Совместимость по линии это означает что логика протокола такова, что к стоящим на линии устройствам MODBUS можно от мастера обращаться без изменения логики и без изменения физики. Устройства MODBUS просто не замечают траффика idiBus.
хм...
"""Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf"""
Сначала наверно стоит ознакомиться со Всеми Спецификациями, чтобы не выдёргивать из конеткста. Благо сайт modbus.org известен, и раздел Технических спецификаций там один. Чтобы понимать что шифрование по необходимости есть.
Ну а самые большие проблемы с протоколом описаны в конце, и собственно лишают новые протоколы всякого смысла - цитата
"""
И да, протокол Modbus это не только библиотеки опросчиков на абсолютно разных языках, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
"""
Всегда что-то начинается и заканчивается. Пока мы видим путь внедрения в устройства, а не в большие системы. Станки и теплицы. Зарядные станции и вообще всякое оборудование.
За последние годы появился далеко не один протокол и строить прогнозы об успешности явно рано. Проблема российских протоколов и вообще всех разработок это русский язык. Потому что его никто не знает и весь мир пользуется английским.
Наши кое=как выучили английский, но заставить иностранцев учить русский невозможно. А для целого протокола одной России маловато. И это более важно чем новизна чего бы то ни было из РФ.
А со всеми спецификациями мы ознакомились по всем наиболее популярным протоколам. И CAN и HART и прочие FIELDBUS.
Взяли все лучшее постарались снизить влияние природных недостатков таких как Master-Slave например.
А "по необходимости" поверх любого протокола можно натянуть что угодно. Хоть шифрование хоть передача видео. Можно даже в протоколы туннели включать. В мастер-слейвы элементы peer-to-peer. Только управлять этой бедой крайне сложно.
На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы.
"""На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы. """
это ещё и обучение и постоянный, наработанный годами штат поддержки.
и тут вообще каждое слово можно написать с большой буквы.
А так то не понятно, ну допустим у Вас умные устрйства с большими процессорами. ну так положите на них opc_ua и не надо ничего нового изобретать. возьмите любой другой уже подходящий протокол. Изобретение нового это дело достаточно неблагодарное. Потому что у Вас видение какого то маленького, достаточно узкого участка АСУ- ТП. я к примеру вот не могу даже представить себе где нужно одновременное начало измерения температуры, передавать по 485-му. а Вы не можете представить к примеру количество опс приборов с опросом 24/7/385, по отношению к асу-тп.
Как раз наоборот. Наши устройства с самыми дешевыми контроллерами 8 бит и этого достаточно и на преобразование форматов и на поддержку протокола. Это в заголовке статьи. Цена на цифру сегодня буквально ноль. В отличие от какого-нибудь встраиваемого датчика давления.
Огромная масса дачников выпускается сейчас с интерфейсами 0-10 или 4-20.
И коробочка с цифровизацией добавляет к цене 10 процентов. И пожалуйста уже можно пользовать. И в приборах внутри корпуса и удаленно.
Скажу даже, что излучался вопрос о том, что бы на этом всем управление судами сделать.
И никаких противопоказаний не обнаружилось.
Другой протокол по сумме затрат на все части процесса - от проектирования до обслуживания и от изготовления самих контроллеров до их корпусов дороже. Прибавим еще затраты на монтаж устройств в каждом из которых своя распиновка подключения вместо унифицированных разъемов. Зарплаты программистов отличаются на разных языках. Соберется общая цена.
Количество приборов я вполне могу представить. Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий.
Вот там кстати надо температуру знать. И разницу давлений при открытии заслонок и влажность. Потому что это такой огромный PID регулятор по факту.
А изобретения вообще дело неблагодарное. У меня есть международный патент к примеру. Так и денег и сил это стоит неразумных.
и при управлении приточкой желательно измерять температуру и управлять кзр-ом как можно медленней.
Чисто для информации. Я - дипломированный магистр по климатической технике. Кроме того что радиоинженер.
вот поэтому и интересно, где в климатической технике, даже теоретически - может возникнуть требование запроса измерений, выполняемых одновременно.
В моей вселенной это вот что что, но климатика настолько инерционна, что некоторые параметры измерять даже раз в секунду - это весьма и весьма быстро. а уж управлять кзр-ом так вообще.
Поэтому такое требование - в виде одновременных измерений - звучит Диссонансом с климатическими системами.
Чисто для информации к примеру сигнетикс не свои алгоритмы не сами писали а списывали с некоторых давно выпускаемых серийно контроллеров. Это не существенней дипломов, зато уровень компетенций не пропиваемый.
Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий.
Ну с таким бэкграундом надо было наверное еще посмотреть EIB/KNX, BACNet, Lonworx, Carel. Там совсем другие подходы и требования.
Не виже почвы для диалога. Есть "ардуинщики", которые не любят читать мануалы, и есть "головастики", которые любят читать и зрить в корень. Их спор риторический (бесконечен). С другой стороны, я вспоминаю как НЕ мог договориться с коллегами-схемотехниками, об общей распиновке (RxD...TxD...) - даже в своих платах они лепили по-разному. Просил файл дефайнов с их регистрами/кличками (кажну неделю ведь всё меняете) - "я ж тебе писал на бумажке месяц назад"..так ты вчера опять поменял табличку..а, ну допиши там...
ModBus можно расширять бесконечно, что и делают кто во что горазд, так что унификация/стандартизация дело благое.
Минусаторы,как всегда,жгут...человек вообще ничего ещё не сказал (по существу), ни одной плюшки не просмаковал - обминусили с ног до головы.("ВСЕ наши проблемы лежат в области нравственности" - Путин ВВ.)
Почему мы решили обновить протокол MODBUS RTU, которому исполнилось 40 лет и как появился его потомок – idiBus