Видимо попалась не та диагональ ) Но "драйвер" это больше термин из операционок. А в нашем случае это скорее библиотека. Хотя драйвер звучит конечно круче.
Так это вы не по ним шьете а поверх. Или я не правильно понял? в 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 если ее достаточно и цены устраивают или открывать документацию и приступать к изучению регистров и к отладке. Мы же не о серии говорим а о разработке. Ну и передача огромного числа регистров не добавляет скорости обмена.
Не хотите свои разработки назвать "поделие"? Поясню свою мысль. Наши изделия установлены уже в реальное оборудование, которое экспортировано в 28 стран. А ваша "фирмочка" что-то уже продала немцам, американцам, итальянцам и прочим? Ну мне чисто любопытно откуда берется такой снобизм и основание давать такие характеристики?
Разница в том, что от проектировщика/программиста скрыто вообще само существование регистров или какие-либо детали устройства. Производитель выдает готовую библиотеку и можно сразу работать с функциями минуя стадию разбиения данных на регистры и адреса сдвигов. Технически можно написать библиотеки на сторону мастера. к тем же самым устройствам Modbus. И надеть эту оболочку поверх самого протокола связи. Но это решает одну проблему и создает другую - канал забивается трафиком передачи адресов и значений регистров вместо того что бы сразу получить нужные данные в нужном формате. Я уже не говорю о шифровании трафика и о возможности заливать новые прошивки, это будет вечной операцией на MODBUS. Фреймы мелкие и данные мелкие. Это как копировать на дискету тысячи файлов.
Ну тема известная. Приведу одну цитату из этого источника "долгий период опроса одного регистра в устройстве — если на шине много устройств и в каждом по паре сотен регистров, то в зависимости от скорости и расположения регистров, пауза между опросами одного и того же регистра может достигать нескольких секунд. Это в конечном счёте приводит к медленной реакции системы." Так что для химзавода это не вариант - опрос ОДНОГО Регистра за несколько секунд, У нас все регистры уже опрошены еще внутри самого устройства и время ответа не зависит ни от чего кроме как просто количества устройств на линии. И оно не умножается на количество регистров. А необходимости в что-то типа DHCP в приборах нет. Все это нужно для технологического оборудования а оно обычно не не работает в режиме горячего подключения устройств.
В нормальные управляющие уже поставили. Это не Realtime система большой дискретизацией. Но управлять оно точно может всем тем для чего используется MODBUS оно может и существенно лучше. И на сегодня MODBUS это максимально популярный протокол
Локально конечно можно что угодно питать. Но мы в варианте с контролем питания шины можем применяться во взрывоопасных зонах так как контроль тока с нашей стороны. И можем не усложнять установку если просто на какой-то части устройств на шине не подводить туда еще и 220
на тесте было 1,5 км дальность на 115200 и 10 метров при 10Мбит. Записать можно до 3 ампера тока. При 50 мА на устройство это 60 штук. При 20 мА 150 штук. далее надо добавлять блок поддержки питания.
Благодарю за поддержку. Еще раз повторюсь что идея в том, что бы кучу функций перенести на сторону устройства на шине пользуясь изменившейся ценой на цифру.
Можно свои датчики подключать к интерфейсным модулям.
Видимо попалась не та диагональ ) Но "драйвер" это больше термин из операционок. А в нашем случае это скорее библиотека. Хотя драйвер звучит конечно круче.
Так это вы не по ним шьете а поверх. Или я не правильно понял? в 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 если ее достаточно и цены устраивают или открывать документацию и приступать к изучению регистров и к отладке. Мы же не о серии говорим а о разработке.
Ну и передача огромного числа регистров не добавляет скорости обмена.
Не хотите свои разработки назвать "поделие"? Поясню свою мысль. Наши изделия установлены уже в реальное оборудование, которое экспортировано в 28 стран. А ваша "фирмочка" что-то уже продала немцам, американцам, итальянцам и прочим? Ну мне чисто любопытно откуда берется такой снобизм и основание давать такие характеристики?
Разница в том, что от проектировщика/программиста скрыто вообще само существование регистров или какие-либо детали устройства. Производитель выдает готовую библиотеку и можно сразу работать с функциями минуя стадию разбиения данных на регистры и адреса сдвигов.
Технически можно написать библиотеки на сторону мастера. к тем же самым устройствам Modbus. И надеть эту оболочку поверх самого протокола связи. Но это решает одну проблему и создает другую - канал забивается трафиком передачи адресов и значений регистров вместо того что бы сразу получить нужные данные в нужном формате. Я уже не говорю о шифровании трафика и о возможности заливать новые прошивки, это будет вечной операцией на MODBUS. Фреймы мелкие и данные мелкие. Это как копировать на дискету тысячи файлов.
Ну тема известная. Приведу одну цитату из этого источника "долгий период опроса одного регистра в устройстве — если на шине много устройств и в каждом по паре сотен регистров, то в зависимости от скорости и расположения регистров, пауза между опросами одного и того же регистра может достигать нескольких секунд. Это в конечном счёте приводит к медленной реакции системы."
Так что для химзавода это не вариант - опрос ОДНОГО Регистра за несколько секунд,
У нас все регистры уже опрошены еще внутри самого устройства и время ответа не зависит ни от чего кроме как просто количества устройств на линии. И оно не умножается на количество регистров.
А необходимости в что-то типа DHCP в приборах нет. Все это нужно для технологического оборудования а оно обычно не не работает в режиме горячего подключения устройств.
Пока 485 тупиком никто не считает кроме вас. Самый популярный интерфейс в приборах на сегодня.
В нормальные управляющие уже поставили. Это не Realtime система большой дискретизацией. Но управлять оно точно может всем тем для чего используется MODBUS оно может и существенно лучше. И на сегодня MODBUS это максимально популярный протокол
Локально конечно можно что угодно питать. Но мы в варианте с контролем питания шины можем применяться во взрывоопасных зонах так как контроль тока с нашей стороны. И можем не усложнять установку если просто на какой-то части устройств на шине не подводить туда еще и 220
на тесте было 1,5 км дальность на 115200 и 10 метров при 10Мбит.
Записать можно до 3 ампера тока. При 50 мА на устройство это 60 штук. При 20 мА 150 штук. далее надо добавлять блок поддержки питания.
Благодарю за поддержку. Еще раз повторюсь что идея в том, что бы кучу функций перенести на сторону устройства на шине пользуясь изменившейся ценой на цифру.
Прокладка провода стоит в несколько раз дороже самого провода.