@atoi

Всем привет,

возникла необходимость в разработке OPC DA 2.05a сервера под .NET, среди бесплатных вариантов ничего не нашел, писать обертки под библиотеки на С/С++/Delphi - довольно сложно.

Выбор пал на реализацию от самой компании - OPC Foundation. Но тут у меня возникла проблема в непонимании, как его использовать. Устроен он следующим образом: OPC-сервер написан на С++, для работы с .NET реализована обертка (OpcDaWrapper.exe) на С++, которая запускает библиотеку, написанную на C#. С помощью Configuration tool зарегистрировал библиотеку, OPC-клиент его видит. В этой библиотеке данные генерируются автоматически, но в моей программе данные получаются от устройств, затем обрабатываются и должны передаваться по OPC (необходимо иметь возможность добавлять/удалять как items, так и groups). И тут я совершенно не понимаю, каким образом осуществляется взаимодействие между оберткой и библиотекой на .NET (т.е. как добавить группу/элемент, обновить значение)?

Добавлено через 2 часа 59 минут
Кажется, кое-что нашел, это inproc-сервер, но по-прежнему остается непонятным, как использовать его в C#

Добавлено через 22 часа 15 минут
Долго думал и кажется понял - весь функционал должен быть реализован в DLL-файле (так устроены in-proc opc-серверы). Кто-нибудь может подтвердить, что я правильно понял? Если все так, то каким образом можно реализовать интерфейс для добавления новых устройств и редактирования их параметров?

0

@Voland_

OPС-сервер может быть выполнен в каком угодно формате. Главное, чтобы он представлял собой COM-сервер, который бы имел к себе доступ через COM/DCOM. Сам форм-фактор не имеет значения.

вы уже сами ответили на свой вопрос. Нужно организовать COM-интерфейс для добавления и редактирования. То есть он должен обеспечивать эти функции при подключении к нему. Но я, допустим, делал это через файлы конфигурации и/или таблицы баз данных. То есть вы просто правите базу, а сервер самостоятельно организуется, в соответствии.

По поводу "на чем писать" - вопрос риторический. Если вы не сильны в С++ или Дельфи, то может ну его нафиг, с OPC-сервером? Ведь задача на самом-то деле непростая, потому что для него нужно много чего понимать, чтобы написать правильно. Обычно сервера поддерживают несколько типов запросов, и должны существовать в тандеме с хранилищем актуальных данных.

0

@atoi

Voland_, согласен, что задача непростая, но мы же не боимся трудностей
Вопрос с выбором языка не стоит, это должен быть C#, а то, что я не силен в C++ или Delphi, то это ничего не значит, благо под .NET есть много коммерческих решений, тот же OPC Foundation предоставляет возможность создания in-proс-сервера на C#.
Если использовать конфигурационный файл, то для того, чтобы добавить новую группу/элемент, нужно перезапустить OPC-сервер? Вы использовали OPC-сервер от OPC Foundation?

0

@Voland_

нет, я использовал проект sOPC на сях и Дельфи и переделывал его под свою задачу. Дополнял еще несколько фич. Для серверов конфиг-файл - не очень интересное решение. Лучше использовать либо реестр, либо какой-то самописный COM-интерфейс для запуска сервера. В общем, что-то стандартизованное в системе, ибо при работе и запуске сервера есть ограничения по работе с файлами - сервер должен знать, где находятся его конфиг.данные, то есть откуда нужно их брать.

я не помню ньюансов добавления/удаления тэгов - кажись, такое присутствует. Но другое дело - вы же понимаете, что список тэгов, например, как и количество и имена таблиц в СУБД должно быть постоянным и неизменным? В сервере, по-моему, тэги так и добавляются - сначала формируется дерево "адресов" тэгов, а потом в этом "дереве" при запуске регистрируются тэги, доступные к доступу. Так что добавлять, получается, можно и "на ходу".

0

@Витальич

Я пользовался Lectus http://lectussoft.com/opcserver.html достаточно не дорогое решения (2 OEM лицензии честно купил). Когда возможностей перестало хватать перешел на SDK от Prosys и Builder C++ Правда лицензия дороговата (более 3000$), но доволен.
а мне всегда удобней было в файлах хранить.
а зачем? OPC сервер стартует автоматически при подключении клиента даже удаленного
Мой да, нормально написанный нет
.

1

@Voland_

речь шла немного не об этом, а о запуске сервера - определения того, с каким набором данных он должен работать.
А насчет того что вы написали - это зависит от настроек COM/DCOM-сервера. И по большому счету, разработчики отключают это возможность, потому что в общем случае непонятно, с какой конфигурацией нужно работать OPC-серверу.
Наприме, у вас на компе лежит с десяток файлов конфигураций, а работать-то должна какая-то конкретная, правда? В других системах, базированных на TCP/IP это решается номером открытого порта. А вот как разделять конфиги и серверы через COM/DCOM - я не знаю.
К тому же у COM-сервера нет закрепленной текущей папки. И inproc-севрер ( в виде DLL или OCX ) цепляется к процессу, который его вызвал. Соответственно, текущая папка, из которой можно было прочитать конфиг - изначально не определена, и этот конфиг надо как-то установить в OPC-сервере, чтобы он начал работать. Вот и я и сказал за "какой-то кастомный COM-интерфейс", через который можно было бы указать что-то, что позволит серверу самоопределиться.

0

@Витальич

Честно говоря не сталкивался с такой ситуацией, у меня всегда были решения с жесткой конфигурацией и её изменение были возможны только "наладчиками" системы.

0