Комментарии 19
Не знаю в каких условиях вы использовали такие скорости на такой дальности, но у нас, на двух частотниках в шкафу, приходилось сбрасывать скорость до 9600. Иначе помехи при включении движков.
И что угодно можно делать — заземлять, экранировать...
С другой стороны интерфейсные лини обычно не используются в критически важных процессах. Например, обновлять температуру жидкости в цистерне с задержкой в 1мс нет никакой необходимости. Соответственно экономят там, где можно.
Но не всё так плохо, есть, например IEC 61850 с его peer-to-peer GOOSE сообщениями с гарантированной доставкой в 4мс.
С циклом управления 20 мс.
Скорость MODBUS точно рассчитать невозможно.
На каждую команду и на доступ к определенным группам данных у слэйвов отдельно специфицируются таймауты реакции.
Например, одно дело записать в рабочий регистр, а другое в NV регистр.
Поэтому если требуется жесткий риалтайм, то надо непосредственно в софте мастера реализовывать измеритель таймаутов, кторый нужен для экспериментального подбора состава пакетов и организации их отправки.
Из-за такого запоздалого квитирования MODBUS не рекомендуют для управления движущимися объектами (но я нарушаю рекомендацию).
Лучший выбор будет CAN, где квитирование сразу во время передачи пакета слэйвам, и EtherCAT где квитирование мгновенное и сразу от всех слэйвов.
И да, это чисто теоретические выкладки или проверено на практике?
Мне всегда было лень считать.
Время ожидания по-хорошему настраивается индивидуально во время пуско-наладки. При времени ожидания 300мс, каждое не отвечающее устройство будет добавлять задержку 300мс в полный цикл опроса. Соответственно, если включен повторный запрос, то добавиться ещё 300мс и т.д.
Выкладки основаны на реальных цифрах поэтому от практики не должны отличаться. Допущение в том, что я использовал для расчётов пересылку максимального количества регистров, что редкость на практике. Чуть позже добавим возможность изменять количество пересылаемых регистров и тогда можно будет посчитать вариант близкий к своей конфигурации.
Посмотрел web, похоже что чистая теория, чтение =x mc, чтение и запись = 2*x ms, в реальной жизни чуть больше зависимостей, начиная от того за сколько слейв отвечает, в некоторых модулях это время настраиваемое, до самих настроек периода опроса и других параметров, так же сильно влияет тип запроса групповой или одиночный и это без рассмотрения ситуации, что кто-то "отвалился" на линии. Замеры разных команд на разных скоростях сделаны тут https://youtu.be/kOo4INKt8Nw для ситуации с одним слейвом.
Я тоже пару недель назад собрался с мыслями и сделал похожий анализ для работы по этому протоколу применительно к программируемым реле в программе 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
Окончательно разбираемся со скоростью передачи по Modbus