Помогите, пожалуйста, решить проблему. Структура проекта ТМ содержит два узла: операторская станция (ОС) и контроллер Теконик. ОС и контроллер обмениваются по протоколу M-Link. ОС является Master в сети RS-485. Она осуществляет запрос данных с контроллера. В запросе учавствуют 107 дискретных и 57 аналоговых каналов, все они имеют дополнение к подтипу In M-Link. Есть особенность в организации сети RS-485, с которой и связана проблема. Связь последовательных интерфейсов осуществляется посредством радиомодема "Невод" компании Геолинк. Максимальная скорость передачи по радиоканалу 100 байт/сек, режим передачи полудуплексный, объем буфера последовательного интерфейса на прием 2,7 кбайта. Очевидно что при частоте опроса каналов раз в секунду большенство каналов не будут успевать обновляться (прикинуто на глаз). Помогите прикинуть точно. Действительно ли, что когда установлена апертура на значения канала, то протокол M-Link не передает те каналы, которые не вышли за ее пределы? Не могу найти в описании этой особенности. Но так или иначе ОС все равно делает запросы на все каналы, как запросы влияют на загрузку сети? В одном из старых диалогов форума я прочитал, что протокол M-Link описанный в книжке по ТМ не совсем тот, который работает на самом деле, там же Вы написали что высылаете всем желающим описание протокола M-Link того, который нужен. Вышлите нам, пожалуйста alexsd@bk.ru. Как поступить в нашей ситуации, как посчитать пропускную способность радиоканала в отношении каналов ТМ, есть ли необходимость писать собственные алгоритмы отсекающие холостой обмен по сети? Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Дело в том, что каналы типа In M-Link - это каналы, которые запрашивают данные, и запросы генерируются с циклом пересчета этих каналов. Апертура Вам здесь не поможет, потому что она должна задаваться на запрашиваемых каналах, а не на каналах, которые запрашивают данные - последние не могут получать уведомления типа "данные изменились, можно запрашивать". Вот если бы у Вас контроллер был Мастер и передавал на ОС данные каналами Out M-Link, тогда бы Апертура помогла, потому как отправка пакетов по Out M-Link'у происходит не с периодом пересчета канала, а только по изменению значения его атрибута "Реальное". В Вашем же случае есть два выхода: 1) Понизить периоды пересчета каналов In M-Link на ОС, тем самым понизив траффик обмена. 2) Управлять Состоянием этих каналов, а на нижнем уровне реализовать канал, который будет опрашиваться ОС постоянно. В этот канал помещать какие-либо значения о текущем состоянии всех каналов контроллера, то есть - реализовать что-то вроде программы, которая будет анализировать момент когда верхнему уровню пора выполнить запрос к контроллеру, потому как большинство каналов поменяло свое значение. Как пример такой программы - анализ атрибута Тенденция опрашиваемых каналов. Признак скачка по тенденции заводить на счетчик и как только значение счетчика выйдет на определенный уровень можно выдать сигнал о том, что контроллер можно опросить верхним уровнем.
Posted by Саша (Участник № / Member № 925) on :
вышлите, пожалуйста, по электронке alexsd@bk.ru описание протокола M-Link. Для того чтобы была возможность оценить Ваши предложения так или иначе необходимо просчитать возможную информационную загрузку радиканала протоколом M-Link, сделать это без его описания мы не сможем.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Описание протокола M-Link5 есть в нашей справочной системе ТМ в разделе "ПРИЛОЖЕНИЯ"-"Описание протокола M-Link", там и 4-я и 5-я версии описаны.
Posted by Саша (Участник № / Member № 925) on :
В приложении есть только описание протокола M-Link версии 4.20. Пятой версии я не нашел. Существенно ли они разлиаются? В описании протокола 4.20 есть не понятный момент. в посылке осуществлящей запрос указываются номер начального канала N4N3N2N1 и номер последнего канала E4E3E2E1. Получается что либо все запрашиваемые каналы должны иметь последовательный номерной порядок в диапазоне N4N3N2N1 - E4E3E2E1 в базе каналов SLAVE или протокол генерирует столько команд запроса сколько в базе каналов узла SLAVE последовательно сгруппированных групп запрашиваемых каналов. Получается количество команд запроса зависит от рассредоточенности запрашиваемых каналов по базе каналов узла SLAVE? Хотел Вас попросить подтвердить правильно или нет я понимаю протокол. Рассмотрим предложенную Вами схему обмена, когда контролер является мастером и каналы с дополнением к подтипу Out-Mlink передают информацию наверх в операторскую станцию. На сколько я понял для передачи таким образом одного значения (например реального) аналогового канала мне необходимо передать на верх 14 бит информации (я не учитываю служебную информацию передаваемою логикой модема) и получить назад ответ размером 14 бит, т.е. всего загрузка сети составит 28 бит в обоих направлениях. Если речь идет о дискретных каналах то посредством 28 бит я смогу передать 16 дискретных сигналов от модулей в/в. Т.е. при скорости радиоканала модема 100 бит/сек я смогу передать грубо говоря 4 аналог. канала в секунду или 64 дискретный сигнала в секунду. Верны ли мои рассуждения?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Начиная с релиза 5.11 в Справочной системе рядом с описанием протокола M_Link 4.20 находится описание протокола M_Link версии 5. 2. Действительно, групповые запросы формируются с учетом упорядоченности каналов приемников и каналов-источников. При этом в одном запросе могут присутствовать только каналы-источники со строго последовательными индексами, а соответствующие каналы-приемники должны иметь упорядоченные по возрастанию индексы (не обязательно строго последовательные). 3. Подход к оценке теоретической производительности в целом справедлив. Надо только учесть, что в протоколе M_Link версии 5 ответ на команду OUT_M_Link имеет длину 12 байтов.
![[crazy / сумасшедший]](graemlins/crazy.gif)