Каким образом мониторить достоверность данных, получаемых от указанного OPC-сервера? Смотрю за аргументом 4 привязанного канала, он показывает достоверность (_I) и при корректной работе, и при выгруженном сервере. Что я делаю не так? Попутно второй вопрос, касающийся Лектуса. При работе от его встроенного клиента (там есть такая возможность) каждый узел создается в отдельной папке и есть возможность создания для каждого отдельного узла встроенной системной переменной "качество связи". При запуске от клиента ТМ все узлы конфигурации Лектуса помещаются в две папки, и все ранее созданные переменные "качества связи" становятся одинаковыми для всех узлов и равны наименьшему значению. В техподдержке (на форума) Лектуса пояснили, что проблема в формировании запросов от клиента ТМ (я использую SYNC/CASH). Прокомментируйте?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
При разрыве связи с OPC-сервером индивидуальные атрибуты ДОСТОВЕРНОСТЬ каждого канала связи обязательно возвращают признак недостоверности (перепроверено в релизе 6.09).
Диагностическая переменная @e_OPC типа INPUT индицирует качество связи с определенным OPC-сервером. Диагностическая переменная @e_OPC типа OUTPUT позволяет реинициализировать потерянную связь с определенным OPC-севером (см. документацию).
Дополнительную диагностику OPC-обмена можно осуществить с помошью ключа DEBUGON=80000 в файле конфигурирования запуска узла *.cnf (см. раздел "Приложения/Задание параметров работы мониторов"). В профайлерном протоколе узла будет диагностическая информация.
Если "встроенные системные переменные "качество связи"" являются OPC-тегами и при организации связи с OPC-сервером в браузере OPC (в инструментальной среде) они предъявляются раздельно, то и каналы, связанные с этими переменными должны быть раздельными и никак не влияют друг на друга независимо от используемого режима OPC-обмена.
Структурировать в узле каналы, связанные с тегами OPC-сервера, можно произвольным образом.
Posted by VaBo1966 (Участник № / Member № 6398) on :
Вот скриншот для выгруженного сервера
Вот скриншот для запущенного ...
В обоих случаях достоверность _Т. Прислать проект?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Работать с Вашим проектом мы смогли бы только при наличии у OPC-сервера Lectus бесплатного демо-режима. У нас такой возможности нет.
Мы перепроверяли (еще раз!, в релизе 6.09) на связи с бесплатными демо-версиями OPC-серверов KEPServerEx и Matrikon OPC. И при невозможности подключиться к OPC-серверу при запуске узла и разрыве соединения или принудительной выгрузке OPC-сервера у каналов выставляется признак недостоверности.
Признак недостоверности выставляется каналу при отсутствии ответа, некорректном ответе или при наличии в ответе OPC-сервера признака недостоверности запрашиваемых у него данных.
Posted by VaBo1966 (Участник № / Member № 6398) on :
В общем-то у него есть такой режим, 30 дней полнофункциональной работы.
В этом стареньком топике обсуждалось, кстати
_http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/31/t/000334.html#000000
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Так ведь в этом топике как раз и указывается, что признак недостоверности выставляется адекватно.
Posted by VaBo1966 (Участник № / Member № 6398) on :
И вот еще:
Диагностическая переменная @e_OPC типа INPUT индицирует качество связи с определенным OPC-сервером - у меня эта переменная в любом случае равна нулю.
Диагностическая переменная @e_OPC типа OUTPUT позволяет реинициализировать... - Это работает, равносильно ф-ии "обновить данные" ОРС-сервера.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В каком релизе Вы работаете? Сколько OPC-серверов у Вас задействовано в проекте? Каков индекс OPC-сервера в проекте (он присутствует в имени файла конфигурирования <имя проекта>_<номер узла>_opc<индекс OPC-сервера>.cnf в папке проекта)? Чему равен ПАРАМЕТР у переменной @e_OPC типа INPUT? В окне компонентов в строке с номером атрибута 003 у канала стоит I или O?
Posted by VaBo1966 (Участник № / Member № 6398) on :
- 6.09 - Тестовый проект, специально для проверки ОРС, соответствунно только один. - номер 0, вот весь .cnf
- параметр равен 0 - [003] I On+T C
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Задайте ключ DEBUGON=80000 в файле конфигурирования запуска узла *.cnf (см. раздел "Приложения/Задание параметров работы мониторов"). В профайлерном протоколе будут сообщения о запуске и остановке OPC-сервера и OPC-клиента, а также сообщения об ошибках OPC-обмена.
Posted by VaBo1966 (Участник № / Member № 6398) on :
Лог запуска клиента при работающем сервере:
(10:12:0) INF_OPC:OPC Clients started (10:12:0) INF_IP:hostname is PC (10:12:0) INF_IP:card0 addr=0.0.0.0 (10:12:0) INF_IP:card1 addr=192.168.1.2 (10:12:0) INF_RTM:start time is 0 s (10:12:0) INF_RTM:total use(MB): pm=888 vm=428 after start (10:12:0) INF_RTM:use(MB): pm=30(30) vm=94(95) pf=5073 after start (10:12:0) INF_RTM:gh:1535 uh:163 hh:233 after start (10:12:0) INF_FLT:ModeSwitch e15=0000 e18=0000 e20=0000 [0] (10:12:0) INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 [src4] (10:12:0) INF_FLT:No detect condition (10:12:0) INF_OPC:0000000I61010019: OPC сервер \\.\Lectus.OPC.1: Сервер стартовал = 0 (10:12:0) INF_GRAPH:scr:1:popup=0 scrref=0 trend=0,0 update=1 (10:12:16) INF_RTM:stoping... (10:12:16) INF_RTM:mode=5(Stop) e15=00 e18=00 e20=00 [src0] (10:12:16) INF_OPC:0000000I6101001a: OPC сервер \\.\Lectus.OPC.1: Сервер остановлен = 0 (10:12:16) INF_OPC:OPC Clients stoped (10:12:17) INF_RTM:stop time is 0.828 s (10:12:17) INF_RTM:number of calculation = 26 (10:12:17) INF_RTM:END OF WORK
Лог запуска клиента при выгруженном сервере:
(10:13:40) INF_OPC:OPC Clients started (10:13:40) INF_IP:hostname is PC (10:13:40) INF_IP:card0 addr=0.0.0.0 (10:13:40) INF_IP:card1 addr=192.168.1.2 (10:13:40) INF_RTM:start time is 0 s (10:13:40) INF_RTM:total use(MB): pm=888 vm=429 after start (10:13:40) INF_RTM:use(MB): pm=30(30) vm=94(95) pf=5064 after start (10:13:40) INF_RTM:gh:1531 uh:159 hh:234 after start (10:13:40) INF_FLT:ModeSwitch e15=0000 e18=0000 e20=0000 [0] (10:13:40) INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 [src4] (10:13:40) INF_FLT:No detect condition (10:13:40) INF_OPC:0000000I61010019: OPC сервер \\.\Lectus.OPC.1: Сервер стартовал = 0 (10:13:40) INF_GRAPH:scr:1:popup=0 scrref=0 trend=0,0 update=1 (10:13:57) INF_RTM:stoping... (10:13:57) INF_RTM:mode=5(Stop) e15=00 e18=00 e20=00 [src0] (10:13:57) INF_OPC:0000000I6101001a: OPC сервер \\.\Lectus.OPC.1: Сервер остановлен = 0 (10:13:57) INF_OPC:OPC Clients stoped (10:13:58) INF_RTM:stop time is 1.547 s (10:13:58) INF_RTM:number of calculation = 28 (10:13:58) INF_RTM:END OF WORK
К сожалению, я мало что понимаю из этого, на мой взгляд - все одинаково. Тем не менее ошибки нет, в первом случае сервер работал, во втором - нет.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В обоих протоколах указывается, что при запуске узла корректная связь с OPC-сервером установлена, а при остановке и выгрузке узла подается команда на остановку OPC-сервера.
Возможно, речь идет не о "выгрузке" OPC-сервера, а об отключении его связи с контроллерами?
Это косвенно подтверждается скриншотом от стороннего OPC-клиента "при выгруженном OPC-сервере" (пост от 30.10 17:22): несмотря на "выгрузку" OPC-сервера переменная Node.LINKQUALITY читается клиентом.
Posted by VaBo1966 (Участник № / Member № 6398) on :
Да, я перевожу сервер в состояние ОСТАНОВ, при этом теряется связь с устройством - состояние, которое я и желаю отследить. Вот сейчас попробовал именно выгрузить, лог ниже:
(13:21:41) INF_OPC:OPC Clients started (13:21:41) INF_IP:hostname is PC (13:21:41) INF_IP:card0 addr=0.0.0.0 (13:21:41) INF_IP:card1 addr=192.168.1.2 (13:21:41) INF_FLT:ModeSwitch e15=0000 e18=0000 e20=0000 [0] (13:21:41) INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 [src4] (13:21:41) INF_FLT:No detect condition (13:21:41) INF_RTM:start time is 0 s (13:21:41) INF_RTM:total use(MB): pm=850 vm=428 after start (13:21:41) INF_RTM:use(MB): pm=30(30) vm=94(95) pf=5058 after start (13:21:41) INF_RTM:gh:1535 uh:163 hh:230 after start (13:21:41) INF_OPC:0000000I61010019: OPC сервер \\.\Lectus.OPC.1: Сервер стартовал = 0 (13:21:41) INF_GRAPH:scr:1:popup=0 scrref=0 trend=0,0 update=1 (13:21:51) INF_OPC:0000000I6101001b: OPC сервер \\.\Lectus.OPC.1: Запрос на отключение от OPC сервера = 0 (13:21:51) INF_OPC:0000000I6101001a: OPC сервер \\.\Lectus.OPC.1: Сервер остановлен = 0 (13:21:58) INF_RTM:stoping... (13:21:58) INF_RTM:mode=5(Stop) e15=00 e18=00 e20=00 [src0] (13:21:58) INF_OPC:0000000I6101001a: OPC сервер \\.\Lectus.OPC.1: Сервер остановлен = 0 (13:21:58) INF_OPC:OPC Clients stoped (13:21:59) INF_RTM:stop time is 1.281 s (13:21:59) INF_RTM:number of calculation = 28 (13:21:59) INF_RTM:END OF WORK
И да, проверил, в этом состоянии достоверность в параметре 004 изменяется! Т.о. я вижу не достоверность отдельно взятой переменной (что мне нужно), а факт работы OPC-сервера.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Признак недостоверности выставляется каналу при отсутствии ответа, некорректном ответе или при наличии в ответе OPC-сервера признака недостоверности запрашиваемых у него данных.
Видимо, OPC-сервер в режиме "ОСТАНОВ" не выдает клиенту признака недоставерности данных в ответе на запрос значения конкретного тега.
Если OPC-сервер может сообщить в каком-то дополнительном теге о своем состоянии "ОСТАНОВ", этот тег может быть считан клиентом и по его значению может идентифицировано состояние разрыва связи с устройствами, подключенными к OPC-серверу.
Posted by VaBo1966 (Участник № / Member № 6398) on :
Беру паузу, пошел на форум Лектуса, покажу техподдержке этот топик.
