This is topic Ошибки в релизе 5.12 на незащищенных каналах связи. in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.
МВР 5.12 (Win2k Professional) опрашивает модули серии I-7000 на скорости 4800. В свою очередь его опрашивает по радиоканалу на скорости 19200 МРВ верхнего уровня (Win2k Server). МРВ нижнего уровня зависает примерно через час. Причем с такими симптомами: в граф. консоли, в таблице каналов, видно, что входа всех каналов (каналов опрашивающих I-7000 и каналов в которые записываются данные с верхнего уровня) меняются, а вот дальше пересчета нет. Так повторялось два раза - оба раза перезапускали. На третий раз приехали на объект – окна сервера мат. обработки (он у нас запускается с командной строки) нет в системе (впрочем, процесса тоже нет) т.е. на этот раз он вообще вылетел, а вот Picrt.exe присутствует. Запустили сервер мат. обработки еще раз – и графика подцепилась к нему. Т.е. зависает (или вываливается) именно DrawServ.exe! Что делать?
[ 04.11.2004, 15:23: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Поставить вместо Drawserv.exe МРВ файл Drawserv.exe из Инструменталки, чтобы он лог-файл вел. Посмотреть, может он в течение работы выдает какие-либо сообщения в лог об ошибках. 2) Необходимо ловить момент когда сваливается сервер. Попробуйте воспроизвести это не на объекте, съэмулировать ситуацию - например, просто запустить отдельно этот узел, чтобы он поработал некоторое время, но не на объекте, а отдельно. Без воспроизведения ситуации трудно что-либо сказать о причинах... 3) Во время работы сервера на объекте запустите диспетчер задач Windows и посмотрите счетчики по памяти, хэндлам, GDI - может что-нибудь растет в процессе работы МРВ?
Posted by ilya (Участник № / Member № 469) on :
1).Поставили вместо МРВ пофайлер. Приехали через день – Drawserv.exe (профайлер) вылетел. В лог-файле около сотни строк: “Wrong FSC”(собственно такой строкой лог и заканчивается). 3).В диспетчере задач для процесса Drawserv.exe параметр “память-использование” постепенно растет (с шагом 4 KB). За 5 минут значение изменилось с 2292 KB на 2316KB. Через 40-50 минут оно было уже 2636KB. (проверялось на профайлере).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) У Вас контрольная сумма по I7000 выставлена - зачем? 2) В графике случайно нет переключений по экранам с формой просмотра ОТ? 3) Попробуйте 5.15 релиз.
Posted by ilya (Участник № / Member № 469) on :
1). В качестве удлиннителя RS-485 используются радиомодемы SST-2400. Возможны помехи в линии связи. Почему бы контрольной сумме не быть включенной? Разве неправильная контрольная сумма должна приводить к краху TM? 2).Форма просмотра ОТ в графике присутствует. 3).Попробую. О результатах напишу.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Нет причина свала скорее всего в ФО просмотра Отчета тревог. Просто у Вас очень много недостоверностей по обмену с FSС. Практика показывает, что контрольная сумма в протоколе I7000 практически ничем не помогает, наоборот обмен только хуже становится. Попробуйте ее убрать и посмотреть на качество обмена.
Posted by ilya (Участник № / Member № 469) on :
Это что же получается, если у нас много пакетов с не правильной контрольной суммой, то если мы ее отключим, весь этот бардак будет воспариниматся как достоверные данные и записыватся в кналы!? Мы пробовали работать без контрольной суммы. Когда ее включили качество особо не изменилось. Хочу сказать, что TM благополучно зависал и при отключенной контрольной сумме! По поводу формы просмота ОТ - в 5.15 это исправлено?
Posted by ilya (Участник № / Member № 469) on :
Попробовал 5.15. Опять зависает.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Да не в плохом обмене зависание! Интересно, а у Вас все пакеты по I7000 протоколу именно в области данных всегда искажаются? Если искажен пакет, то прочитать его ТМ все равно не сможет, если конечно он не в области данных повредился при передаче.
2) Давайте Ваш проект - посмотрим у себя...
Posted by ilya (Участник № / Member № 469) on :
Проект отправлен на forum@adastra.ru Зависает узел ns43. Он опрашивается узлом Disp.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Посмотрели Ваш проект, однако он нормально работает и не зависает. Проверяли на 5.12 и 5.15. Пожалуйста, сообщите характеристики Вашего ПК, на котором он работает, а также ключи запуска сервера, если Вы их используете.
Posted by ilya (Участник № / Member № 469) on :
1)Снял компьютер с объекта. Тестировал в офисе. Опрашивал модули I7000, и опрашивал проблемный узел другим МРВ. Т.е. практически полностью повторил ситуацию на объекте. Правда, без использования радиомодемов для связи между нижним и верхним уровнем (просто перекрестным кабелем). И без использования радиомодемов SST-2400 для связи с отдельными модулями. Результат тот же, что и у Вас: ни каких зависаний. Если Вы говорите, что плохой обмен не может быть источником проблемы, то тогда не знаю где искать причину.
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?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
2) Это сообщение относится к обмену по M-Link. Мы создали исскуственную ситуацию, когда появляется это сообщение и сегодня будем проводить более детальные тесты по этому направлению. Похоже, что что-то там неладно, но это пока только догадки. О результатах тестов сообщим на форуме.
Posted by Mikhail Kagan (Участник № / Member № 28) on :
Меня заинтересовало упоминание о зависимости устойчивости работы DrawServ и его размеров от наличия ФО Отчет тревог на консолях. В моей практике с течением времени (порядка нескольких сотен часов непрерывной работы)сервер подрастает в размерах, затем наблюдается очень большое запаздывание в рассылках тревожных сообщений (до 15 мин) по отношению к записи тревог в файл, после чего сервер приходится перегружать.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
У моих коллег похожая ситуация. Только у них на нижнем уровне несколько МикроМРВ. При опросе по M-Link порты у контроллеров "вешаются" через интервал времени от часа до двух дней. Линия находится в зоне промышленных помех. Лабораторные исследования подтвердили, что наличие помех на RS-485 приводит к зависанию портов на МикроМРВ.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
На данный момент ситуация с M-Link прояснилась - действительно возможны варианты когда искажения в M-Link Slave приводят к зависаниям. Это вызвано тем, что возможны такие искажения в пакете из-за помех, которые не отслеживаются контрольной суммой пакета. И система неадекватно реалировала на такую искаженную команду. Параллельно с испытаниями также выявилось, что и сам физический канал RS485 (конвертеры) можно "завесить" помехами. Сейчас мы принимаем меры для того, чтобы в дальнейшем искаженный помехой пакет не приводил к столь фатальной ситуации с обменом, однако это все равно не дает гарантий, что система будет защищена от помех на все 100% (стойкость контрольной суммы не позволяет это сделать, все равно остаются варианты, когда искаженный пакет может быть принят системой за нормальный, что может привести к ошибочным командам). К тому же сам физический канал чувствителен к помехам - поэтому в первую очередь, чтобы система была стабильна, необходимо обеспечивать стабильность самого канал связи.
Posted by СВТ (Участник № / Member № 707) on :
Описание системы. Имеем систему состоящую из пяти контроллеров 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Н не описана зато сказано, что при возникновении ошибок линии порт переинициализируется. Я так понимаю, что этого не происходит, по крайней мере в моем случае. Пожалуйста, прокомментируйте ситуацию и посоветуйте еще какие-нибудь варианты борьбы с этим явлением.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Причина скорее всего та же, что и описана выше - реакция Микро МРВ в режиме Slave на искаженный пакет. Старший байт - это код аппаратной ошибки СОМ-порта (так называемый статус СОМ-порта). Вот их описание: 0x0001 // Receive Queue overflow 0x0002 // Receive Overrun Error 0x0004 // Receive Parity Error 0x0008 // Receive Framing error
В любом случае - реинициализация порта проводится МикроМРВ при любой из аппаратных ошибок.
Posted by СВТ (Участник № / Member № 707) on :
Сложилось впечатление, что переинициализации порта автоматически не производится! Мы вынуждены делать это сами. Какие меры собирается предпринять АдАстра для повышения надежности обмена по M-Link? И когда?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Нам удалось смоделировать ситуацию зависания M_Link-SLAVE при некоторых ошибках на линии RS 485. Вышлите, пожалуйста, на адрес техподдержки запрос с указанием регистрационного номера лицензии на микроМРВ. Мы отправим Вам рабочую версию микроМРВ с соответствующей коррекцией. Дополнительное повышение надежности обмена можно получить, если ввести проверку байтов "по четности/нечетности".
Протокол M_Link не позиционируется в качестве телемеханического, поэтому к нему не предъявлялись такие же жесткие требования по обнаружению ошибок, как для систем телемеханики. В системах реального времени, к которым относится АСУ ТП, плохое качество канала связи может привести к существенному снижению реактивности системы в целом. Поэтому повышение помехоустойчивости протокола и, как следствие, снижение производительности канала связи, по крайней мере, не во всех случаях можно признать целесообразным. Эффективнее все-таки повышать качество канала связи. Для перепроверки "автоматической реинициализации COM-порта при обнаружении аппаратных ошибок" нам потребуется время.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Должен извиниться. В документации неточная формулировка: при обнаружении ошибок на линии осуществляется не полная реинициализация COM-порта SLAVE, а общепринятая в таких случаях процедура очистки буферов и сброс прерывания. Соответствующее изменение будет внесено в документацию.
Posted by ilya (Участник № / Member № 469) on :
Поскольку проблема осталась у нас не решенной, попробовали исправить ситуацию сами. Закольцевали два свободных COM-порта (благо у нас их по четыре на компьютере) перекрестным кабелем и написали свою программу. Она работает по следующему принципу: на компьютере-мастере через пару портов получает TraceMod-овские пакеты добовляет к ним контрольную сумму, посчитанную по методу CRC16 и через третий порт отсылает все это компьютеру-slave-у. На slave пакеты получает опять наше приложение убирает CRC16 (соответственно отбрасывает пакет если КС не сошлась) и отдает пакет Trace Mod-у через закольцованную пару. Надо сказать после добавления к пакетам TM CRC16 ситуация явно улучшилась: за две недели работы ни одного глючного значения “1.#QNAN” и ни одной испорченной записи в архиве. Вот только привязка у нашей программки получилась жесткой к протоколу Trace Mode. Поэтому, не могли бы Вы обнародовать не документированные коды перекачки архивов? У нас в проекте предусмотрена эта опция.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Я отправил Вам ответ по почте.
Posted by Svetlov (Участник № / Member № 1193) on :
Здравствуйте. Вернувшись с курсов домой, первым делом стал проверять исправленную версию микро МРВ. ( получена по почте пользователем СВТ) Данные с контроллера Octagon 2050 передавались через COM1 и два преобразователя 7520 (RS232-RS485) на COM1 персонального компьютера. Поток данных дублировался по сети. Помеха создавалась искусственно при помощи второго контроллера, COM1 которого через 7520 был подключен к тому же RS485. Загружаясь, SERIAL CONSOL контроллера посылает текст в линию через которую происходит обмен. Проверял два микро МРВ «j86_noemm.exe» и «jf7.exe». И оба показали одинаково печальный результат, после нескольких секунд загрузки второго контроллера, обмен по протоколу Mlink полностью прекращался, а по сети данные продолжали приходить. Восстановить обмен удавалось только перезагрузкой контроллера, все прочие элементы тоже перегружать пробовал но не помогало. В общем ситуация полностью та же что и на не исправленной версии. Вывод: по прежнему существуют такие варианты ошибок которые вешают задачу Mlink-Slave. Ошибки в паке не должны приводить к полной остановке обмена. Мне так кажется, что виноват либо обработчик пакета, ища несуществующий канал, либо порт после аппаратных ошибок пере инициализируется не правильно или не полностью.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это на МикроМРВ последнего релиза, или на 5.11?
Posted by Svetlov (Участник № / Member № 1193) on :
Изначально проблема была на МикроМРВ версии 5.11, но после переписки, приведенной выше в этом топике,вы выслали нам почтой версию в которой ошибка должна быть исправленна. Переписка велась пользователем СВТ. В декабре я был у вас на курсах по 6 версии где вы меня просили проверить исправлена ли ошибка. Вот проверил, ошибка не исправлена.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
### Мы проведем дополнительные исследования по предполагаемым причинам зависания обмена по M-Link и результат сообщим немного позже.
Posted by Svetlov (Участник № / Member № 1193) on :
Здравствуйте. Ожидая результатов вашего исследования, я провел еще одну серию экспериментов. Испытательный стенд описан в предыдущих сообщениях. Надеюсь, что результаты этих экспериментов смогут хоть как-то вам помочь. Напомню. В обмен по протоколу Mlink между контроллером и компьютером искусственно вносилась помеха. В результате чего обмен прекращался. После зависания канал Диагностика Mlink(Master) работающий в компьютере выдает 8H, а канал Диагностика Mlink(Slave) работающий в контроллере 804H. Причем всегда после зависания коды одни и те же. Я завел в контроллере канал RSreinit, посылка в него 1 всегда приводит к восстановлению обмена по зависшему порту, но стоит послать в него 2 или больше прекращается любой обмен по всем последовательным портам, восстанавливается только перезагрузкой контроллера. (Проверялось многократно на Oct 6030 и на 2050). На только что прошедшей конференции вы просили послать файл записи обмена по Mlink сделанный при помощи шпиона подключенного к тому же RS485. Высылаю на hotline@adastra.ru два таких файла. В каждом из них зафиксирован момент зависания, в конце файла идут запросы без ответов. В свою очередь готов оказать вам любое содействие в решении этой проблемы так как располагаю хорошим испытательным полигоном, но прошу вас ускорить процесс, а то недельки через 3-4 оборудование будет смонтировано на объект и проверять исправления будет негде.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
"Шпион" дал нам информацию в очень трудно читаемом виде. Я отправил Вам более удобный вариант. Реинициализация COM-порта действительно способствует восстановлению обмена (для того и введен такой канал). Посылка "1" в этот канал приводит к реинициализации COM1, "2" - COM2. Может быть, у Вас COM2 нет?
Я отправил Вам "более чистую" версию микроМРВ. Жду ответа.
Posted by Svetlov (Участник № / Member № 1193) on :
Все получил. Спасибо за интересную программу. Запись новых файлов займет какоето время(день два). По поводу RSreinit: пробовал на Octagon 6030 (4 СОМ порта), работает только на первом, переинициализация любого другово приводит к полному зависанию обмена по всем СОМам. Пришлось MLink вешать на СОМ1 и отключать SerialConsol так как этот порт отладочный, а это не очень удобно.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Вопрос очень актуален и для Нас. Большая просьба,если будет достигнут положительный результат - указать путь получения обновлений для МикроМРВ (МРВ). Серийные номера Мы вышлем по почте.
Posted by Svetlov (Участник № / Member № 1193) on :
Новые дампы обмена и проект отправил на hotline@adastra.ru
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы ведем работу по повышению устойчивости SLAVE микроМРВ при большой интенсивности помех в канале связи.
По завершении работы результаты войдут в очередной релиз.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! У нас те же проблемы с зависанием контроллера при обмене по протоколу M-Link (Slave). Зависание контроллера происходит через интервал времени час или более.Зависание полное, снимается перезапуском проекта. Контроллер в сети один(WAFER),МикроМРВ -JF7 alfa version,скорость обмена по СОМ1-57.6Кб,8-1-n, Timeout=50.Линия связи 1,5 м (RS-232-RS-232). Как бороться с этой бедой ?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Насколько я понимаю, в Вашем проекте микроМРВ одновременно выступает в качестве МАСТЕРА MODBUS и SLAVE M_LINK. И "плохого канала связи" у вас нет. Мы специально займемся исследованием этой проблемы.
Posted by HELLA (Участник № / Member № 104) on :
Совершенно верно! Увеличили скорость по M-link до 115.2 Кбод,8-1-е. Запустили на выдержку.
Posted by HELLA (Участник № / Member № 104) on :
Добрый день! Провели очередной эксперимент. Проработав 4 часа контроллер завис. Попробуем эксперимент без обмена по MLINK.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
На Вашем проекте стенд проработал больше 12 часов. Количество ошибок - меньше 0.01%. Продолжаем гонять.
Posted by Svetlov (Участник № / Member № 1193) on :
Добрый день. Хотел поинтересоваться как продвигается работа по устранению зависаний MLink(Slave). Найдена ли ошибка? Когда ожидать исправленной версии МикроМРВ?
Дело в том, что через неделю оборудование на котором я провожу испытания будет установленно на объект, по этому проверка исправлений будет проблематичной.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Нам представляется, что в этом топике обсуждаются очень разные проблемы.
Повышение надежности обмена по M_Link будет решаться, к сожалению, в марте. Придется искать альтернативный способ испытаний.
![[А-а! / Eek!]](eek.gif)
![[Недоумение / Confused]](confused.gif)
![[crazy / сумасшедший]](graemlins/crazy.gif)
![[Безумие / Mad]](mad.gif)
![[Растерянность / Embarrassed]](redface.gif)