Kassl dOPC for Delphi против eMation Wizcon OPC Server.

[Beltar]

По случаю первопоста, всем здравствуйте.

Дано, старая SCADA eMation Wizcon, не менее 10 лет, развернута еще на Windows XP. Есть желание собрать с нее данные по OPC DA, для чего пытаюсь использовать программулину, сделанную с помощью Kassl dOPC for Delphi текущей версии (5.11) и Delphi 10.3.2 Rio, до того она успешно использовалась для сходного агрегата, но с другой SCADA.

Данные либо успешно считываются, либо клиент намертво зависает при попытке подключения. Аналогично полностью зависает Delphi, если попробовать настроить компоненты на данный сервер в режиме разработки. Грузит opcproxy.dll и на этом всё. Что странно, идущий с самой dOPC простенький клиент всегда подключается нормально.

Я могу тут винить либо Wizcon, либо opcproxy.dll (но как я понял это весьма стандартная штука от OPC-foundation), либо dOPC, раз Delphi зависает в режиме разработки, но ничего из этого, я очевидно, исправить не смогу. Попробовал в качестве прокладки между Wizcon и моей софтинкой Advanced OPC Data logger, но она тоже повисла.

Есть какие-нибудь идеи, как это можно побороть? Можно, конечно, напрямую к контроллерам цепляться, но в них, скорее всего, нет информации о рецепте.

[SaNNy]

Можно попробовать использовать библиотеку от graybox (http://gray-box.net/download_daawrapper.php?lang=ru) для взаимодействия с opc сервером.

[Beltar]

Враппер, я конечно гляну, но я уже попробовал в качестве промежуточного звена еще одну демо-версию из числа платных программ, (Tunneler OPC DA Client) она начинает вытягивать теги, выводя в процессе их список и затыкивается в одном и том же месте выводя вместо GetItem список тегов в одну строку.

Пока я маленько в недоумении, будто сам OPC-сервер сломан.

[MuadDib]

Пока я маленько в недоумении, будто сам OPC-сервер сломан.

Скорее всего, так оно и есть. Стандарты OPC жестко задают интерфейс и регламентируют поведение OPC-сервера, но за конкретную реализацию отвечает производитель софта. В вашей скаде что-то идет не так при обращении к какому-то функционалу OPC. "Идущий с самой dOPC простенький клиент", видимо, проблемный функционал просто не использует, а остальной ваш софт (run-time и design-time части вашего компонента в Дельфи, Tunneler OPC DA Client) обращаются к этой фиче и вызывают undefined behavior.

Варианты у вас такие:
1. Выяснить, что конкретно работает не так в вашем сервере и попытаться сконфигурировать ваш компонент Delphi так, чтобы проблемная часть функционала не была задействована. Готового рецепта, как это сделать, дать не могу. Возможно, в диагностике помогут утилиты для тестов на соответствие стандарту от OPC foundation. Есть ли в принципе у вашего Delphi компонента возможность что-то поменять я тоже не знаю.
2. Написать собственный OPC-клиент. Delphi умеет в COM, а для работы с "классическим" OPC больше ничего не нужно. Раз "идущий с самой dOPC простенький клиент" работает, значит работать с вашим сервером можно. Скорее всего, для вас это будет самый простой вариант, поскольку для разборок по варианту 1 вам в любом случае придется досконально разбирать, как идет процесс взаимодействия между клиентом и сервером и, скорее всего, все равно понадобится писать какие-то тестовые клиенты для прямой работы с COM интерфейсом сервера.

[MuadDib]

Вдогонку, еще один вариант:
3. Судя по сайту, Kassl dOPC поставляют полный исходный код своего компонента. Поэтому, возможно, самый эффективный способ поиска проблемы - отдебажить ситуацию с зависанием при подключении. Когда будет понятно, где конкретно процесс спотыкается, можно будте придумать, как это побороть.

[NewOrdered]

в качестве прокладки

FSGateway ?

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

1200px-FS_Gateway.png

[Beltar]

Судя по сайту, Kassl dOPC поставляют полный исходный код своего компонента.

При добавлении OPC-итема в группу (он требует создать хотя бы одну) компонента. Т. е. можно получить от сервера список тегов, но при попытке начать работать с ними, происходит сбой. Почему работает dOPC Explorer, который только это и делает, что получает от сервера список тегов и позволяет посмотреть значение, загадка. Я долго ковырялся, может у библиотеки есть какой-то еще способ работы, и dOPc Explorer использует именно его, но ничего не нашел. Вариант, он написан на Builder'е, но ЕМНИП сами компоненты, чтобы они и в Delphi, и в Builder'е работали надо только на Паскале писать. Т. е. библиотека д/б та же. Или не та же... какой-нибудь приватный билд с доп. настройками.

Я не поленился под дизассемлером до сбоя дойти, разумеется, в стене асма я ничего не пойму, но хотя бы стек вызовов посмотреть, где-то в OLE32.dll крашится. Но это мне не сильно помогает, да и Win7 там обновляется. Скорее всего, этот файл не виноват.

FSGateway ?

Ну попытка не пытка. Хотя я уже дважды пытался воткнуть конвертер. Было бы, конечно, хорошо, если утилита умеет в диагностику. Возможно, те проги, что я пробовал, тоже что-то умеют, но либо это недоступно в демо-версиях, либо я просто не нашел.

Вообще, есть еще вариант, попробовать DDE, хотя не хочется. Или вообще брать с контроллера, он там стандартный, но надо дождаться, пока АСУТП'шники сделают хотя бы стенд, и в нем может не быть тегов с названиям рецептов.

[MuadDib]

Beltar, спускаться до уровня OLE32.dll нет смысла. С точки зрения клиента (вашего приложения) OPC-сервер - это набор COM интерфейсов, а Kassl dOPC - это обертка (wrapper) для этих интерфейсов. Структура интерфейсов жестко задана спецификацией OPC DA, а реализация источника ваших данных целиком на совести производителя вашей скады (eMation Wizcon - честно говоря, не знаю что это за софт). Виндовая инфраструктура типа OLE32.dll отвечает лишь за связь между вашим клиентом и существующим сервером. Ее можно считать заведомо рабочей.

Поэтому, если вы хотите разобраться в ситуации, для начала вам надо понять, что конкретно делает ваше приложение с COM интерфейсами сервера и на каком вызове функции через COM возникает трабла.

Я долго ковырялся, может у библиотеки есть какой-то еще способ работы, и dOPc Explorer использует именно его, но ничего не нашел.

Не знаю, что вы имеете в виду под библиотекой, но если речь идет об OPC интерфейсе, то да, есть два основных способа получения данных через OPC:

4.2.8 Asynchronous vs. Synchronous Interfaces
Assuming that most clients want to access Cached data, there are several ways for a client to obtain that data from a server.
• It can perform a synchronous read from cache (simple and reasonably efficient). This may be appropriate for fairly simple clients that are reading relatively small amounts of data and where maximum efficiency is not a concern. A client that operates in this way is essentially duplicating the ‘scanning’ that the server is already doing.
• It can ‘subscribe’ to cached data using IOPCDataCallback.. This is the recommended behavior for clients because it will minimize use of CPU and NETWORK resources.

По вашему последнему посту у меня сложилось впечатление, что у вашего сервера работает синхронное чтение (поэтому "простой" клиент не крашится), а с подпиской какие-то проблемы. Но чтобы в этом убедиться, надо понимать, что происходит на уровне COM интерфейсов, см. выше.

Вообще, есть еще вариант, попробовать DDE, хотя не хочется.

Нормальный вариант. Если с OPC серьезные проблемы, то почему бы и нет.

[MuadDib]

(Tunneler OPC DA Client) она начинает вытягивать теги, выводя в процессе их список и затыкивается в одном и том же месте выводя вместо GetItem список тегов в одну строку.

У меня еще вот этот момент вызывает сомнения. Походу получение от сервера списка тэгов тоже работает как-то не так...