8.3.2 Интерфейсы и их методы объекта opcGroup

Интерфейс IOPCGroupStateMgt:

HRESULT	GetState(pUpdateRate, pActive, ppName, pTimeBias, pPercentDeadband, pLCID, phClientGroup, phServerGroup)
HRESULT	SetState(pRequestedUpdateRate, pRevisedUpdateRate, pActive, pTimeBias, pPercentDeadband, pLCID, phClientGroup)
HRESULT	SetName(szName);
HRESULT	CloneGroup(szName, riid, ppUnk);

Интерфейс IOPCPublicGroupStateMgt:

HRESULT	GetState(pPublic);
HRESULT	MoveToPublic(void);

Интерфейс IOPCSyncIO:

HRESULT	Read(dwSource, dwCount, phServer, ppItemValues, ppErrors)
HRESULT	Write(dwCount, phServer, pItemValues, ppErrors)

Интерфейс IOPCAsyncIO2:

HRESULT	Read(dwCount, phServer, dwTransactionID, pdwCancelID, ppErrors,)
HRESULT	Write(dwCount, phServer, pItemValues, dwTransactionID, pdwCancelID, ppErrors);
HRESULT	Cancel (dwCancelID);
HRESULT	Refresh(dwSource, dwTransactionID, pdwCancelID);
HRESULT	SetState(bEnable);
HRESULT	GetState(pbEnable);

Интерфейс IOPCItemMgt:

HRESULT	AddItems(dwCount, pItemArray, ppAddResults, ppErrors)
HRESULT	ValidateItems(dwCount, pItemArray, bBlobUpdate, ppValidationResults, ppErrors)
HRESULT	RemoveItems(dwCount, phServer, ppErrors)
HRESULT	SetActiveState(dwCount, phServer, bActive, ppErrors)
HRESULT	SetClientHandles(dwCount, phServer, phClient, ppErrors)
HRESULT	SetDatatypes(dwCount, phServer, pRequestedDatatypes, ppErrors)
HRESULT	CreateEnumerator(riid, ppUnk)

Интерфейс IConnectionPointContainer:

HRESULT	EnumConnectionPoints( IEnumConnectionPoints ppEnum);
HRESULT	FindConnectionPoint( REFIID riid, IConnectionPoint ppCP);

8.3.3 Объект EnumOPCItemAttributes

Интерфейс IEnumOPCItemAttributes:

HRESULT	Next(celt, ppItemArray, pceltFetched);
HRESULT	Skip(celt);
HRESULT	Reset( void);
HRESULT	Clone(ppEnumItemAttributes);

8.4 Поддержка технологии OPC в системе TraceMode

TraceMode может выступать в качестве OPC-сервера и OPC-клиента. В качестве OPC-клиента он поддерживает следующие режимы: SYNC/CACHE – синхронное чтение из кэша; SYNC/DEVICE – синхронный обмен данными с устройством; ASYNC/DEVICE – асинхронный обмен данными с устройством; ADVISE – асинхронное чтение данных при изменении их значения.

В режиме ADVISE принимаются значения, присылаемые по каналу подписки, которые присылаются сервером только при изменении значения параметра. В режиме ASYNC опрашивается OPC-сервер и принимаются данные, присылаемые по каналу подписки. Поддерживаемые типы данных: VT_R4 (FLOAT, 4 байта) – для каналов типа FLOAT и VT_I4 (INT, 4 байта) – для каналов типа HEX.

Доступ к значениям каналов через механизм OPC осуществляется с помощью программного шлюза. Он реализован в виде отдельного программного модуля, поддерживающего интерфейс OPC Data Access (OPCDA) версии 2.0. В состав шлюза OPC входят следующие файлы: opcgate.exe – исполнительный модуль шлюза; opccomn_ps.dll – библиотека поддержки DCOM для OPC 2.0; opcproxy.dll – библиотека поддержки DCOM для OPC 2.0. Шлюз должен быть зарегистрирован на том компьютере, где установлен TraceMode. Доступ к данным через шлюз осуществляется при условии работы TraceMode. Шлюз OPC для TraceMode имеет следующие идентификаторы: ProgID:"TraceMode.OPC_Gateway", CLSID:{D5238CB9-AEBE-11D2-B5E1-00409524E73B}.

8.5 Поддерживаемые интерфейсы

В качестве OPC-сервера TraceMode поддерживает следующие интерфейсы.

1. Интерфейсы сервера:

• IOPCCommon – поддерживается (смена LCID реализована только для NT);

• IOPCServer – поддерживается;

• IOPCBrowseServerAddressSpace – поддерживается;

• IconnectionPointContainer – (для IOPCShutdown) поддерживается;

2. Интерфейсы группы:

• IOPCGroupStateMgt – все методы, кроме CloneGroup();

• IOPCSyncIO – поддерживается;

• IOPCAsyncIO2 – поддерживается;

• IOPCItemMgt – поддерживается;

• IOPCAsyncIO – поддерживается;

• IdataObject – поддерживается;

• IEnumOPCItemAttributes – поддерживается;

• IconnectionPointContainer – (для IOPCDataCallback) поддерживается.

Для обращения к различным атрибутам каналов надо после имени канала через точку указать обозначение атрибута в мнемонике ТРЕЙС МОУД. Например, channel.R – реальное значение канала channel. Чтение значений атрибутов каналов разрешено всем OPC-клиентам.

Чтобы разрешить OPC-клиентам запись в каналы, можно использовать два механизма:

1. Создать в проекте пользователя с именем default (пароль не имеет значения) – в этом случае запись разрешена всем OPC-клиентам. Данный способ разрешения записи в каналы имеет наивысший приоритет.

2. Создать в реестре раздел HKEY_LOCAL_MACHINE\Software\AdAstra\TRACE MODE\5.0\OPC Gateway. Создать в нем следующие текстовые параметры и задать их значение: Login – имя пользователя; Password – пароль. Значения этих параметров, а также имя пользователя и пароль OPC-клиента, через шлюз OPC передаются серверу матобработки. В случае совпадения имен и паролей, OPC-клиент получает разрешение на запись в каналы. Данный способ имеет более низкий приоритет по отношению к первому. То есть, если имя и пароль OPC-клиента не совпадают с указанными в реестре, но при этом в проекте создан пользователь с именем default, OPC-клиент получает право на запись в каналы.

Если ни один из этих способов не применен, то запись в каналы запрещена, и операция Write возвращает ошибку E_FAIL.

Посредством своей программы OPC-клиент может установить значения трех системных переменных с целью проверки, разрешена ли ему запись в каналы: $OPCGATE_USER – имя пользователя; $OPCGATE_PASSWORD – пароль пользователя; $OPCGATE_LOGIN_STATUS – если запись разрешена, устанавливается в единицу.

8.6 Настройка обмена по OPC. Файл конфигурации

Для обмена данными с OPC-серверами предусмотрен специальный подтип каналов. Он называется OPC. МРВ может одновременно установить связь с 256-ю серверами. Для каждого из них создается файл конфигурации, в котором описываются его идентификаторы и соответствие его каналов каналам ТРЕЙС МОУД. Эти файлы располагаются в директории проекта. Их имя формируется следующим образом:

NODENAME_OPC<n>.CNF,

где NODENAME – имя базы каналов узла; <n> – номер от 0 до 255 (этот номер соответствует номеру сервера). Файлы конфигурации OPC-сервера имеют текстовый формат.

1. В первой строке файла присутствует следующая запись: %%OPC_SERVER_CONFIG.

2. Далее следуют строки, описывающие параметры сервера:

   • PROGID:<id>, где id – идентификатор в формате строки, под которым OPC-сервер зарегистрирован в системе.

   • CLSID:<id>, где id – идентификатор в формате GUID, под которым OPC-сервер зарегистрирован в системе. При наличии параметра CLSID параметр PROGID игнорируется.

   • HOSTNAME:<PC_name>, где PC_name – имя компьютера в сети. Этот параметр следует задать при обмене с удаленным OPC-сервером. В этом случае необходимо задать параметр CLSID.

3. Далее в файле описания следуют описания каналов.

• Каждое описание начинается строкой: %CHANID:<id>, где <id> – идентификатор канала ТРЕЙС МОУД. Если файл конфигурации создается автоматически, то в нем прописываются числовые идентификаторы. При редактировании файла вручную можно указать имя канала.

• После этой строки следует описание канала OPC-сервера: ID:<id>, где <id> – идентификатор канала OPC-сервера.

• ACCPATH:<path>, где <path> – путь доступа (зависит от OPC-сервера). При отсутствии этого атрибута в качестве пути доступа принимается пустая строка.

Для доступа к удаленному серверу может потребоваться запуск утилиты DCOMCNFG.EXE и установка соответствующих разрешений. Удаленный сервер должен запускаться пользователем, имеющим достаточно прав.

В случае невозможности запуска OPC-серверов МРВ выдает код ошибки 50.

Контроль текущего состояния обмена по OPC осуществляется с помощью канала ДИАГНОСТИКА с дополнением к подтипу OPC. Значение этого канала определяет следующие ситуации в обмене:

0 – нормальная работа;

3 – ошибка записи;

4 – ошибка чтения;

5 – ошибка работы с памятью;

7 – ошибка конфигурации (конфигурационных файлов);

9 – ошибка связи с OPC-сервером;

11 – ошибка выполнения операции (вызова ОС или функции OPC);

12 – неизвестная ошибка.