Обращение внешнего OPC клиента к DAServer

[005xb]

Здравствуйте,
Есть система из нескольких InTouch RunTime и одного DAServer (DASABCIP), в котором сконфигурены обязательные Device Group.
Появилась необходимость обращаться к контроллерам через тот же DAServer с другого приложения, которое является OPC клиентом. Соответственно обращение от него идёт к OPC серверу, встроенному в DAServer. Идея в том, чтобы использовать те же Device Group-ы и поминимуму увеличивать трафик обмена данными с контроллерами, так как 90% данных, запрашиваемых новым приложением, совпадает с теми, что уже читаются приложением InTouch (переодичность опроса тоже совпадает).

Проблема в том, что новый OPC клиент не поддерживает поле Access Path, в котором предполагается указывать Device Group.
Без указания Device Group, Daserver будет использовать Default Device Group для обслуживание запросов OPC клиента. Т.е. две разные Device Group (созданая ранее и Default) будут опрашивать одни и те же данные, т.е. трафик удвоится.

Есть ли возможность указать Device Group в адресации точки (LinkID) на стороне OPC клиента? (Некоторые ОРС серверы поддерживают такой альтернативный способ задания Access Path значения (обычно topic для ОРС серверов комбинированных с DDE)?

Или есть другие идеи как решить проблему?

[NewOrdered]

Попробуйте такую схему:
OPC Client > Archestra FSGateway > DASABCIP
На Archestra FSGateway настройте только те теги, которые нужны клиенту.

[005xb]

Попробуйте такую схему:
OPC Client > Archestra FSGateway > DASABCIP

Извините, я неправильно указал версию. Версия InTouch 9.5. Софт установлен в 2011. Получится доставить FSGateway?

[NewOrdered]

Попробуйте такую схему:
OPC Client > Archestra FSGateway > DASABCIP

Извините, я неправильно указал версию. Версия InTouch 9.5. Софт установлен в 2011. Получится доставить FSGateway?

Верно, FSGateway нужно устанавливать отдельно. Технически его даже необязательно устанавливать на ту же машину, где DAS сервер или OPC клиент, конфигурация может быть распределенной (если лицензии позволяют).

Отправлено спустя 1 минуту 8 секунд:
Хотя с DDE могут быть проблемы

[005xb]

FSGateway нужно устанавливать отдельно

Не могу нагуглить какая версия FSGateway нужна (чтоб встала вместе с имеющимся DASABCIP (IOServer InTouch 9.5) под XP). Помогите, пожалуйста, разобраться.

Спасибо.

[NewOrdered]

FSGateway нужно устанавливать отдельно

Не могу нагуглить какая версия FSGateway нужна (чтоб встала вместе с имеющимся DASABCIP (IOServer InTouch 9.5) под XP). Помогите, пожалуйста, разобраться.

Спасибо.

http://archestra.info/index.php/FS_Gateway

http://archestra.info/index.php/%D0%92% ... 0%B4%D0%B0

[keysansa]

Проблема в том, что новый OPC клиент не поддерживает поле Access Path

А зачем вам Access Path, если данные запрашиваются одни и те же?

[005xb]

А зачем вам Access Path, если данные запрашиваются одни и те же?

Access Path нужен чтобы под запрос ОРС клиента использовалась та же Device-группа, что сейчас используется в DASABCIP сервере для чтения с контроллера данных, запрошенных InTouch RunTime. Т.е. сейчас есть DeviceGroup LOGIX_PLC1 с опросом раз в 1секунду. Эта группа работает "топиком" SuitLink(accesss name) для InTouch приложений (SuitLink) и отрабатывает коммуникацию 1000тэгов. Если для OPC клиента, которому нужны те же 1000 тэгов не указать в качестве Access Path существующую девайс группу (LOGX_PLC1), то DASABCIP будет использовать default девайс группу и будет считывать эти 1000тэгов с контроллера ещё раз. Т.е. траффик DASABCIP-PLC удвоится. Кроме того, ОРС-клиенту нужно чтобы часть данных обновлялась с контроллера чаще. Это можно сделать только через ещё одну девайс группу. Но ОРС-клиент не сможет ей воспользоваться, так как для этого нужно задать эту группу в поле Access Path.

[005xb]

Если кому то интересно: использование FSGateway (OPC), в качестве посредника между клиентом и DASABCIP (OPC), позволило обойти проблему. Спасибо NewOrdered за идею.