я ответил на одно письмо уже с приложением спецификаций. с какого адреса было Ваше? не дошло пока. Если Слейву надо обратиться к мастеру, то он в специальном окне выставляет запрос со своим адресом. Мастер видит, что есть сообщение типа ALARM и знает от кого. И уже начинает со своей стороны выяснять что там произошло прямо следующим обращением к слейву. И слеву дает информацию, что его сообщение дошло. Если слейвов несколько то сообщения они накладывают одно на другое Так как формат сообщения одинаковый но отличается адрес и CRC то мастер ничего им не отвечает и продолжает свой цикл опроса. Все слейвы, которые не получили немедленного к себе запроса, но находящиеся в состоянии ALARM будут повторять свой выход на линию. Но каждый из них сделает случайную паузу от нуля до нескольких пакетов. То есть они разойдутся по времени. Такой же механизм и в других протоколах используется.
Как раз наоборот. Наши устройства с самыми дешевыми контроллерами 8 бит и этого достаточно и на преобразование форматов и на поддержку протокола. Это в заголовке статьи. Цена на цифру сегодня буквально ноль. В отличие от какого-нибудь встраиваемого датчика давления. Огромная масса дачников выпускается сейчас с интерфейсами 0-10 или 4-20. И коробочка с цифровизацией добавляет к цене 10 процентов. И пожалуйста уже можно пользовать. И в приборах внутри корпуса и удаленно. Скажу даже, что излучался вопрос о том, что бы на этом всем управление судами сделать. И никаких противопоказаний не обнаружилось. Другой протокол по сумме затрат на все части процесса - от проектирования до обслуживания и от изготовления самих контроллеров до их корпусов дороже. Прибавим еще затраты на монтаж устройств в каждом из которых своя распиновка подключения вместо унифицированных разъемов. Зарплаты программистов отличаются на разных языках. Соберется общая цена. Количество приборов я вполне могу представить. Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий. Вот там кстати надо температуру знать. И разницу давлений при открытии заслонок и влажность. Потому что это такой огромный PID регулятор по факту. А изобретения вообще дело неблагодарное. У меня есть международный патент к примеру. Так и денег и сил это стоит неразумных.
Всегда что-то начинается и заканчивается. Пока мы видим путь внедрения в устройства, а не в большие системы. Станки и теплицы. Зарядные станции и вообще всякое оборудование. За последние годы появился далеко не один протокол и строить прогнозы об успешности явно рано. Проблема российских протоколов и вообще всех разработок это русский язык. Потому что его никто не знает и весь мир пользуется английским. Наши кое=как выучили английский, но заставить иностранцев учить русский невозможно. А для целого протокола одной России маловато. И это более важно чем новизна чего бы то ни было из РФ. А со всеми спецификациями мы ознакомились по всем наиболее популярным протоколам. И CAN и HART и прочие FIELDBUS. Взяли все лучшее постарались снизить влияние природных недостатков таких как Master-Slave например. А "по необходимости" поверх любого протокола можно натянуть что угодно. Хоть шифрование хоть передача видео. Можно даже в протоколы туннели включать. В мастер-слейвы элементы peer-to-peer. Только управлять этой бедой крайне сложно. На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы.
"А как устройство понимает, что оно не одно передаёт? Слушать шину в 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 С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)
Ну "ваша" это означает где вы работаете. Ну так что вам как пользователю не нравится? что есть новый стандарт и устройства к нему? Или что система так устроена, что любой школьник может с ней работать имея багаж кружка робототехники? Нет задачи заставить всех создавать паровозы. Наоборот. Есть задача создать такой паровоз на котором любой ребенок может кататься. "Поделие" вовсю работает и не ломается.
Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf Обновление прошивок возможно как и вовсе передача любых данных в пакетах. Однако есть разница между единым механизмом и чисто теоретической возможностью которую каждый реализует по-разному. В idiBus вы можете узнать у устройства оно вообще имеет прошивку или нет? это обязанность устройства так как часть протокола. Выдачу данных через сервер конверсии бит в физические величины можно применять вообще с любым устройством. Взяли слева биты и послали направо. и справа пришли значения. Но тут то речь идет о том, что само устройство уже вполне может это делать и само цена этой функции - ноль так как в любом устройстве уже стоит чип как в телефоне. Можно уже в тетрис играть на датчиках давления. Коллизии разруливаются как в других протоколах. К мастеру можно обращаться вне очереди. В случаях повышения или снижения давления, температуры или по любой срочной надобности что бы не ждать своей очереди в опросе. Групповые опросы масками не решить. Это механизм для разных устройств. Любого типа. В физических процессах часто надо мерять не один параметр а несколько но нужны их значения именно в один момент времени. Когда они динамичны. Например давление и температура. Измерение происходит в один момент, а получение этих данных может быть и последовательное. Безопасный режим это способ сохранения системы если имеются сбои и надо ввести систему или ее часть в состоянии когда она своими действиями не может себя разрушить. Совместимость по линии это означает что логика протокола такова, что к стоящим на линии устройствам MODBUS можно от мастера обращаться без изменения логики и без изменения физики. Устройства MODBUS просто не замечают траффика idiBus.
в протоколе только базовый набор функций. В этом наборе вообще нет ничего про передачу конкретных данных. И есть способ для расширения числа функций. Их самих в протоколе нет но процесс их обслуживания уже есть. предусмотрено количество функций от 1 до 219. И есть набор стандартных для всех модулей команд. Init, Shutdown, Sleep. Набор данных для каждой функции может быть большим. И ответ от частотника тоже. Приборы которые имеют MODBUS можно непосредственно подключать. И пользоваться как обычно. Регистры и все прочее. Можно миксовать на одной линии. И постепенно менять иностранное на наше.
У меня партнер был 10 лет главным импортером Эмерсона. Теперь вот сложности с импортом. Мы говорим о том, что данфосс не дает Драйверов. Ибо в мире компов есть линукс яблоко и виндовс. и как-то драйверы люди пишут к этому. А в мире омронов и эмерсонов даже внутри эмерсонов все по-разному. Филдбасы придумали новый разъем и новый провод. Который у нас вообще некому произвести. В РФ явно требуется момент объединения под одну крышу всем. Рынок наш настолько мал и настолько занят иностранцами, что своего мы никогда не сделаем если не объединимся хотя бы при АСУ хотя бы какой-то большой части устройств. Пока в РФ никто не готов заменить систему управления вентиляцией очистного здания. Ибо там много устройств. Можно или уходить к китайцам (корейцы тоже вон санкции устроили) или левый импорт делать. Но нам больше нравится вариант - откусывать от иностранного АСУ куски в пользу наших разработчиков аппаратуры. и датчиков и Серв и контроллеров. Наша идея - более простое проектирование с широким кругом программистов на стандартных языках. и более дешевые устройства. совместимость обратная с MODBUS. Что бы выпустить какие-то датчики давления или влажности или еще чего-то надо и сам датчик и его оцифрить. Мы даем цифру. Дешево и сердито. И любой студент может программировать все это. Позже подцепимся к SCADA какому-то открытому. Если государство довело эту сферу до того, что ни одного ЖК экрана в стране сенсорного не производится и прости господи сотни миллионов тратятся на контроллеры типа "БАГЕТ", то кто-то должен начать процесс объединения национальных разработчиков. И глупо при этом не воспользоваться тем, что за 40 лет цифра стала такая дешевая, что можно ее в сигареты засовывать. В РФ промышленное оборудование, которому надо АСУТП всегда малые серии. Рынок такой и никто не умеет ничего экспортировать. idiBus решает задачу удешевления этой автоматики. От лифтов и станков до теплиц и бетономешалок.
Отнюдь. список функций всяко проще списка функций плюс таблица адресов и регистров. плюс надо еще написать некую функцию для установки этих регистров и не ошибиться. вызвать setСкоростьТорможения(%) и удобнее и контроль ошибок доступен. Модуль idiBus выдаcт специальный тип ошибки - что разработчик задал значение вне диапазона.
а в слейвах нет времени. вот мы тут все сидим сейчас а где-то проектируют датчик давления. Без времени. Работает по факту запроса. В базовом протоколе именно поэтому нет синхронизации времени. Одновременность решена возможностью объединения в группы и отправка групповой команды сразу всем членам группы. Отложенная передача данных откуда и куда? Если потеря связи то мастер стучит и потом докладывает что не достучался. Это не часть протокола. Это ошибка связи. А отложенной передачи из слейва нет. Есть передача больших пакетов данных (состоящих из более чем одного модуля данных) с подтверждением получения очередного пакета. Есть в качестве устройства на шине например уже готовый модуль логгирования. Там стоит флешка и часы реального времени. В нем же можно хранить переводы текстовых значений для кодов ошибок для разных языков. Коды и индексация языков тоже стандартизированы. Кстати кто такой комтрейд? я приезжий не все слова еще знаю
я в курсе. но они имеют тенденцию кого-то выгнать, что-то закрыть и вообще затеять санкции. Это люди из страны агрессора. Поэтому там все российское может прямо завтра пропасть.
Токовая петля это интерфейс 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 и прочие интерфейсы. В нашем случаем имеется модуль интерфейса, который уже имеет все фунции протокола. И мы берем и добавляем поверх готовой библиотеки только ту часть, которая из этих интерфейсов делает сразу физические величины. Ну или команды если это что-то командное. И такие все цифро-аналоговые датчики типа той же термопары становятся цифровыми устройствами на шине. Вся базовая часть протокола уже написана. Остается кусочек дописать и залить прошивку в готовый уже интерфейсный модуль,
наверно в спаме было, уже все в спаме найдено и обслужено
Чисто для информации. Я - дипломированный магистр по климатической технике. Кроме того что радиоинженер.
я ответил на одно письмо уже с приложением спецификаций. с какого адреса было Ваше? не дошло пока.
Если Слейву надо обратиться к мастеру, то он в специальном окне выставляет запрос со своим адресом.
Мастер видит, что есть сообщение типа ALARM и знает от кого. И уже начинает со своей стороны выяснять что там произошло прямо следующим обращением к слейву. И слеву дает информацию, что его сообщение дошло.
Если слейвов несколько то сообщения они накладывают одно на другое Так как формат сообщения одинаковый но отличается адрес и CRC то мастер ничего им не отвечает и продолжает свой цикл опроса.
Все слейвы, которые не получили немедленного к себе запроса, но находящиеся в состоянии ALARM будут повторять свой выход на линию. Но каждый из них сделает случайную паузу от нуля до нескольких пакетов. То есть они разойдутся по времени. Такой же механизм и в других протоколах используется.
Как раз наоборот. Наши устройства с самыми дешевыми контроллерами 8 бит и этого достаточно и на преобразование форматов и на поддержку протокола. Это в заголовке статьи. Цена на цифру сегодня буквально ноль. В отличие от какого-нибудь встраиваемого датчика давления.
Огромная масса дачников выпускается сейчас с интерфейсами 0-10 или 4-20.
И коробочка с цифровизацией добавляет к цене 10 процентов. И пожалуйста уже можно пользовать. И в приборах внутри корпуса и удаленно.
Скажу даже, что излучался вопрос о том, что бы на этом всем управление судами сделать.
И никаких противопоказаний не обнаружилось.
Другой протокол по сумме затрат на все части процесса - от проектирования до обслуживания и от изготовления самих контроллеров до их корпусов дороже. Прибавим еще затраты на монтаж устройств в каждом из которых своя распиновка подключения вместо унифицированных разъемов. Зарплаты программистов отличаются на разных языках. Соберется общая цена.
Количество приборов я вполне могу представить. Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий.
Вот там кстати надо температуру знать. И разницу давлений при открытии заслонок и влажность. Потому что это такой огромный PID регулятор по факту.
А изобретения вообще дело неблагодарное. У меня есть международный патент к примеру. Так и денег и сил это стоит неразумных.
Всегда что-то начинается и заканчивается. Пока мы видим путь внедрения в устройства, а не в большие системы. Станки и теплицы. Зарядные станции и вообще всякое оборудование.
За последние годы появился далеко не один протокол и строить прогнозы об успешности явно рано. Проблема российских протоколов и вообще всех разработок это русский язык. Потому что его никто не знает и весь мир пользуется английским.
Наши кое=как выучили английский, но заставить иностранцев учить русский невозможно. А для целого протокола одной России маловато. И это более важно чем новизна чего бы то ни было из РФ.
А со всеми спецификациями мы ознакомились по всем наиболее популярным протоколам. И CAN и HART и прочие FIELDBUS.
Взяли все лучшее постарались снизить влияние природных недостатков таких как Master-Slave например.
А "по необходимости" поверх любого протокола можно натянуть что угодно. Хоть шифрование хоть передача видео. Можно даже в протоколы туннели включать. В мастер-слейвы элементы peer-to-peer. Только управлять этой бедой крайне сложно.
На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы.
"А как устройство понимает, что оно не одно передаёт? Слушать шину в 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
С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)
Ну "ваша" это означает где вы работаете. Ну так что вам как пользователю не нравится? что есть новый стандарт и устройства к нему? Или что система так устроена, что любой школьник может с ней работать имея багаж кружка робототехники?
Нет задачи заставить всех создавать паровозы. Наоборот. Есть задача создать такой паровоз на котором любой ребенок может кататься.
"Поделие" вовсю работает и не ломается.
Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf
Обновление прошивок возможно как и вовсе передача любых данных в пакетах. Однако есть разница между единым механизмом и чисто теоретической возможностью которую каждый реализует по-разному. В idiBus вы можете узнать у устройства оно вообще имеет прошивку или нет? это обязанность устройства так как часть протокола.
Выдачу данных через сервер конверсии бит в физические величины можно применять вообще с любым устройством. Взяли слева биты и послали направо. и справа пришли значения. Но тут то речь идет о том, что само устройство уже вполне может это делать и само цена этой функции - ноль так как в любом устройстве уже стоит чип как в телефоне.
Можно уже в тетрис играть на датчиках давления.
Коллизии разруливаются как в других протоколах.
К мастеру можно обращаться вне очереди. В случаях повышения или снижения давления, температуры или по любой срочной надобности что бы не ждать своей очереди в опросе.
Групповые опросы масками не решить. Это механизм для разных устройств. Любого типа. В физических процессах часто надо мерять не один параметр а несколько но нужны их значения именно в один момент времени. Когда они динамичны. Например давление и температура. Измерение происходит в один момент, а получение этих данных может быть и последовательное.
Безопасный режим это способ сохранения системы если имеются сбои и надо ввести систему или ее часть в состоянии когда она своими действиями не может себя разрушить.
Совместимость по линии это означает что логика протокола такова, что к стоящим на линии устройствам MODBUS можно от мастера обращаться без изменения логики и без изменения физики. Устройства MODBUS просто не замечают траффика idiBus.
в протоколе только базовый набор функций. В этом наборе вообще нет ничего про передачу конкретных данных. И есть способ для расширения числа функций. Их самих в протоколе нет но процесс их обслуживания уже есть. предусмотрено количество функций от 1 до 219. И есть набор стандартных для всех модулей команд. Init, Shutdown, Sleep.
Набор данных для каждой функции может быть большим. И ответ от частотника тоже.
Приборы которые имеют MODBUS можно непосредственно подключать. И пользоваться как обычно. Регистры и все прочее. Можно миксовать на одной линии. И постепенно менять иностранное на наше.
У меня партнер был 10 лет главным импортером Эмерсона. Теперь вот сложности с импортом.
Мы говорим о том, что данфосс не дает Драйверов. Ибо в мире компов есть линукс яблоко и виндовс. и как-то драйверы люди пишут к этому.
А в мире омронов и эмерсонов даже внутри эмерсонов все по-разному.
Филдбасы придумали новый разъем и новый провод. Который у нас вообще некому произвести.
В РФ явно требуется момент объединения под одну крышу всем.
Рынок наш настолько мал и настолько занят иностранцами, что своего мы никогда не сделаем если не объединимся хотя бы при АСУ хотя бы какой-то большой части устройств.
Пока в РФ никто не готов заменить систему управления вентиляцией очистного здания. Ибо там много устройств.
Можно или уходить к китайцам (корейцы тоже вон санкции устроили) или левый импорт делать.
Но нам больше нравится вариант - откусывать от иностранного АСУ куски в пользу наших разработчиков аппаратуры. и датчиков и Серв и контроллеров.
Наша идея - более простое проектирование с широким кругом программистов на стандартных языках. и более дешевые устройства. совместимость обратная с MODBUS.
Что бы выпустить какие-то датчики давления или влажности или еще чего-то надо и сам датчик и его оцифрить.
Мы даем цифру. Дешево и сердито. И любой студент может программировать все это.
Позже подцепимся к SCADA какому-то открытому.
Если государство довело эту сферу до того, что ни одного ЖК экрана в стране сенсорного не производится и прости господи сотни миллионов тратятся на контроллеры типа "БАГЕТ", то кто-то должен начать процесс объединения национальных разработчиков.
И глупо при этом не воспользоваться тем, что за 40 лет цифра стала такая дешевая, что можно ее в сигареты засовывать.
В РФ промышленное оборудование, которому надо АСУТП всегда малые серии. Рынок такой и никто не умеет ничего экспортировать.
idiBus решает задачу удешевления этой автоматики. От лифтов и станков до теплиц и бетономешалок.
Отнюдь. список функций всяко проще списка функций плюс таблица адресов и регистров. плюс надо еще написать некую функцию для установки этих регистров и не ошибиться.
вызвать setСкоростьТорможения(%) и удобнее и контроль ошибок доступен. Модуль idiBus выдаcт специальный тип ошибки - что разработчик задал значение вне диапазона.
а в слейвах нет времени. вот мы тут все сидим сейчас а где-то проектируют датчик давления. Без времени. Работает по факту запроса.
В базовом протоколе именно поэтому нет синхронизации времени.
Одновременность решена возможностью объединения в группы и отправка групповой команды сразу всем членам группы.
Отложенная передача данных откуда и куда? Если потеря связи то мастер стучит и потом докладывает что не достучался. Это не часть протокола. Это ошибка связи. А отложенной передачи из слейва нет. Есть передача больших пакетов данных (состоящих из более чем одного модуля данных) с подтверждением получения очередного пакета.
Есть в качестве устройства на шине например уже готовый модуль логгирования. Там стоит флешка и часы реального времени.
В нем же можно хранить переводы текстовых значений для кодов ошибок для разных языков. Коды и индексация языков тоже стандартизированы.
Кстати кто такой комтрейд? я приезжий не все слова еще знаю
ясный перец что код будет открытый. готовим документацию и вывалим на какой-то гит
я в курсе. но они имеют тенденцию кого-то выгнать, что-то закрыть и вообще затеять санкции. Это люди из страны агрессора. Поэтому там все российское может прямо завтра пропасть.
Токовая петля это интерфейс 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 и прочие интерфейсы. В нашем случаем имеется модуль интерфейса, который уже имеет все фунции протокола. И мы берем и добавляем поверх готовой библиотеки только ту часть, которая из этих интерфейсов делает сразу физические величины. Ну или команды если это что-то командное. И такие все цифро-аналоговые датчики типа той же термопары становятся цифровыми устройствами на шине. Вся базовая часть протокола уже написана. Остается кусочек дописать и залить прошивку в готовый уже интерфейсный модуль,