This is topic Скорость обмена по M-Link in forum Микро Мониторы Реального Времени / Micro Real Time Monitors at Форум TRACE MODE: техническая поддержка.
Имеем следующую проблему. С ПЭВМ верхнего уровня по каналу M-Link (COM-порт)опрашивается порядка 100 каналов контроллера. Вроде число каналов невелико для пропускной способности в 115.2 кбит/с, но ужасно медленно происходит передача, где-то за 2 секунды, что неприемлемо. Каким образом можно ускорить обмен? Заранее спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Обратите внимание на атрибут Достоверность по всем каналам, может у Вас качество связи не совсем хорошее и часто возникают таймауты ожидания ответа с последующей недостоверностью данных? Какой таймаут задан в настройках СОМ-порта?
Posted by zotov (Участник № / Member № 1113) on :
Раньше были установлены таймауты 3000 (и на верхнем уровне, и в контроллере). Сейчас установили 500. Ситуация от этого вроде не изменилась. А как следует выбирать значения таймаута?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Таймаут - это время ожидания сервером ответа на отправленный запрос данных к устройству, либо подтверждения от устройства на принятые данные, которые передал сервер. Соответсвенно сюда входят: время реакции самого устройства + время на транзакцию данных в коммуникационной линии. Так как последнее зачастую очень мало, то во внимание принимается первый параметр.
Так что у Вас с Достоверностями по каналам при обмене?
Posted by zotov (Участник № / Member № 1113) on :
Как показали проверки, все достоверности = 0 (правда в логе протоколируются ошибки чтения порта com2). Все же непонятно, что является причиной замедления обмена. Период пересчета на нижнем уровне у нас 700 мс, на верхнем 300 мс. Запросы по M-Link происходят по инициативе верхнего уровня, т.е. в течение каждых 300 мс. Как же так ВУ не успевает считать данные из контроллера?! Понимаю, если бы верхний уровень был медленнее нижнего! В чем все-таки причина?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Дословный текст ошибки, а еще лучше кусок текста из лог-файла работы узла можете здесь привести?
Posted by zotov (Участник № / Member № 1113) on :
Судя по логу - вообще нет ответа от узла контроллера. Линия - чистый RS232? Или RS485? Если последний, то с каким управлением приемо-передатчиком и какое железо исползуется в качестве конвертера? На самом деле лечше, когда опрашиваемый узел работает в два раза быстрее того, кто опрашивает.
Posted by zotov (Участник № / Member № 1113) on :
1. Линия у нас - RS485. Управление приемником и передатчиком отсутствует, т.е. взято по умолчанию. Конвертер - I-7520R. 2. Как может опрашивающий узел быть в 2 раза медленнее?! Он тогда не сможет отобразить "быстрые" процессы в опрашиваемом узле. Могут быть пропущены короткие импульсы, в том числе и кратковременные аварийные сигналы, что крайне нежелательно, да и может быть опасным. Поэтому я совершенно не согласен с тем, что опрашивающий узел должен быть медленнее, тем более в 2 раза. Он должен быть быстрее как минимум в 2 раза. И тогда он сможет отследить все изменения сигналов в опрашиваемом узле. Но почему в нашем случае все-таки все не так? Не логично! Пропускная способность канала RS-485 более 100 кбит / сек. Каждый запрос имеет длину 14 байт (по описанию M-Link). Ответ тоже имеет длину 14 байт, т.е. опрос одного значения с ПЭВМ требует передачи лишь 28 байт. Получается, что ПЭВМ может опросить более 1000 значений за секунду! У нас же опрашивается менее 100 каналов! В чем все же проблема?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Давайте Ваш проект - попробуем запустить у нас и посмотреть причину. Удаленно трудно диагностировать, почему у Вас контроллер не отвечает на некоторые запросы МРВ.
Posted by zotov (Участник № / Member № 1113) on :
Хорошо. На какой адрес высылать проект? Нужен ли драйвер RWH?
Posted by zotov (Участник № / Member № 1113) on :
Да, мы пробовали проект и на RS-232, и на RS-485. Эффект сохраняется.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
На hotline1@adastra.ru Что за драйвер RWH, без спец оборудования в режиме эмуляции он будет работать?
Posted by zotov (Участник № / Member № 1113) on :
По идее драйвер должен работать, только значения без нашего контроллера он будет возвращать какие угодно. На работать скорее всего должен. Вышлю проект вместе с драйвером. Заранее спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это кто же Вас научил такие разрешения таймера выставлять в настройках узла для цикла пересчета? 250 микросекунд на 700 периодов в контроллере - никогда не будет работать под МикроМРВ. Минимальное значение разрешения = 0.001 секунда (1 миллисекунда). Если Вам необходим цикл пересчета базы в 175 миллисекунд, то лучше поставить Разрешение=0.025, а Период=7. А еще лучше - Разрешение=0.05, а Период=3. Аналогично - 0.00025 и 300 для МРВ тоже работать не будут никогда и не только в ТМ! Под MS Windows минимальное разрешение таймера ОС выставляет всегда в 10 миллисекунд, и нельзя его выставить меньше. Соответственно - Вам нужно подобрать здесь тоже более реальные значения. Попробуйте для начала выставить в узлах: для контроллера 4 на 0.05 и 2 на 0.05 для МРВ.
Теперь понятно, почему у Вас не работал обмен по СОМ-порту. Контроллер справедливо не отвечал, потому что 1 миллисекунды разрешения явно не хватало обработчику прерывания СОМ-порта в DOS'е для нормальной работы. Ведь в MS-DOS обработчик СОМ-порта вызывается именно с циклом Разрешения тиков таймера, которое Вы задаете в параметрах узла контроллера в проекте. Думаю, что если Вы поменяете эти настройки на рекомендуемые, проект должен у Вас заработать нормально.
Да - и для СОМ1 в контроллере не забудте тоже таймаут задать, а то он у Вас там нулевой.
Posted by zotov (Участник № / Member № 1113) on :
В том то и дело, что учить нас некому, т.к. понять из Руководства пользователя ТМ что есть Период и что есть Разрешение таймера практически невозможно и приходится работать методом "научного тыка" :-) Но это уже, правда, отдельная тема - о качестве документации :-( (Кстати, отличный пример оформления Help - MS SQL Server 2000. И теория, и масса реальных примеров, и перекрестные ссылки. По-моему, есть что перенять :-) И тем не менее ... Поясните, пожалуйста, что все-таки такое Период. По документации мы поняли (подозреваем, что неправильно), что это рекомендуемое время пересчета базы каналов узла, задаваемое в миллисекундах. И что такое Разрешение? Наконец, по каким критериям нужно выбирать значения этих параметров?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Разрешение - это период одного тика аппаратниго таймера в секундах. Для MS Win - от 0.010 до неограниченного значения. Для MS DOS - от 0.001 до 0.055 секунд. Период - количество тиков таймера в одном цикле.
То есть: Цикл пересчета узла=Период*Разрешение.
Posted by zotov (Участник № / Member № 1113) on :
Понятно. Спасибо. 1. А что понимается под циклом в определении периода? 2. К сожалению, с рекомендованными Вами настройками периода и разрешения качество связи в нашем проекте только ухудшилось :-( Если с подобранными нами установками связь осуществлялась "через раз", то с рекомендованными - "через 3 раза" :-((
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Цикл пересчета базы каналов узла. 2) В логе также ошибки идут?
Posted by zotov (Участник № / Member № 1113) on :
Да, ошибки те же ... по порту COM2.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Попробуйте отключить от обмена часть каналов и оставить только 10 или больше. Может линия связи или СОМ-порт сбоит?
Posted by zotov (Участник № / Member № 1113) on :
При снижении числа подключенных каналов скорость обмена растет. С портом вроде все в порядке. А Вы не можете запустить наш проект у себя? В принципе он должен заработать. Драйвер есть. Только для запуска используйте файл kotel.bat.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Зачем в контроллере и в АРМе Вы создали такое огромное количество каналов ПУСТОЙ-Key_Read, тем более в контроллере? 2) Что за контроллер Вы используете и почему именно МикроМРВ без поддержки сопроцессора запускаете?
Судя по объему базы каналов+два СОМ порта на скорости 115.2+RWH-драйвер - у Вас МикроМРВ без сопроцессора не потянет такую задачу. Да и аппаратная платформа нужна тоже не слабая. Сейчас пытаюсь запустить Ваш проект - похоже что драйвер Ваш не заработал у нас...
Чуть позже будут результаты испытаний.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Результаты вполне соответсвуют тому, о чем я уже сказал выше. На моем тестовом контроллере Теконик с ЦПУ Intel486 75Мгц, Ваш проект с отключенным обменом с внешним драйвером и DK8070 под обычным МикроМРВ требует как минимум 500 мс времени на пересчет всей базы. Скорее всего у Вас действительно система не успевает обрабатывать запросы по M-Link от АРМа, потому как у Вас идут постоянные превышения цикла пересчета. Что показывает в контроллере канал подтипа СИСТЕМНЫЙ_время пересчета, попробуйте его по M-Link в АРМ запросить?
Posted by zotov (Участник № / Member № 1113) on :
СИСТЕМНЫЙ_Время пересчета мы выводим на DK-8070. Он показывает 385 мс.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
А цикл для узла какой сейчас задан?
Posted by zotov (Участник № / Member № 1113) on :
Имеете в виду период пересчета узла? Мы задавали его от 500 до 750 мс (пробовали разные значения, меняли разрешение и период в настройках обоих узлов). В принципе, удалось добиться более-менее хорошей связи при 700 мс в контроллере и 200 в ПЭВМ верхнего уровня. Но все равно верхний уровень может пропускать значения с контроллера, правда, теперь не каждое второе, а где-то каждое пятое. С уменьшением периода контроллера до 500 процент пропускаемых значений в ПЭВМ возрастает. Если ставить меньше 500, то уже перестает обновляться экран DK8070. PS: Процессор контроллера у нас на 300 МГц.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это на обычном МикроМРВ - не mrt86 который?
Posted by zotov (Участник № / Member № 1113) on :
Да, это на микроМРВ.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Я имел в виду МикроМРВ, который с поддержкой сопроцессора: mrt_e.exe или mrt.exe?
Posted by zotov (Участник № / Member № 1113) on :
mrt86_e
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Почему Вы используете mrt86_e.exe? Это МикроМРВ без поддержки сопроцессора, предназначен для старых конфигураций ЦПУ, в которых нет сопроцессора. У Вас же нормальная процессорная система - используйте обычный МикроМРВ - он гораздо быстрее безсопроцессорного варианта!
Posted by zotov (Участник № / Member № 1113) on :
Спасибо. Проверим работу системы с mrt7.exe. Похоже, мы упустили этот модуль из виду и использовали медленный безсопроцессорный mrt86.exe.
Posted by zotov (Участник № / Member № 1113) on :
Да. С mrt7.exe обмен работает стабильно при периодах контроллера даже в 0.3 сек. Спасибо. PS: Будем внимательнее читать readme
![[Улыбка / Smile]](smile.gif)