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

  Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
» Форум TRACE MODE: техническая поддержка » ТЕХНИЧЕСКАЯ ПОДДЕРЖКА / TECHNICAL SUPPORT TRACE MODE 5 » Мониторы Реального Времени / Real Time Monitors » Ошибки в релизе 5.12 на незащищенных каналах связи. (Страница / Page 1)

  Этот топик включает в себя следующие страницы /
This topic is comprised of pages 1  2 
 
Автор / Author Тема / Topic: Ошибки в релизе 5.12 на незащищенных каналах связи.
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
МВР 5.12 (Win2k Professional) опрашивает модули серии I-7000 на скорости 4800. В свою очередь его опрашивает по радиоканалу на скорости 19200 МРВ верхнего уровня (Win2k Server). МРВ нижнего уровня зависает примерно через час. Причем с такими симптомами: в граф. консоли, в таблице каналов, видно, что входа всех каналов (каналов опрашивающих I-7000 и каналов в которые записываются данные с верхнего уровня) меняются, а вот дальше пересчета нет. Так повторялось два раза - оба раза перезапускали. На третий раз приехали на объект – окна сервера мат. обработки (он у нас запускается с командной строки) нет в системе (впрочем, процесса тоже нет) т.е. на этот раз он вообще вылетел, а вот Picrt.exe присутствует. Запустили сервер мат. обработки еще раз – и графика подцепилась к нему. Т.е. зависает (или вываливается) именно DrawServ.exe! Что делать? [А-а! / Eek!]

[ 04.11.2004, 15:23: Сообщение отредактировал / Message edited by AdAstra Technical Support ]

Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
1) Поставить вместо Drawserv.exe МРВ файл Drawserv.exe из Инструменталки, чтобы он лог-файл вел. Посмотреть, может он в течение работы выдает какие-либо сообщения в лог об ошибках.
2) Необходимо ловить момент когда сваливается сервер. Попробуйте воспроизвести это не на объекте, съэмулировать ситуацию - например, просто запустить отдельно этот узел, чтобы он поработал некоторое время, но не на объекте, а отдельно. Без воспроизведения ситуации трудно что-либо сказать о причинах...
3) Во время работы сервера на объекте запустите диспетчер задач Windows и посмотрите счетчики по памяти, хэндлам, GDI - может что-нибудь растет в процессе работы МРВ?

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
1).Поставили вместо МРВ пофайлер. Приехали через день – Drawserv.exe (профайлер) вылетел. В лог-файле около сотни строк: “Wrong FSC”(собственно такой строкой лог и заканчивается).
3).В диспетчере задач для процесса Drawserv.exe параметр “память-использование” постепенно растет (с шагом 4 KB). За 5 минут значение изменилось с 2292 KB на 2316KB. Через 40-50 минут оно было уже 2636KB. (проверялось на профайлере).

Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
1) У Вас контрольная сумма по I7000 выставлена - зачем?
2) В графике случайно нет переключений по экранам с формой просмотра ОТ?
3) Попробуйте 5.15 релиз.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
1). В качестве удлиннителя RS-485 используются радиомодемы SST-2400. Возможны помехи в линии связи. Почему бы контрольной сумме не быть включенной? Разве неправильная контрольная сумма должна приводить к краху TM?
2).Форма просмотра ОТ в графике присутствует.
3).Попробую. О результатах напишу.

Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
1) Нет причина свала скорее всего в ФО просмотра Отчета тревог. Просто у Вас очень много недостоверностей по обмену с FSС. Практика показывает, что контрольная сумма в протоколе I7000 практически ничем не помогает, наоборот обмен только хуже становится. Попробуйте ее убрать и посмотреть на качество обмена.
Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
Это что же получается, если у нас много пакетов с не правильной контрольной суммой, то если мы ее отключим, весь этот бардак будет воспариниматся как достоверные данные и записыватся в кналы!? [Недоумение / Confused] [crazy / сумасшедший]
Мы пробовали работать без контрольной суммы. Когда ее включили качество особо не изменилось. Хочу сказать, что TM благополучно зависал и при отключенной контрольной сумме! [Безумие / Mad]
По поводу формы просмота ОТ - в 5.15 это исправлено?

Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
Попробовал 5.15. Опять зависает.
Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
1) Да не в плохом обмене зависание!
Интересно, а у Вас все пакеты по I7000 протоколу именно в области данных всегда искажаются? Если искажен пакет, то прочитать его ТМ все равно не сможет, если конечно он не в области данных повредился при передаче.

2) Давайте Ваш проект - посмотрим у себя...

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
Проект отправлен на forum@adastra.ru Зависает узел ns43. Он опрашивается узлом Disp.
Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
Посмотрели Ваш проект, однако он нормально работает и не зависает. Проверяли на 5.12 и 5.15.
Пожалуйста, сообщите характеристики Вашего ПК, на котором он работает, а также ключи запуска сервера, если Вы их используете.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
1)Снял компьютер с объекта. Тестировал в офисе. Опрашивал модули I7000, и опрашивал проблемный узел другим МРВ. Т.е. практически полностью повторил ситуацию на объекте. Правда, без использования радиомодемов для связи между нижним и верхним уровнем (просто перекрестным кабелем). И без использования радиомодемов SST-2400 для связи с отдельными модулями. Результат тот же, что и у Вас: ни каких зависаний. Если Вы говорите, что плохой обмен не может быть источником проблемы, то тогда не знаю где искать причину. [Растерянность / Embarrassed]

2)Характеристики ПК:
  • мат. плата Nova 7895R
  • процессор Celeron 1200 MHz Tualatin
  • 128Mb
  • Windows 2000 Professional
Верхний уровень
  • мат. плата Nova 7895R
  • PIII 1266MHz
  • 256Mb
  • Windows 2000 Server
Верхний уровень работает без проблем вторую неделю. Связь между верхним и нижним уровнем через радиомодемы MDS 2710.

3). Ключи для запуска сервера мат. обработки (просто указание проекта):
DrawServ.exe /P:<path> /F:<node> /RUN
PicRT.exe <prg>.ctm /N:<node>

4) Вопрос к Вам: сообщение “ Wrong FSC ” в логе профайлера относится именно к обмену с модулями I7000, или оно может относится и к обмену по MLink?

Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
2) Это сообщение относится к обмену по M-Link.
Мы создали исскуственную ситуацию, когда появляется это сообщение и сегодня будем проводить более детальные тесты по этому направлению. Похоже, что что-то там неладно, но это пока только догадки. О результатах тестов сообщим на форуме.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Mikhail Kagan
Junior Member / Новичок
Участник № / Member № 28


Icon 1 отправлено / posted      Профиль для / Profile for Mikhail Kagan           Редактировать/удалить сообщение / Edit/Delete Post 
Меня заинтересовало упоминание о зависимости устойчивости работы DrawServ и его размеров от наличия ФО Отчет тревог на консолях. В моей практике с течением времени (порядка нескольких сотен часов непрерывной работы)сервер подрастает в размерах, затем наблюдается очень большое запаздывание в рассылках тревожных сообщений (до 15 мин) по отношению к записи тревог в файл, после чего сервер приходится перегружать.
Сообщения / Posts 15 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119


Icon 1 отправлено / posted      Профиль для / Profile for Kramarenko Stanislav           Редактировать/удалить сообщение / Edit/Delete Post 
У моих коллег похожая ситуация.
Только у них на нижнем уровне несколько МикроМРВ.
При опросе по M-Link порты у контроллеров "вешаются" через интервал времени от часа до двух дней.
Линия находится в зоне промышленных помех.
Лабораторные исследования подтвердили, что наличие помех на RS-485 приводит к зависанию портов на МикроМРВ.

Сообщения / Posts 337 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
На данный момент ситуация с M-Link прояснилась - действительно возможны варианты когда искажения в M-Link Slave приводят к зависаниям. Это вызвано тем, что возможны такие искажения в пакете из-за помех, которые не отслеживаются контрольной суммой пакета. И система неадекватно реалировала на такую искаженную команду.
Параллельно с испытаниями также выявилось, что и сам физический канал RS485 (конвертеры) можно "завесить" помехами.
Сейчас мы принимаем меры для того, чтобы в дальнейшем искаженный помехой пакет не приводил к столь фатальной ситуации с обменом, однако это все равно не дает гарантий, что система будет защищена от помех на все 100% (стойкость контрольной суммы не позволяет это сделать, все равно остаются варианты, когда искаженный пакет может быть принят системой за нормальный, что может привести к ошибочным командам).
К тому же сам физический канал чувствителен к помехам - поэтому в первую очередь, чтобы система была стабильна, необходимо обеспечивать стабильность самого канал связи.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
СВТ
Junior Member / Новичок
Участник № / Member № 707


Icon 1 отправлено / posted      Профиль для / Profile for СВТ           Редактировать/удалить сообщение / Edit/Delete Post 
Описание системы.
Имеем систему состоящую из пяти контроллеров Octagon 2050(MRT7 ver 5.11), дублированный сервер (DFrtm 5.12) и просто сервер (rtm 5.12).
Контроллеры посылают данные по сети дублированному серверу в виде автопосылки (проблем нет).
На СОМ 2 каждого контроллера через преобразователь ICP-7520 сидят модули ICP70XX(проблем не вызывают), а вот СОМ 1 настроен как M_Link (slave) и подключен через такой же преобразователь к просто серверу (образуя резервную линию связи RS-485).
Протяженность линии примерно 50 метров специальным кабелем для RS-485. Место расположения системы - кабельный полуэтаж ТЭЦ , помех хватает.
Проблема.
С периодичностью от 1 часа до 3 суток прекращается обмен по резервному каналу (RS-485) с одним из контроллеров, остальные продолжают отвечать. Бывало не отвечало и несколько контроллеров, но обмен прекращался в разное время (не одновременно). Основной обмен по сети продолжался. Канал Диагностика M_LINK (Slave) пересылаемый из контроллеров по сети всегда после зависания показывал 804Н, только однажды я видел 6003Н. Эксперименты со скоростями, контролем четности и увеличением стоп бита ни к чему существенному не привели (немного вырос период). Несколько раз пробовали перегружать ICP-7520, но связь не восстанавливалась.
В лабораторных условиях ситуация не повторялась, пока не стали искусственно создавать ошибку в линии, во время обмена посылали с терминала в RS-485 всякую чушь.
При этом M-Link(Master) не разу не завис, а вот M-Link(Slave) вис с завидным постоянством. Из чего сделали вывод о том, что microRTM просто некорректно обрабатывает ошибки порта или вообще не обрабатывает. Непонятно, почему возникновение ошибки приводит к таким фатальным последствиям.
Частично решили проблему переинициализацией порта каналом RS_REINIT, при возникновении ошибок с кодом больше 255, но иногда и это не помогает (возможно неидеален алгоритм).
Вопрос.
В описании канала Диагностика M_LINK (Slave) ошибка 804Н не описана зато сказано, что при возникновении ошибок линии порт переинициализируется. Я так понимаю, что этого не происходит, по крайней мере в моем случае.
Пожалуйста, прокомментируйте ситуацию и посоветуйте еще какие-нибудь варианты борьбы с этим явлением.

Сообщения / Posts 9 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 2 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
Причина скорее всего та же, что и описана выше - реакция Микро МРВ в режиме Slave на искаженный пакет.
Старший байт - это код аппаратной ошибки СОМ-порта (так называемый статус СОМ-порта). Вот их описание:
0x0001 // Receive Queue overflow
0x0002 // Receive Overrun Error
0x0004 // Receive Parity Error
0x0008 // Receive Framing error

В любом случае - реинициализация порта проводится МикроМРВ при любой из аппаратных ошибок.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
СВТ
Junior Member / Новичок
Участник № / Member № 707


Icon 1 отправлено / posted      Профиль для / Profile for СВТ           Редактировать/удалить сообщение / Edit/Delete Post 
Сложилось впечатление, что переинициализации порта автоматически не производится!
Мы вынуждены делать это сами.
Какие меры собирается предпринять АдАстра для повышения надежности обмена по M-Link?
И когда?

Сообщения / Posts 9 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
Нам удалось смоделировать ситуацию зависания M_Link-SLAVE при некоторых ошибках на линии RS 485.
Вышлите, пожалуйста, на адрес техподдержки запрос с указанием регистрационного номера лицензии на микроМРВ. Мы отправим Вам рабочую версию микроМРВ с соответствующей коррекцией.
Дополнительное повышение надежности обмена можно получить, если ввести проверку байтов "по четности/нечетности".

Протокол M_Link не позиционируется в качестве телемеханического, поэтому к нему не предъявлялись такие же жесткие требования по обнаружению ошибок, как для систем телемеханики.
В системах реального времени, к которым относится АСУ ТП, плохое качество канала связи может привести к существенному снижению реактивности системы в целом. Поэтому повышение помехоустойчивости протокола и, как следствие, снижение производительности канала связи, по крайней мере, не во всех случаях можно признать целесообразным. Эффективнее все-таки повышать качество канала связи.
Для перепроверки "автоматической реинициализации COM-порта при обнаружении аппаратных ошибок" нам потребуется время.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
Должен извиниться.
В документации неточная формулировка: при обнаружении ошибок на линии осуществляется не полная реинициализация COM-порта SLAVE, а общепринятая в таких случаях процедура очистки буферов и сброс прерывания.
Соответствующее изменение будет внесено в документацию.

Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469


Icon 1 отправлено / posted      Профиль для / Profile for ilya           Редактировать/удалить сообщение / Edit/Delete Post 
Поскольку проблема осталась у нас не решенной, попробовали исправить ситуацию сами. Закольцевали два свободных COM-порта (благо у нас их по четыре на компьютере) перекрестным кабелем и написали свою программу. Она работает по следующему принципу: на компьютере-мастере через пару портов получает TraceMod-овские пакеты добовляет к ним контрольную сумму, посчитанную по методу CRC16 и через третий порт отсылает все это компьютеру-slave-у. На slave пакеты получает опять наше приложение убирает CRC16 (соответственно отбрасывает пакет если КС не сошлась) и отдает пакет Trace Mod-у через закольцованную пару.
Надо сказать после добавления к пакетам TM CRC16 ситуация явно улучшилась: за две недели работы ни одного глючного значения “1.#QNAN” и ни одной испорченной записи в архиве.
Вот только привязка у нашей программки получилась жесткой к протоколу Trace Mode. Поэтому, не могли бы Вы обнародовать не документированные коды перекачки архивов? У нас в проекте предусмотрена эта опция.

Сообщения / Posts 216 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
Я отправил Вам ответ по почте.
Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193


Icon 1 отправлено / posted      Профиль для / Profile for Svetlov           Редактировать/удалить сообщение / Edit/Delete Post 
Здравствуйте. Вернувшись с курсов домой, первым делом стал проверять исправленную версию микро МРВ. ( получена по почте пользователем СВТ)
Данные с контроллера Octagon 2050 передавались через COM1 и два преобразователя 7520 (RS232-RS485) на COM1 персонального компьютера. Поток данных дублировался по сети. Помеха создавалась искусственно при помощи второго контроллера, COM1 которого через 7520 был подключен к тому же RS485. Загружаясь, SERIAL CONSOL контроллера посылает текст в линию через которую происходит обмен.
Проверял два микро МРВ «j86_noemm.exe» и «jf7.exe». И оба показали одинаково печальный результат, после нескольких секунд загрузки второго контроллера, обмен по протоколу Mlink полностью прекращался, а по сети данные продолжали приходить. Восстановить обмен удавалось только перезагрузкой контроллера, все прочие элементы тоже перегружать пробовал но не помогало. В общем ситуация полностью та же что и на не исправленной версии.
Вывод: по прежнему существуют такие варианты ошибок которые вешают задачу Mlink-Slave.
Ошибки в паке не должны приводить к полной остановке обмена. Мне так кажется, что виноват либо обработчик пакета, ища несуществующий канал, либо порт после аппаратных ошибок пере инициализируется не правильно или не полностью.

Сообщения / Posts 31 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post 
Это на МикроМРВ последнего релиза, или на 5.11?
Сообщения / Posts 15203 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
  Этот топик включает в себя следующие страницы /
This topic is comprised of pages 1  2 
 

   Закрыть тему / 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

Rambler's Top100 Rambler's Top100



Powered by Infopop Corporation
UBB.classic™ 6.7.2