Comments 22
Нужен заголовок "делаем CAN из modbus" и картинка про 15 стандартов в качестве КДПВ. Не могу не отметить что разжевано все очень подробно.
Мне нравится ваш юмор :) Проблема «ещё одного протокола» в том, что пользователи покупают железки с этим протоколом, у них всё хорошо до тех пор, пока не потребуется сменить контроллер или добавить оборудование другого вендора и тут начинаются проблемы.
Поэтому мы старались найти решение, которое не будет привязывать пользователя к нам. У пользователя нашего оборудования будет стандартная шина RS-485 с протоколом Modbus RTU и он сможет добавить туда устройства сторонних производителей или поставить контроллер другого вендора без переделки физики.
Не могу не отметить что разжевано все очень подробно.
Спасибо, этой статьёй мы старались ответить на все вопросы по работе расширения, которые задавали нам с момента его анонса в апреле этого года: https://habr.com/ru/companies/wirenboard/articles/737402/
Очень подробное описание! Быстрый Modbus использую уже некоторое время, теперь стал лучше понимать, как он работает :)
Интересное расширение, может быть полезно. Непонятно, зачем вообще мастеру автоматически определять параметры обмена устройств на шине - ведь если они разные у разных устройств - ничего не получится. Гораздо логичнее устанавливать в мастере любые параметры из того набора, который поддерживают слэйвы, а уже в слэйвах делать автонастройку на любые поддерживаемые параметры обмена. Так же не понятно, в чём трудность подбора в мастере длительности стоп-бита - достаточно найти на шине одно отвечающее устройство, использовав максимальную длительность стоп-бита, и потом либо запросить у него используемые параметры обмена, либо уменьшать длительность стоп-бита до тех пор, пока это устройство не перестанет отвечать. Насчёт коллизий адресов - при автоматическом назначении адресов по описанному алгоритму коллизий между устройствами, поддерживающими новый протокол быть не должно. Коллизии возможны, если подключить к работающей шине устройство, которое не поддерживает автоматическое назначение адресов. Как в этом случае автоматически обнаружить эту коллизию?
Непонятно, зачем вообще мастеру автоматически определять параметры обмена устройств на шине - ведь если они разные у разных устройств - ничего не получится.
Почему не получится? Мы можем обратиться к каждому устройству с его параметрами связи по серийному номеру и прописать нужные настройки, например, 115200 8N2, а заодно и сменить адрес, если есть дубли.
а уже в слэйвах делать автонастройку на любые поддерживаемые параметры обмена.
Распишите, пожалуйста, подробнее эту мысль. Что такое «автонастройка в слейве»?
У нас там есть регистры, в которые мастер может записать настройки связи. То есть логика сейчас такая: ищем всех слейвов на всех вариантах настроек связи и потом делаем всем одинаковые настройки.
Так же не понятно, в чём трудность подбора в мастере длительности стоп-бита - достаточно найти на шине одно отвечающее устройство, использовав максимальную длительность стоп-бита, и потом либо запросить у него используемые параметры обмена, либо уменьшать длительность стоп-бита до тех пор, пока это устройство не перестанет отвечать.
На самом деле в новых прошивках нет проблемы со стоп-битами — устройства умеют работать и 1 и с 2 стоповыми битами из коробки и им не важно, что там хочет мастер.
Но это наши устройства, а расширение должно быть универсальным. На одной шине могут быть устройства с разными настройками связи. Это бывает по разным причинам: инсталляцию собирают методом каннибализации других, с устройствами кто-то уже игрался до установки в инсталляцию и т.п.
Насчёт коллизий адресов - при автоматическом назначении адресов по описанному алгоритму коллизий между устройствами, поддерживающими новый протокол быть не должно.
Мы на заводе записываем в устройства адреса из диапазона 1-247, наклейку с которым мы потом клеим на корпус устройства. Это позволяет в большинстве случаев получить в инсталляции устройства с разными адресами и ничего перенастраивать не нужно. Но иногда могут попасться пара устройств с одинаковыми адресами.
Наше расширение позволяет обратиться к устройству по серийному номеру и прописать новый адрес. С помощью этой возможности мы сделаем в софте контроллера кнопку автоматической настройки, которая выставит одинаковые параметры связи и разные адреса в устройствах.
Коллизии возможны, если подключить к работающей шине устройство, которое не поддерживает автоматическое назначение адресов. Как в этом случае автоматически обнаружить эту коллизию?
Стандартно: подключили новое устройство в инсталляцию, сканируем шину, что-то делаем с его настройками, если нужно.
Мы можем обратиться к каждому устройству с его параметрами связи по серийному номеру и прописать нужные настройки
Так, конечно, можно делать. Но если в инсталляции есть хотя бы одно устройство, не поддерживающее быстрый Modbus - тогда всё равно придётся делать полное сканирование старым методом, и наличие быстрого сканирование у новых устройств совсем не ускорит цикл сканирования, а даже немного его замедлит - к обычному сканированию добавится быстрое. Я думал, что речь идёт о поиске параметров обмена до первого корректного обмена - он действительно будет быстрее.
Что такое «автонастройка в слейве»?
Мастер ведёт обычный обмен, или, если не нужно - периодически отправляет специальный короткий пакет сканирования со своими параметрами и специальным адресом, а слэйв пытается принять любой пакет с любым адресом, перебирая параметры обмена до первого успешного приёма пакета.
Ещё не прочитал но одобряю. Вы молодцы.Появление быстрого модбаса наверное послужило причиной выбрать ваш контпрлле а не Овен/Сименс .
Единственное что уже дождусь вайренборд 8.
Вопрос: а почему в опциях не было использование модбас тсп? Скорости хорошие, сразу топология звезда, что удобно. Может быть можно было бы в poe тогда вообще красиво было бы.
Я же правильно понимаю, что modbus tcpможет работать не поллингом а прямым соединением до каждого устройства?.. правда в некоторых контроллерах типа Siemens s7-1200 можно поднять всего 8 соединений помоему. Но у вас же Линукс, вы можете и 8000 соединений поднять?)
Единственное что тсп это удорожание устройства, а в вашем случае вы программно сделали, типа не увеличивая цену)
... а почему в опциях не было использование модбас тсп?
... сразу топология звезда, что удобно.
С виду выглядит хорошо, но есть нюансы :)
Тысячи инсталляций сейчас собраны с шиной RS-485 и Modbus RTU. Это значит нам придётся выпускать и поддерживать две линейки устройств, чтобы уже собранные инсталляции можно было обслуживать и менять там со временем оборудование.
Шина — это всего три провода (A, B, GND), которые оборачивают объект или проходят через все устройства в щите — это просто очень экономно в деньгах. Также шина в щите сильно экономит место.
Siemens s7-1200 можно поднять всего 8 соединений помоему.
И это одна из причин — использование наших устройств с другими контроллерами. Нередко на объекте уже стоит контроллер другого вендора и при модернизации добавляют наши устройства.
Шина 3 провода а по факту 5, т.к. питание, короче та же самая витая пара))
Но в целом мне кажется, рано или поздно вы перейдёте на Ethernet , особенно если пойдете в промку)
Шина 3 провода а по факту 5
С питанием 4 провода: A, B и GND, +24В.
Но в целом мне кажется, рано или поздно вы перейдёте на Ethernet , особенно если пойдете в промку)
Я не понял о промке :) В шкафу удобно использовать шину RS-485 — занимает меньше места, требует меньше провода. Если речь про отправку данных из шкафа куда-то наверх, то маленький конвертер протоколов в 2 юнита решает задачу.
Ethernet занимает много места, стоит дороже обычного клеммника, требует специального инструмента для обжима и навыков. А в месте с PoE ещё и ощутимо увеличит стоимость устройств, так как PoE модули довольно дорогие.
Количество, поддерживаемых TCP соединений, зависит как от аппаратной, так и от программной реализации, т.е. на одной и той же аппаратуре один софт может на 200 подключениях уже лаговать, когда другой обрабатывает их тысячами.
во втором разделе "Поиск решения" был ответ на ваш вопрос, звучит он так:
Мы хорошо умеем делать устройства с Modbus RTU и RS-485 — под это заточены наши процессы в разработке и производстве.
Поэтому нам было важно сохранить наш основной протокол Modbus RTU, а значит единственное решение — разработка расширения протокола, используя заложенные разработчиками протокола Modbus возможности.
А не проще ли было делать чтение буферированым. Если в адресном пространстве есть запрещеные адреса отдавать там нули и ложь. Тогда мастер на первом проходе поймёт кого нет. А на следующих просто будет читать только тех кто есть. И скорость вырастет и не надо городить велосипед
Я так понимаю, речь о сканировании шины? Расскажите, пожалуйста, свою идею подробнее — с виду кажется сложнее, чем сделали мы.
Я так понял прочитать все слейвы которые из конфигурации. Те кто не ответил - исключать из поллинга, чтобы по тайм-ауту не ждать
Я так понял прочитать все слейвы которые из конфигурации...
Это просто — сейчас так и работает: если слейв есть в конфигурации и не ответил, то мы его не опрашиваем некоторое количество циклов, потом пытаемся снова. Если он так и молчит, исключаем его из опроса. Так работало почти всегда у нас так без всяких расширений.
Проблема возникает, когда в конфигурации драйвера никого нет — тогда единственный путь, стучаться по каждому адресу и ждать таймаут на ответ устройства. Здесь наша итоговая цель проста: автоматическое конфигурирование устройств на шине и добавление их в конфигурацию драйвера.
Сейчас в софте контроллера Wiren Board есть только табличка устройств на шине, но это не конечный вариант.
В modbus tcp можно организовать так называемые unsolicited messages и таким образом организовать спонтанную передачу данных (по изменению), возможно ли как-то модернизировать последовательные устройства или сеть из них чтобы реализовать такой режим? ради любопытства спрашиаю...
Расширение как раз таки позволяет устройствам решить что они хотят уведомить систему о произошедшем событии, а арбитраж позволяет разрулить при этом коллизии. Проблема в другом. Что делать с сообщением дальше ? где-то должно быть правило, как реагировать на такое сообщение. На данный момент всем дирижирует мастер с линуксом, потомучто на нем есть сервис wb-rules, который позволяет написать и обработать любой сценарий реакции на событие.
Что произойдёт с фитерами RS-485 если на линии появятся два передатчика из-за программной ошибки, и начнут передавать информацию? Фитеры выйдут из строя.
Основное отличие (изюминка) ModBus в отсутствии логики подтяжечных резисторов (не давящих помеху).
Поэтому мастер включается (давит шину единицей) НЕ когда хочет передать, а сразу после приёма (хочет-не хочет, но давит помеху, не надеясь на резисторы).
Не нужна помехоустойчивость - не называйте "ModBus".
Прокачиваем Modbus: арбитраж, сканирование шины, события