Статистика опроса модулей ОВЕН

[Спорягин Кирилл]

Добрый день, уважаемые форумчане!

Появилась возможность собрать статистику опроса модулей ОВЕН. Привожу результаты экспериментов.
Думаю, что они будут интересны как корефеям ОВЕНа, так и новичкам. Довольно часто на форуме спрашивают уложится ли опрос определенного набора модулей в заданное время. Надеюсь, что собранная мной статистика поможет ответить на подобные вопросы.

Структура стенда:
1. ПЛК110-24.30.Р-М M02 (мастер сети Modbus RTU);
2. МУ110-220.32Р (адрес - 1);
3. МВ110-220.32ДН (адрес - 2);
4. МВ110-224.8А (адрес - 3).

Проект контроллера, и архив с конфигурацией модулей прикрепляю.
Опрос выполнен с помощью универсального диспетчера (http://www.owen.ru/forum/showthread.php?t=25112). Единственное, что я добавил в базовую структуру модулей дополнительное поле "полного числа ошибок".

Статистические данные собраны в таблицах 1 и 2 на рисунке "Статистика опроса модулей".

[Спорягин Кирилл]

Дам некоторые комментарии по проведению экспериментов и результатам.

В настройках опроса во всех экспериментах были установлены следующие параметры:
1. TimeOut (максимальное время ожидания ответа от модуля) у всех модулей был установлен в 60 мс;
2. FramingTime (пауза между опросами модулей) был установлен в 5 мс;
3. PollingTime (период опроса) для модулей МВ110-32.ДН и МУ110-32Р был установлен в 100 мс;
4. PollingTime (период опроса) для модуля МВ110-8А установлен в 200 мс.
5. MaxAttempts (максимальное количество попыток опроса, в случае неудачной первой попытки) у всех модулей был установлен в 2. Т.е. если первая попытка опроса завершалась неудачно, то контроллер (диспетчер) пробовал еще раз опросить модуль. В случае, если вторая попытка завершалась неудачно, то контроллер переходил к опросу следующего модуля и возвращался к опросу этого уже спустя время PollingTime.
6. MinCycleLength у контроллера равна 1 мс.


Анализ таблиц 1 и 2.

I.
Для начала оценим теоретическое время чтения/записи 4 байт (модули МВ110-32ДН и МУ110-32Р).
Команда чтения/записи состоит из: адреса уст-ва (1 байт) + номера функции (1 байт) + адреса регистра (2 байта) + кол-ва регистров (1 байт) + CRC (2 байта) = 7 байт.
Ответ в общем случае состоит из: адреса уст-ва (1 байт) + номера функции (1 байт) + кол-во данный (1 байт) + данные (4 байт) + CRC (2 байта) = 9 байт.
Итого передать по сети туда-обратно нужно 16 байт.
Таким образом теоретически чтение/запись для дискретных 32-х канальных модулей ввода/вывода должна составлять на разных скоростях следующие значения:
1. Для 9600: 16*9*1000/9600 = 15 мс;
2. Для 19200: 16*9*1000/19200 = 7,5 мс;
3. Для 38400: 3,75 мс;
4. Для 57600: 2,5 мс;
5. Для 115200: 1,25 мс.

Как хорошо видно из таблицы 1, теоретическое время значительно отличается от практического. Сразу оговорюсь, что такое явление наблюдается и для других слейвов. Так, например, давно я измерял время опроса ПЛК S7-1214 (см. тут (http://www.owen.ru/forum/showthread.php?t=21940&page=5&p=179837&viewfull=1#post179837)) и там практическое время опроса так же значительно отличалось от теоретического.

Так же следует пояснить почему иногда минимальное и максимальное время опроса близки к среднему (например для МУ110 на скоростях <= 19200), а иногда сильно отличаются (МУ110 на скоростях > 19200).
Это связано с организацией опроса. Так как у всех модулей количество попытко опроса равно 2, то при первичной неудачной попытке опроса, которая оканчивается по таймауту (а он у нас 60 мс), модуль повторяет опрос. В этом случае время опроса складывается из собственно времени опроса и времени таймаута.

II.
Из таблицы 2 видно, что на скоростях <= 19200 количество ошибок опроса модулей равно 0 для всех модулей.
На скоростях 38400 и 57600 их количество ничтожно - меньше 17*100/9000 = 0,2%.
А вот на скорости 115200 процент ошибок уже становится ощутимым. Хотя почему-то только один модуль МУ110 преимущественно выдает ошибки. Процент ошибок для него составляет:
9709*100/408000 = 2,4%.

[capzap]

Для начала оценим теоретическое время чтения/записи 4 байт (модули МВ110-32ДН и МУ110-32Р).
Команда чтения/записи состоит из: адреса уст-ва (1 байт) + номера функции (1 байт) + адреса регистра (2 байта) + кол-ва регистров (1 байт) + CRC (2 байта) = 7 байт.
Ответ в общем случае состоит из: адреса уст-ва (1 байт) + номера функции (1 байт) + данные (4 байт) + CRC (2 байта) = 8 байт.
Итого передать по сети туда-обратно нужно 15 байт.
Таким образом теоретически чтение/запись для дискретных 32-х канальных модулей ввода/вывода должна составлять на разных скоростях следующие значения:
1. Для 9600: 8*8*1000/9600 = 6.6 мс;
2. Для 19200: 8*8*1000/19200 = 3.3 мс;
3. Для 38400: 1,6 мс;
4. Для 57600: 1,1 мс;
5. Для 115200: 0,55 мс.


что касается модбас смотрим на картинку, как минимум не хватает по одному байту в запросе и ответе. То что максимум можно прочитать количество регистров вмещающихся в размерность одного байта, не означает что на количество регистров в запросе тратится один байт. В ответе перед данными идет количество передаваемых байт
Кроме того ни как не упомянуты сетевые настройки, зачем мы выставляем тогда количество стоп-битов, размер данных, а еще существуют допустимые паузы между кадрами, в модбасРТУ это описано, вот плохо когда человек берется за сбор статистики, усовершенствовав только надстройку над модбас библиотекой и не разобравшись с самим протоколом. Расчеты прохождения пакетов раньше приводились на вики-страничке, сейчас правда оттуда убраны и здесь на форуме был правильный теоретический расчет. Напомню, что слейв еще должен обработать информацию чтоб что то отправитьи плюсом в его настройках может стоять время задержки ответа больше нуля

[Трофимов Артем]

Мы проводили теоретический расчёт для опроса одного регистра по Modbus RTU на настройках 9600 8N1 - итог запрос - ответ составляет 36.3 мс ( с учётом необходимых таймаутов фрейма протокола).
Также был проведён эксперимент на ПЛК304 с использованием библиотек Modbus.lib , немного округлив до 40мс время цикла опроса и таймаут ожидания ответа , мы получили сабильный обмен данными без провалов в сообщениях.
slave'ами выступали как новый ПЛК110 [М02] так и модули дискретного ввода МВ110-16ДН, модули дискретного вывода МУ110-16Р .

[Спорягин Кирилл]

Я подправил расчет. Главная опечатка была в том, что я пишу, что необходимо 16 байт передавать туда-обратно, а сам умножал на 8 байт. Замылился глаз.
Так же учел стоп-бит. Теперь умножаю на 9, а не на 8.
Значения измелись, но существенная разница все равно осталась между теоретическим временем и практическим.

[Спорягин Кирилл]

Мы проводили теоретический расчёт для опроса одного регистра по Modbus RTU на настройках 9600 8N1 - итог запрос - ответ составляет 36.3 мс ( с учётом необходимых таймаутов фрейма протокола).
Также был проведён эксперимент на ПЛК304 с использованием библиотек Modbus.lib , немного округлив до 40мс время цикла опроса и таймаут ожидания ответа , мы получили сабильный обмен данными без провалов в сообщениях.
slave'ами выступали как новый ПЛК110 [М02] так и модули дискретного ввода МВ110-16ДН, модули дискретного вывода МУ110-16Р .

Артем, Вы не могли бы показать свой расчет. Потому как по Вашим данным практически быстрее, чем теоретически. Это странно вдвойне.

[Трофимов Артем]

Кирилл, я постараюсь найти расчёт ( он был года два назад) и выложить тут.
могу выложить проект ( он под рукой) . задача была на скорости 9600 опросить 16 устройств по одному регистру за секунду или быстрее ( второе собственно и получилось).

[Трофимов Артем]

Пропускная способность ModBus RTU.
Обычно, на каждые 8 бит, передаваемые по UART приходится 2 служебных:
стартовый и стоп-бит (при формате 8-н-1, т.е. 8 бит данных без контроля
чётности и один стоп-бит). Кадр ModBus RTU составляет от 4 до 256 байт.
Между кадрами должна соблюдаться пауза в 3,5 символа.
Таким образом, минимальное время передачи одного кадра длиной 4 байта
на скорости 115200 бод составит (4+3,5)*10/115200 = 651 мкс; для кадра
длиной 256 байт это время составит 22,5 мс. На скорости 9600 аналогичные
кадры передадутся за 7,8 мс и 270,3 мс, соответственно.

[Спорягин Кирилл]

Пропускная способность ModBus RTU.
Обычно, на каждые 8 бит, передаваемые по UART приходится 2 служебных:
стартовый и стоп-бит (при формате 8-н-1, т.е. 8 бит данных без контроля
чётности и один стоп-бит). Кадр ModBus RTU составляет от 4 до 256 байт.
Между кадрами должна соблюдаться пауза в 3,5 символа.
Таким образом, минимальное время передачи одного кадра длиной 4 байта
на скорости 115200 бод составит (4+3,5)*10/115200 = 651 мкс; для кадра
длиной 256 байт это время составит 22,5 мс. На скорости 9600 аналогичные
кадры передадутся за 7,8 мс и 270,3 мс, соответственно.

Тогда как я правильно понимаю, расчет принимает следующий вид.
Первый кадр - это запрос. Запрос на чтение из модуля МВ110-32ДН = 7 байт (см. выше). Плюс 3,5 символа - пауза между кадрами. Того 10,5 байт.
Второй кадр - это ответ. Ответ модуля = 9 байт (см. выше). Плюс 3,5 символа = 12,5 байт.
Полный цикл обмена (запрос-ответ) = 10,5 + 12,5 = 23 байта.
1. Для скорости 9600 получаем: 23*10*1000/9600 = 23,95 мс. Статистика опроса модуля МВ110-32ДН на скорости 9600 показывает 33 мс. Уже довольно близко, но все же теоретический расчет дает меньшие значения, чем практические измерения.
Видимо, эти 9,05 мс уходят на раздумья модуля?

Артем, жду от Вас комметариев, как от представителя производителя.

[capzap]

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

[Трофимов Артем]

данный расчёт слишком точен, тут необходимо добавить время задержки ответа от модуля , времена переключения портов из приёма в передачу и обратно , также цикл контроллера ( а лучше два, т.к. окончание посылки может попасть в самое начало фазы обработки программного кода (после фазы вычитки входных параметров) , т.е. завершение работы приёма будет только в окончании следующего цикла , т.к. буфер будет дочитан полностью и будет подана команда на готовность к передаче) .
все эти микро- и милли-задержки складываются, потому мы обычно , чтобы не вдаваться в подробности рекоммендуем и говорим сразу +10 а то и +15 мс на такой скорости к расчитанной по математике.
пару вопросов :
1) каково реальное время исполнения программы у Вас на ПЛК? если смотреть в модуле статистики
2) в таймерах используете такты цикла или опираетесь на время? ( погрешность при переключении стадий тоже может внести свою лепту, но это уже очень глубокий анализ)

[Спорягин Кирилл]

Ответ в целом понятен. Спасибо.



пару вопросов :
1) каково реальное время исполнения программы у Вас на ПЛК? если смотреть в модуле статистики
2) в таймерах используете такты цикла или опираетесь на время? ( погрешность при переключении стадий тоже может внести свою лепту, но это уже очень глубокий анализ)

1. Реальное время исполнения программы указываемое в модуле статистики 100 мкс. MinCycleLength указан = 1 мс.
2. В таймере использую функцию Time(). Первый раз вызываю ее в начале опроса (при взводе Enable). Второй раз вызываю, как только получил ответ (Complete = tue). По разнице определяю время опроса. Более подробно можно понять посмотрев библиотеку GCTimer.lib (прикреплена в посте №1).

Артем, встречный вопрос.
Из-за чего возникают ошибки модуля МУ110 на скорости 115200?
Быть может какой-то процент ошибок в сети RS-485 является нормой?

[Трофимов Артем]

0.5 % ошибок считается нормальным для домашних условий.
1.0 % для систем где линия подвержена ЭМ воздействию извне.
о каком конкретно модуле МУ110 Вы говорите? из поста 1 про 32Р?

[Спорягин Кирилл]

о каком конкретно модуле МУ110 Вы говорите? из поста 1 про 32Р?

Да, про него. Причем видно, что распределение ошибок по модулям явно не равномерно. Практически все ошибки приходятся на модуль МУ110-32Р.

[Спорягин Кирилл]

Глянул выше на результаты измерений. Не впечатлило.

Мастер 110й, старый. Минц 0.
Слейв МУ110-32Р (ессно 2 регистра разом)

Рез-т
38400, 9.1мс (110 транзакций/сек). 50тыс запросов. Ошибок - 0
115200, 6.1мс, (164 транз/сек) пока писал ответ - за 500 тыс запросов. Ошибок - 0.
9600, 24.3мс (411транз/10сек). Ни одной ошибки не дождался пока пил чай.

1. Валенок, можете прокомментировать свои результаты.
Как я понимаю, Вы не используете Modbus.lib, а используете SysLibCom.
Если Вам известны узкие места библиотеки Modbus.lib, которые не позволяют получить максимальное быстродействие при опросе, не могли бы Вы их указать?

2. Все же откуда возникают ошибки. Может ли быть причина в том, что на стенде я использовал не экранированную витую пару, а 2 простых провода?
Откуда на стенде помехи?

[Спорягин Кирилл]

1. Modbus это и есть SysLibCom. Делал тупо по википедии и логике протокола.

Понятно, что в библиотеке Modbus.lib ОВЕН использует функции из SysLibCom. В этом не трудно убедиться, просто заглянув туда.
Но использовать их можно по-разному. Вот я и спрашиваю: "Если Вам известны узкие места реализации Modbus.lib, то расскажите?"
В противном случае мне не понятно почему Вы решили реализовывать протокол самостоятельно вместо того, чтобы воспользоваться библиотекой Modbus.lib?



2. Не знаю. Если там только плк и модули - хоть пвс. Помеха и ошибка разные вещи (в смысле не все ошибки - от помехи) - по шагам разбирайте Modbus, что/куда/накой/в каких количествах.

Вот и я не знаю откуда ошибки на стенде?
Скажу более и в реальных системах я наблюдаю наличие ошибок. Причем и со сторонним оборудованием (например, частотники ABB) тоже. Так же ошибки есть, если пользоваться стандартным конфигуратором (и на стенде и на реальном объекте).

[Спорягин Кирилл]

Вот здесь (http://www.owen.ru/forum/showthread.php?t=21940&page=4&p=178550&viewfull=1#post178550) Вы пишите:
"Перейдя на modbus.lib через некоторое время уходишь на просто syslibcom.lib, т.к. modbus.lib простой и надежный - но можно и улучшить".

Одним словом раскройте тему, если возможно.

[Спорягин Кирилл]

И сразу еще вопрос.
А в реальных проектах Вы отслеживаете процент ошибок. И есть они там у Вас?

[Спорягин Кирилл]

Сожалею, что избегаете серьезного ответа.

[Спорягин Кирилл]

SysLibCom еще более низкоуровневая, но Вы ее используете, отказываясь от Modbus.lib. Вот я и спрашиваю, что конкретно Вам не нравится в Modbus.lib.

[Спорягин Кирилл]

Можете конкретизировать на примере, как быстрее подняться с этажа 1 на этаж 3?

[Спорягин Кирилл]

Эксперименты выполнялись на прошивке 3.53. После перепрошивки на 3.67 ошибки на сети RS-485 свелись к 0 (см. тут (http://www.owen.ru/forum/showthread.php?t=26000&page=5&p=238258&viewfull=1#post238258)).
Остальная статистика не изменилась.