preo_alm
Junior Member / Новичок
Участник № / Member № 33
отправлено / posted
Мы пробовали реализовать драйвер типа Т11 для опроса 2-х групп каналов по 3 канала в каждой. Для каждой группы данные от контроллера приходят в одном пакете (для 3-х каналов сразу). При обработке этих данных по алгоритму блоковых запросов BLOCKDATA11 при опросе одного канала из группы требуемые данные поступают во все каналы этой группы (то, что надо), но при опросе 2-х групп, вначале, опрашиваются по очереди 3 канала первой группы (т.е. происходит 3 раза опрос контроллера, хотя достаточно было бы и одного раза, а каналы второй группы в это время не опрашиваются), а затем каналы второй группы (та же самая ситуация). Как сделать так, чтобы одна группа опрашивалась только один раз за цикл ( независимо от количества каналов в этой группе) и все группы опрашивались за один цикл (например, при большом периоде цикла опроса).
Сообщения / Posts 23 | Из / From: Ukraine
| IP / IP: IP адрес / IP address |
отправлено / posted
Алгоритм формирования групповых запросов, осуществляемый функцией zCompare_xxx, не зависит от того, сколько групп формируется. Если Вы запускаете проект под профайлером, то в начале протокола Вы должны увидеть список каналов для обмена по RS и в последнем параметре каждой из этих строк - признак и объем группового запроса. Алгоритм реализации групповых запросов также не зависит от количества групп. Те же алгоритмы используются во всех поставляемых с инструментальной системой протоколах Трейс Моуд и проверен практикой пользователй, писавших собственные драйверы по типу КОНТР_1. Вам следует проверить, как драйвер реализует эти процедуры при наличии каналов одной группы и двух групп. Если формирование запросов правильное, посмотрите в протоколе профайлера, как драйвер отвечает на групповые запросы (можно использовать при запуске сервера ключ /DEBUG=FFFF). Дополнительную информацию об обмене даст также канал ДИАГНОСТИКА_КОНТР_1.
Сообщения / Posts 17322 | Из / From: Россия
| IP / IP: IP адрес / IP address |
preo_alm
Junior Member / Новичок
Участник № / Member № 33
отправлено / posted
Ваш ответ не совсем показался мне понятным. Не могли бы Вы поподробнее объяснить свой ответ, а я постараюсь еще раз уточнить суть проблемы. Вот список каналов для обмена по RS 1 k2____ 11:9; 0 0 2 k1____ 11:9; 0 0 3 k3____ 11:9; 0 0 4 n1____ 11:9; 0 0 5 n2____ 11:9; 0 0 6 n3____ 11:9; 0 0 RSIN RS=0 ADDR=1 by CH=1 Q=2 RSIN RS=0 ADDR=1 by CH=2 Q=1 RSIN RS=0 ADDR=1 by CH=3 Q=0 RSIN RS=0 ADDR=2 by CH=4 Q=2 RSIN RS=0 ADDR=2 by CH=5 Q=1 RSIN RS=0 ADDR=2 by CH=6 Q=0 Я думаю, глядя на этот список, Вы поймете, в каком виде будет выводиться информация о каналах (хотя это было описано в прошлом сообщении), но меня интересует, как сделать так (изменить настройки каналов, драйвер..), чтобы одна группа обращалась к контроллеру только один раз за период опроса всех каналов, а не столько, сколько каналов в этой группе. Это первый вопрос. Вопрос второй: При опросе первой группы каналы второй группы не опрашиваются, а при опросе второй -каналы первой. Если период опроса канала Т=1час, то исходя из описанной выше ситуации получается, что периоды опроса первой и второй группы равны: Т1=Т2=2Т=2часа. Для 3-х групп - 3часа и т.д. Как сделать так, чтобы за период опроса одного канала (1час) опрашивались все группы?
Сообщения / Posts 23 | Из / From: Ukraine
| IP / IP: IP адрес / IP address |
Судя по представленному Вами фрагменту протокола, групповые запросы формируются правильно. А вот как они реализуются, это должно быть отражено в последующих фрагментах того же протокола. Далее должны быть записи текстов запросов и текстов ответов. По ним можно попытаться разобрать, какой запрос отправляется по инициативе, например, первого канала первой группы, и какой ответ от устройства получается. Этот анализ надо провести в двух вариантах: - заложены каналы только одной группы, - заложены каналы двух групп. Если запросы и ответы в обоих вариантах одинаковы, то следует обратиться к анализу работы драйвера. Это Вы сможете сделать только самостоятельно. Мы не сможем провести эту работу, поскольку не участвовали в написании драйвера, а чужие программы мы анализировать и отлаживать не можем.
Обмен по последовательному каналу оформлен как самостоятельный поток. Последовательность запросов определяется скоростью обмена и реактивностью абонентов (это типично для полудуплексного режима). Каждый сеанс (запрос/ответ) продолжается столько времени, сколько требуется абоненту на подготовку и передачу ответа, либо обрывается по тайм-ауту, который вы задаете при настройке параметров последовательного порта. Здесь очень существенным является также режим управления приемо-передатчиками у ведущего и ведомых устройств (если вы используете RS 485). Ведущие должны отвечать только на запросы, которые относятся к ним. Поэтому, строго говоря, нельзя ожидать, что последовательность всех опросов, которые имеют один период, обязательно уложится в один цикл. Поток обработки базы каналов и поток запросов по последовательному интерфейсу не могут быть полностью синхронными.
Т.к. точно такой же алгоритм используется в протоколе M_Link, Вы можете смоделировать его работу (например, создав проект в базовой версии), организовав аналогичный обмен между МАСТЕРОМ и двумя SLAVE. Чтобы аналогия была полной, повторите Ваш проект в части обмена по последовательному интерфейсу целиком, а затем замените в нем каналы КОНТР_1 на СВЯЗЬ_IN_M_Link. Если Вы на такой модели получите тот же эффект, мы готовы рассмотреть его у себя.
Тема закрыта / Topic Closed
Printer-friendly view of this topic
