This is topic OPC-Lectus и достоверность in forum Общие вопросы / Common questions at Форум TRACE MODE: техническая поддержка.


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

Posted by VaBo1966 (Участник № / Member № 6398) on :
 
Каким образом мониторить достоверность данных, получаемых от указанного 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

%%OPC_SERVER_CONFIG
PROGID:Lectus.OPC.1
CLSID:{8FD7B87A-E35E-47DC-A1FD-5D52233E6F2E}
%CHANID:1
ID:Node.Item11
%CHANID:2
ID:Node.Item12
%CHANID:3
ID:Node.Item13
%CHANID:4
ID:Node.Item14
%CHANID:5
ID:Node.LINKQUALITY

- параметр равен 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 :
 
Беру паузу, пошел на форум Лектуса, покажу техподдержке этот топик.
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2