|
[ На главную ] -- [ Список участников ] -- [ Правила форума ] -- [ Зарегистрироваться ] |
On-line: |
Телемеханика и связь в энергетике / Модемы и протоколы ТМ / ТУ в ТМ |
Автор | Сообщение | |||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 11-10-2010 17:04 | |||||
Здравствуйте! Поясните, пожалуйста, как принято в телемеханике передавать с ПУ на КП команды телеуправления коммутационными аппаратами в протоколе МЭК-101/104? Передачей слова, к котором упакован номер аппарата и операция (вкл/выкд), которую нужно выполнить, либо обращением по адресу конкретного аппарата? |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 18-10-2010 17:20 | |||||
Вопрос не ясен, что не понятно? В протоколе достаточно точно и ясно это прописанно. Есть 2 номера комманд для использования в качестве ТУ. Это комманда с типом 45 (однопозиционная) и типом 46 двухпозиционная. Соответственно вкл/выкл задаются 1 или 2мя битами (в отдельном байте). Адрес объекта стандартен как и для других типов данных (ТС,ТИ). Обычно это слово. Эти оба параметра не упакованны в слово, а занимают свои байты. Читайте стандарт. | ||||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 26-10-2010 10:20 | |||||
Я только пытаюсь вникать в работу по этим протоколам, поэтому, мне кажется, что если коммутационных аппаратов несколько сотен, то было бы удобнее посылать команды управления разными коммутационными аппратами на один адрес (например, командой с типом 49, а не просматривать сотни адресов в каждом цикле на предмет обнаружения команды управления. Правда, тогда на стороне ПУ придется упаковать в одно слово и номер коммутационного аппрата, и выполняемую операцию. Или это не соответствует идеологии протокола? | ||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 31-10-2010 18:34 | |||||
Ни то и не другое. По протоколам (если коротко)указан тип передаваемой информации и её адрес. А "кому чего и куда" занимается , как правило контролер, который сконфигурирован в соответствии с привязкой железа (там свои адреса). Так что, нарисовать протокол и связать с каким то конкретным изделием - не выйдет. |
||||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 02-11-2010 08:49 | |||||
Но как контроллер определит "откуда" пришла команда, если управление осуществляется из нескольких мест? |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 02-11-2010 16:35 | |||||
А контролеру по-барабану откуда управление. Просто активизируется тот дискретный выход, на который ссылается привязка. А что касается разных мест, то , допустим 101 протокол всегда через СОМ порт, и сколько портов, столько и мест (даже возможно с одним и тем же номером ASDU). Почти так же и по 104. Я думаю, что Вы имеете мало опыта програмирования контролеров, и если попрактикуетесь, то сразу масса вопросов отпадёт. Кстати, "АББ" последние года комплектует SCADA шкафами RTU560. На базе этих шкафов строится и телемеханика. Особенность RTU560 в том, что используется контроллер CPU560, позволяющий вести автономный сбор и передачу информации для ТМ. Очень многофункциональный и гибкий, позволяет вести передачу как Slave, так и в режиме master, с протоколами модбас, внутренняя шина I/O, 101, 104, Ethernet, стыки RS232,RS485,RS422. Позволяет с помощью РЛС-функций создавать витруалные данные и логические операции. Это всё сказанное не в качестве рекламы. Я просто эксплуатирую телемеханику RTU560 и знаю её достоинства. Так что, рекомендую поближе познакомится с контролерами (лучше всего с хорошими). |
||||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 02-11-2010 17:36 | |||||
Контроллеру-то по барабану, но в архив событий нужно занести инициатора команды. То, о чем вы говорите, верно, если непосредственно в программе контроллера обращаться к функциям работы с COM-портами или Ethernet. А если обмен с "внешним миром" определяется на стадии конфигурирования контроллера, то при работе программы контроллера уже не понять, откуда появилась команда по 101 протоколу от диспетчера или по 104 от оператора ПС по данному IOA. Обмен по этим протоколам в данном случае идет уже "независимо от нашего сознания". Думаю, что со временем масса вопросов отпадет, хотя и не сразу)) А с RTU-560 обязательно познакомлюсь при случае. |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 11-11-2010 12:00 | |||||
Alleksandr
Не верно. Это частный случай, и в стандарте нет такого ограничения. МЭК 101 может передаваться по любым низкоскоростным последовательным каналам. Мы его используем при передаче данных ещё и через RS-485, GSM-связь, модемная связь(напр: телефонный канал, ВЧ-связь).
Адрес ASDU обычно представляет собой "Адрес КП" по нашему, и поэтому он един для всех данных контроллера. ASM
Почему не понять? Если Вы сами пишите ПО контроллера то ВСЁ в ваших руках. А вот если используете чужую оболочка типа Изаграф или Кодесис, то тут ...
Присвойте всем связным интерфейсам разные адреса и сохраняйте их в журнале при приёме ТУ, или что Вам там надо. А для чего контроллеру нужна эта инфа? Всё что должен контроллер это выстрелить ТУ на исполнение и выдать на верх квитанцию об успешном выполнении. Или Вам требуется запрет выдачи ТУ с некоторых интерфейсов?
Получиться каша. Как разобрать кому пришло ТУ. Такого в стандарте нет.
Во первых тип 49 предназначен не для ТУ, а для ТР (аналоговый выход). Упаковывать вместе адрес и выполняемую команду нельзя. В стандарте для этого есть разные поля. Никак не пойму для чего Вы пытаетесь переиначить стандарт и в общем то усложнить работу. Вся эта упаковка-распаковка всё делает сложнее. Есть слово - занесли в него адрес. Есть байт - занести в него команду. Всё вроде просто в данном случае. Это я Вам говорю как автор ПО для контроллера телемеханики ВАРИКОНТ-МИКРО. |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 11-11-2010 16:18 | |||||
Не верно. Вы путаете различные интерфейсы. Сом порт - устройство для реализации обмена, а RS232(422,485)- тип стыка двух обменивающихся устройств. Тем более и GSM не в тех дебрях нарыли. Может вы и автор ПО, но в электронике - слабоват. |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 11-11-2010 17:22 | |||||
Alleksandr
СОМ-портом исторически называют интерфейс RS232. А "устройством для реализации обмена" можно назвать микруху UART (например), если уж быть более точным. Хотя вообще эта фраза слишком расплывчата. Надо более конкретно выражаться что имеете ввиду. Например слово "стык" в приминёной фразе не совсем верно, правильнее называть стандарты RS232(422,485) типом интерфейса.
Позабавило. Скорее всего у Вас приняты другие понятия и идёт путаница.
Имел ввиду что МЭК 101 можно передавать не только по шнурку, который соединяет 2 устройства через интерфейсы RS232, но и через GSM модемы. А также МЭК 101 можно передавать через телемеханические модемы по аналоговым линиям связи, что я ранее и упоминал. А уж они к СОМ порту ни как не относятся! Как пример, у нас плата модема вставляется прямо в контроллер как и все другие платы. А если кто использует устаревшую идеологию построения на основе кАнальных адаптеров и простейших ЧМ-модемов типа АПСТМ (прошлого века), то сочувствую. Мы проводили сравнительный тест с подобной системой. И те люди поняли что не канал связи у них барахлит, а железо такое. Это я отвлекся.
Не верно. |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 11-11-2010 20:35 | |||||
Если "откуда пришла команда" определяется протоколом 101/104 = таки наверно Вы знаете текущий/используемый протокол при принятии команды в теле программы ? :) Обычно сначала же происходит распознавание протокола, затем прием /анализ данных. ИМХО |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 12-11-2010 08:46 | |||||
Сожалею, но Вы не правы. Не знаю, какие исторические корни у тех или иных названий, и в какое время , и кто им это раздавал, но на сегодня даже ребята из Майкрософта Вам подтвердят. (извините, что пальцем ткну :-). Включаете комп. - правой кнопкой Мой компьютер –Свойства – Оборудование – Диспетчер устройств – Порты – Сом(со своими драйверами). -------Слабак!----- (как выразился бы Леонид Быков в фильме "В бой идут одни старики" (Конечно - шутка!) |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 12-11-2010 09:07 | |||||
Интересно, как Вы умудрились работать по 101-у протоколу через аналоговый канал связи с помощью телемеханических модемов!?. Насколько я знаю, в ТЧ канале скорость телемеханики ограничена величиной в 2400Бод. А для 101 протокола рекомендованная скорость не ниже 9600 бит\с?????? То, что запихать 101 в ТЧ канал можно - да, согласен, только не говорите, что он - РАБОТАЕТ!!!!!!! Метки времени, фоновое сканирование, общий запрос и т.п. и т.д. на низких скоростях канал забивают напрочь, в итоге реальную картину какого-либо инцидента на объекте отследить практически невозможно (это из двухлетнего опыта работы со 101 протоколом). По поводу канальных адаптеров: да, идеология может и устаревшая на сегодняшний день, но практически она РАБОТАЕТ и довольно неплохо. Имейте ввиду, что канальный адаптер ведет первичную обработку всей поступающей телемеханической информации, а потом отправляет ее в HOST (верхнему уровню ПЭВМ), который занимается окончательной обработкой (архивирование, ретрансляция и т.п.) Такое "разделение" наиболее ГРАМОТНО, чем если у Вас ВСЕМ занимается ОДИН контроллер!!!!!!!!!! |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 12-11-2010 11:02 | |||||
Alleksandr Я так и подумал что понятия у Вас "из винды". Ребята из Майкрософта всё делают что бы домохозяйкам... было понятно. Да, там для упрощения применили наименование СОМ порт. Но Вы где то видели комп с RS585 на материнке? Отсюда и прирасло понятие СОМ=RS232. Обратимся к первоисточнику, для разьяснения. А им является IBM PC. Там был СОМ порт для связи с мышкой и модемом. И он всегда был только RS232. Это просто вопросы терминологии. Как я и говорил у нас с вами они чуть разняться. Ну не называем мы интерфейс RS485 СОМ-портом. О шутке - ой как не красиво. marshal
У нас вышло постановление концерна что вся телемеханика должна уметь работать с 101 и 104. Вот мы их и реализовали на всех видах связи. Но эти протоколы не являются у нас основными. Их ставим только по просьбе заказчика. А основным является протокол от телемеханики Сириус. Он гораздо быстрее и легче МЭКов. У нас не простой ЧМ-модем, а модем на основе сигнального процессора. Он производит цифровую фильтрацию входного сигнала с полосой пропускания рассчитанной исходя из заданых частот 0 и 1 и скорости, причём он делает это сам. Затем приём сигнала и его проверка. Центральному процу он передаёт готовый пакет с уже проверенными контрольными битами. Например при приёме протокола МКТ-3, модем приняв 14 битовое слово проверяет все 5 контрольных бит. Центральному процу выдаёт уже нормальный 8 битный байт данных. Это уже не модем в ваших понятиях, это гораздо большее. Посему разделение для нас не имеет смысла. Мы получили гораздо более высокое качество приёма! 2400 бод это предел для ЧМ модемов, и то на широком канале. Мы давно сделали фазовую модуляцию со скоростями до 9600, и ЧМ практически не используем. В канале с полосой до 3 кГц устойчивая связь со скоростью 4800. Подробнее тут
Нет. Учитывайте что у нас в каждом модеме свой мощный проц. Центральный проц контроллера только "тусует" готовые пакеты. Итого в 1 контроллере у нас до 12 процессоров, вместе ведут работу. Поймите, Вы просто не видели как можно работать по другому. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 12-11-2010 11:27 | |||||
Тогда это уже не совсем модем, а типа канального контроллера (который работает с каналми ТМ, а затем выдает "наверх"). Тогда вопрос: чем такое Ваше устройство отличается от классического канального адаптера? (который,например, у нас обрабатывает сразу 32 канала, вставляется в PCI-слот ПК). |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 12-11-2010 12:39 | |||||
Представьте, работает на скоростях 300-600 бод. Телеканал М2 емкостью 80ТС,40ТИ.Настроены апертуры. Общий опрос и команда синхронизации времени - раз в час. Период фонового сканирования ТС/ТИ что-то порядка 1 и 2 минут, кажется. |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 12-11-2010 12:55 | |||||
Скорость в идеальном канале ТЧ с использованием модемов 57600 бит/с история
А по поводу стык/интерфейс/протокол троллинг кончайте! Детский сад просто.. |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 12-11-2010 13:20 | |||||
Скорее это плата совмещающая в себе функции модема и канального адаптера.
Тем что наш модем работает с 1 направлением, но обрабатывает одновременно обе линии - приём и передача. Ну и содержит сам "модем". Наша часть "аналогового модема" фильтрует сигнал в точности под параметры связи. Обычный внешний модем ничего про параметр скорости канала не знает. А значит и точно фильтровать не может и его полоса шире оптимальной. Легче сюда пролазят шумы, помехи и наводки соседних каналов. Часть "канального адаптера" имеет доступ к исходной синусойде и точнее производит автоподстройку по скорости... Генераторы старых КП уходят в сторону, и частоты и скорости их плавают. Мы работая непосредственно с синусойдой точнее подстраиваемся под них. Надёжность выше. Ещё массо-габаритные показатели в нашем случае ниже на порядок а то и на 2 порядка. Да, чуть не забыл. Всё это работает при -25С, и не требет обогрева. Таже плата модема работает и в составе КП. У нас единый конструктив на КП и ПУ, наполнение разное. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 12-11-2010 14:05 | |||||
Понятно..........В диалог вступил в силу того, что сам с 2000 года эксплуатирую устройства ТМ через канальные адаптеры и модемы ТМ...... На сегодняшний день в лабораторных условиях протестировал устройства, через которые ЛЮБОЕ устройство телемеханики способно работать в сети Ethernet по ЛЮБОМУ протоколу. (подробнее в топике "Подключение 2-х устройств телемеханики через Ethernet"). Так что использовать ТЧ канал для передачи телеинформации, наверное, уже не будем.......... Вот......... |
||||||
Ol_merry Группа: Участники Сообщений: 8 |
Добавлено: 13-11-2010 10:14 | |||||
у нас принимается ТМ в 101 протоколе на обычный модем ТФМ на скорости 1200. И отлично всё работает |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 13-11-2010 10:26 | |||||
Что значит отлично!? Вот расчет скорости для МЭК 101/104: Все параметры ТИ, ТС передаются по изменениям. Изменившаяся телеинформация (ТИ, ТС) ставится в очередь (ТС в свою, ТИ в свою) на передачу с меткой времени, точность которой 1 мсек. Очередь разбирается по мере освобождения канала связи по принципу «первый зашёл – первый вышел». Наибольшим приоритетом обладает очередь ТС. Пример: Максимальный размер ASDU (блок данных прикладного уровня) МЭК 870.5-101/104 равен 247 байт. 1. ТИТ в формате float + 7байт метки времени. На каждый ТИТ идет 4+1+7+3=15, где 4-значение 1-качество, флаги достоверности, ручной ввод и т.д. 7-время 3-адрес параметра Получается 247/15=16 параметров за одну посылку. К посылке добавляется шапка 6 байт, получаем 253 байт. 100 ТИТ можно передать за 100/16=6,25 посылок или за 6,25*253=1581 2. Одиночный ТС+7байт времени к каждому ТС На каждый ТС идет 1+1+7+3=12, где 1-значение одиночного ТС 1- качество, флаги достоверности, ручной ввод и т.д. 7-время 3-адрес параметра Получается 247/12=20 параметров за одну посылку. К посылке добавляется шапка 6 байт, получаем 253 байт. 100 ТС можно передать за 100/20=5 посылок или за 5*253=1265 байт Итого 1581+1265=2846 байт или 22768 бит. При скорости канала 1200 бит/сек время передачи изменения всех ТС и ТИТ составит 18,97 с. И Вы считаете это "ОТЛИЧНО РАБОТАЕТ"!? |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 13-11-2010 12:59 | |||||
ТСы и ТИТы пакетами/группами могут передаваться: · данные группы ТС (ГТС) · данные массива ТС (МТС) · данные группы ТИТ (ГТИТ) А скорость - да, где-то надо побыстрее вот 8 КП на радиолинии скорость 50 бод лидер 1200 мс просто опрос требования проходит где-то раз в 30 секунд ТС доходит до диспетчера через 45-120 секунд. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 13-11-2010 13:35 | |||||
К примеру, по проекту у нас на одной из ПС порядка 107 ТС и порядка 50 ТИТ. Теперь представьте, сколько ТС\ТИ изменится при системной аварии на ПС. Ясно, что не один и не два........ К тому же, из всех изменившихся ТС\ТИ диспетчеру нужно точно знать, что явилось ПРИЧИНОЙ аварии, а что СЛЕДСТВИЕМ. Это он может определить только по времени прихода ТС\ТС. Ясно, что сначала придет ПРИЧИНА, а потом СЛЕДСТВИЕ. А если что-то где-то задержится!? Поэтому скорость в канале на МЭК-101 нужно выбирать максимальную, и не ниже рекомендованной.......... А все эти "у нас все работает" - лишь отговорки........Понятно, что два устройства соединяться и на скорости 200 Бод, но кому нужна такая РАБОТА!!!! |
||||||
JJL долгожитель Группа: Участники Сообщений: 385 |
Добавлено: 13-11-2010 14:20 | |||||
Ув. vad74 ! После заявленных преимуществ Вашего модема (ФМ, 4800, и др.), следует отметить следующее: - Все это возможно реализовать на стандартном в части АЧХ, ГВЗ, полноты спектра, ограниченном количестве переприемов, низком уровне шумов и прочими стабильными во времени параметрами, заполучить которые в реальной сети связи эл.энергетики крайне сложно, разве что на цифровой системе передачи, но там есть иные, безмодемные способы взаимодействия; - Все это возможно, если и КП и ПУ (обе стороны) оснащены Вашими модемами (т.е. Вашими изделиями), что согласитесь, не всегда реализуемо; - В случае же с ЦППС иного типа (и "хвоста" канала ТЧ) все уходит на ЧМ в те-же 300-600 бод; - Модемы ТМ "прошлого века" (АПТ, АПСТ и др.) обеспечивают заявленную в их ТУ скорость и прыгать выше головы не могут и не должны; - При появлении на объекте цифровых каналов и при работе Ваших изделий с картами первичных мультиплексоров (с RS-портами непосредственно), Ваш интегрированный модем становится физически не нужным, но, в отличии от АПТ, АПСТ и др., его нельзя взять и перенести под другое КП, ну а интерфейсная карта Вашего КП (с RS-портом) становится опять "канальным адаптером". |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 13-11-2010 15:56 | |||||
Для этого есть метки времени, которые присваиваются устройством ТМ. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 13-11-2010 19:53 | |||||
Первое: Смотрите выше: На каждый ТС идет 1+1+7+3=12, где 1-значение одиночного ТС 1- качество, флаги достоверности, ручной ввод и т.д. 7-время 3-адрес параметра Т.е. больше половины байт для одного ТС занимают метки времени (7 байт). В итоге низкоскоростной канал полностью забит метками времени. Второе. Наверху, если ТС пришел с меткой времени, то в архив он должен укладываться с ЭТОЙ же меткой времени.Теперь смотрите: при системной аварии, когда начинают ТС сыпаться, телесигналы с низкоскоростных каналов придут значительно позднее(см. у Skoctehs: "ТС доходит до диспетчера через 45-120 секунд."), а в архиве они будут с той меткой времени, которую ей присвоил КП. Получается, в архиве верхнего уровня диспетчер их не будет видеть в темпе процесса. Опять же пришли к тому, что диспетчер в архиве ПРИЧИНУ увидит на 45-120 с. позднее, чем СЛЕДСТВИЕ.....Ему эта путаница НАДО!? Видел, не помню у кого, в архивах ОИК-а 2 столбца времени: время, которое зафиксировал ОИК при изменении ТС, и время, с которым ТС зафиксировался на КП. Для телемеханика это, конечно, хорошо (видна задержка в канале), а для диспетчеров лишняя головная боль. Причем, эти "примочка" (2 столбца времени)хороша лишь при высокоскоростных каналах........ |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 13-11-2010 22:41 | |||||
у нас ТМ снята с производства = КОМПАС ТМ 1.1 2001 года меток времени в канале нет но есть возможность скачать архив изменений ТС с метками времени (часы КП синхронизируются раз в час ) обычно диспетчера просят распечатку через день-два сразу не до этого |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 13-11-2010 23:22 | |||||
Совершенно верно. Аварии уже разбирают потом, по архивам. Если они есть. А события при аварии валятся пачками. В одной посылке может присутствовать сразу несколько событий с разными метками времени, так что наверное не правильно говорить о том что диспетчер в состоянии в темпе реального времени оценить правильно последовательность событий. |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 13-11-2010 23:25 | |||||
Можно использовать 3-байтные метки. Касательно анализа аварий написал выше. А вообще никто не спорит, что каналы нужны высокоскоростные. Просто говорить о том что на низкоскоростных каналах МЭК-101 ВООБЩЕ не работает - это согрешить против истины. Надо смотреть конкретно каждый случай - какой объем информации передается, как настроены апертуры, насколько вообще устойчив сам канал связи. Устройства небольшой емкости работают на низкоскоростных каналах очень даже замечательно. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 14-11-2010 18:48 | |||||
В принципе, согласен............ Каждый случай надо рассматривать отдельно... На своих примерах из опыта: на устройствах КП Гранит-Микро и МПТК с монтированной емкостью ТИТ\ТС\ТУ:32\32\16(32) скорость ниже 600 Бод иметь не желательно. Правда, это на ИХ прикладных протоколах. ...... Спасибо за диалог!!!!!!!! |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 15-11-2010 14:24 | |||||
JJL
ФМ требует ровную АЧХ в полосе приёма. По шумам и помехам она более стабильная чем ЧМ. Из практики, уже скоро лет 10 будет как ставим в основном ФМ. Был правда случай когда на радиоканале он не пошёл. Снял АЧХ радиотракта, оказалась очень кривая. Спад от нижней частоты до верхней в 2 раза. Ставили на одном из трудных каналов - надтональный спектр ВЧ связи. Было 200 бод ЧМ, стабильно пошло 600 бод ФМ. Пробовали 1200 но пошли переспросы. Улучшение есть, энергетики довольны.
Да, так и есть. Но это всё реже ставится проблеммой. И в таком случае просто в конфигураторе КП ставим работать с ЧМ. Модем он программный, ему всё равно. Также с ЧМ через него работаем с чужими: ТМ120, МКТ3, РПТ80...
Так от них этого никто и не требует.
Взять и перенести в другое КП (наше) можно, пусть работает.
Вы не поняли. Модему не нужен никакой адаптер с RS-портом. Он ставится прямо на системную ISA шину контроллера КП. Если появился новый канал связи с RS-портом, то надо вместо платы модема воткнуть плату с RS-портами. В итоге канального адаптера нет вообще. Тут фото. |
||||||
JJL долгожитель Группа: Участники Сообщений: 385 |
Добавлено: 15-11-2010 20:42 | |||||
to vad74
Все как раз очень понятно. Вопрос почти в терминологии. Может ли Ваша плата с RS-портами называться канальным (мультиканальным) адаптером ? |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 16-11-2010 11:29 | |||||
JJL
Думаю нет. На плате только UART и интерфейсные м/с. Канальный адаптер, в моём понимании, ещё ведёт обработку сигнала. |
||||||
K9 бывалый Группа: Участники Сообщений: 49 |
Добавлено: 18-11-2010 09:48 | |||||
В принципе вы правы. Но есть небольшой нюанс. В каждом протоколе есть таймаут на ожидание ответа со стороны slave. Правильно делать этот таймаут зависимым от скорости. Но в жизни всякое бывает и может оказаться, что он задан статически. Тогда при низких скоростях передача одного кадра может занять больше времени, чем величина таймаута. Тогда master может считать, будто его запросы все время теряются, хотя просто долго идут ответы от slave. В общем вполне можно встретить реализации МЭК-101 которые не будут работать на низких скоростях. |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 18-11-2010 15:50 | |||||
Проблем при передаче на низких скоростях (ВЧ-каналы, как правило) три: 1) неустойчивый канал связи 2) большой объем данных 3) ненастроенные апертуры Каждая в отдельности создает периодические трудности, а в комбинации друг с другом приводят к полной неработоспособности. Настройка таймаутов у мастера - это вообще не проблема. |
||||||
K9 бывалый Группа: Участники Сообщений: 49 |
Добавлено: 18-11-2010 17:54 | |||||
Неужели это специфические проблемы именно МЭК-101, работающего на низких скоростях. А можно подробнее про проблему не настроенных апертур при передаче на низких скоростях? |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 18-11-2010 23:26 | |||||
Так ведь это очевидно.Несколько ТИ в состоянии забить весь медленный канал своей спорадикой (особенно это касается измерений направления и скорости ветра). И не дай бог, если еще и канал связи при этом сбоит.Можно вообще не дождаться всех данных с ПС, поскольку после каждого сбоя ВСЕ данные на верхнем уровне становятся недостоверными. После восстановления связи по-новой начинается передача данных с КП по общему опросу, которая постоянно будет перемежаться лупящей спорадикой, имеющей более высокий приоритет. В итоге - окончания передачи данных по общему опросу можно вообще не дождаться, если канал в очередной раз сбойнёт. Будете иметь несколько достоверных ТИ, которые постоянно передаются из-за своих ненастроенных апертур. И только.Остальное так и не будет успевать передаться с КП. А если это всё еще усугубляется большим объемом ТС/ТИ, тогда вообще труба. Лечится настройкой апертур и приведением канала связи в работоспособное состяние. При разумных объемах ТС/ТИ. |
||||||
K9 бывалый Группа: Участники Сообщений: 49 |
Добавлено: 19-11-2010 10:04 | |||||
Вообще да, что бы канал более или менее нормально работал, нужно специфическое поведение КП. То есть спорадика не перебивает полный опрос и поиск нового набора ТИТ/ТС для передачи начинается с того места, где остановились в прошлый раз (отдельно для спорадики и для полного опроса). Если для спорадики последнее требование, это нормально, то для полного опроса как-то необычно. Я думаю, к такому поведению спокойно отнесется любой мастер МЭК-101, но вот с соответствием стандартам как-то неясно. |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 19-11-2010 14:01 | |||||
На стороне Кп (МЭК101)всегда есть приоритет и очередь. Сам протокол предусматривает режим активации и нормальный режим. Они немного отличаются характером обмена. В случае обрыва канала связи – очередь растёт. И всё равно после следующей активации все данные должны уйти на ПУ. За счёт этой очереди и медленного канала происходят все проблемы. По требованию РДУ апертура должна быть 0,4 процента (хотя в большинстве у нас 1%), И вот представьте, как на скорости 100 бод передать весь объём. Конечно КП зависнет. Поэтому эти протоколы и надо делать скоростными. Мы сейчас используем 9600 и перешли на оптику. Со стороны КП запретили циклическую передачу (не путать с ответом на циклический запрос). На стороне ПУ циклический запрос увеличили до 9 минут. И нагрузка на систему упала, и информативность не пострадала. Так что, всё сходится в соответствии с описанием при нормальном подходе. | ||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 19-11-2010 14:29 | |||||
Вот правильный подход к реализации МЭК-101\104.......-;))))) |
||||||
K9 бывалый Группа: Участники Сообщений: 49 |
Добавлено: 19-11-2010 14:49 | |||||
А что конкретно понимается под "режимом активации"? |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 19-11-2010 20:02 | |||||
Если кратко, - хендшейк и время. А конкретно, увидите реально во вторник( викэнд ещё не отменили - :-)))). |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 22-11-2010 18:00 | |||||
Обмен сервера с кп. Предлагаю открыть описание протокола и сравнить правильность расшифровки байтов обмена. Пояснения к трассировке: -> ---- от пу к кп <- ---- от кп к пу первая строка - анализатор байтовых посылок второй строки (в случае их раздельной записи). Начало строки символ < или >. -> [16:24:54.000 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС СТАТУСА КАНАЛА: 10 49 0E 57 16 ........................................... -> [16:24:55.296 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС СТАТУСА КАНАЛА: 10 49 0E 57 16 <- [16:24:55.328 22.11.2010] "IEC101(UNB)" (СТ=14) СТАТУС СВЯЗИ ОК: 10 0B 0E 19 16 -> [16:24:55.343 22.11.2010] "IEC101(UNB)" (СТ=14) СБРОС КАНАЛА: 10 40 0E 4E 16 <- [16:24:55.359 22.11.2010] "IEC101(UNB)" (СТ=14) ACK: 10 00 0E 0E 16 -> [16:24:55.375 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=6,ASDU=14,EL=0) УСТ.ВРЕМЯ [ ВР=16:24:55.000 22.11.2010 ] -> [16:24:55.390 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ (БЕЗ ОТВЕТА): 68 0F 0F 68 44 0E 67 01 06 0E 00 00 D8 D6 18 10 16 0B 0A CF 16 -> [16:24:55.406 22.11.2010] "IEC101(UNB)" • (СТ=14,ASDU=14) ОПРОС [ QOI = 20] -> [16:24:55.421 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 09 09 68 73 0E 64 01 06 0E 00 00 14 0E 16 <- [16:24:55.437 22.11.2010] "IEC101(UNB)" (СТ=14) ACK: 10 00 0E 0E 16 -> [16:24:55.453 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС КЛАССА 2: 10 5B 0E 69 16 <- [16:24:55.484 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=4,ASDU=14) КОНЕЦ ИНИЦИАЛИЗАЦИИ [0: COI = 0 ] <- [16:24:55.484 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 09 09 68 08 0E 46 01 04 0E 00 00 00 6F 16 -> [16:24:55.500 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС КЛАССА 2: 10 7B 0E 89 16 <- [16:24:55.531 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=7,ASDU=14) ОПРОС [0: QOI = 20 ] <- [16:24:55.531 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 09 09 68 08 0E 64 01 07 0E 00 00 14 A4 16 -> [16:24:55.546 22.11.2010] "IEC101(UNB)" (СТ=14) ЗАПРОС КЛАССА 2: 10 5B 0E 69 16 <- [16:24:55.640 22.11.2010] "IEC101(UNB)" • (СТ=14,ПР=1,ASDU=14) ТС [1001: 0 Q80] [1002: 0 Q80]............. <- [16:24:55.640 22.11.2010] "IEC101(UNB)" (СТ=14) ДАННЫЕ: 68 3B 3B 68 08 0E 01 B3 01 0E E9 03 80 80 80 80 80 80... ..................ну и так далее............... |
||||||
Karp редкий гость Группа: Участники Сообщений: 11 |
Добавлено: 11-03-2011 10:28 | |||||
Кроме того, есть такое понятие, как "реакция комплекса" - время прохождения ТС. Метки времени вещь полезная - это хорошо для разбора полетов, но для оперативной работы более важен минимальный временной интервал, от времени срабатывания до времени отображения. (Согласно брошюре "Руководящие указания по выбору объемов информации, проектированию систем сбора и передачи информации в энергосистемах" № 13861тм-Т1, должно быть не более 10сек). |
||||||
Рэльс Группа: Участники Сообщений: 7 |
Добавлено: 23-05-2012 18:44 | |||||
Уважаемый Alleksandr, не могли бы вы кратко рассказать или указать на источник, каким образом происходит "общение" между контроллером и платами ввода-вывода в RTU560? очень интересно, но, видимо, "военная тайна". |
Телемеханика и связь в энергетике / Модемы и протоколы ТМ / ТУ в ТМ |