Форум TRACE MODE: техническая поддержка   
мой профиль / my profile авторизация / login | регистрация / register | поиск / search | часто задаваемые вопросы / faq | начало / forum home

  Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
» Форум TRACE MODE: техническая поддержка » ТЕХНИЧЕСКАЯ ПОДДЕРЖКА / TECHNICAL SUPPORT TRACE MODE 5 » Общие вопросы / Common questions » M-Link по радиоканалу

   
Автор / Author Тема / Topic: M-Link по радиоканалу
Саша
Forum Member / Участник форума
Участник № / Member № 925


Icon 1 отправлено / posted      Профиль для / Profile for Саша           Редактировать/удалить сообщение / Edit/Delete Post 
Здравствуйте!

Помогите, пожалуйста, решить проблему.
Структура проекта ТМ содержит два узла: операторская станция (ОС) и контроллер
Теконик. ОС и контроллер обмениваются по протоколу M-Link. ОС является Master в
сети RS-485. Она осуществляет запрос данных с контроллера. В запросе учавствуют
107 дискретных и 57 аналоговых каналов, все они имеют дополнение к подтипу In M-Link. Есть особенность в организации сети RS-485, с которой и связана проблема.
Связь последовательных интерфейсов осуществляется посредством радиомодема "Невод" компании Геолинк. Максимальная скорость передачи по радиоканалу 100 байт/сек, режим передачи полудуплексный, объем буфера последовательного интерфейса на прием
2,7 кбайта. Очевидно что при частоте опроса каналов раз в секунду большенство
каналов не будут успевать обновляться (прикинуто на глаз). Помогите прикинуть
точно. Действительно ли, что когда установлена апертура на значения канала, то протокол M-Link не передает те каналы, которые не вышли за ее пределы? Не могу найти в описании этой особенности. Но так или иначе ОС все равно делает запросы на все каналы, как запросы влияют на загрузку сети? В одном из старых диалогов форума
я прочитал, что протокол M-Link описанный в книжке по ТМ не совсем тот, который работает на самом деле, там же Вы написали что высылаете всем желающим описание протокола M-Link того, который нужен. Вышлите нам, пожалуйста alexsd@bk.ru.
Как поступить в нашей ситуации, как посчитать пропускную способность радиоканала в отношении каналов ТМ, есть ли необходимость писать собственные алгоритмы отсекающие холостой обмен по сети? [crazy / сумасшедший]

Сообщения / Posts 54 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post 
Дело в том, что каналы типа In M-Link - это каналы, которые запрашивают данные, и запросы генерируются с циклом пересчета этих каналов. Апертура Вам здесь не поможет, потому что она должна задаваться на запрашиваемых каналах, а не на каналах, которые запрашивают данные - последние не могут получать уведомления типа "данные изменились, можно запрашивать". Вот если бы у Вас контроллер был Мастер и передавал на ОС данные каналами Out M-Link, тогда бы Апертура помогла, потому как отправка пакетов по Out M-Link'у происходит не с периодом пересчета канала, а только по изменению значения его атрибута "Реальное". В Вашем же случае есть два выхода:
1) Понизить периоды пересчета каналов In M-Link на ОС, тем самым понизив траффик обмена.
2) Управлять Состоянием этих каналов, а на нижнем уровне реализовать канал, который будет опрашиваться ОС постоянно. В этот канал помещать какие-либо значения о текущем состоянии всех каналов контроллера, то есть - реализовать что-то вроде программы, которая будет анализировать момент когда верхнему уровню пора выполнить запрос к контроллеру, потому как большинство каналов поменяло свое значение.
Как пример такой программы - анализ атрибута Тенденция опрашиваемых каналов. Признак скачка по тенденции заводить на счетчик и как только значение счетчика выйдет на определенный уровень можно выдать сигнал о том, что контроллер можно опросить верхним уровнем.

Сообщения / Posts 17321 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Саша
Forum Member / Участник форума
Участник № / Member № 925


Icon 1 отправлено / posted      Профиль для / Profile for Саша           Редактировать/удалить сообщение / Edit/Delete Post 
вышлите, пожалуйста, по электронке alexsd@bk.ru описание протокола M-Link. Для того чтобы была
возможность оценить Ваши предложения так или иначе необходимо просчитать возможную
информационную загрузку радиканала протоколом M-Link, сделать это без его описания мы не
сможем.

Сообщения / Posts 54 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post 
Описание протокола M-Link5 есть в нашей справочной системе ТМ в разделе "ПРИЛОЖЕНИЯ"-"Описание протокола M-Link", там и 4-я и 5-я версии описаны.
Сообщения / Posts 17321 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Саша
Forum Member / Участник форума
Участник № / Member № 925


Icon 1 отправлено / posted      Профиль для / Profile for Саша           Редактировать/удалить сообщение / Edit/Delete Post 
В приложении есть только описание протокола M-Link версии 4.20. Пятой версии
я не нашел. Существенно ли они разлиаются?
В описании протокола 4.20 есть не понятный момент.
в посылке осуществлящей запрос указываются номер начального канала N4N3N2N1 и номер последнего канала E4E3E2E1. Получается что либо все запрашиваемые каналы должны иметь последовательный номерной порядок в диапазоне N4N3N2N1 - E4E3E2E1 в базе каналов SLAVE или протокол генерирует столько команд запроса
сколько в базе каналов узла SLAVE последовательно сгруппированных групп запрашиваемых каналов.
Получается количество команд запроса зависит от рассредоточенности запрашиваемых каналов по базе каналов узла SLAVE?
Хотел Вас попросить подтвердить правильно или нет я понимаю протокол.
Рассмотрим предложенную Вами схему обмена, когда контролер является мастером и каналы с дополнением к подтипу Out-Mlink передают информацию наверх в операторскую станцию.
На сколько я понял для передачи таким образом одного значения (например реального) аналогового канала мне необходимо передать на верх 14 бит
информации (я не учитываю служебную информацию передаваемою логикой модема) и получить назад ответ размером 14 бит, т.е. всего загрузка сети составит 28 бит в обоих направлениях. Если речь идет о дискретных каналах то посредством 28 бит я смогу передать 16 дискретных сигналов от модулей в/в.
Т.е. при скорости радиоканала модема 100 бит/сек я смогу передать грубо говоря 4 аналог. канала в секунду или 64 дискретный сигнала в секунду.
Верны ли мои рассуждения?

Сообщения / Posts 54 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post 
1. Начиная с релиза 5.11 в Справочной системе рядом с описанием протокола M_Link 4.20 находится описание протокола M_Link версии 5.
2. Действительно, групповые запросы формируются с учетом упорядоченности каналов приемников и каналов-источников. При этом в одном запросе могут присутствовать только каналы-источники со строго последовательными индексами, а соответствующие каналы-приемники должны иметь упорядоченные по возрастанию индексы (не обязательно строго последовательные).
3. Подход к оценке теоретической производительности в целом справедлив. Надо только учесть, что в протоколе M_Link версии 5 ответ на команду OUT_M_Link имеет длину 12 байтов.

Сообщения / Posts 17321 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
   

   Закрыть тему / Close Topic   Feature Topic   Переместить топик / Move Topic   Удалить топик / Delete Topic Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
 - Printer-friendly view of this topic
Перейти к / Hop To


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2