This is topic Связь между RTM+ и NLL. Неустойчивая работа RTM+, зависание in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.
Опишу ситуацию: RTM+ стоит на АРМ на удаленном объекте. Контроллер один Omron с Ethernet. Организована радиорелейная связь по которой передаются сигналы с видеокамер (видео наблюдение используя видеосервер Domination), пожарная сигнализация, охранная сигнализация и конечно АСУТП.
При большой задержке ответа от компьютера более 250-300 мс (проверяю командой ping) происходит сначала аварийное завершение работы программы RTM+ а потом и ее полное зависание. Большая задержка идет в следствии большого потока данных с видеокамер, если видеосервер Domination отключить, то задержка ответа от компьютера 4-5 мс (проверяю командой ping) и таких проблем не наблюдается.
Понимаю, что надо бы решать проблему через уменьшение ping'а хотя бы до 50-60 мс. Но непонятно почему падает RTM+!!!??? Проверял, если отключить NLL, то все в порядке, падения не происходит!!!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Уточните, пожалуйста, организацию связи между RTM+, контроллером и NLL. По какому протоколу идет обмен с контроллером?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Если Вы работаете в релизе до 6.07, необходимо обновиться до релиза 6.07 (лежит у нас на сайте).
Posted by raven999 (Участник № / Member № 4537) on :
1. Между RTM+ и контроллером Omron через Omron_IP 2. Между RTM+ и NLL через Ethernet (просто транспорт беспроводной). Ничего нестандартного нет, все стандартно.
Проблема возникает только тогда когда большой ping между RTM+ и NLL. Сначала RTM+ просто закрывается( в Windows отключены отчеты об ошибках, чтобы программа просто закрывалась, для возможности запустить ее еще раз) После 8-10 таких некорректных закрываний происходит зависание программы)
Релиз 6.07
Posted by raven999 (Участник № / Member № 4537) on :
+добавлю, что иногда вылетает ошибка: Runtime Error! Program: ...les\AdAstra Research Group\TRACE MODE 6 Runtime\rtcx.exe R6025- pure virtual function call
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Необходимо получить диагностическую информацию сетевого обмена между узлами RTM и CONSOLE.
Для этого надо временно подменить в папках исполнительных модулей dllxRTM32.dll на dllxRTM32_e.dll (скопировать dllxRTM32_e.dll под именем dllxRTM32.dll). Теперь исполнительные модули будут вести профайлерные протоколы.
Разместите в папке каждого узла (RTM и CONSOLE) файлы конфигурирования запуска TMcom_xx.cnf следующего содержания
DEBUG=400 END_OF_CNF <пустая строка>
В папках узлов должны генерироваться профайлерные протоколы с дополнительной информацией о сетевых процедурах и ошибках.
Если Вы не сможете использовать эту информацию для диагностики, присылайте нам проект, протоколы профайлеров и файлы tm6_log.txt обоих узлов.
ВНИМАНИЕ. Начиная с релиза 6.07.7, в исполнительных модулях отсутствуют dllxRTM32_e.dll. Каждый исполнительный модуль с dllRTM32.dll в состоянии вести профайлерный протокол, если в файле TMcom_xx.cnf будут заданы соответствующие ключи.
Posted by raven999 (Участник № / Member № 4537) on :
После того, как видео поток с видео камер уменьшили, время пинга упало до 6 мс, проблемы с зависанием RTM+ не стало. 5 Дней, полет нормальный. Но все равно случай из разряда горячих. Вполне возможно завтра придется делать проект в котором NLL будет находиться далеко от RTM+ и при этом скорость будет минимальная. Как в этом случае вопрос решать, это уже проблематично. Думаю поддержке стоит задуматься над тем чтобы проверить устойчивость системы при больших задержках. Сейчас проводить диагностику не имею возможности, потому что проект сдан в опытную эксплуатацию, и все работы на объекте закрыты. Вполне возможно вам самим сделать такую диагностику, достаточно организовать канал данных с большими задержками и низкой помехоустойчивостью.
Могу помочь только тем, что выслать вам свой проект для диагностики.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проект с интересом примем на hotline@adastra.ru. Над организацией такого стенда подумаем.
Однако любое моделирование - это только моделирование. Модель строится, в основном, на основании гипотез. Они не всегда исчерпывающе верны. Не исключено, что дело не просто в задержках, а сетевых потоках, загрузках памяти и пр. Нужна информация с реального процесса. Поэтому, если будет возможность в какой-то момент снять и предоставить нам информацию по предложенной выше методике, мы будем очень благодарны.
Posted by raven999 (Участник № / Member № 4537) on :
проект отправлен
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проект получили. Мы его посмотрим и, если обнаружим какие-то проблемы, сообщим Вам.
Очень надеемся, что по возможности Вы предоставите нам диагностическую информацию с реального процесса.
Posted by raven999 (Участник № / Member № 4537) on :
Все дело в том, что сейчас эту проблему уже не повторить, видео наблюдение настроено и задержек нет. Так что, только своими силами...
