Окончательно разбираемся со скоростью передачи по Modbus

Скорость обновления данных по Modbus зависит от нескольких неочевидных параметров. На стадии проектирования возникает проблема, как оценить скорость будущей интерфейсной линии. В этой статье рассмотрим факторы, влияющие на скорость обновления данных по Modbus RTU, сделаем несколько типовых расчётов, а в конце статьи будет ссылка на web калькулятор скорости работы Modbus RTU линии.


Modbus всё ещё остаётся самым распространённым протоколом связи промышленного оборудования. Описание протокола и причины его распространённости можно найти во множестве статей, например тут. Далее подразумевается, что вы знакомы с основами работы протокола.

Мы будем рассматривать Modbus RTU, но полученные выводы будут частично применимы и к Modbus TCP.

Чтобы рассчитать скорость, начнём с рассмотрения физического протокола (1й уровень модели OSI). Modbus RTU использует физический интерфейс RS-485, RS-422 или RS-232(последний практически не используется для Modbus). Для передачи сигнала данные интерфейсы используют UART (Universal Asynchronous Receiver-Transmitter). Подробнее про UART можно прочитать тут.

Стандартная посылка UART состоит из:

  1. стартовый бит ($inline$start\_bit$inline$) 1 бит
  2. полезные данные ($inline$data$inline$) 7-8 бит
  3. бит чётности ($inline$parity\_bit$inline$) 0-1 бит
  4. стоповый бит ($inline$stop\_bit$inline$) 1-2 бит

То есть на каждые 7-8 бит полезных данных передается 2-4 вспомогательных бита. Скорость передачи полезных данных ($inline$V_{data}$inline$) будет ниже скорости работы интерфейса ($inline$V_{uart}$inline$). Вычислить $inline$V_{data}$inline$ можно по формуле:

$$display$$V_{data} = \frac{V_{uart} * data}{start\_bit + data + parity\_bit + stop\_bit}$$display$$



Далее необходимо разобраться как Modbus мастер общается с подчинёнными устройствами на канальном уровне (2й уровень модели OSI). В силу особенности физического интерфейса устройства подключенные к линии передают данные последовательно, то есть только одно устройство в текущий момент времени может слать данные. Из-за этого общение мастера с подчинёнными устройствами происходит циклически, последовательно читая и записывая регистры в подчиненные устройства. Полный цикл чтения регистров из подчиненного устройства будет выглядеть следующим образом:

  1. задержка (минимум 3.5 символа = 28 бит, ниже пересчитаем в секунды)
  2. передача запроса на чтение (8 байт)
  3. задержка ответа ведомого устройства (минимум 28 бит, часто это десятки миллисекунд на формирование ответной посылки)
  4. передача ведомым устройством ответной посылки (максимум 256 байт для Modbus RTU).

Некоторые инженеры выбирают четырехпроводную версию интерфейса, надеясь на ускорение передачи (подразумевая параллельную пересылку данных на приём и передачу). Очевидно это решение не работает. Последовательность посылки данных будет одинаковой для 2х и 4х — проводных линий.

Рассчитаем время, затрачиваемое на полный цикл чтения 125ти holding registers (максимальное количество для Modbus RTU) при следующих параметрах линии:

Формат кадра: 8N1 (8 data bit, no parity bit, 1 stop bit)
Скорость uart: $inline$V_{uart}$inline$ = 19200 bit/s
Скорость передачи полезных данных: $inline$V_{data}$inline$ = 15360 bit/s
Задержка мастера: $inline$master\_silence$inline$ = 28 bit / $inline$V_{uart}$inline$ (это минимально допустимая задержка, обычно больше)
Задержка ответа ведомого устройства: $inline$slave\_silence$inline$ = 0.04 s (значение зависит от ведомого устройства)
Посылка с запросом 125ти holding registers: 8 byte или 64 bit
Ответ со 125ю holding registers: 256 byte или 2048 bit

Формула для расчёта времени цикла чтения:

$$display$$T_{cycle} = silence\_master + 64 bit / V_{data} + slave\_silence + 2048 bit / V_{data} = 0.179 s$$display$$



Последовательность на запись регистров практически идентична. Размер посылки мастера будет больше, т.к. включает в себя информацию о записываемых регистрах. Подтверждение удачной записи от ведомого устройства будет 8 байт.

По спецификации Modbus к линии RS-485/422 можно подключить 32 ведомых устройства. Опрос ведомых устройств так же ведётся последовательно, обычно по кругу. Чтобы понять с какой скорость будут обновляться данные от $inline$N$inline$ ведомых устройств, надо умножить $inline$T_{cycle}$inline$ на $inline$N$inline$ Назовем это полным временем обновления $inline$T_{full}$inline$.
Несколько расчётов $inline$T_{full}$inline$ (читаем и записываем максимальное количество holding registers) при различных параметрах связи:
Формат кадра: 8N1, $inline$V_{uart}$inline$ = 19200 bit/s, Количество ведомых устройств, $inline$N$inline$ = 16
$inline$T_{full}$inline$ = 5.727 s
Формат кадра: 8N1, $inline$V_{uart}$inline$ = 9600 bit/s, Количество ведомых устройств, $inline$N$inline$ = 16
$inline$T_{full}$inline$ = 10.173 s
Формат кадра: 7E1, $inline$V_{uart}$inline$ = 19200 bit/s, Количество ведомых устройств, $inline$N$inline$ = 16
$inline$T_{full}$inline$ = 6.355 s
Формат кадра: 8N1, $inline$V_{uart}$inline$ = 19200 bit/s, Количество ведомых устройств, $inline$N$inline$ = 2
$inline$T_{full}$inline$ = 0.716 s

Как видно формат кадра влияет на время обновления данных, но не сильно. Значительно влияет скорость передачи данных, но в нашем примере мы передаём максимальное количество регистров, в реальных проектах этот фактор может быть не столь значителен. Сильнее всего на скорость обновления данных влияет количество ведомых устройств.

Для упрощения расчётов мы сделали web приложение для оценочного расчета времени обновления данных по Modbus
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 18

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

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

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

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

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

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

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

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

                      Я тоже пару недель назад собрался с мыслями и сделал похожий анализ для работы по этому протоколу применительно к программируемым реле в программе 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

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое