This is topic Период пересчета in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/35/t/000108.html

Posted by Алекс К (Участник № / Member № 1337) on :
 
Есть 6 каналов связаных с источниками modbus. Надо чтобы 2 из них пересчитывались реже. И соответственно запросы по COM отсылались реже. При установке этим каналам в настройках периода пересчета отличных значений от других каналов - никаких изменений не происходит. По линии связи запросы идут одинаково - подряд для всех каналов.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Обычно групповые запросы настолько экономичнее по трафику, чем одиночные, что зачастую оказывается выгоднее запросить лишние переменные, чтобы не разрывать групповой запрос, чем посылать несколько коротких запросов.
Групповой запрос на 6 каналов - это 1 транзакция общим объемом 25 байт.
2 "частых" запроса - 34 байта.
1 "редкий" запрос - 15 байтов.
Никакого выигрыша в трафике COM-порта в этом конкретном случае Вы не получите.
Пусть запросы идут в полном объеме, а обработку каналов, если нужно, сделайте более редкую.
 
Posted by Алекс К (Участник № / Member № 1337) on :
 
Забыл самое главное. Все 6 каналов опрашивают разные адреса устройств. Что тогда?
и обьясните пожалуйста след. ... "а обработку каналов, если нужно, сделайте более редкую."
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Если я правильно понял, 6 каналов опрашивают 6 разных MODBUS-Slave?
В таком случае речь может идти только о том, что поток запросов (асинхронный по отношению к основному потоку обработки каналов) не успевает отработать все запросы за 1 цикл работы МРВ.
Надо просчитать все во времени. Подключите, например, PortMon и просмотрите во времени весь трафик.
Если не сможете провести анализ протокола PortMon2, присылайте нам проект вместе с протоколом.
2. Обработка каждого канала при одном и том же цикле персчета базы каналов в МРВ определяется собственными настройками канала ("Период" и "Единица измерения"). Изменяя эти настройки, можно изменять период обработки каждого канала.
 
Posted by Алекс К (Участник № / Member № 1337) on :
 
Спасибо, но Вы не поняли.
Нам надо сделать так:
1й цикл modbus в линии связи запрашивает адреса 1-4
2й цикл modbus запрашивает адреса 1-4
3й цикл modbus запрашивает адреса 1-6
и заново.
Имееется ввиду цикл запросов, который Вы видете в Portmon'e
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Я уже писал выше, что групповой запрос определяется вне зависимости от задаваемых Вами циклов обработки каналов - по циклу обработки первого канала из группового запроса.
Для того чтобы реализовать разные запросы, надо создать 2 группы каналов - с адресами 5-6 и с адресами 1-4.
Тогда Ваш регламент будет выглядеть иначе:
1й цикл modbus в линии связи запрашивает адреса 1-4 - 21 байт,
2й цикл modbus запрашивает адреса 1-4 - 21 байт,
3й цикл modbus запрашивает адреса 1-4 и адреса 5-6 - 21 байт + 17 байтов = 38 байтов.
Итого за 3 цикла 80 байтов.
Если оставить групповой запрос адресов 1-6, то за 3 цикла будет 25*3=75 байтов.
Т.о., никакой выгоды в загрузке RS-канала Вы не получаете.
Если при этом еще учесть асинхронность RS-потока по отношению к основному потоку обработки каналов, то реализация преполагаемого Вами регламента может оказаться в принципе проблематичной.
 
Posted by Алекс К (Участник № / Member № 1337) on :
 
1-6 - это адреса устройств. Всего 6 устройств - с каждого принимается 8 байт данных. Для данных с 4х устройств критично время обновления, для данных с 2х утсройств нет (их нужно опрашивать реже в 3 раза). Как это лучше реализовать?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В этом случае единственное решение - задавать разные циклы обработки каналам с адресами устройств 1-4 и 5-6.
Похоже, что Вы задаете такие циклы обработки этих каналов, что поток по COM-порту не успевает их обрабатывать в течение одного цикла обработки базы каналов.
Например, если реальная продолжительность одной транзакции (запрос/ответ от одного канала) равна 0.1 сек., то при заданном цикле обращения 0.2 сек. в течение одного цикла можно будет обработать только 2 транзакции. На 4 "быстрых" транзакции будет затрачено 2 цикла. Поэтому "медленные" каналы будут опрашиваться с тем же периодом, что и "быстрые".
В такой ситуации надо либо повышать реальную скорость обмена, либо увеличивать циклы опроса.
Все это описано для случая, если к одному прибору осуществляется 1 групповой запрос.
Если к одному прибору осуществляется несколько запросов (например, с разными функциями MODBUS), то ситуация еще усугубляется.
А если в реальном процессе обмена появятся ошибки, то реальная производительность RS-канала снизится и разницы между потоками "быстрых" и "медленных" каналов совсем не будет.
 
Posted by Алекс К (Участник № / Member № 1337) on :
 
А вариант подключения - отключения канала к источнику не подходит?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Вариант управления подключением к источнику подходит, однако он требует программной реализации этой функции управления. Это не сложно, но все-таки это дополнительная математическая процедура.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2