1.Экраны в NetLink не успевают обновляться, вследствии каждые 10 секунд они мигают разными цветами, т.к на них много графических элементов. Ставили в настройках каналов CALL время отработки - цикл IDLE, ситуация не изменилась!? 2.Есть 18 Com портов после промежутка времени 20мин.- 1час перестает опрашиваться несколько COM портов!?
Если можно ответить побыстрее, в случае если нужно отправить проект смогу выложить на файлообменник и прислать вам на почту ссылку, т.к. по почте не получиться, размер проекта более 40Мб.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Вышлите проект на hotline3@adastra.ru. 2. Создайте в папке узла проекта cnf-файл с ключом "DEBUG=200"(как создавать такой файл описано в справочной системе). После этого воспроизведите ситуацию и вышлите нам на e-mail log-файл, файл протокола профайлера и файл проекта.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Отправил с адреса xxx@hotmail.com
[ 14.08.2011, 19:54: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ждем файл протокола профайлера и log-файл.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
К сожалению ситуация не воспроизвелась, как только получиться сразу пришлем!
Posted by Денис Зражевский (Участник № / Member № 5265) on :
И что можно сказать по первому вопросу!
Posted by Nico (Участник № / Member № 5342) on :
если не успевают обнавляться и в этом есть полная уверенность( через диагностику или debugon=20 в окне компонентов)
1) увеличить период экрана период экрана > суммарного времени отрисовок всех активных экранов 2) если экраны ресурсоемкие - анимация,куча слоев,постоянные запросы архивов,итп -> уменьшить 3) посмотреть что с памятью 4) вся диагностика в TM6 есть к сожалению она разбросана в разных топиках хэлпа
[ 19.08.2011, 10:34: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Запустили проект. Описанная ситуация не воспроизвелась, что может объясняться производительностью нашего ПК.
Рекомендации, данные пользователем Nico верны.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Насчет портов, сегодня повторилось все файлы высланы почтой от xxx@hotmail.com
Насчет экранов сделали! Спасибо!
[ 19.08.2011, 10:34: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В файле протокола профайлера есть сообщения о том, что на запросы по COM-портам не приходят ответы. Также не удается выполнить запись.
Наиболее вероятная причина - слишком большой поток обмена по COM-портам. Возможно, что причина в расширителе COM-портв, который не успевает обрабатывать поток информации.
Для диагностики ситуации можно отключить половину COM-портов, а затем постепенно подключать отключенные порты, чтобы определить при какой интенсивности обмена начинаются проблемы.
Напишите, какие расширители COM-портов Вы используете, и используются ли "родные" COM-порты ПК.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Используем Moxa CP-168EL, проблема в том что сейчас стоит другая скада и все в норме. В данный момент переводим все на групповые запросы. Попробуем подключить в проекте одну линию. Но проблема еще в том что, когда возникает эта проблема на всех каналах стоит достоверность - true. И посмотреть можем только по moxa опрашивается линия или нет
[ 19.08.2011, 15:22: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Не сразу обратили внимание.
На COM-портах стоит очень маленький таймаут. Его нужно увеличить. Причем начать надо со значение не меньше выставляемого по умолчанию в 300 мс.
Используйте групповые Modbus-запросы - это поможет снизить объем передаваемой информации.
Если ответ на Modbus-запрос не приходит, а судя по протоколу профайлера именно это и происходит, то в канале, связанном с Modbus-источником, должна выставляться недостоверность. Это проверено.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Сделал одну линию, все равно COM порт отваливается, менял таймаут - ничего не помогло. Проанализировав запросы от двух scada, выяснил что XXXXX - перед каждым запросом делает две команды RXABORT, RXCLEAR, а ТМ6 делает RXCLEAR, TXCLEAR. Какое решение можете предложить?
[ 05.09.2011, 09:22: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Насчет - "Если ответ на Modbus-запрос не приходит, а судя по протоколу профайлера именно это и происходит, то в канале, связанном с Modbus-источником, должна выставляться недостоверность. Это проверено. " можете спросить у Вашего представительста в Киеве они подтвердят!!!! Что я каналах остается достоверность - True !!!!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Команда RXABORT немедленно прекращает все операции записи по COM-порту, даже если они не завершены. Подавать эту команду перед каждым запросом не совсем корректно.
Команды RXCLEAR, TXCLEAR - очищают очередь приема и передачи в драйвере.
Что означает "одна линия"? Один COM-порт? Если один COM-порт, то среди опрашиваемых по этой линии устройств нет совпадающих адресов?
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Одна линия - контроллеры начиная с адреса 1 и выше! Конкретно по той линии по которой спрашивал! Один COM-порт - все эти контроллеры сидят на одном com порту. Если один COM-порт, то среди опрашиваемых по этой линии устройств нет совпадающих адресов? - конечно нет, в данный момент работает другая scada-система и все опрашивается нормально. Как сделать команду RXABORT перед каждым опросом!!!???
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Могу скинуть файл протокола запросов и ответов от XXXXX!
[ 05.09.2011, 09:23: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Реализовать команду RXABORT нельзя. В необходимый момент такая команда посылается Trace Mode.
Оставьте один контроллер на COM-порте и добейтесь устойчивого обмена с ним. Когда добьетесь, подключайте следующее устройство. Таким образом можно будет выяснить из-за чего возникают проблемы с обменом.
Вышлите файл перехвата запросов/ответов от Trace Mode и от сторонней СКАДА-системы для анализа на hotline3@adastra.ru.
ПОСТ ОТРЕДАКТИРОВАН 22.08.2011 16:15.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
В какой именно момент ТМ6 посылает такую команду???
Posted by Денис Зражевский (Участник № / Member № 5265) on :
файл отправлен
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Перехват был сделан, когда в Trace Mode не поступают данные?
Был нужен перехват обмена только в HEX-формате.
По перехвату для Trace Mode (который был в HEX-формате) видно, что никаких проблем при обмене не возникает.
В обмене сторонней СКАДА-системы практически после каждого запроса возникают ошибки по таймауту. После таких ошибок запросы дублируются.
Совпадающих запросов от Trace Mode и сторонней СКАДА-системы в файле перехвата нет.
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Проблема отпала сама собой, после перехода на групповые запросы!
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Проблема обратно появилась! В какой именно момент ТМ6 посылает команду RXABORT???
Posted by Nico (Участник № / Member № 5342) on :
RXABORT TM6 после открытия порта не посылает смотрите перехват RXABORT -> прекратить прием
Posted by Денис Зражевский (Участник № / Member № 5265) on :
Спасибо!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Для анализа ситуации нужно запустить проект с ключом DEBUG=200 и добиться воспроизведения ситуации. После этого отправьте на hotline3@adastra.ru файл проекта, файл tm6_log.txt, файл протокола профайлера и перехват обмена в HEX-формате по одному из COM-портов, на котором возникают проблемы.
