Тема / Topic: Ошибки в релизе 5.12 на незащищенных каналах связи.
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
МВР 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 ]
Сообщения / Posts 216 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1) Поставить вместо Drawserv.exe МРВ файл Drawserv.exe из Инструменталки, чтобы он лог-файл вел. Посмотреть, может он в течение работы выдает какие-либо сообщения в лог об ошибках. 2) Необходимо ловить момент когда сваливается сервер. Попробуйте воспроизвести это не на объекте, съэмулировать ситуацию - например, просто запустить отдельно этот узел, чтобы он поработал некоторое время, но не на объекте, а отдельно. Без воспроизведения ситуации трудно что-либо сказать о причинах... 3) Во время работы сервера на объекте запустите диспетчер задач Windows и посмотрите счетчики по памяти, хэндлам, GDI - может что-нибудь растет в процессе работы МРВ?
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
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 |
отправлено / posted
1) У Вас контрольная сумма по I7000 выставлена - зачем? 2) В графике случайно нет переключений по экранам с формой просмотра ОТ? 3) Попробуйте 5.15 релиз.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
1). В качестве удлиннителя RS-485 используются радиомодемы SST-2400. Возможны помехи в линии связи. Почему бы контрольной сумме не быть включенной? Разве неправильная контрольная сумма должна приводить к краху TM? 2).Форма просмотра ОТ в графике присутствует. 3).Попробую. О результатах напишу.
Сообщения / Posts 216 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1) Нет причина свала скорее всего в ФО просмотра Отчета тревог. Просто у Вас очень много недостоверностей по обмену с FSС. Практика показывает, что контрольная сумма в протоколе I7000 практически ничем не помогает, наоборот обмен только хуже становится. Попробуйте ее убрать и посмотреть на качество обмена.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
Это что же получается, если у нас много пакетов с не правильной контрольной суммой, то если мы ее отключим, весь этот бардак будет воспариниматся как достоверные данные и записыватся в кналы!? Мы пробовали работать без контрольной суммы. Когда ее включили качество особо не изменилось. Хочу сказать, что TM благополучно зависал и при отключенной контрольной сумме! По поводу формы просмота ОТ - в 5.15 это исправлено?
Сообщения / Posts 216 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
1) Да не в плохом обмене зависание! Интересно, а у Вас все пакеты по I7000 протоколу именно в области данных всегда искажаются? Если искажен пакет, то прочитать его ТМ все равно не сможет, если конечно он не в области данных повредился при передаче.
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
Проект отправлен на forum@adastra.ru Зависает узел ns43. Он опрашивается узлом Disp.
Сообщения / Posts 216 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Посмотрели Ваш проект, однако он нормально работает и не зависает. Проверяли на 5.12 и 5.15. Пожалуйста, сообщите характеристики Вашего ПК, на котором он работает, а также ключи запуска сервера, если Вы их используете.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
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?
Сообщения / Posts 216 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
2) Это сообщение относится к обмену по M-Link. Мы создали исскуственную ситуацию, когда появляется это сообщение и сегодня будем проводить более детальные тесты по этому направлению. Похоже, что что-то там неладно, но это пока только догадки. О результатах тестов сообщим на форуме.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Mikhail Kagan
Junior Member / Новичок
Участник № / Member № 28
отправлено / posted
Меня заинтересовало упоминание о зависимости устойчивости работы DrawServ и его размеров от наличия ФО Отчет тревог на консолях. В моей практике с течением времени (порядка нескольких сотен часов непрерывной работы)сервер подрастает в размерах, затем наблюдается очень большое запаздывание в рассылках тревожных сообщений (до 15 мин) по отношению к записи тревог в файл, после чего сервер приходится перегружать.
Сообщения / Posts 15 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
У моих коллег похожая ситуация. Только у них на нижнем уровне несколько МикроМРВ. При опросе по M-Link порты у контроллеров "вешаются" через интервал времени от часа до двух дней. Линия находится в зоне промышленных помех. Лабораторные исследования подтвердили, что наличие помех на RS-485 приводит к зависанию портов на МикроМРВ.
Сообщения / Posts 340 | Из / From: Russia
| IP / IP: IP адрес / IP address |
отправлено / posted
На данный момент ситуация с M-Link прояснилась - действительно возможны варианты когда искажения в M-Link Slave приводят к зависаниям. Это вызвано тем, что возможны такие искажения в пакете из-за помех, которые не отслеживаются контрольной суммой пакета. И система неадекватно реалировала на такую искаженную команду. Параллельно с испытаниями также выявилось, что и сам физический канал RS485 (конвертеры) можно "завесить" помехами. Сейчас мы принимаем меры для того, чтобы в дальнейшем искаженный помехой пакет не приводил к столь фатальной ситуации с обменом, однако это все равно не дает гарантий, что система будет защищена от помех на все 100% (стойкость контрольной суммы не позволяет это сделать, все равно остаются варианты, когда искаженный пакет может быть принят системой за нормальный, что может привести к ошибочным командам). К тому же сам физический канал чувствителен к помехам - поэтому в первую очередь, чтобы система была стабильна, необходимо обеспечивать стабильность самого канал связи.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
СВТ
Junior Member / Новичок
Участник № / Member № 707
отправлено / posted
Описание системы. Имеем систему состоящую из пяти контроллеров 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 |
отправлено / posted
Причина скорее всего та же, что и описана выше - реакция Микро МРВ в режиме Slave на искаженный пакет. Старший байт - это код аппаратной ошибки СОМ-порта (так называемый статус СОМ-порта). Вот их описание: 0x0001 // Receive Queue overflow 0x0002 // Receive Overrun Error 0x0004 // Receive Parity Error 0x0008 // Receive Framing error
СВТ
Junior Member / Новичок
Участник № / Member № 707
отправлено / posted
Сложилось впечатление, что переинициализации порта автоматически не производится! Мы вынуждены делать это сами. Какие меры собирается предпринять АдАстра для повышения надежности обмена по M-Link? И когда?
Сообщения / Posts 9 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Нам удалось смоделировать ситуацию зависания M_Link-SLAVE при некоторых ошибках на линии RS 485. Вышлите, пожалуйста, на адрес техподдержки запрос с указанием регистрационного номера лицензии на микроМРВ. Мы отправим Вам рабочую версию микроМРВ с соответствующей коррекцией. Дополнительное повышение надежности обмена можно получить, если ввести проверку байтов "по четности/нечетности".
Протокол M_Link не позиционируется в качестве телемеханического, поэтому к нему не предъявлялись такие же жесткие требования по обнаружению ошибок, как для систем телемеханики. В системах реального времени, к которым относится АСУ ТП, плохое качество канала связи может привести к существенному снижению реактивности системы в целом. Поэтому повышение помехоустойчивости протокола и, как следствие, снижение производительности канала связи, по крайней мере, не во всех случаях можно признать целесообразным. Эффективнее все-таки повышать качество канала связи. Для перепроверки "автоматической реинициализации COM-порта при обнаружении аппаратных ошибок" нам потребуется время.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Должен извиниться. В документации неточная формулировка: при обнаружении ошибок на линии осуществляется не полная реинициализация COM-порта SLAVE, а общепринятая в таких случаях процедура очистки буферов и сброс прерывания. Соответствующее изменение будет внесено в документацию.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilya
Forum Professor / Завсегдатай форума
Участник № / Member № 469
отправлено / posted
Поскольку проблема осталась у нас не решенной, попробовали исправить ситуацию сами. Закольцевали два свободных COM-порта (благо у нас их по четыре на компьютере) перекрестным кабелем и написали свою программу. Она работает по следующему принципу: на компьютере-мастере через пару портов получает TraceMod-овские пакеты добовляет к ним контрольную сумму, посчитанную по методу CRC16 и через третий порт отсылает все это компьютеру-slave-у. На slave пакеты получает опять наше приложение убирает CRC16 (соответственно отбрасывает пакет если КС не сошлась) и отдает пакет Trace Mod-у через закольцованную пару. Надо сказать после добавления к пакетам TM CRC16 ситуация явно улучшилась: за две недели работы ни одного глючного значения “1.#QNAN” и ни одной испорченной записи в архиве. Вот только привязка у нашей программки получилась жесткой к протоколу Trace Mode. Поэтому, не могли бы Вы обнародовать не документированные коды перекачки архивов? У нас в проекте предусмотрена эта опция.
Сообщения / Posts 216 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193
отправлено / posted
Здравствуйте. Вернувшись с курсов домой, первым делом стал проверять исправленную версию микро МРВ. ( получена по почте пользователем СВТ) Данные с контроллера 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 |
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193
отправлено / posted
Изначально проблема была на МикроМРВ версии 5.11, но после переписки, приведенной выше в этом топике,вы выслали нам почтой версию в которой ошибка должна быть исправленна. Переписка велась пользователем СВТ. В декабре я был у вас на курсах по 6 версии где вы меня просили проверить исправлена ли ошибка. Вот проверил, ошибка не исправлена.
Сообщения / Posts 31 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
### Мы проведем дополнительные исследования по предполагаемым причинам зависания обмена по M-Link и результат сообщим немного позже.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193
отправлено / posted
Здравствуйте. Ожидая результатов вашего исследования, я провел еще одну серию экспериментов. Испытательный стенд описан в предыдущих сообщениях. Надеюсь, что результаты этих экспериментов смогут хоть как-то вам помочь. Напомню. В обмен по протоколу Mlink между контроллером и компьютером искусственно вносилась помеха. В результате чего обмен прекращался. После зависания канал Диагностика Mlink(Master) работающий в компьютере выдает 8H, а канал Диагностика Mlink(Slave) работающий в контроллере 804H. Причем всегда после зависания коды одни и те же. Я завел в контроллере канал RSreinit, посылка в него 1 всегда приводит к восстановлению обмена по зависшему порту, но стоит послать в него 2 или больше прекращается любой обмен по всем последовательным портам, восстанавливается только перезагрузкой контроллера. (Проверялось многократно на Oct 6030 и на 2050). На только что прошедшей конференции вы просили послать файл записи обмена по Mlink сделанный при помощи шпиона подключенного к тому же RS485. Высылаю на hotline@adastra.ru два таких файла. В каждом из них зафиксирован момент зависания, в конце файла идут запросы без ответов. В свою очередь готов оказать вам любое содействие в решении этой проблемы так как располагаю хорошим испытательным полигоном, но прошу вас ускорить процесс, а то недельки через 3-4 оборудование будет смонтировано на объект и проверять исправления будет негде.
Сообщения / Posts 31 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
"Шпион" дал нам информацию в очень трудно читаемом виде. Я отправил Вам более удобный вариант. Реинициализация COM-порта действительно способствует восстановлению обмена (для того и введен такой канал). Посылка "1" в этот канал приводит к реинициализации COM1, "2" - COM2. Может быть, у Вас COM2 нет?
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193
отправлено / posted
Все получил. Спасибо за интересную программу. Запись новых файлов займет какоето время(день два). По поводу RSreinit: пробовал на Octagon 6030 (4 СОМ порта), работает только на первом, переинициализация любого другово приводит к полному зависанию обмена по всем СОМам. Пришлось MLink вешать на СОМ1 и отключать SerialConsol так как этот порт отладочный, а это не очень удобно.
Сообщения / Posts 31 | Из / From: Россия
| IP / IP: IP адрес / IP address |
HELLA
Forum Haunter / Завсегдатай форума
Участник № / Member № 104
отправлено / posted
Добрый день! Вопрос очень актуален и для Нас. Большая просьба,если будет достигнут положительный результат - указать путь получения обновлений для МикроМРВ (МРВ). Серийные номера Мы вышлем по почте.
Сообщения / Posts 139 | Из / From: РОССИЯ
| IP / IP: IP адрес / IP address |
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193
HELLA
Forum Haunter / Завсегдатай форума
Участник № / Member № 104
отправлено / posted
Добрый день! У нас те же проблемы с зависанием контроллера при обмене по протоколу M-Link (Slave). Зависание контроллера происходит через интервал времени час или более.Зависание полное, снимается перезапуском проекта. Контроллер в сети один(WAFER),МикроМРВ -JF7 alfa version,скорость обмена по СОМ1-57.6Кб,8-1-n, Timeout=50.Линия связи 1,5 м (RS-232-RS-232). Как бороться с этой бедой ?
Сообщения / Posts 139 | Из / From: РОССИЯ
| IP / IP: IP адрес / IP address |
отправлено / posted
Насколько я понимаю, в Вашем проекте микроМРВ одновременно выступает в качестве МАСТЕРА MODBUS и SLAVE M_LINK. И "плохого канала связи" у вас нет. Мы специально займемся исследованием этой проблемы.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
HELLA
Forum Haunter / Завсегдатай форума
Участник № / Member № 104
отправлено / posted
Совершенно верно! Увеличили скорость по M-link до 115.2 Кбод,8-1-е. Запустили на выдержку.
Сообщения / Posts 139 | Из / From: РОССИЯ
| IP / IP: IP адрес / IP address |
HELLA
Forum Haunter / Завсегдатай форума
Участник № / Member № 104
отправлено / posted
Добрый день! Провели очередной эксперимент. Проработав 4 часа контроллер завис. Попробуем эксперимент без обмена по MLINK.
Сообщения / Posts 139 | Из / From: РОССИЯ
| IP / IP: IP адрес / IP address |
отправлено / posted
На Вашем проекте стенд проработал больше 12 часов. Количество ошибок - меньше 0.01%. Продолжаем гонять.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Svetlov
Forum Member / Участник форума
Участник № / Member № 1193
отправлено / posted
Добрый день. Хотел поинтересоваться как продвигается работа по устранению зависаний MLink(Slave). Найдена ли ошибка? Когда ожидать исправленной версии МикроМРВ?
Дело в том, что через неделю оборудование на котором я провожу испытания будет установленно на объект, по этому проверка исправлений будет проблематичной.
Сообщения / Posts 31 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Нам представляется, что в этом топике обсуждаются очень разные проблемы.
Повышение надежности обмена по M_Link будет решаться, к сожалению, в марте. Придется искать альтернативный способ испытаний.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[А-а! / Eek!]](eek.gif)
![[Недоумение / Confused]](confused.gif)
![[crazy / сумасшедший]](graemlins/crazy.gif)
![[Безумие / Mad]](mad.gif)
![[Растерянность / Embarrassed]](redface.gif)
