Форум TRACE MODE: техническая поддержка: Ошибка работы МРВ

This is topic Ошибка работы МРВ in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.

To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/35/t/000150.html

Posted by arido (Участник № / Member № 2961) on :

Здравствуйте.
Проблема такая.
Есть проект обработки данных с 3-х контроллеров (2 Mitsubishi и Siemens). Данные снимаются ОРС-серверами (родными). После работы монитора в течение нескольких часов (периоды работы разные от 10 мин до 8 часов) возникает ошибка и монитор выключается. В файле tm6_log.txt пишет " 0029 00000000[65535] Process timeout "
Как определить в чем проблема. Переписывала проект 3 раза заново - не помогает. [prey / молящийся]

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Какая ошибка возникает? И какой релиз у Вас?

Posted by arido (Участник № / Member № 2961) on :

Иногда просто пишет, что обнаружена ошибка (к сожалению не знаю как прицепить файл с отчетом).
Иногда "pure virtual function call" (что-то вроде этого)

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Попробуйте обновится до релиза 6.06

Posted by arido (Участник № / Member № 2961) on :

Обновила и среду разработки и мониторы - ошибки все равно выскакивают (с разными периодами времени). Что делать? [cry / плачь]

Производство стоит.

В проекте два узла МРВ (пока). Каждый запускается на отдельном ПК. Один проработал без сбоев почти сутки (и пока продолжает работать).
Может проблема в том, что я создала обычный узел RTM, а ключ TFactory RTM?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

" 0029 00000000[65535] Process timeout "

Данная ошибка не может появляться в релизе 6.06. Проверьте есть ли у Вас в файле tm6_log.txt указание даты или только время.

Posted by arido (Участник № / Member № 2961) on :

В релизе 6.05.1 было так
"время 0029 00000000[65535] Process timeout "

После установки 6.06
"13:39:07 0000 00000000[0] 31.10.2008
13:39:07 0000 00000000[0] Start
14:10:17 0000 00000000[0] Stop"

Про ошибку здесь не пишет, но окнос сообщением "pure virtual function call" было (правда после установки 6.06 только 1 раз).

И еще, только заметила.
есть функция, в ней 75 аргументов. В релизе 6.05.1 все работало. После установки 6.06 - последние 40 аргументов как-будто не видит. Если переносить аргумент вверх - появляется.
В чем проблема?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Пришлите, пожалуйста, пример этой функции.

Posted by arido (Участник № / Member № 2961) on :

Отправила на адрес текст функции.
Попробовала поднять последний аргумент и поставить за последним "видимым". Сработал, ниже - нет.

???

В релизе 6.05.1 все работало.

Posted by arido (Участник № / Member № 2961) on :

И так, похоже, со всеми функциями.

Что делать ??? [cry / плачь]

Столько привязок, столько работы ??? [Недоумение / Confused]

Posted by arido (Участник № / Member № 2961) on :

Здравствуйте.
Сбои в работе опять появились. Теперь появляется окно Windows о сбое программы. Ни в одном из файлов ТМ не пишется какая ошибка и была ли она вообще. Просто МРВ закрывается и все. Стала проскакивать и такая ошибка "Insufficient: memory". С чем это может быть связано? Проекты не изменялись. [Неодобрение / Frown]

Может это связано с большим количеством запросов к одной БД? (я отправляла вам фрагмент проекта).
Подскажите, что делать? [Недоумение / Confused]

Posted by arido (Участник № / Member № 2961) on :

Так что же делать??

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Ошибка "Insufficient: memory" возникает при недостатке оперативной памяти. Большое количество запросов к БД могут на это влиять.

Потребуется тестирование проекта, для этого нам нужен сам проект (файл prj) и все что нужно для его функционирования (БД, OPC и т.д.). А также если у Вас есть CNF файлы в узлах, то их тоже лучше прислать.

Posted by arido (Участник № / Member № 2961) on :

Фрагмент проекта я вам отправляла. Запросы генерируются поочередно (программа "Обмен_БД_"). Могу прислать структуру БД (MSSQL 2000). А вот с ОРС сложнее - они лицензионные. Я думаю, что можно и без ОРС протестировать. У меня тоже сложилось впечатление, что на сбои в работе проектов влияет большое количество запросов. Но, к сожалению, их количество нельзя уменьшить - у вас ведь нет таблицы для вывода информации из БД (это бы многое изменило!!!)
Посмотрите, пожалуйста, программу "Обмен_БД_". Такая ситуация - когда приходит время отправки запроса, запрос отправляется, а вот данные могут приходить через раз (а то и 5-10 раз), и приходят вопреки условию! Например, в базе три строки мне нужно вывести на экран их в порядке появления - 1, 2, 3. А они могут вывестись в любом порядке, хотя в запросе стоит условие!?
Если запросы посылать вручную - отрабатываю сразу и правильно??

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Без полного проекта рассматривать эту ситуацию нельзя. Возможно ошибка возникает в результате влияния нескольких факторов. Можно и без OPC, мы их заменим на генераторы, хотя это уже исказит результат.

Posted by arido (Участник № / Member № 2961) on :

Отправила Вам проект. В проекте оставила 1 узел, остальные - подобны и каждый запускается на отдельном ПК.
А так же отправила структуру БД.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Здравствуйте. У нас возникает что-то подобное. Никаких ошибок не выскакивает. МРВ просто закрывается.
Вот tm6_log:
11:14:52 0000 00000000[0] 17.11.2008
11:14:52 0000 00000000[0] Start
11:14:52 0000 00000000[4]
11:49:05 0002 00000033[2]
11:49:11 0002 00000033[2]

Версия 6.06. В проекте сейчас работает один МРВ и несколько NLL. Запросов к БД нет. Есть OPC-каналы.
В чем может быть проблема?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

В какое время он закрывается? Примерно в 11:49 по файлу или потом еще какое-то время работает?

Posted by SerchenyaN (Участник № / Member № 2877) on :

Не знаю точно. МРВ работает на сервере в отдельном помещении, где нет возможности постоянного контроля за работоспособностью TM. Когда связь NLL с МРВ обрывается, мы идём и смотрим, что произошло. Приходим, а на компьютере нет ни следа какой-либо работы МРВ. При этом вылетает МРВ не постоянно, а иногда (может раз в две недели, а может и сразу 2 раза за день закрытся) и совершенно непонятно по каким причинам.

Posted by arido (Участник № / Member № 2961) on :

Аналогичная ситуация.
У меня еще запущен проект без запросов к БД и в нем всего 14 каналов - сбор статистики по связи с контроллерами (достоверность сигналов ОРС-сервера). Вот он еще не разу не вываливался ?!

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Нам необходимо хотя бы примерно знать является ли сообщения
11:49:05 0002 00000033[2]
11:49:11 0002 00000033[2]

возможной причиной ошибки или эти записи не связаны с падением.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Примерно в это время связь с МРВ и оборвалась. Только вот точно сказать не можем, именно в этот момент закрылся МРВ или минуту раньше/позже.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Эта запись означает проблемы с памятью при отправке по IP. Пришлите, пожалуйста, файлы tm6_log.txt, название проекта_цифра.txt, а также проекта_цифра.cnv

Posted by SerchenyaN (Участник № / Member № 2877) on :

Письмо отправлено на hotline@adastra.ru. Будем ждать результатов.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

У Вас они почему-то свежие, нам нужны именно те, с падением.

V..._0.cnv
V..._0.txt
tm6_log.txt

Posted by SerchenyaN (Участник № / Member № 2877) on :

Как мы уже писали, МРВ вываливается периодически, и как раз 2008_12_02 это снова повторилось. Файл лога как раз после закрытия МРВ 2008_12_02 мы вам и отослали и он отличается от лога предыдущего закрытия за 17_11_2008.
Файлы V..._0.cnv и V..._0.txt за 17_11_2008 отослать не получится, так как в тот момент мы не знали, что они могут понадобиться и соответственно не скопировали их, а проект с того момента дорабатывался, не один раз обновлялся и перезапускался.
Сейчас пытаемся отследить хоть какую-то закономерность изменений и поведения МРВ. Один раз МРВ вывалился буквально через минуту после того, как запустили NLL.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Уважаемая техподдержка, что-нибудь можете сказать по данной ошибке:
Event Type: Error
Event Source: Application Error
Event Category: (100)
Date: 22.01.2009
Time: 19:42:01
Description:Faulting application rtcx.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0001bd02

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Можно сказать только, что ошибка возникла в компоненте ядра ОС и синхронизирована с вызовом этого компонента от rtcx.exe.
Однако истинную причину ошибки таким образом определить нельзя. Она может быть связана, в том числе, с искажением данных в rtcx.exe из-за неправильного обращения к памяти со стороны другого приложения, или с недостатком памяти, выделенной системой rtcx.exe или другому приложению.
Насколько я понимаю, Вы работаете в релизе 6.06.
Некоторые ситуации, вызывающие аналогичные проблемы были нейтрализованы в релизе 6.06.2, который сейчас выложен на сайте.
Если Вы решите опробовать этот вариант, сообщите нам результаты.
Тем не менее мы хотели бы получить от Вас протоколы, которые соответствовали бы критическим моментам.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Какие именно протоколы вы имеете в виду?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

файлы tm6_log.txt + название_проекта_номер_узла.txt

Posted by SerchenyaN (Участник № / Member № 2877) on :

файл tm6_log.txt выглядим следующим образом:

15:43:45 0000 00000000[0] 17.02.2009
15:43:45 0000 00000000[0] Start
10:37:41 0000 00000000[0] 26.02.2009
10:37:41 0016 00000032[14] Главный экран:27
12:05:22 0000 00000000[0] 26.02.2009
12:05:22 0000 00000000[0] Start
09:24:29 0000 00000000[0] 27.02.2009
09:24:29 0000 00000000[0] Start
10:49:04 0000 00000000[0] 05.03.2009
10:49:04 0000 00000000[0] Start
05:12:32 0000 00000000[0] 09.03.2009
05:12:32 0002 00000033[2]
05:12:32 0002 00000033[2]
05:12:34 0002 00000033[2]
05:12:34 0002 00000033[2]
05:12:34 0002 00000033[2]
05:12:34 0002 00000033[2]
05:12:34 0002 00000033[2]
05:12:35 0016 00000032[14] Главный экран:27
08:34:10 0000 00000000[0] 09.03.2009
08:34:10 0000 00000000[0] Start
00:17:17 0000 00000000[0] 18.03.2009
00:17:17 0002 00000033[2]
00:17:18 0016 00000032[14] Главный экран:27
00:17:19 0002 00000033[2]
00:17:19 0002 00000033[2]
08:08:57 0000 00000000[0] 18.03.2009
08:08:57 0000 00000000[0] Start
13:46:21 0002 00000033[2]
15:17:19 0000 00000000[0] 20.03.2009
15:17:19 0000 00000000[0] Start
15:47:08 0000 00000000[0] Stop
15:50:44 0000 00000000[0] 23.03.2009
15:50:44 0000 00000000[0] Start
09:45:28 0000 00000000[0] 26.03.2009
09:45:28 0000 00000000[0] Stop
09:54:24 0000 00000000[0] 26.03.2009
09:54:24 0000 00000000[0] Start

За промежуток времени, освещённый в логе, МРВ вывалился 4 раза:
26.02.2009 10:39:11 Application Error Error (100) 1000 N/A MVKSCADAO Faulting application rtcx.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0002caa2.

27.02.2009 0:33:24 Application Error Error (100) 1000 N/A MVKSCADAO Faulting application rtcx.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0002af51.

09.03.2009 5:13:33 Application Error Error (100) 1000 N/A MVKSCADAO Faulting application rtcx.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0002a99f.

18.03.2009 0:18:23 Application Error Error (100) 1000 N/A MVKSCADAO Faulting application rtcx.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0002a754.

Файла название_проекта_номер_узла.txt нет в папке узла и никогда не было.

Posted by SerchenyaN (Участник № / Member № 2877) on :

AdAstra Technical Support, у нас всё никак не решится огромная проблема с вылетом МРВ. В пятницу 3 апреля мы будем участвовать в семинаре, проводимом компанией AdAstra Research Group в её офисе. Будет возможность показать вам проект для выяснения причин ошибки, а также разъяснить нюансы. Может быть это позволит решить вопрос?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Ждем Вас.

13:46:21 0002 00000033[2] - это ошибка обмена по IP
05:12:35 0016 00000032[14] Главный экран:27 - проблема с экраном

Что именно происходит, надо будет посмотреть на примере.

Posted by arido (Участник № / Member № 2961) on :

Здравствуйте.
Опять проблемы с вылетом МРВ. Теперь в файле tm6_log.txt содержатся строки:
14:24:53 0000 00000000[0] 05.11.2009
14:24:53 0000 00000000[0] Start
Вылет произошел ориентировочно 00:48 (определила по архивным трендам)
Где можно еще посмотреть, что бы определить в чем ошибка?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Приведенные строки из tm6_log.txt говорят о том, что 05.11.2009 14:24:53 узел был запущен без проблем.
Возможно, какая-то информация "о вылете" содержится в системном журнале событий.
Запускайте МРВ с его отладочной библиотекой (dllxRTM32_e.dll), тогда он будет вести в папке узла протокол с сообщениями об обнаруженных ошибках.

Posted by arido (Участник № / Member № 2961) on :

Подскажите, как это сделать(самостоятельно - не получилось)

Вот еще ситуация - проект был запущен, проработал без сбоев какое-то время. Я, периодически, проверяю правильность показаний. И, в один день, оказалось, что проект работает, ошибок tm6_log нет, но каналы не пересчитывались около 10 часов. То есть значения "застыли" и не обновляются.
Как можно предотвратить такое состояние. Может можно определять, что пересчет застыл и перезапускать проект?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Не пересчитываются все каналы или только какие-то группы?
Насколько Вы уверены в том, что действительно перестала пересчитываться вся база каналов?

Возможно, в проекте существуют проблемы с отображением, перестает функционировать графика?
Или перестают функционировать каналы внешней связи, что приводит к отсутствию видимых изменений в каналах?
Должны ли были быть в течение этих 10 часов сообщения в ОТ? Можете ли Вы посмотреть сам файл ОТ за этот период времени?

Posted by arido (Участник № / Member № 2961) on :

Не пересчитываются все каналы (включая программы), в этом я уверена.Сообщения в ОТ не пишутся, идет архивация некоторых значения (для отображения стоят тренды). И, по возникновению определенных событий (дискретные входы), идет запись в БД. На протяжении 10-ти часов в трендах по 20-ти параметрам шла ровная линия (значения записывались в архив!!!) (значение на момент прекращения пересчета). И в БД записи заканчиваются тем же моментом времени (значение времени (тип DATE_AND_TIME) тоже пишется в БД)

quote:
Отправитель / Originally posted by AdAstra Technical Support:

Возможно, в проекте существуют проблемы с отображением, перестает функционировать графика?

Тренды писались (ось времени соответствовала реальному)

quote:
Отправитель / Originally posted by AdAstra Technical Support:

Или перестают функционировать каналы внешней связи, что приводит к отсутствию видимых

Данный считываются с контроллеров через ОРС-сервера. При "отваливании" ОРС-сервера (по атрибуту "Достоверность") срабатывает программа перезапуска ОРС-серверов (использую @e_OPC := 250)

Такая ситуация возникла первый раз, до этого МРВ просто "вылетал".

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Без установления причин происходящего нельзя искать средства борьбы с этим.
Все перечисленные факты не указывают однозначно на остановку пересчета базы каналов.
Надо ввести какой-то независимый от внешних интерфейсов канал-генератор, задать ему границы, подключить словарь сообщений и направить в ОТ. Аналогично поступить и с каким-нибудь наиболее динамичным каналом связи с OPC-сервером.
Тогда после наступления аварийной ситуации можно будет установить, действительно ли пересчет базы каналов был полностью остановлен.

Если МРВ "вылетает", то, как правило, это сопровождается появлением системного сообщения и записью в системной журнале.
Можно запустить системный монитор и по его счетчикам отследить состояние системных ресурсов в критический момент.

Наиболее вероятными причинами подобных событий являются проблемы с ресурсами или ошибки по памяти. Известны случаи, когда имели место конфликты по памяти с внешними приложениями. Например, было установлено, что один из OPC-серверов при определенных условиях захватывал чужую область памяти. Пришлось пользователям обращаться к создателям этого OPC-сервера и просить его откорректировать. Коллизии были устранены.

Posted by arido (Участник № / Member № 2961) on :

Похоже, причину нашла. Установила апгрейд 6.06.3 для IDE. Проект из IDE 6.06.3 работал в RTM 6.06.2.
Когда поставила апгрейд RTM 6.06.3, после запуска проект работает, но значения не меняются.

И еще, заметила, что объем файла СПАД увеличивается, а при просмотре история не отображается.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

В апдейте 6.06.3 есть ошибка при обмене с OPC. В самое ближайшее время мы обновим его.

Posted by arido (Участник № / Member № 2961) on :

И еще - в МРВ не генерируется отчет.
Пробовала так IDE 6.06.3 - RTM 6.06.2 и IDE 6.06.3 - RTM 6.06.3.
В IDE генерация работает.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

А раньше генерировался?

У Вас нет зарегистрированных МРВ с поддержкой документирования.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Апдейты обновлены.

Posted by arido (Участник № / Member № 2961) on :

Здравствуйте. И снова вылет МРВ.
Вот содержимое файла tm6_log.txt
11:20:51 0000 00000000[0] 12.01.2010
11:20:51 0000 00000000[0] Start
11:49:24 0000 00000000[0] 12.01.2010
11:49:24 0000 00000000[0] Start
23:50:22 0000 00000032[7] Запись_состояния_LSA
23:50:22 0000 00000032[7] Запись_состояния_90_3
23:50:22 0000 00000032[7] Запись_состояния_90_4
23:51:00 0000 00000000[0] 12.01.2010
23:51:00 0000 00000000[0] Start

Код 0000 00000032[7] - Фатальная ошибка МРВ при пересчете канала.
Канал "Запись_состояния_***" - канал CALL, осуществляющий запись данных в БД.
Я уже спрашивала, может ли отключение БД влиять на работу МВР, вы сказали, что нет. Но подозрения остаются - по ночам ведутся обновления БД и она может отключаться или быть занята.

Подскажите, что можно сделать?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

При корректных операциях с БД не должно быть критических ошибок. Если БД просто не отвечает ,каналу выставляется признак недостоверности, но сообщения о критической ошибке, типа приведенных выше, не возникает.

Фатальная ошибка говорит о том, что произошло нарушение процедур работы с памятью, выход на критическую секцию. Выход из первичной критической ситуации МРВ завершил (выдал сообщение). Но сама критическая ситуация, видимо, осталась, и МРВ натыкается уже на не диагностируемую ошибку и падает.
Если есть фатальные ошибки, дальнейшие процедуры уже не продуктивны.
Это говорит о том, что внешние процедуры с БД (обновления, отключения, работа с другими клиентами) выполняются с какими-то нарушениями.
Надо их анализировать и исключать.

Posted by arido (Участник № / Member № 2961) on :

Перешла на СУБД PostgreSQL, пока работает стабильно.
Остался такой вопрос - при переинициализации ОРС-серверов МРВ "вылетает" иногда с системным сообщение, иногда без. И не всегда сразу - может через минуту вылететь.
Я убрала программную переинициализацию, делала в ручную, любое значение (перебрала около 50-ти разных вариантов). Все равно вылетает.
Подскажите что делать. Без переинициализации никак, а при вылета теряется статистика.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Если осуществляется переинициализация (программно или вручную), то она осуществляется только двумя способами: частично или полностью. "Перебор значений" не продуктивен.
Процедура инициализации OPC-сервера соответствует стандарту.
Причина фатальной ситуации - не в самой процедуре переинициализации, а в реакции ОС. Скорее всего происходят какие-то коллизии с памятью или с DCOM.
Если эти ситуации возникают регулярно, надо методом исключения искать узкое место.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Здравствуйте. Помогите, пожалуйста, решить проблему с вылетом МРВ. После запуска на удалённом компьютере NLL, буквально пару минут МРВ работает, а затем просто закрывается. Раньше такого не было. Запустили МРВ с отладкой (заменили библиотеку dllxRTM32.dll на dllxRTM32_e.dll).

Запись в системном журнале:

code:

  
Event Source:	Application Error
Event Category:	(100)
Event ID:	1000
Date:		13.01.2011
Time:		10:14:17
User:		N/A
Computer:	MVKSCADAO
Description:
Faulting application rtcx.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.4455, fault address 0x0002a38b.

Файл tm6_log:

code:

 
12:44:01 0000 00000000[0] 11.01.2011
12:44:01 0000 00000000[0] Start
12:44:01 0000 00000000[4]
10:36:39 0000 00000000[0] 13.01.2011
10:36:39 0000 00000000[999] Checking Message Disabled
10:36:44 0000 00000000[0] Start
10:36:44 0000 00000000[4]

Файл ИмяПроекта_<ordinal>.txt :

code:

  
 INF_LOAD:Starting... VodoprovodP_0
INF_RTM:Detected NT5.RTM 5.2 
._.:Professional RTM+  ver. 6.06.2 
INF_LOAD:Load Channels = 3664
INF_LOAD:Templates=40 
INF_LOAD:Objects = 3
INF_RTM:Timer=0.1s CalcLoop=1000ms 
WRN_DDE:Can't bind to DSDM service 
INF_IP:name is mvkscadao ; cards=2 
INF_IP:card0 addr=0.0.0.0 
INF_IP:card1 addr=200.200.25.114 
INF_IP:Create InSocket = 0
INF_IP:Mask for use cards 101
INF_IP:Create OutSocket = 0
INF_IP:Number of ind_block=256 Length of pocket=1452(70) IP Buffer =8kB queue=2048 
INF_TCP:listen 0.0.0.0
._.:client rcv = 92928
ERR_.:Checking Message Disabled 
INF_RTM:start time is 0 s 
INF_RTM:ModeSwitch e15=0000 e18=0000 e20=0000 
INF_IP:node=1 addr=200.200.25.154 port=402 card=0 
INF_IP:node=2 addr=10.137.0.200 port=402 card=0 
INF_IP:node=2 addr=200.200.25.14 port=402 card=0 
INF_RTM:mode=2(Work) e15=10 e18=00 e20=1000 
DBG_RTM:(T) g_ID=2398 Index=-1 SVal= id_attr=2 
DBG_RTM:(L) g_ID=2398 Index=-1 LVal=0 id_attr=4
 
DBG_RTM:(L) g_ID=1581 Index=-1 LVal=0 id_attr=39
 
DBG_RTM:(L) g_ID=3322 Index=-1 LVal=0 id_attr=39
..............................
..............................
 
DBG_RTM:(L) g_ID=4250 Index=-1 LVal=-686751744 id_attr=2
 
DBG_RTM:(L) g_ID=4250 Index=-1 LVal=0 id_attr=4
 
ERR_IP:no memory for data buffer 

DBG_RTM:(T) g_ID=2398 Index=-1 SVal=38 id_attr=2 
DBG_RTM:(L) g_ID=2398 Index=-1 LVal=0 id_attr=4
 
DBG_RTM:(L) g_ID=1581 Index=-1 LVal=0 id_attr=39
 
DBG_RTM:(L) g_ID=3322 Index=-1 LVal=0 id_attr=39
 
DBG_RTM:(L) g_ID=3354 Index=-1 LVal=0 id_attr=39

О каком именно буфере идёт речь в строке отладочного файла: ERR_IP:no memory for data buffer

Posted by SerchenyaN (Участник № / Member № 2877) on :

И при этом, если выполнить такую последовательность: запускаем МРВ, запускаем NLL (вылетает МРВ), оставляем запущенным NLL, перезапускаем МРВ, то дальше всё работает стабильно.
МРВ установлен на компьютере с Windows Server 2003, NLL - Windows XP. C другими NLL такого не происходит (работают один МРВ и четыре NLL). С МРВ идёт рассылка сообщений в сеть.

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

ERR_IP:no memory for data buffer - буфер, через которых сетевая ОС передает сообщения от МРВ.
Его объем может скорректирован ключом в файле конфигурирования запуска МРВ:
"...IPSIZE=<BUF> – BUF задается как число в формате HEX. Значение байта 0 BUF задает размер буфера отправки по IP (в килобайтах). Размер буфера приема по IP задается автоматически как (k+1)*<размер буфера отправки>, где k – значение байта 1 BUF. Размер буферов по умолчанию – 8 кБ; "

В момент запуска NLL консоль, видимо, запрашивает у МРВ большой объем данных, для которых заданного объема буфера недостаточно.
Фатальные последствия такой ситуации в последнем релизе блокированы.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Спасибо. Попробуем увеличить размер буфера и обновиться до релиза 6.07.

Posted by SerchenyaN (Участник № / Member № 2877) on :

Почитав форум о возможных проблемах при переходе на релиз 6.07, решили с этим пока повременить - проект очень объёмный.
Увеличение размера буфера не помогло. При запуске консоли МРВ с таким же успехом вылетает, но теперь без ошибок в отладочном файле. Пока просто автоматически отслеживаем наличие процесса rtcx.exe и если его нет - перезапускаем МРВ. После всяческих экспериментов возникли подозрения, что проблема в некорректной работе компьютера с NLL и сетевых настройках, но на данный момент решить этот вопрос не представляется возможным.

При работе в режиме отладки возник вопрос. За несколько дней работы файл ИмяПроекта_<ordinal>.txt достиг размера в 10Гб. Такого объёма текстовый файл анализировать сложнова-то. Можно ли как-то ограничить размер файла, чтобы происходило как в случае с файлом Отчета тревог узла - при достижении заданного размера новые строки записывались поверх старых?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Мы подумаем над предложением об ограничении размера файла протокола профайлера.
Пока можно с помощью системной переменной @Debug
в реальном времени изменять объем информации, выводимой в протокол.

Топик закрывается, т.к. он слишком объемный и рамытый по тематике.

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

UBB.classic™ 6.7.2