 |
Интерфейсы и их методы объекта 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 – неизвестная ошибка.
|
|
|
