Здравствуйте, Relayer, Вы писали:

R>Здравствуйте, ironwit, Вы писали:

А>>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
I>>DA, HDA, alarms поддерживаете?
I>>есть интерес к приобретению, необходимо увидеть возможности, скорость работы, возможность расширения под наши нужды итд..

R>тааакс, чувствую пора нашу скаду на рынок выкатывать
показывай
а то меня уже этот трэйс мод просто замучил

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.
А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Интересно было бы посмотреть.. Я сам в свою очередь сделал такой сервер и даже не один . Могу поделиться своими разработками для сравнения .
Связаться со мной можно по мылу splin tut by, вставив недостающие символы

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.
А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?

Добрый день.
Что вы называете "универсальным" OPC сервером? Поподробней можно?

Здравствуйте, _KVasiliy, Вы писали:

_KV>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте.
А>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?

_KV>Добрый день.
_KV>Что вы называете "универсальным" OPC сервером? Поподробней можно?

Здравствуйте!
Универсальным я его называю потому, что при написании драйвера к нему (DLL), он может работать с любыми (теоретически) устройствами (посмотрите мой ответ (был от Аноним) в начале темы)

зы. не понял как ссылку дать на конкретный ответ ...

Здравствуйте, XShura, Вы писали:

XS>Здравствуйте, _KVasiliy, Вы писали:

_KV>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте.
А>>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?

_KV>>Добрый день.
_KV>>Что вы называете "универсальным" OPC сервером? Поподробней можно?

XS>Здравствуйте!
XS>Универсальным я его называю потому, что при написании драйвера к нему (DLL), он может работать с любыми (теоретически) устройствами (посмотрите мой ответ (был от Аноним) в начале темы)

Как на счёт .NET ? Managed Code?
Если глянуть на opcfoundation они очень целеустремленно туда движутся... Более того некоторые СКАДА системы уже полностью писаны на дод нете.
Предусмаривает ли ваш универсализм это явление.

Ну и вот вопрос вы писали
Естественно необходим драйвер для работы с конкретным устройством (DLL), но в драйвере необходимо реализовать лишь физический обмен с устройством (в нужное место пакета подставить маршрут, команду, данные (все это доставляет сервер) и передать каким-либо образом в устройство. Формирование данных для драйвера происходит уже в сервере при помощи скриптов (Pascal).

То есть каждый драйвер должен реализовывать интерфейс работы с Вашим сервером. На сколько этот интерфейс универсален? И не будет ли очень сложно его реализовывать для "теоритически любых приборов"?

_KV>Как на счёт .NET ? Managed Code?
_KV>Если глянуть на opcfoundation они очень целеустремленно туда движутся... Более того некоторые СКАДА системы уже полностью писаны на дод нете.
_KV>Предусмаривает ли ваш универсализм это явление.

нет, в данном продукте этого нет

_KV>Ну и вот вопрос вы писали
_KV>Естественно необходим драйвер для работы с конкретным устройством (DLL), но в драйвере необходимо реализовать лишь физический обмен с устройством (в нужное место пакета подставить маршрут, команду, данные (все это доставляет сервер) и передать каким-либо образом в устройство. Формирование данных для драйвера происходит уже в сервере при помощи скриптов (Pascal).

_KV>То есть каждый драйвер должен реализовывать интерфейс работы с Вашим сервером. На сколько этот интерфейс универсален? И не будет ли очень сложно его реализовывать для "теоритически любых приборов"?

интерфейс драйвера позволяет вести следующие виды обмена : запрос-ответ (например протокол Modbus), запрос-асинхронный ответ, прослушка (т.е. идут лишь пакеты от устройства), так же позволяет работу с многопоточном драйвером (ну например SocketServer, где на каждого подключившегося клиента создается отдельный поток)
ну а если есть более конкретные вопросы, то давайте по почте поговорим

Здравствуйте, azzx, Вы писали:


A>Кстати, одна из причин использования DDE заключается в том, что основная,
A>используемая нами, SCADA-система — это InTouch. Там "родного" OPC нет — всё делается через
A>специальный клиент — OPC Link. А с DDE он умеет работать напрямую. Да и вообще — кто-нибудь
A>знает способ ОФИЦИАЛЬНО получить описание соответствующих интерфейсов и т.д.? Платить
A>денюжку не предлагать.
На http://opcfoundation.org до недавнего времени сейчас незнаю были доступны для скачивания спецификации ОРС бесплатно необходимо было только зарегистрироваться

A>А DDE — реально свободный для использования стандарт
OPC более предпочтительный
. Хотелось бы как-то получить описание
A>SuiteLink, но там вообще всё глухо. Не понимаю я почему Wonderware его прячет
Наверное SuiteLink более производительный, требует меньше настроек, если клиент и сервер на разных машинах
(Для ОРС нужно конфигурировать DCOM что реально на объектах у заказчика выливается в геморой )

Для InTouch для работы с ОРС есть бесплатные дополнения FSGateway(более предпочтителен) и OPCLink. это все же лучше чем DDE

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.
А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Мое мнение лучше разрабатывать какой то специализированный ОРС сервер нежели пользоватся
толкитами или универсальным ОРС сервером (трудоемкость разработки будет ненамного выше если ОРС разрабатывать с нуля), поскольку при разработке с помощью универсального
ОРС сервера придется изучить интерфейс обмена dll устройства и универсального сервера т.е
если сервер поддерживает IOPCBrowseServerAddressSpace то его нужно будет как то конфигурировать по
dll устройства и в конечном итоге предоставлять dll устройства должна предоставлять имя тега и его хендл, что например для протокола MODBUS
разработка dll будет ненамного проще, хотя для простых протоколов ( имеется ввиду если мониторится порядка едениц -десятка параметров) наверное вполне и подойдет.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте.
А>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
А>Мое мнение лучше разрабатывать какой то специализированный ОРС сервер нежели пользоватся
А>толкитами или универсальным ОРС сервером (трудоемкость разработки будет ненамного выше если ОРС разрабатывать с нуля), поскольку при разработке с помощью универсального
А>ОРС сервера придется изучить интерфейс обмена dll устройства и универсального сервера т.е
А>если сервер поддерживает IOPCBrowseServerAddressSpace то его нужно будет как то конфигурировать по
А>dll устройства и в конечном итоге предоставлять dll устройства должна предоставлять имя тега и его хендл, что например для протокола MODBUS
А>разработка dll будет ненамного проще, хотя для простых протоколов ( имеется ввиду если мониторится порядка едениц -десятка параметров) наверное вполне и подойдет.

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

написанное выше сообщение мое.

Здравствуйте, <Аноним>, Вы писали:

А>На http://opcfoundation.org до недавнего времени сейчас незнаю были доступны для скачивания спецификации ОРС бесплатно необходимо было только зарегистрироваться

Хм... Спасибо, посмотрю ещё раз — может просто плохо смотрел... Помнится, там вопрос заключался в том,
кем регистрироваться.

A>>А DDE — реально свободный для использования стандарт
А>OPC более предпочтительный

Предпочтителен он только тем, что используется в большинстве SCADA-систем.
Хотя это и не мало, конечно.

А>Наверное SuiteLink более производительный, требует меньше настроек, если клиент и сервер на разных машинах

Недавно получил информацию из первых рук — от местного отделения Klinkmann — спецификация SuiteLink не распространяется.
Хочешь — покупай Toolkit. Насколько понимаю, работает он через TCP/IP, чем и привлекает... Но какого чёрта они
делают его закрытым — это вопрос...

А>(Для ОРС нужно конфигурировать DCOM что реально на объектах у заказчика выливается в геморой )

Дык! Да и вообще — не люблю я эту технологию. Конечно, это, скорее всего, просто мои тараканы,
но не доверяю я любым сложно замороченным вещам.

А>Для InTouch для работы с ОРС есть бесплатные дополнения FSGateway(более предпочтителен) и
А>OPCLink. это все же лучше чем DDE

FSGateway не знаю — не смотрел. Надо пошарить... А OPCLink работает, собственно, через те
же самые DDE/SuiteLink. Подозреваю, что FSGateway подключается так же.

Здравствуйте, azzx, Вы писали:

A>Здравствуйте, <Аноним>, Вы писали:

А>>На http://opcfoundation.org до недавнего времени сейчас незнаю были доступны для скачивания спецификации ОРС бесплатно необходимо было только зарегистрироваться

A>Хм... Спасибо, посмотрю ещё раз — может просто плохо смотрел... Помнится, там вопрос заключался в том,
A>кем регистрироваться.

Спецификации были доступны до недавнего времени, сейчас только для членов OPCFoundation. Если надо, могу скинуть, напишите мне на почту в инфо.

Здравствуйте, XShura, Вы писали:

XS>Здравствуйте, azzx, Вы писали:

A>>Здравствуйте, <Аноним>, Вы писали:

А>>>На http://opcfoundation.org до недавнего времени сейчас незнаю были доступны для скачивания спецификации ОРС бесплатно необходимо было только зарегистрироваться

A>>Хм... Спасибо, посмотрю ещё раз — может просто плохо смотрел... Помнится, там вопрос заключался в том,
A>>кем регистрироваться.

XS>Спецификации были доступны до недавнего времени, сейчас только для членов OPCFoundation. Если надо, могу скинуть, напишите мне на почту в инфо.

0:ОК — написал на адрес в профиле.

Здравствуйте, ironwit, Вы писали:

R>>тааакс, чувствую пора нашу скаду на рынок выкатывать
I>показывай а то меня уже этот трэйс мод просто замучил

не знаю кто тебя там замучал, но склепали мы такую вот интерестную систему: среда визуальная с обджект инспектором и встроенным событийно-ориентированным языком. может работать с любым стандартным опц сервером. скриптовый язык помимо заточенности на обработку событий имеет некоторое подобие ООП. почему подобие — ибо используется не наследование а система прототипов объектов (нечто подобное есть в некоторых экспериментальных языках).

R>Здравствуйте, ironwit, Вы писали:

R>>>тааакс, чувствую пора нашу скаду на рынок выкатывать
I>>показывай а то меня уже этот трэйс мод просто замучил

да, забыл добавить — основное назначение — визуализация техпроцессов.

Здравствуйте, Relayer, Вы писали:

R>Здравствуйте, ironwit, Вы писали:

R>>>тааакс, чувствую пора нашу скаду на рынок выкатывать
I>>показывай а то меня уже этот трэйс мод просто замучил

R>не знаю кто тебя там замучал, но склепали мы такую вот интерестную систему: среда визуальная с обджект инспектором и встроенным событийно-ориентированным языком. может работать с любым стандартным опц сервером. скриптовый язык помимо заточенности на обработку событий имеет некоторое подобие ООП. почему подобие — ибо используется не наследование а система прототипов объектов (нечто подобное есть в некоторых экспериментальных языках).
example please

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.
А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?

Я занимаюсь разработкой ПО верхнего уровня систем АСУ электрической части, С OPC работаю
довольно длительное время (более 5 лет).

Есть совершенно нормальный и бесплатный Toolkit — это LightOPC, который поставляется с исходным кодом (код написан допольно неплохо). Идея там в точности совпадает с Вашей. Пишется драйвер в виде dll и прикручивается к dll сервера, Работает ОЧЕНЬ быстро и надежно (проверено лучшими OPC-водами). При несложных доработках можно сделать OPC сервер в виде сервиса. Из недостатков хочу отметить только поддержку OPC DA 2.05 (уже есть 3.0) + нужно писать конфигуратор, хотя это не всегда нужно. А чем Ваш OPC сервер лучше? Насколько он соответствует Compliance Test?

Из аналогичных toolkit'ов хочу отметить uniopc, но мы от него отказались, т.к. в наших проектах он почему-то глючил. Наиболее качественные toolkit'ы делают такие известные бренды как Softing, Matrikon. Особенно нам понравился Softing. Сделано ОЧЕНЬ качественно, но стоит дороговато (около 1.5к$).

Тут кто-то говорил про Lextus. Видели мы это чудо. Написан с использованием низкокачественных дельфийских исходников здесь и работает довольно странно, но зато дешевый.

Мое личное мнение: рынок OPC довольно насыщен и конкурировать с гигантами типа Softing и Matricon можно только в узкоспециализированных областях, а их очень мало. Как тут уже сказали, лучше разрабатывать готовые OPC сервера, которые взял и поставил. Для протокола Modbus таких серверов десятки, но качественно сделаны единицы.

Зайдите на opcconnect.com в раздел Toolkits и все станет ясно. Почти все компании там являются членами OPC foundation.

Здравствуйте, Relayer, Вы писали:

R>Здравствуйте, ironwit, Вы писали:

R>>>тааакс, чувствую пора нашу скаду на рынок выкатывать
I>>показывай а то меня уже этот трэйс мод просто замучил

R>не знаю кто тебя там замучал, но склепали мы такую вот интерестную систему: среда визуальная с обджект инспектором и встроенным событийно-ориентированным языком. может работать с любым стандартным опц сервером. скриптовый язык помимо заточенности на обработку событий имеет некоторое подобие ООП. почему подобие — ибо используется не наследование а система прототипов объектов (нечто подобное есть в некоторых экспериментальных языках).

А пощупать это можно в каком-нибудь виде?

Здравствуйте, Виктор Юров, Вы писали:

ВЮ>Я занимаюсь разработкой ПО верхнего уровня систем АСУ электрической части, С OPC работаю
ВЮ>довольно длительное время (более 5 лет).

ВЮ>Есть совершенно нормальный и бесплатный Toolkit — это LightOPC, который поставляется с исходным кодом (код написан допольно неплохо). Идея там в точности совпадает с Вашей. Пишется драйвер в виде dll и прикручивается к dll сервера, Работает ОЧЕНЬ быстро и надежно (проверено лучшими OPC-водами). При несложных доработках можно сделать OPC сервер в виде сервиса. Из недостатков хочу отметить только поддержку OPC DA 2.05 (уже есть 3.0) + нужно писать конфигуратор, хотя это не всегда нужно. А чем Ваш OPC сервер лучше? Насколько он соответствует Compliance Test?

в DLL для LightOPC надо реализовывать не только физический обмен с устройством, но и формирование всей логики опроса (списки тэгов,формирование пакетов команд, очереди опроса), и это все приходится проделывать заново если добавляется новое устройство, у которого допустим протокол такой же, а параметры и команды, необходимые для формированя значений тэгов совсем другие. Т.е. написание драйвера для LightOPC не совсем простая задача, здесь нужно иметь представление о потоках, их синхронизации и т.д. Я же напротив упростил насколько можно требования к драйверу, который общается непосредственно с устройством. Вся же логика опроса, формирование данных для опроса, взаимодействие разных устройств (разных протоколов) я реализовал в самом сервере. Разработчик при работе с моим сервером столкнется лишь с написанием тривиального кода для скриптов.

Насчет Compliance Test.
Мы не входим в OPC Foundation, поэтому я скажу так — я бы не стал выходить с сервером на широкую публику, если бы не был уверен о полном соответствии со стандартом OPC DA 2.05


ВЮ>Из аналогичных toolkit'ов хочу отметить uniopc, но мы от него отказались, т.к. в наших проектах он почему-то глючил. Наиболее качественные toolkit'ы делают такие известные бренды как Softing, Matrikon. Особенно нам понравился Softing. Сделано ОЧЕНЬ качественно, но стоит дороговато (около 1.5к$).

ВЮ>Мое личное мнение: рынок OPC довольно насыщен и конкурировать с гигантами типа Softing и Matricon можно только в узкоспециализированных областях, а их очень мало. Как тут уже сказали, лучше разрабатывать готовые OPC сервера, которые взял и поставил. Для протокола Modbus таких серверов десятки, но качественно сделаны единицы.

я расчитываю на тех клиентов, у которых есть так скажем "зоопарк" различного железа с нестандартными протоколами.


ВЮ>Зайдите на opcconnect.com в раздел Toolkits и все станет ясно. Почти все компании там являются членами OPC foundation.

Здравствуйте, RomashkaX, Вы писали:

RX>А пощупать это можно в каком-нибудь виде?

пока еще к сожалению нет