Рекомендации ниже в первую очередь относятся к протоколу Modbus TCP, но частично могут быть применены и к Modbus RTU.
Для оптимизации скорости опроса есть четыре пути:
1.Сокращение количество запросов;
2.Реорганизация памяти;
3.Использование асинхронного режима опроса.
Сокращение количества запросов
Чем больше запросов выполняется к устройству - тем более медленным будет опрос. Чтобы определить сколько сейчас запросов чтения выполняется к устройству, воспользуйтесь диагностической информацией лога протокола.
Начать нужно с очевидного - избавиться от тех каналов, значения которых не нужны.
Следующим способом сокращения количества запросов является их группировка. В Modbus все запросы чтения - групповые, т.е. читается сразу набор регистров, Максимальное количество в одном запросе - 125 регистров.
Предположим, у нас есть регистры с номерами - 0, 1, 2, 5, 6, 8, 10, 12. По умолчанию в устройство будет послано 5 запросов, регистры: 0-2, 5-6, 8, 10 и 12. Можно сделать, чтобы в устройство уходило меньше запросов. Для этого предназначена настройка:
Если значение в данной ячейке превышает разрыв между соседними регистрами, то они будут сгруппированы в 1 запрос. Например, если мы укажем здесь число 2, то мы получим уже 2 запроса: 0-2, 5-12. Если укажем значение 3 - то всего один 0 – 12. Т.е. указывая значение больше или равное разрыву адресов, мы складываем их в один запрос (при условии, что общая длина запроса не превышает 125 регистров - ограничение Modbus протокола).
В случае работы с Modbus TCP можно сразу задать в это поле максимально допустимое значение -100. Как правило Modbus TCP не имеют проблем с ограничением длины запроса характерных для Modbus RTU и позволяют выполнять запросы на максимально допустимую длину пакета Modbus - 125 регистров.
Поэтому для ускорения опроса в Modbus TCP задайте значение Максимальный интервал неиспользуемых регистров - 100. После этого снова посмотрите в логе протокола количество и структуру запросов чтения. Так вы сможете понять насколько вам помогла данная оптимизация.
Реорганизация памяти
Если опрашиваемые значения очень сильно разбросаны по памяти контроллера (с разрывами более 100 регистров), то настройка Максимальный интервал неиспользуемых регистров не поможет. Поэтому, если есть возможность и доступ к исходному проекту контроллера, то следует реорганизовать память, чтобы нужные переменные шли подряд, друг за другом. Тогда количество запросов сократится до минимально возможного.
Асинхронный опрос
Асинхронный опрос можно применить, если требуется максимально быстрая реакция на запись данных. При обычном, синхронном опросе протокол посылает запрос и ожидает ответа, и так по очереди для всех запросов.
Например, для опроса всех каналов устройства требуется выполнить несколько десятков запросов, что может растянутся на 2-3 секунды. Поэтому если мы произведем запись уставки, то ее считанное значение (обратную связь) мы увидим также через 2-3 секунды, что может показаться странным для операторов и восприниматься ими как задержка.
Асинхронный опрос с прерыванием цикла чтения решает эту проблему. В этом режиме, протокол посылает запросы на чтение и запись, а затем ожидает ответы на отправленные запросы в течении времени цикла задачи (настройка протокола, по умолчанию 100 мс), полученные ответы обрабатывает и анализирует. Если время задачи вышло, то протокол выходит из цикла ожидания, и записывает считанные значения в каналы. Затем вновь заходит в задачу, посылает запросы, которые еще не были отправлены (если таковые остались) или вновь ожидает получения ответов.
В результате, если общий цикл опроса устройства составляет, например 3 секунды, то используя асинхронный режим с прерыванием, выполнив запись в канал, мы увидим это значение на входе канала через 1-2 цикла задачи, т.е. через 100-200 мс.
Мы рекомендуем применить следующий алгоритм настройки.
Сначала настройте обычный опрос (с выключенным флагом Асинхронный запрос). Посмотрите статистику АРМ или контроллера - посмотрите значение Общее время задачи. Включите Асинхронный режим и запустите проект снова. Если данные поступают, то повторно проверьте Общее время задачи. Если оно стало меньше, чем при первом запуске (или хотя бы такое же) - значит контроллер корректно обрабатывает асинхронные запросы и рекомендуется оставить асинхронный режим включенным.
После этого включаем настройку Прерывать цикл чтения при превышении времени задачи.
Смотрите также: