How to become an author
Search
Write a publication
Pull to refresh

Comments 20

Непонятно, почему до сих пор для Modbus используют скорости 9600 и 19200 бит/с, в то время как RS-485 даже на максимальной длине линии 1200 м может работать на скорости 62500 бит/с (а реально на UTP-5 работает и на 115200)? И почему нормальной для ведомого устройства считается такая большая задержка ответа, 40мс, в то время как в современных микроконтроллерах достаточно легко обеспечить задержку не более 1мс?
Rating is hidden
Потому что на практике — в рабочих условиях на высокой скорости, либо при больших пакетах (уже от 60 байт) не работает — частая ошибка CRC.
Rating is hidden

Не знаю в каких условиях вы использовали такие скорости на такой дальности, но у нас, на двух частотниках в шкафу, приходилось сбрасывать скорость до 9600. Иначе помехи при включении движков.
И что угодно можно делать — заземлять, экранировать...

Rating is hidden
совершенно согласен, особенно на частотниках сплошные помехи, но пару раз я смог от них почти избавиться, но это это отразилось на цене
Rating is hidden
Потому что Modbus это дешёвый инструмент, который решает задачу. Всем понятный и всеми поддерживаемый. Проблема в том, что у каждого производителя целый зоопарк проприетарных протоколов.
С другой стороны интерфейсные лини обычно не используются в критически важных процессах. Например, обновлять температуру жидкости в цистерне с задержкой в 1мс нет никакой необходимости. Соответственно экономят там, где можно.
Но не всё так плохо, есть, например IEC 61850 с его peer-to-peer GOOSE сообщениями с гарантированной доставкой в 4мс.
Rating is hidden
GOOSE — это широковещательный протокол по модели Publusher-Subscriber, без гарантированной доставки сообщений. Надежность доставки достигается за счет многократных повторений посылки. Стандартом IEC 61850-5 определяются несколько классов производительности. Для наиболее критических сообщений — отключение электроустановки действием защиты — определен класс P1, с временем доставки сообщения <= 3 мс, без учета возможной потери пакета.
Rating is hidden
Поверх Эзернета — не смешите мою бабушку. Надежность. Ха

Там как бы не в стандарте прописана оптика
Rating is hidden
Поверх Езернета, да. И еще PRP используется. В чем проблема с надежностью?
Rating is hidden
Потому, что эти скорости передачи заданы в стандарте. Другие скорости опциональны и поэтому могут поддерживаться не всеми устройствами.
Rating is hidden
Всегда работаю по MODBUS на скрости 115200. С частотными преобразователями для двигателей.
С циклом управления 20 мс.
Скорость MODBUS точно рассчитать невозможно.
На каждую команду и на доступ к определенным группам данных у слэйвов отдельно специфицируются таймауты реакции.
Например, одно дело записать в рабочий регистр, а другое в NV регистр.
Поэтому если требуется жесткий риалтайм, то надо непосредственно в софте мастера реализовывать измеритель таймаутов, кторый нужен для экспериментального подбора состава пакетов и организации их отправки.
Из-за такого запоздалого квитирования MODBUS не рекомендуют для управления движущимися объектами (но я нарушаю рекомендацию).
Лучший выбор будет CAN, где квитирование сразу во время передачи пакета слэйвам, и EtherCAT где квитирование мгновенное и сразу от всех слэйвов.
Rating is hidden
потому что в пакетах иногда стабильно, иногда какими-то отдельными всплесками начинаются появляться ошибки, отчасти спасает переинициализация при накоплении какого-то количества ошибок за промежуток, но она отнимает время, поэтому приходиться снижать скорость.Да есть свои правила прокладки линии, использовании правильного кабеля, даже с экранированием, но даже в этом случае может иметь место одно или несколько пересечений с силовыми и мы начинаем искать пути решения проблем вызванных помехами.
Rating is hidden
А что, если один абонент из 32х помер(не отвечает), как тогда поменяются скорости в расчетах (для разного числа слейвов)?

И да, это чисто теоретические выкладки или проверено на практике?
Мне всегда было лень считать.
Rating is hidden
У мастера есть предустановленное время ожидания на ответ от ведомого устройства. Если в течение этого времени ответа не поступило, то мастер может послать повторный запрос или перейти к опросу следующего устройства.
Время ожидания по-хорошему настраивается индивидуально во время пуско-наладки. При времени ожидания 300мс, каждое не отвечающее устройство будет добавлять задержку 300мс в полный цикл опроса. Соответственно, если включен повторный запрос, то добавиться ещё 300мс и т.д.

Выкладки основаны на реальных цифрах поэтому от практики не должны отличаться. Допущение в том, что я использовал для расчётов пересылку максимального количества регистров, что редкость на практике. Чуть позже добавим возможность изменять количество пересылаемых регистров и тогда можно будет посчитать вариант близкий к своей конфигурации.
Rating is hidden
Я полагаю чуть чуть, буквально на 10 процентов будут отличаться — канал на 100% в 485-м по моему мнению достаточно редко используют — таймаут между посылками в реальности немного выше.
Достаточно подробный и грамотный расчёт, Спасибо, порадовали.
Rating is hidden

Посмотрел web, похоже что чистая теория, чтение =x mc, чтение и запись = 2*x ms, в реальной жизни чуть больше зависимостей, начиная от того за сколько слейв отвечает, в некоторых модулях это время настраиваемое, до самих настроек периода опроса и других параметров, так же сильно влияет тип запроса групповой или одиночный и это без рассмотрения ситуации, что кто-то "отвалился" на линии. Замеры разных команд на разных скоростях сделаны тут https://youtu.be/kOo4INKt8Nw для ситуации с одним слейвом.

Rating is hidden
скорости не поменяются, но вот из-за таймаутов на пропавшем абоненте увеличиться время между периодами опроса устройств, что субъективно будет похоже на снижение скорости обмена в целом.
Rating is hidden

Я тоже пару недель назад собрался с мыслями и сделал похожий анализ для работы по этому протоколу применительно к программируемым реле в программе OwenLogic. Так как помимо расчета времени самих кадров есть еще разные факторы. которые влияют на итоговое быстродействие, часто вижу как даже на высоких скоростях система "тупит" из-за некорректных настроек или не оптимального использования регистрами.
Сделал 3 ролика:
Первые два более специфические и относятся к настройкам и использования в программе,
третий как раз по теме данной статьи.
Modbus и OwenLogic ч.1 https://www.youtube.com/watch?v=k9rUF5_kLqk
Modbus и OwenLogic ч.2 https://www.youtube.com/watch?v=miTsntqGIQA
Modbus и OwenLogic ч.3 https://www.youtube.com/watch?v=kOo4INKt8Nw

Rating is hidden
Sign up to leave a comment.

Articles

Your account

Sections

Information

Services

Support
© 2006–2025, Habr