Страница 1 из 3 123 ПоследняяПоследняя
Показано с 1 по 10 из 22

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

  1. #1
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

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

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

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

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

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

    Статистические данные собраны в таблицах 1 и 2 на рисунке "Статистика опроса модулей".
    Изображения Изображения
    Вложения Вложения
    Последний раз редактировалось Спорягин Кирилл; 10.02.2017 в 11:16. Причина: Добавлена библиотека

  2. #2
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

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

    В настройках опроса во всех экспериментах были установлены следующие параметры:
    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 (см. тут) и там практическое время опроса так же значительно отличалось от теоретического.

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

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

  3. #3
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,383

    По умолчанию

    Цитата Сообщение от Спорягин Кирилл Посмотреть сообщение
    Для начала оценим теоретическое время чтения/записи 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 мс.
    что касается модбас смотрим на картинку, как минимум не хватает по одному байту в запросе и ответе. То что максимум можно прочитать количество регистров вмещающихся в размерность одного байта, не означает что на количество регистров в запросе тратится один байт. В ответе перед данными идет количество передаваемых байт
    Кроме того ни как не упомянуты сетевые настройки, зачем мы выставляем тогда количество стоп-битов, размер данных, а еще существуют допустимые паузы между кадрами, в модбасРТУ это описано, вот плохо когда человек берется за сбор статистики, усовершенствовав только надстройку над модбас библиотекой и не разобравшись с самим протоколом. Расчеты прохождения пакетов раньше приводились на вики-страничке, сейчас правда оттуда убраны и здесь на форуме был правильный теоретический расчет. Напомню, что слейв еще должен обработать информацию чтоб что то отправитьи плюсом в его настройках может стоять время задержки ответа больше нуля
    Изображения Изображения
    • Тип файла: png owen.png (18.5 Кб, Просмотров: 155)
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

  4. #4

    По умолчанию

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

  5. #5
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

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

  6. #6
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

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

  7. #7

    По умолчанию

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

  8. #8

    По умолчанию

    Пропускная способность 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 мс, соответственно.

  9. #9
    Пользователь
    Регистрация
    10.11.2014
    Адрес
    Санкт-Петербург
    Сообщений
    646

    По умолчанию

    Цитата Сообщение от Трофимов Артем Посмотреть сообщение
    Пропускная способность 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 мс уходят на раздумья модуля?

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

  10. #10
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,383

    По умолчанию

    не совсем верно, пауза 3.5 символа это время после которого принимается решение что запрос или ответ полностью переданы, внутри посылки паузы намного меньше и время это описывается как не более, соответственно может и не быть пауз, тут все зависит от микросхем. И еще есть разделение по продолжительности пауз в зависимости от применяемой скорости, но это если для теоретических расчетов, на практике такие времена по-моему не существенны
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

Страница 1 из 3 123 ПоследняяПоследняя

Похожие темы

  1. Зависание опроса модулей
    от KSergey в разделе ПЛК1хх
    Ответов: 5
    Последнее сообщение: 27.07.2016, 08:33
  2. Ответов: 4
    Последнее сообщение: 10.02.2015, 16:12
  3. Порядок опроса по Rs485 нескольких модулей
    от InV в разделе Сетевые технологии
    Ответов: 2
    Последнее сообщение: 16.12.2012, 08:38
  4. Скорость опроса модулей ввода/вывода.
    от Sergey_Byk в разделе ПЛК3хх
    Ответов: 14
    Последнее сообщение: 16.11.2012, 08:53

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •