я в курсе. но они имеют тенденцию кого-то выгнать, что-то закрыть и вообще затеять санкции. Это люди из страны агрессора. Поэтому там все российское может прямо завтра пропасть.
Токовая петля это интерфейс 4-20 мА. Ток пускают и датчик его регулирует. И поскольку это ток, то оно может на любых расстояниях работать так как ток он один и тот же во всей цепи. Когда дошло до протоколов а не просто замеров тока, то по тем ж проводам пустили еще и переменный ток. И получился протокол HART. Но там частоты такие, что он очень медленный. https://dzen.ru/a/ZSjeV4NlVBw522z_
Протокол это некий вид насилия над разработчиком устройства. Возьмем тот же файнкойл с вентилятором который подключен к уже упомянутому частотнику DANFOSS FC-51. А вас есть некая система EMERSON которая имеет MODBUS. Каким образом вы будете ветер регулировать? Начнете читать спецификацию этого конкретного устройства. В котором есть полно всякого не нужного вам мусора. Ибо частотник этот набит функциями которые к вам отношения не имеют. И для вашей, внешней для DANFOSS среды, никаких драйверов не существует. Как говорится "читайте мануал". Но Данфос то хочет что бы вы на него перешли. Ну и вот сиди и разбирайся в документации. И неплохо бы еще и не наделать при этом ошибок. А вот если DANFOSS некая сила заставит создать отлаженный драйвер (библиотеку), которую можно будет загрузить в EMERSON, то будет красота. Но ее нет и не предвидится. Мы же решаем задачу унификации и как раз избегаем изобретения велосипеда. а точнее его разработки. Базовый модуль с протоколом уже есть. И он уже все что надо передает и все функции выполняет. Разработчику устройства требуется дописать только то, что относится к его устройству. Причем даже понимать не надо как устроена транспортная часть. Производишь датчики с интерфейсом 0-10В ? Минимальные усилия - и ты в цифровой среде idiBus. ЭКОНОМИЯ.
Прежде чем изобрести велосипед, я вас уверяю были исследованы все имеющиеся тачки, самокаты, велосипеды и протоколы к ним. И ничего из того что там было полезного не было упущено. Все реализовано или не хуже или лучше. Не сомневайтесь. Но один взгляд хорошо, а несколько еще лучше. Главный критерий всего действа - снижение стоимости разработки и стоимости уже готовых изделий. На это нацелена и система плат и система межплатных соединений и кабельная система и питание по кабелю и все остальное тоже. Взять к примеру всеобразные датчики всего. Они или уже c MODBUS и уже дорогие или 0-10В и дешевые. В нашей версии мы берем модуль 0-10В с четырьмя каналами и подключаем 4 датчика. А не 4 отдельных датчика с MODBUS. А у всех MODBUS нет стандартного разъема. И стандартной цоколевки, И вот вы уже комбинируете аппаратный зоопарк. Который безусловно гарантирует появление ошибок. Если все сложить вместе то idiBus в каждом аспекте создания устройства дешевле. А вся сложность устройств на шине переложена на плечи разработчика устройства. Которое лучше него никто не знает. А со стороны АСУ оставлена только логика управления. Каждый занимается своим делом.
проводов в кабеле 8 штук. 4 витые пары. прокладка их несоизмеримо дороже стоимости самого кабеля. В случае 485 репитеры до 1,2 км не требуются. При скорости 115200. Но можно для пущей защиты еще снизить скорость, В отличие от MODBUS RTU в idiBus доля полезной части протокола выше потому что данные уже сформатированы на стороне slave. Что эквивалентно увеличению скорости. Физически в кабеле две линии передачи. Но логически это просто две независимые шины
Да аруинко вообще отличная вещь. Я про саму среду. Но хочу сказать про всякие датчики. Имеется много разных устройств и датчиков, которые НЕ MODBUS. Они 0-10В, 4-20мА, 1Wire и прочие интерфейсы. В нашем случаем имеется модуль интерфейса, который уже имеет все фунции протокола. И мы берем и добавляем поверх готовой библиотеки только ту часть, которая из этих интерфейсов делает сразу физические величины. Ну или команды если это что-то командное. И такие все цифро-аналоговые датчики типа той же термопары становятся цифровыми устройствами на шине. Вся базовая часть протокола уже написана. Остается кусочек дописать и залить прошивку в готовый уже интерфейсный модуль,
Мы реализовали некий подход в этом вопросе. На шину idiBus можно насажать наши готовые модули для работы с датчиками и устройствами с интерфейсами 0-10В, 4-20мА, iWire и другими. И это все по своему протоколу. Что-то даже можно по шине обеспечить и питанием. Но на эту же физическую линию можно прикрутить и любые готовые устройства которые работают на MODBUS RTU и с ними тоже работать. У них адреса отличаются и размеры фреймов. Это специально сделано, что бы можно было любыми готовыми изделиями с рынка пользоваться используя те же кабели и те же библиотеки.
Открытый клуб) милости просим. Но мы не Хабр и правила можем свои установить. Оно одно и вроде как не злое. Просто просим представиться. И если есть желание написать статью с разбором , то конечно неплохо сравнить с FIELDBUS, PROFIBUS, HART, CAN и самим MODBUS RTU. Кстати вот ссылка на устройство в котором это все работает: www.aeftrade.eu/a12 - самый продвинутый в мир шкаф для замораживания еды. И вот тут: www.pradox.info Уже года три как тестируется. Мы тут в РФ не можем себе позволить закрытые клубы. Рынок всего 1 процент от мирового и все контроллеры и шины импортные. А тиражи изделий - мелкосерийные. Это вот СВЧ печек китайцы каждой модели выпускают миллионы. А у нас такие тиражи только у счетчиков электричества и воды только.
Видимо попалась не та диагональ ) Но "драйвер" это больше термин из операционок. А в нашем случае это скорее библиотека. Хотя драйвер звучит конечно круче.
Так это вы не по ним шьете а поверх. Или я не правильно понял? в idiBus изначально может стоять на шине прибор вообще без прошивки. Только с той частью, что содержит протокол. И можно влить именно по нему прошивку. Причем не прерывая работу самого протокола для всех других устройств.
Придется вставить все вопросы еще раз что бы дать ответы
Добавлю еще что на той же физической шине можно ставить и 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 км не получается, а на витой паре работает.
Наверняка большую часть вопросов снимет подробное описание протокола, но ссылки на него я, к сожалению, не нашёл.
Причины изложены в тексте. Основных несколько. Вы когда драйвер принтера ставите то это же драйвер. Все что надо уже есть внутри. Знать внутренние подробности не требуется. Что бы работать сразу с физическими величинами и кодами ошибок вам надо поверх регистрового трафика написать библиотеки и дать их пользователю. Что бы ему не изучать способы извлечения конкретных данных их конкретного прибора или в обратную сторону как ему давать команды. И можно эти библиотеки разместить на стороне мастера, а можно на стороне слейва. На Мастер можно и ARM поставить для управления и логикой и протоколом. Но регистровый протокол удваивает и утраивает загрузку канала. Я уже не говорю что люди умнеют и исправляют ошибки. А по MODBUS новую прошивку то никак не загрузить. Таким образом для облегчения труда и сокращения и сроков явно нужны библиотеке. Выбор лишь с какой стороны будет обработка. Мы сложили все факторы и посчитали что уже можно это делать со стороны SLAVE. Нет аргумента по которому выгоднее делать обработку на стороне MASTER. Есть и еще одна причина. Разработчик конечного устройства на шину всяко лучше знает свое устройство чем разработчик системы. И в как в объектном программировании полезно скрыть от пользователя детали реализации. И также избавить его от трудозатрат на этот процесс.
ПАЗ я уж думал это автобус. При частоте 1Мб и возможности протокола прервать опрос и влезть со своей аварией как раз и можно в отличие от MODBUS где можно много секунд ждать следующего опроса одного следующего регистра. Пакет данных там слишком мелкий. КПД протокола ниже плинтуса
Вы видимо не все прочли коли советуете библиотеки для протокола. Речь идет о библиотеках для устройств на шине. А я их что-то не наблюдаю пока. Вот к примеру мне надо вентилятор подключить через популярный частотник DANFOSS FC-51. Не подскажете где мне взять такую библиотеку, что бы задать скорость 80 процентов от Максимума? Думаю нигде их нет. А включить два насоса одновременно? одной командой? Или вам надо податься в экосистему DANFOSS если ее достаточно и цены устраивают или открывать документацию и приступать к изучению регистров и к отладке. Мы же не о серии говорим а о разработке. Ну и передача огромного числа регистров не добавляет скорости обмена.
я в курсе. но они имеют тенденцию кого-то выгнать, что-то закрыть и вообще затеять санкции. Это люди из страны агрессора. Поэтому там все российское может прямо завтра пропасть.
Токовая петля это интерфейс 4-20 мА. Ток пускают и датчик его регулирует. И поскольку это ток, то оно может на любых расстояниях работать так как ток он один и тот же во всей цепи. Когда дошло до протоколов а не просто замеров тока, то по тем ж проводам пустили еще и переменный ток. И получился протокол HART. Но там частоты такие, что он очень медленный.
https://dzen.ru/a/ZSjeV4NlVBw522z_
Протокол это некий вид насилия над разработчиком устройства. Возьмем тот же файнкойл с вентилятором который подключен к уже упомянутому частотнику DANFOSS FC-51. А вас есть некая система EMERSON которая имеет MODBUS. Каким образом вы будете ветер регулировать? Начнете читать спецификацию этого конкретного устройства. В котором есть полно всякого не нужного вам мусора. Ибо частотник этот набит функциями которые к вам отношения не имеют. И для вашей, внешней для DANFOSS среды, никаких драйверов не существует. Как говорится "читайте мануал". Но Данфос то хочет что бы вы на него перешли. Ну и вот сиди и разбирайся в документации. И неплохо бы еще и не наделать при этом ошибок.
А вот если DANFOSS некая сила заставит создать отлаженный драйвер (библиотеку), которую можно будет загрузить в EMERSON, то будет красота. Но ее нет и не предвидится.
Мы же решаем задачу унификации и как раз избегаем изобретения велосипеда. а точнее его разработки. Базовый модуль с протоколом уже есть. И он уже все что надо передает и все функции выполняет. Разработчику устройства требуется дописать только то, что относится к его устройству.
Причем даже понимать не надо как устроена транспортная часть.
Производишь датчики с интерфейсом 0-10В ? Минимальные усилия - и ты в цифровой среде idiBus. ЭКОНОМИЯ.
Прежде чем изобрести велосипед, я вас уверяю были исследованы все имеющиеся тачки, самокаты, велосипеды и протоколы к ним.
И ничего из того что там было полезного не было упущено. Все реализовано или не хуже или лучше. Не сомневайтесь.
Но один взгляд хорошо, а несколько еще лучше.
Главный критерий всего действа - снижение стоимости разработки и стоимости уже готовых изделий. На это нацелена и система плат и система межплатных соединений и кабельная система и питание по кабелю и все остальное тоже.
Взять к примеру всеобразные датчики всего. Они или уже c MODBUS и уже дорогие или 0-10В и дешевые. В нашей версии мы берем модуль 0-10В с четырьмя каналами и подключаем 4 датчика. А не 4 отдельных датчика с MODBUS.
А у всех MODBUS нет стандартного разъема. И стандартной цоколевки, И вот вы уже комбинируете аппаратный зоопарк. Который безусловно гарантирует появление ошибок.
Если все сложить вместе то idiBus в каждом аспекте создания устройства дешевле. А вся сложность устройств на шине переложена на плечи разработчика устройства. Которое лучше него никто не знает. А со стороны АСУ оставлена только логика управления. Каждый занимается своим делом.
проводов в кабеле 8 штук. 4 витые пары. прокладка их несоизмеримо дороже стоимости самого кабеля. В случае 485 репитеры до 1,2 км не требуются. При скорости 115200. Но можно для пущей защиты еще снизить скорость,
В отличие от MODBUS RTU в idiBus доля полезной части протокола выше потому что данные уже сформатированы на стороне slave. Что эквивалентно увеличению скорости.
Физически в кабеле две линии передачи. Но логически это просто две независимые шины
нам чужды творения Микрософт.
Да аруинко вообще отличная вещь. Я про саму среду.
Но хочу сказать про всякие датчики. Имеется много разных устройств и датчиков, которые НЕ MODBUS. Они 0-10В, 4-20мА, 1Wire и прочие интерфейсы. В нашем случаем имеется модуль интерфейса, который уже имеет все фунции протокола. И мы берем и добавляем поверх готовой библиотеки только ту часть, которая из этих интерфейсов делает сразу физические величины. Ну или команды если это что-то командное. И такие все цифро-аналоговые датчики типа той же термопары становятся цифровыми устройствами на шине. Вся базовая часть протокола уже написана. Остается кусочек дописать и залить прошивку в готовый уже интерфейсный модуль,
Мы реализовали некий подход в этом вопросе. На шину idiBus можно насажать наши готовые модули для работы с датчиками и устройствами с интерфейсами 0-10В, 4-20мА, iWire и другими. И это все по своему протоколу. Что-то даже можно по шине обеспечить и питанием. Но на эту же физическую линию можно прикрутить и любые готовые устройства которые работают на MODBUS RTU и с ними тоже работать. У них адреса отличаются и размеры фреймов. Это специально сделано, что бы можно было любыми готовыми изделиями с рынка пользоваться используя те же кабели и те же библиотеки.
Открытый клуб) милости просим. Но мы не Хабр и правила можем свои установить. Оно одно и вроде как не злое. Просто просим представиться. И если есть желание написать статью с разбором , то конечно неплохо сравнить с FIELDBUS, PROFIBUS, HART, CAN и самим MODBUS RTU.
Кстати вот ссылка на устройство в котором это все работает: www.aeftrade.eu/a12 - самый продвинутый в мир шкаф для замораживания еды.
И вот тут: www.pradox.info
Уже года три как тестируется.
Мы тут в РФ не можем себе позволить закрытые клубы. Рынок всего 1 процент от мирового и все контроллеры и шины импортные. А тиражи изделий - мелкосерийные. Это вот СВЧ печек китайцы каждой модели выпускают миллионы. А у нас такие тиражи только у счетчиков электричества и воды только.
Можно свои датчики подключать к интерфейсным модулям.
Видимо попалась не та диагональ ) Но "драйвер" это больше термин из операционок. А в нашем случае это скорее библиотека. Хотя драйвер звучит конечно круче.
Так это вы не по ним шьете а поверх. Или я не правильно понял? в idiBus изначально может стоять на шине прибор вообще без прошивки. Только с той частью, что содержит протокол. И можно влить именно по нему прошивку. Причем не прерывая работу самого протокола для всех других устройств.
Придется вставить все вопросы еще раз что бы дать ответы
Добавлю еще что на той же физической шине можно ставить и MODBUS устройства тоже. Протоколы физически и логически обратно совместимы.
И в idiBus две линии связи. Можно при необходимости использовать или обе как главную и резервную линии или можно одну линию использовать внутри прибора как скоростную, а вторую вне прибора для удаленных устройств но с меньшей скоростью. Адреса на каждой линии свои
Привет коллегам по цеху, спасибо за статью — интересно, но она породила больше вопросов, чем ответов.
Очень интересно про логические группы — расскажите, как вы это реализовали?
Поскольку каждое устройство имеет мозг, то мы ему даем стандартную команду - ты теперь член группы номер 5. Всем кому надо присваиваем номер группы и потом даем команду "группе 5 замерять то, что умеет замерять каждое из устройств". или "всем включать то что задано на включение". Дается команда не по индивидуальному адресу каждого устройства по очереди а команда "исполнить" по адресу группы.
Потом можно группу обратно разобрать. Есть еще групповые команды. Это если в устройстве есть несколько одинаковых каналов то им всем можно дать одну команду если параметры совпадают. Типа "на всех выходах выставить 12В"
«Временное окно» — это вы про 3,5 бита тишины? Как вы в этом случае разрешили коллизии? Ведь несколько устройство может начать одновременно отвечать и на шине получится кавардак.
Коллизии разрешаются примерно также как других протоколах. Если сунулся в окно более чем один прибор, то все они не получат ответа от Мастера. И тогда каждый сделает паузу случайного размера и когда будет следующая пауза то уже в нее полезут не все одновременно.
Что это значит? Расскажите, пожалуйста, подробнее.
Это смесь ошибок которые уже есть в MODBUS (10 шт) и ошибки обработки данных связанных с тем, что протокол не примитивный. В idiBus может передаваться бинарный пакет данных. Устройства могут исполнять команду по времени более длинную, чем длительность интервала опроса.
Ошибки 0-9 это буквально от MODBUS RTU
Ну неправда же — мы выпускаем сотнями тысяч штук простые устройства в РФ. Если надо партию прототипов из 10 штук — тоже нет проблем. И непонятно, как это связано с разработкой нового протокола.
Ну я не в математическом смысле сказал что "не выпускаются" а в экономическом.
По сравнению с Китаем у нас подавляющее большинство производств мелкосерийные.
Не понял в чём разница с программированием устройства под Modbus RTU. Ведь для него есть библиотеки, которые делают всю рутинную работу и программист пишет на языке верхнего уровня, оперируя понятными сущностями — регистрами или группой регистров. Все байтики, тайминги и прочее от него спрятано.
А мы предполагаем и дальше спрятать от программиста и регистры тоже. Сразу можно работать с физическими величинами. А есть там регистры или нет их это уже и не важно.
Тут речь про визуальное программирование?
Нет. Мы даем программисту набор устройств на который можно установить. их адрес. Это АЦП, Термометры, Амперметры, Счетчики и т. д. И программист обращается через библиотечную функцию к устройству с указанным адресом. И по этому адресу может запросить данные или дать команду.
Никаких сведений об устройстве ему не требуется кроме как что оно может и как это получить используя библиотеку. Все остальное скрыто внутри протокола.
Ему и ошибки все тоже выдаст протокол.
О, я пишу код для своих устройств в Ардуино — поделитесь библиотечкой?
Она одинаковая для Microchip Studio и Arduino. Сейчас реализация чипа на мастере это ATMEGA 2560 или 1280. Сейчас делаем то же под STM32.
Интересно. Обычно делают так: берут контроллер, берут периферию и собирают шкаф управления чем-то. Вы для каждого проекта разрабатываете с нуля свою автоматику?
И так тоже делаем если есть заказчик на прямо разработку своей платы. Если тираж изделий позволяет.
Но сейчас идем другим путем. Имеется базовый набор idiBus. Все это без корпусов потому что все и так внутри корпуса собирается. Имеется материнская плата с чипом в виде мезонина. и к ней подключаются уже по проводу платы расширения. на которых ставятся модули разных типов. Например есть модуль термопар. На 3 термопары К типа. Можем мерять три канала температуры. Если надо еще три то ставим еще модуль. Это если речь идет о непосредственном измерении. А есть модуль iWire, к которому например можно подключить термометры 18B20. И тогда к базовому драйверу этого модуля дописывается маленький кусок именно касающийся получения температуры. Остальное все что связано с протоколом уже стоит на модуле.
То же самое например модуль счетчика. Мы к нему прикручиваем расходомер и дописываем ту часть которая переводит импульсы счетчика в литры.
То же с модулем АЦП. 0-10В. Любой датчик с этим протоколом можно подключить и дописать минимальную часть, которая переведет эти вольты в физическую величину , которую датчик измеряет.
Сейчас уже есть модули памяти, часы, реле, UART.
К сожалению, я не представляю, как не зная железа и техпроцессов сделать продукт. В Modbus RTU это тоже #include и getCoil(ячейка с температурой/состоянием входа и т.п.).
Увы наша практика показала, что производители не торопятся делать универсальные библиотеки. Даже надо сказать и физически все устройства MODBUS RTU как в зоопарке.
Везде свои разъемы и распаковки. Мы же принудительно ограничили все обычным RJ-45
Как-то сложно, зачем две линии? Тянем далеко, ставим скорость поменьше. Собираем щит, ставим скорость побольше. Ну и 115200 бит/с на 1,2 км не получится — чем дальше, тем медленнее, физика. Как вы решили это?
Это мы и решили двумя линиями. Одна рассчитана на скорость и работу внутри установок, а вторая - внешняя на длинные линии. Есть еще разветвитесь 1/4. Можно шину удлинить или разветвить. 115200 на лапше на 1,2 км не получается, а на витой паре работает.
Наверняка большую часть вопросов снимет подробное описание протокола, но ссылки на него я, к сожалению, не нашёл.
Можно не ссылку а спецификацию. Надо написать письмо на info@idibus.com, представится и получить спецификацию и примеры.
Ну это уже без нас наложили. Но скорость увы далека от современных норм.
Можно черкнуть письмо на info@idibus.com, представиться и получить документацию. И описание готовых примеров.
Причины изложены в тексте. Основных несколько. Вы когда драйвер принтера ставите то это же драйвер. Все что надо уже есть внутри. Знать внутренние подробности не требуется. Что бы работать сразу с физическими величинами и кодами ошибок вам надо поверх регистрового трафика написать библиотеки и дать их пользователю. Что бы ему не изучать способы извлечения конкретных данных их конкретного прибора или в обратную сторону как ему давать команды. И можно эти библиотеки разместить на стороне мастера, а можно на стороне слейва.
На Мастер можно и ARM поставить для управления и логикой и протоколом. Но регистровый протокол удваивает и утраивает загрузку канала. Я уже не говорю что люди умнеют и исправляют ошибки. А по MODBUS новую прошивку то никак не загрузить.
Таким образом для облегчения труда и сокращения и сроков явно нужны библиотеке. Выбор лишь с какой стороны будет обработка. Мы сложили все факторы и посчитали что уже можно это делать со стороны SLAVE. Нет аргумента по которому выгоднее делать обработку на стороне MASTER.
Есть и еще одна причина. Разработчик конечного устройства на шину всяко лучше знает свое устройство чем разработчик системы. И в как в объектном программировании полезно скрыть от пользователя детали реализации. И также избавить его от трудозатрат на этот процесс.
ПАЗ я уж думал это автобус. При частоте 1Мб и возможности протокола прервать опрос и влезть со своей аварией как раз и можно в отличие от MODBUS где можно много секунд ждать следующего опроса одного следующего регистра. Пакет данных там слишком мелкий. КПД протокола ниже плинтуса
можно
Вы видимо не все прочли коли советуете библиотеки для протокола. Речь идет о библиотеках для устройств на шине. А я их что-то не наблюдаю пока. Вот к примеру мне надо вентилятор подключить через популярный частотник DANFOSS FC-51. Не подскажете где мне взять такую библиотеку, что бы задать скорость 80 процентов от Максимума? Думаю нигде их нет. А включить два насоса одновременно? одной командой?
Или вам надо податься в экосистему DANFOSS если ее достаточно и цены устраивают или открывать документацию и приступать к изучению регистров и к отладке. Мы же не о серии говорим а о разработке.
Ну и передача огромного числа регистров не добавляет скорости обмена.