Здравствуйте.
Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
не уверен насчет порки, но на универсальный сервер я бы посмотрел. не очень понимаю как он может быть универсальным.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте. А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Попороть наверно навряд ли, а вот тема интересная. Можете поподробнее рассказать — у вас конкретный OPC сервер или компонента для разработки серверов?
" Аноним " <0@users.rsdn.ru> wrote in message news:2121934@news.rsdn.ru... > Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Сервера в принципе интересны, но что такое ОРС?
Posted via RSDN NNTP Server 2.0
Re[2]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
22.09.06 07:46
Оценка:
Здравствуйте, ov, Вы писали:
А>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
ov>не уверен насчет порки, но на универсальный сервер я бы посмотрел. не очень понимаю как он может быть универсальным.
Естественно необходим драйвер для работы с конкретным устройством (DLL), но в драйвере необходимо реализовать лишь физический обмен с устройством (в нужное место пакета подставить маршрут, команду, данные (все это доставляет сервер) и передать каким-либо образом в устройство. Формирование данных для драйвера происходит уже в сервере при помощи скриптов (Pascal). Пример: имеем устройство которое выдает два параметра — температуру, давление. Создаем шаблон этого устройства — добавляем в него два тэга "Температура", "Давление", у этих тэгов имеются обработчики событий "При чтении тэга", "При записи в тэг", в этих обработчиках формируем массив байтов данных (физический) который необходимо передать в драйвер. После подачи команды, драйвер возвращает массив от устройства и этот массив так же обрабатывается в скрипте (происходит присвоение данных нужному тэгу). Когда у нас готов шаблон, в сервере мы можем добавить несколько однотипных устройств, присвоив им написанный нами шаблон и драйвер, по которому мы хотим общаться с устройством. Когда же мы захотим изменить канал обмена с устройством, (был RS232, стал TCP\IP) мы лишь должны написать новый драйвер обмена, а шаблон остается прежним. Вот примерно так.
ov>>не уверен насчет порки, но на универсальный сервер я бы посмотрел. не очень понимаю как он может быть универсальным. А>Естественно необходим драйвер для работы с конкретным устройством (DLL), но в драйвере необходимо реализовать лишь
я с этой темой сталкивался года два назад и уже тогда намечалась тенденция, что производители умных железок сразу делали ОРС-сервера для своего оборудования. ОРС тогда становился стандартом. процесс повернулся вспять? иначе зачем делать такой сервер
Re[4]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
22.09.06 07:57
Оценка:
Здравствуйте, ov, Вы писали:
ov>>>не уверен насчет порки, но на универсальный сервер я бы посмотрел. не очень понимаю как он может быть универсальным. А>>Естественно необходим драйвер для работы с конкретным устройством (DLL), но в драйвере необходимо реализовать лишь
ov>я с этой темой сталкивался года два назад и уже тогда намечалась тенденция, что производители умных железок сразу делали ОРС-сервера для своего оборудования. ОРС тогда становился стандартом. процесс повернулся вспять? иначе зачем делать такой сервер
Есть множество организаций где используется свое оборудование, т.е. сервер расчитан в основном на нестандартные протоколы обмена. Так же он позволяет объединять разнотипные устройства.
Re[2]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
22.09.06 08:00
Оценка:
Здравствуйте, wellwell, Вы писали:
W>" Аноним " <0@users.rsdn.ru> wrote in message news:2121934@news.rsdn.ru... >> Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
W>Сервера в принципе интересны, но что такое ОРС?
OPC — OLE for Process Control Стандартный интерфейс обмена между оборудованием и СКАДА системами
Здравствуйте, Severn, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте. А>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
S>Попороть наверно навряд ли, а вот тема интересная. Можете поподробнее рассказать — у вас конкретный OPC сервер или компонента для разработки серверов?
Насчет возможностей написал выше
А>Есть множество организаций где используется свое оборудование, т.е. сервер расчитан в основном на нестандартные протоколы обмена. Так же он позволяет объединять разнотипные устройства.
Народ старается не заморачиваться и часто обходится DDE. Я например.
А задача действительно распространена — например подключить дешёвые приборы фирм
типа owen. Может быть вам стоит (если будете выходить на российский рынок) написать
для таких приборов готовых библиотек связи? Для Owen есть их сосбтвенная стандартная
DLL, так что можно подцепиться. Если что — могу немного погонять (т.к. в своих
проектах предпочитаю использовать более, имхо, предсказуемый DDE). В общем если
интересно — обращайтесь.
Да — у вас конкурент есть — Lectus OPC (или как там его). Продаёт что-то похожее,
только я встречал минимум один не очень хороший отзыв (одна из причин использования
мною DDE ).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
25.09.06 05:42
Оценка:
Здравствуйте, Severn, Вы писали:
S>Здравствуйте, XShura, Вы писали:
XS>>Здравствуйте, Severn, Вы писали:
XS>>Насчет возможностей написал выше
XS>>Только что зарегистрировался.
S>OPC UA случаем не используете?
мы не входим в OPC Foundation (пока по крайней мере.... кстати сильно ли это влияет на продажи ?), поэтому документашка по UA недоступна, сейчас они всю документашку прикрыли...
Здравствуйте, azzx, Вы писали:
A>Здравствуйте, <Аноним>, Вы писали:
А>>Есть множество организаций где используется свое оборудование, т.е. сервер расчитан в основном на нестандартные протоколы обмена. Так же он позволяет объединять разнотипные устройства.
A>Народ старается не заморачиваться и часто обходится DDE. Я например.
A>А задача действительно распространена — например подключить дешёвые приборы фирм A>типа owen. Может быть вам стоит (если будете выходить на российский рынок) написать A>для таких приборов готовых библиотек связи? Для Owen есть их сосбтвенная стандартная A>DLL, так что можно подцепиться. Если что — могу немного погонять (т.к. в своих A>проектах предпочитаю использовать более, имхо, предсказуемый DDE). В общем если A>интересно — обращайтесь.
подумаю
A>Да — у вас конкурент есть — Lectus OPC (или как там его). Продаёт что-то похожее, A>только я встречал минимум один не очень хороший отзыв (одна из причин использования A>мною DDE ).
насколько я помню, в Lectus все завязано на COM технологии, я же старался, чтобы разработчику нужно было писать лишь тривиальный код (без потоков, без COM) т.е. на уровне A:=B
Здравствуйте, XShura, Вы писали:
XS>насколько я помню, в Lectus все завязано на COM технологии, я же старался, XS>чтобы разработчику нужно было писать лишь тривиальный код (без потоков, без COM) т.е. на уровне A:=B
Не разбирался — совершенно не впечатлило первое знакомство.
Кстати, одна из причин использования DDE заключается в том, что основная,
используемая нами, SCADA-система — это InTouch. Там "родного" OPC нет — всё делается через
специальный клиент — OPC Link. А с DDE он умеет работать напрямую. Да и вообще — кто-нибудь
знает способ ОФИЦИАЛЬНО получить описание соответствующих интерфейсов и т.д.? Платить
денюжку не предлагать.
А DDE — реально свободный для использования стандарт. Хотелось бы как-то получить описание
SuiteLink, но там вообще всё глухо. Не понимаю я почему Wonderware его прячет, при наличии
конкурента в виде OPC.
Я думаю тут больший интерес представляют специализировнные сервера.
Хотя написать сервер полностью соответствующий спецификации довольно таки геморойно....
А>Здравствуйте. А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте. А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
DA, HDA, alarms поддерживаете?
есть интерес к приобретению, необходимо увидеть возможности, скорость работы, возможность расширения под наши нужды итд..
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте. А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Я мог бы попороть ваш OPC в ближайшие две недели, шлите на remote . developers @ гмайл .com
Здравствуйте, ironwit, Вы писали:
А>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт? I>DA, HDA, alarms поддерживаете? I>есть интерес к приобретению, необходимо увидеть возможности, скорость работы, возможность расширения под наши нужды итд..
тааакс, чувствую пора нашу скаду на рынок выкатывать
Здравствуйте, Relayer, Вы писали:
R>Здравствуйте, ironwit, Вы писали:
А>>>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт? I>>DA, HDA, alarms поддерживаете? I>>есть интерес к приобретению, необходимо увидеть возможности, скорость работы, возможность расширения под наши нужды итд..
R>тааакс, чувствую пора нашу скаду на рынок выкатывать
показывай
а то меня уже этот трэйс мод просто замучил
... << RSDN@Home 1.2.0 alpha rev. 655>>
Я не умею быть злым, и не хочу быть добрым.
Re: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
02.10.06 14:21
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте. А>Я являюсь разработчиком универсального 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, где на каждого подключившегося клиента создается отдельный поток)
ну а если есть более конкретные вопросы, то давайте по почте поговорим
Re[8]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
04.10.06 08:20
Оценка:
Здравствуйте, 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 будет ненамного проще, хотя для простых протоколов ( имеется ввиду если мониторится порядка едениц -десятка параметров) наверное вполне и подойдет.
Re[2]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
04.10.06 09:37
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте. А>>Я являюсь разработчиком универсального 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. Если надо, могу скинуть, напишите мне на почту в инфо.
Здравствуйте, 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.
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, Виктор Юров, Вы писали:
XS>в DLL для LightOPC надо реализовывать не только физический обмен с устройством, но и формирование всей логики опроса (списки тэгов,формирование пакетов команд, очереди опроса), и это все приходится проделывать заново если добавляется новое устройство, у которого допустим протокол такой же, а параметры и команды, необходимые для формированя значений тэгов совсем другие. Т.е. написание драйвера для LightOPC не совсем простая задача, здесь нужно иметь представление о потоках, их синхронизации и т.д. Я же напротив упростил насколько можно требования к драйверу, который общается непосредственно с устройством. Вся же логика опроса, формирование данных для опроса, взаимодействие разных устройств (разных протоколов) я реализовал в самом сервере. Разработчик при работе с моим сервером столкнется лишь с написанием тривиального кода для скриптов.
Конечно все зависит от реализации, ИМХО за тривиальный код придется заплатить быстродействием. Также должна быть какая-то среда для написания тривиального кода с отладчиком и всеми вытекающими. Надеюсь, она у Вас есть? А как обстоят дела с хитроумными устройствами, которые работают через COM, USB, LPT?
XS>Насчет Compliance Test. XS>Мы не входим в OPC Foundation, поэтому я скажу так — я бы не стал выходить с сервером на широкую публику, если бы не был уверен о полном соответствии со стандартом OPC DA 2.05
А как Вы определили это соответствие?
XS>я расчитываю на тех клиентов, у которых есть так скажем "зоопарк" различного железа с нестандартными протоколами.
Ваши партнеры прежде всего — это системные интеграторы, которые занимаются разработкой АСУ. Владельцы "зоопарка" — это крупные предприятия, а на них редко встретишь специалистов, которые вообще что-то понимают в программировании (даже тривиальном).
Искренне Вам желаю удачи в продвижении. Она Вам ой как потребуется.
Каждый человек стоит столько, сколько стоит то, о чем он хлопочет.(с) Народная мудрость.
Здравствуйте, Виктор Юров, Вы писали:
ВЮ>Здравствуйте, XShura, Вы писали:
XS>>Здравствуйте, Виктор Юров, Вы писали:
XS>>в DLL для LightOPC надо реализовывать не только физический обмен с устройством, но и формирование всей логики опроса (списки тэгов,формирование пакетов команд, очереди опроса), и это все приходится проделывать заново если добавляется новое устройство, у которого допустим протокол такой же, а параметры и команды, необходимые для формированя значений тэгов совсем другие. Т.е. написание драйвера для LightOPC не совсем простая задача, здесь нужно иметь представление о потоках, их синхронизации и т.д. Я же напротив упростил насколько можно требования к драйверу, который общается непосредственно с устройством. Вся же логика опроса, формирование данных для опроса, взаимодействие разных устройств (разных протоколов) я реализовал в самом сервере. Разработчик при работе с моим сервером столкнется лишь с написанием тривиального кода для скриптов. ВЮ>Конечно все зависит от реализации, ИМХО за тривиальный код придется заплатить быстродействием.
С этим согласен. Но для тех задач с которыми нам приходится сталкиваться этого быстродействия вполне достаточно, основное время уходит на обмен с устройством нежели на обсчет данных в скриптах.
Также должна быть какая-то среда для написания тривиального кода с отладчиком и всеми вытекающими. Надеюсь, она у Вас есть?
Естественно!
А как обстоят дела с хитроумными устройствами, которые работают через COM, USB, LPT?
Не понял вопроса....
Вся работа по обмену идет в драйвере DLL, т.е. для сервера без разницы откуда драйвер получил данные.
XS>>Насчет Compliance Test. XS>>Мы не входим в OPC Foundation, поэтому я скажу так — я бы не стал выходить с сервером на широкую публику, если бы не был уверен о полном соответствии со стандартом OPC DA 2.05 ВЮ>А как Вы определили это соответствие?
CTT
XS>>я расчитываю на тех клиентов, у которых есть так скажем "зоопарк" различного железа с нестандартными протоколами. ВЮ>Ваши партнеры прежде всего — это системные интеграторы, которые занимаются разработкой АСУ. Владельцы "зоопарка" — это крупные предприятия, а на них редко встретишь специалистов, которые вообще что-то понимают в программировании (даже тривиальном).
ВЮ>Искренне Вам желаю удачи в продвижении. Она Вам ой как потребуется.
XS>Также должна быть какая-то среда для написания тривиального кода с отладчиком и всеми вытекающими. Надеюсь, она у Вас есть?
XS>Естественно!
Т.е. пользователю не нужно будет покупать среду разработки (VS, Delphi и т.д.)? Эсли так, то это большой плюс.
XS> А как обстоят дела с хитроумными устройствами, которые работают через COM, USB, LPT? XS>Не понял вопроса.... XS>Вся работа по обмену идет в драйвере DLL, т.е. для сервера без разницы откуда драйвер получил данные.
Это понятно. Вы позиционируете свой Toolkit как средство быстрой, простой разработки OPC серверов различного назначения. Более того, Вы упростили (не понял пока как) написание драйвера до того уровня когда даже не нужно заботиться о создании и синхронизации потоков. Допустим, я хочу разработать OPC сервер, который обменивается какими-то данные по COM (еще хуже по USB или LPT) со специфичным устройством. Понимание потоков и их синхронизации не вызывает особой сложности в отличии от написания драйвера LPT, USB и т.д. Т.е. я хочу сказать, что для привлекательности Вашего тулкита обязательно должен быть некий framework, который облегчит непосредственно работу с устройством всеми доступными способами. Тогда действительно разработка будет выглядеть очень просто: есть, например, компонент LPT и есть компонент OPC Server, содержащий теги. Задача разработчика OPC сервера реализовать взаимодействие этих двух компонентов. ИМХО для достижения такого уровня функциональности требуется очень большая работа.
Каждый человек стоит столько, сколько стоит то, о чем он хлопочет.(с) Народная мудрость.
Здравствуйте, Виктор Юров, Вы писали:
ВЮ>Здравствуйте, XShura, Вы писали:
XS>>Также должна быть какая-то среда для написания тривиального кода с отладчиком и всеми вытекающими. Надеюсь, она у Вас есть?
XS>>Естественно! ВЮ>Т.е. пользователю не нужно будет покупать среду разработки (VS, Delphi и т.д.)? Эсли так, то это большой плюс.
Да, но драйвер (DLL) придется все равно писать на этих языках
А внутри сервера я использую Pascal Sctipt (он используется например в инсталляторе Inno Setup).
XS>> А как обстоят дела с хитроумными устройствами, которые работают через COM, USB, LPT? XS>>Не понял вопроса.... XS>>Вся работа по обмену идет в драйвере DLL, т.е. для сервера без разницы откуда драйвер получил данные. ВЮ>Это понятно. Вы позиционируете свой Toolkit как средство быстрой, простой разработки OPC серверов различного назначения. Более того, Вы упростили (не понял пока как) написание драйвера до того уровня когда даже не нужно заботиться о создании и синхронизации потоков. Допустим, я хочу разработать OPC сервер, который обменивается какими-то данные по COM (еще хуже по USB или LPT) со специфичным устройством. Понимание потоков и их синхронизации не вызывает особой сложности в отличии от написания драйвера LPT, USB и т.д. Т.е. я хочу сказать, что для привлекательности Вашего тулкита обязательно должен быть некий framework, который облегчит непосредственно работу с устройством всеми доступными способами. Тогда действительно разработка будет выглядеть очень просто: есть, например, компонент LPT и есть компонент OPC Server, содержащий теги. Задача разработчика OPC сервера реализовать взаимодействие этих двух компонентов. ИМХО для достижения такого уровня функциональности требуется очень большая работа.
Тут или вы меня не понимаете или я вас Напишу простой пример как осуществляется работа сервера...
Имеем устройство с протоколом Modbus. Разберем одну команду номер 3. Ее формат :
Запрос
Имя поля Пример
(Hex)
Адрес подчиненного 11
Функция 03
Начальный адрес ст. 00
Начальный адрес мл. 6B
Кол-во регистров ст. 00
Кол-во регистров мл. 03
Контрольная сумма --
в драйвер из сервера пойдут следующие данные : Адрес подчиненного (в формате строки), Функция (в формате строки), Массив байт [Начальный адрес ст,Начальный адрес мл.,Кол-во регистров ст.,Кол-во регистров мл.] — этот массив будет сформирован на сервере в соответствующих скриптах. В драйвере же мы эти данные как нам надо "разбрасываем" по пакету (применительно к этому примеру, еще вычисляем CRC), после этого отправляем это все в устройство (неважно по какому каналу), после принятия ответа, опять таки раскидываем пакет по принципу : Адрес, Функция, Данные, все это уходит опять в сервер, и там уже при помощи скриптов Данные раскидываются по тэгам.
Здравствуйте, Relayer, Вы писали:
R>Здравствуйте, RomashkaX, Вы писали:
RX>>А пощупать это можно в каком-нибудь виде?
R>пока еще к сожалению нет
а когда планируется, что будет можно?
может есть скриншоты или что-нибудь в этом роде, по чему можно понять какая функциональность?
Я уже 11 лет в автоматизации и приличная и удобная среда для визуализации за разумные деньги — большая проблема.
Здравствуйте, XShura, Вы писали:
XS>Тут или вы меня не понимаете или я вас Напишу простой пример как осуществляется работа сервера... XS>Имеем устройство с протоколом Modbus. Разберем одну команду номер 3. Ее формат :
XS>Запрос
XS> Имя поля Пример XS> (Hex)
XS> Адрес подчиненного 11 XS> Функция 03 XS> Начальный адрес ст. 00 XS> Начальный адрес мл. 6B XS> Кол-во регистров ст. 00 XS> Кол-во регистров мл. 03 XS> Контрольная сумма --
XS>в драйвер из сервера пойдут следующие данные : Адрес подчиненного (в формате строки), Функция (в формате строки), Массив байт [Начальный адрес ст,Начальный адрес мл.,Кол-во регистров ст.,Кол-во регистров мл.] — этот массив будет сформирован на сервере в соответствующих скриптах. В драйвере же мы эти данные как нам надо "разбрасываем" по пакету (применительно к этому примеру, еще вычисляем CRC), после этого отправляем это все в устройство (неважно по какому каналу), после принятия ответа, опять таки раскидываем пакет по принципу : Адрес, Функция, Данные, все это уходит опять в сервер, и там уже при помощи скриптов Данные раскидываются по тэгам.
Т.е. цепочка такая: Ваш OPC Server Runtime <-> Скрипты пользователя <-> Драйвер пользователя ?
Каждый человек стоит столько, сколько стоит то, о чем он хлопочет.(с) Народная мудрость.
Здравствуйте, Виктор Юров, Вы писали:
ВЮ>Т.е. цепочка такая: Ваш OPC Server Runtime <-> Скрипты пользователя <-> Драйвер пользователя ?
именно так, т.е. драйвер выполняет лишь функции траспорта данных (ну и еще могут быть дополнительные вычисления типа подсчета CRC .... хотя именно CRC можно в скрипте сделать)
Здравствуйте, Виктор Юров, Вы писали:
ВЮ>Тут кто-то говорил про Lextus. Видели мы это чудо. Написан с использованием низкокачественных дельфийских исходников здесь и работает довольно странно, но зато дешевый.
Здравствуйте, azzx, Вы писали:
A>Здравствуйте, <Аноним>, Вы писали:
А>>Есть множество организаций где используется свое оборудование, т.е. сервер расчитан в основном на нестандартные протоколы обмена. Так же он позволяет объединять разнотипные устройства.
A>Народ старается не заморачиваться и часто обходится DDE. Я например.
A>А задача действительно распространена — например подключить дешёвые приборы фирм A>типа owen. Может быть вам стоит (если будете выходить на российский рынок) написать A>для таких приборов готовых библиотек связи? Для Owen есть их сосбтвенная стандартная A>DLL, так что можно подцепиться. Если что — могу немного погонять (т.к. в своих A>проектах предпочитаю использовать более, имхо, предсказуемый DDE). В общем если A>интересно — обращайтесь.
A>Да — у вас конкурент есть — Lectus OPC (или как там его). Продаёт что-то похожее, A>только я встречал минимум один не очень хороший отзыв (одна из причин использования A>мною DDE ).
Интересно было бы узнать по подробнее о не очень хорошем отзыве.
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, azzx, Вы писали:
A>>Здравствуйте, <Аноним>, Вы писали:
А>>>Есть множество организаций где используется свое оборудование, т.е. сервер расчитан в основном на нестандартные протоколы обмена. Так же он позволяет объединять разнотипные устройства.
A>>Народ старается не заморачиваться и часто обходится DDE. Я например.
A>>А задача действительно распространена — например подключить дешёвые приборы фирм A>>типа owen. Может быть вам стоит (если будете выходить на российский рынок) написать A>>для таких приборов готовых библиотек связи? Для Owen есть их сосбтвенная стандартная A>>DLL, так что можно подцепиться. Если что — могу немного погонять (т.к. в своих A>>проектах предпочитаю использовать более, имхо, предсказуемый DDE). В общем если A>>интересно — обращайтесь.
XS>подумаю
A>>Да — у вас конкурент есть — Lectus OPC (или как там его). Продаёт что-то похожее, A>>только я встречал минимум один не очень хороший отзыв (одна из причин использования A>>мною DDE ).
XS>насколько я помню, в Lectus все завязано на COM технологии, я же старался, чтобы разработчику нужно было писать лишь тривиальный код (без потоков, без COM) т.е. на уровне A:=B
Неправда. Для написания драйверов нет необходимость в работе с COM или потоками. В dll необходимо реализовать только логику работы с устройством.
Кстати, каким образом в Вашей программе будет реализовано следующее — посылка пароля устройству перед первым обращением к устройству или в случае простоя в течении скажем 30 минут ?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте. А>Я являюсь разработчиком универсального OPC сервера. Разработка подходит к концу, и я хотел бы узнать, есть ли здесь люди, которым интересна эта тема, и которые могут попороть этот продукт?
Возможна. Поддерживается ли Modbus RTU? Если да, то шлите на nikolayСОБАКАpromkipТОЧКАru.
Здравствуйте, lectus, Вы писали:
L>Неправда. Для написания драйверов нет необходимость в работе с COM или потоками. В dll необходимо реализовать только логику работы с устройством.
Может я и неправ, давно смотрел, но что там интерфейсы используются это точно
L>Кстати, каким образом в Вашей программе будет реализовано следующее — посылка пароля устройству перед первым обращением к устройству или в случае простоя в течении скажем 30 минут ?
Ну это по всякому можно сделать .... ну например: заводим тэг "Пароль на устройство", в событии "При записи в тэг" формируем пакет из пароля и передаем в драйвер, как уж там драйвер будет поступать, это без разницы. Насчет простоя: заводим тэг "Время последнего запроса на устройство", в нем каждый раз запоминаем время обращения к драйверу, ну и потом проверяем его. Еще много можно чего придумать, т.е. это не очень сложная задача
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, lectus, Вы писали:
L>>Неправда. Для написания драйверов нет необходимость в работе с COM или потоками. В dll необходимо реализовать только логику работы с устройством. XS>Может я и неправ, давно смотрел, но что там интерфейсы используются это точно
Интерфейсы используется только общения между сервером и dll. Никакого COM.
Горорю Вам как разработчик этого программного продукта.
L>>Кстати, каким образом в Вашей программе будет реализовано следующее — посылка пароля устройству перед первым обращением к устройству или в случае простоя в течении скажем 30 минут ?
XS>Ну это по всякому можно сделать .... ну например: заводим тэг "Пароль на устройство", в событии "При записи в тэг" формируем пакет из пароля и передаем в драйвер, как уж там драйвер будет поступать, это без разницы. Насчет простоя: заводим тэг "Время последнего запроса на устройство", в нем каждый раз запоминаем время обращения к драйверу, ну и потом проверяем его. Еще много можно чего придумать, т.е. это не очень сложная задача
Понятно. Будет интересно что получится в результате
Поддержку OPC DA 3.0 не планируете ?
Кроме того пользуется спросом OPC HDA, но с этим возни много.
Здравствуйте, lectus, Вы писали:
L>Здравствуйте, XShura, Вы писали:
XS>>Здравствуйте, lectus, Вы писали:
L>>>Неправда. Для написания драйверов нет необходимость в работе с COM или потоками. В dll необходимо реализовать только логику работы с устройством. XS>>Может я и неправ, давно смотрел, но что там интерфейсы используются это точно
L>Интерфейсы используется только общения между сервером и dll. Никакого COM. L>Горорю Вам как разработчик этого программного продукта.
Ну не буду спорить, не буду
L>>>Кстати, каким образом в Вашей программе будет реализовано следующее — посылка пароля устройству перед первым обращением к устройству или в случае простоя в течении скажем 30 минут ?
XS>>Ну это по всякому можно сделать .... ну например: заводим тэг "Пароль на устройство", в событии "При записи в тэг" формируем пакет из пароля и передаем в драйвер, как уж там драйвер будет поступать, это без разницы. Насчет простоя: заводим тэг "Время последнего запроса на устройство", в нем каждый раз запоминаем время обращения к драйверу, ну и потом проверяем его. Еще много можно чего придумать, т.е. это не очень сложная задача
L>Понятно. Будет интересно что получится в результате
L>Поддержку OPC DA 3.0 не планируете ?
Планирую конечно, к тому же там не так много переделывать придется.
L>Кроме того пользуется спросом OPC HDA, но с этим возни много.
Насчет HDA не понял... насколько я могу судить, то по сравнению с DA, там намного проще... хотя я только написал тестовую прогу, которая тянет данные из базы и выдает их по запросу клиента по HDA интерфейсу.
Здравствуйте, XShura, Вы писали:
L>>Интерфейсы используется только общения между сервером и dll. Никакого COM. L>>Горорю Вам как разработчик этого программного продукта. XS>Ну не буду спорить, не буду
L>>Поддержку OPC DA 3.0 не планируете ? XS>Планирую конечно, к тому же там не так много переделывать придется.
L>>Кроме того пользуется спросом OPC HDA, но с этим возни много. XS>Насчет HDA не понял... насколько я могу судить, то по сравнению с DA, там намного проще... хотя я только написал тестовую прогу, которая тянет данные из базы и выдает их по запросу клиента по HDA интерфейсу.
Возни много в том смысле что в данный момент чаще всего для каждого устройства используется свой узкоспециализированый протокол выдачи истории. И не только в формате: запрос — ответ. Встречал протокол обмена в котором нужно периодически изменять кол-во стоп битов, четности (это в отношении COM порта)
L>>>Кроме того пользуется спросом OPC HDA, но с этим возни много. XS>>Насчет HDA не понял... насколько я могу судить, то по сравнению с DA, там намного проще... хотя я только написал тестовую прогу, которая тянет данные из базы и выдает их по запросу клиента по HDA интерфейсу.
L>Возни много в том смысле что в данный момент чаще всего для каждого устройства используется свой узкоспециализированый протокол выдачи истории. И не только в формате: запрос — ответ. Встречал протокол обмена в котором нужно периодически изменять кол-во стоп битов, четности (это в отношении COM порта)
Ну это по DA можно слить вначале в базу, а потом из базы по HDA смотреть
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, lectus, Вы писали:
L>>>>Кроме того пользуется спросом OPC HDA, но с этим возни много. XS>>>Насчет HDA не понял... насколько я могу судить, то по сравнению с DA, там намного проще... хотя я только написал тестовую прогу, которая тянет данные из базы и выдает их по запросу клиента по HDA интерфейсу.
L>>Возни много в том смысле что в данный момент чаще всего для каждого устройства используется свой узкоспециализированый протокол выдачи истории. И не только в формате: запрос — ответ. Встречал протокол обмена в котором нужно периодически изменять кол-во стоп битов, четности (это в отношении COM порта) XS>Ну это по DA можно слить вначале в базу, а потом из базы по HDA смотреть
Можно, хотя это не есть хорошо. На компе может быть нет никакой базы.
Здравствуйте, RomashkaX, Вы писали:
RX>может есть скриншоты или что-нибудь в этом роде, по чему можно понять какая функциональность?
постараемся сделать чтото типа демо-ролика
RX>Я уже 11 лет в автоматизации и приличная и удобная среда для визуализации за разумные деньги — большая проблема.
Здравствуйте, Spender, Вы писали:
S>Здравствуйте, Relayer.
S>А есть ли поддержка свойств ТЭГа в вашем OPC сервере? И если поддерживаете, то можно ли добавлять свои (которые после 5000)
Да, есть. Можно добавлять свои свойства, можно их читать как тэги (ну и естественно по IOPCItemProperties), но они пока только для чтения.
Здравствуйте, mishin, Вы писали:
M>Здравствуйте, XShura, Вы писали:
XS>>вот мой номер аськи 176606226 давайте там обсудим, если аськи нет, но ща че нить придумаем
M>а можно куда-нибудь это на время положить? M>хотелось бы немного познакомится, может придется изобретать что-то, типа велосипеда
Вы по поводу документации по OPC или по поводу демки моего сервера ?
По документации .... я честно говоря ламер в этих вопросах , если скажете как и куда залить, то залью.
По серверу... у меня еще не готова документация на него, ну и остались кое какие глюки, которые исправляю, поэтому пока демки нет. Когда будет готово,выложу сюда ссылку.
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, mishin, Вы писали:
M>>Здравствуйте, XShura, Вы писали:
XS>>>вот мой номер аськи 176606226 давайте там обсудим, если аськи нет, но ща че нить придумаем
M>>а можно куда-нибудь это на время положить? M>>хотелось бы немного познакомится, может придется изобретать что-то, типа велосипеда
XS>Вы по поводу документации по OPC или по поводу демки моего сервера ? XS>По документации .... я честно говоря ламер в этих вопросах , если скажете как и куда залить, то залью. XS>По серверу... у меня еще не готова документация на него, ну и остались кое какие глюки, которые исправляю, поэтому пока демки нет. Когда будет готово,выложу сюда ссылку.
Меня интересует пока знакомство с документацией
Она большая по объему? Может на какой-нибудь файлообменник, если не очень здоровая?
Если не влом заниматься благоворительностью, то можно было бы разбить на части и по почте
Интересно, а какже писался Ваш сервер, без документации ?
Наша контора пока присматривается к ОПЦ и поэтому сначала хотим прикинуть трудозатраты на написание собственного сервера, затем и дока понадобилась
А если надумаем готовое купить обязательно и Ваш сервер будем рассматривать в качестве варианта, тем более, что поддержка будет на русском
M>Меня интересует пока знакомство с документацией M>Она большая по объему? Может на какой-нибудь файлообменник, если не очень здоровая? M>Если не влом заниматься благоворительностью, то можно было бы разбить на части и по почте
документашки в zip : DA2= 300кб. DA3 = 4.2мег. ... давайте адрес почты, я вам скину.
M>Интересно, а какже писался Ваш сервер, без документации ?
что значит без документации ???? она у меня давно есть.
M>Наша контора пока присматривается к ОПЦ и поэтому сначала хотим прикинуть трудозатраты на написание собственного сервера, затем и дока понадобилась M>А если надумаем готовое купить обязательно и Ваш сервер будем рассматривать в качестве варианта, тем более, что поддержка будет на русском
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, mishin, Вы писали:
M>>Меня интересует пока знакомство с документацией M>>Она большая по объему? Может на какой-нибудь файлообменник, если не очень здоровая? M>>Если не влом заниматься благоворительностью, то можно было бы разбить на части и по почте
XS>документашки в zip : DA2= 300кб. DA3 = 4.2мег. ... давайте адрес почты, я вам скину.
киньте пожалуйста сюда; mishinСОБАКАamrita.ru
M>>Интересно, а какже писался Ваш сервер, без документации ?
XS>что значит без документации ???? она у меня давно есть.
Наверное я неправильво Вас понял, здесь: XS>По документации .... я честно говоря ламер в этих вопросах , если скажете как и куда залить, то залью.
Извиняюсь
M>>Наша контора пока присматривается к ОПЦ и поэтому сначала хотим прикинуть трудозатраты на написание собственного сервера, затем и дока понадобилась M>>А если надумаем готовое купить обязательно и Ваш сервер будем рассматривать в качестве варианта, тем более, что поддержка будет на русском
XS>Буду только рад, если он вас заинтересует
Я подписался на тебу, так что буду следить
Здравствуйте, mishin, Вы писали:
M>киньте пожалуйста сюда; mishinСОБАКАamrita.ru
M>>>Интересно, а какже писался Ваш сервер, без документации ?
XS>>что значит без документации ???? она у меня давно есть. M>Наверное я неправильво Вас понял, здесь: XS>>По документации .... я честно говоря ламер в этих вопросах , если скажете как и куда залить, то залью. M>Извиняюсь
я имел ввиду что я не слишком разбираюсь, как "Может на какой-нибудь файлообменник" скинуть что-либо
отправил.... вы мне отпишитесь на почту когда все придет, а то иногда письма не доходят.
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, mishin, Вы писали:
M>>киньте пожалуйста сюда; mishinСОБАКАamrita.ru
M>>>>Интересно, а какже писался Ваш сервер, без документации ?
XS>>>что значит без документации ???? она у меня давно есть. M>>Наверное я неправильво Вас понял, здесь: XS>>>По документации .... я честно говоря ламер в этих вопросах , если скажете как и куда залить, то залью. M>>Извиняюсь
XS>я имел ввиду что я не слишком разбираюсь, как "Может на какой-нибудь файлообменник" скинуть что-либо
XS>отправил.... вы мне отпишитесь на почту когда все придет, а то иногда письма не доходят.
Здравствуйте, XShura, Вы писали:
XS>Поднимаю тему. XS>Готова демо версия сервера XS> старничка http://www.integralplus.ru/inga/ XS> прямой линк http://integralplus.ru/inga/out/IngaOPCSetup.exe размер: 2256Кб (2,309,860 байт) XS>Буду рад выслушать критику, пожелания и т.д. XS>Спасибо.
XS>P.S. насчет странички пока ниче говорить не надо... это временно
че то не ощущаю никакой активности .... неужели никому неинтересен этот продукт ?
кстати, в самой программе, в окне "О программе" адрес почты, был недоступен (на сервере че то не так было), сейчас все нормально.
Re[3]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
19.12.06 21:01
Оценка:
Здравствуйте, XShura, Вы писали:
XS>че то не ощущаю никакой активности .... неужели никому неинтересен этот продукт ?
Ты бы пару иллюстрированных примеров использования сервера привел, а то таким чайникам как я непонятно что с чем едят: "IngaOPC сервер предназначен для получения данных от различных устройств и передачи этих данных клиентам, которые поддерживают стандарт OPC DA2". Я давеча "изобрел" очередной велосипед в виде универсального DDE коннектора, который также "получает данные от различных устройств и передает их клиентам, которые поддерживают стандарт ... описанный тегами". Видимо это из той же оперы?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, XShura, Вы писали:
XS>>че то не ощущаю никакой активности .... неужели никому неинтересен этот продукт ?
А>Ты бы пару иллюстрированных примеров использования сервера привел, а то таким чайникам как я непонятно что с чем едят: "IngaOPC сервер предназначен для получения данных от различных устройств и передачи этих данных клиентам, которые поддерживают стандарт OPC DA2". Я давеча "изобрел" очередной велосипед в виде универсального DDE коннектора, который также "получает данные от различных устройств и передает их клиентам, которые поддерживают стандарт ... описанный тегами". Видимо это из той же оперы?
В хелпе есть пример. Отдельно выкладывать пример работы смысла нет, т.к. в нем все завязано на действиях в редакторах сервера. Т.е. по любому нужно будет качать инсталяху сначала. А что касается принципа работы, то в данной ветке это все тоже было написано.
Re[3]: OPC сервер. Возможна ли здесь порка?
От:
Аноним
Дата:
20.12.06 21:52
Оценка:
Здравствуйте, XShura, Вы писали:
XS>че то не ощущаю никакой активности .... неужели никому неинтересен этот продукт ? XS>кстати, в самой программе, в окне "О программе" адрес почты, был недоступен (на сервере че то не так было), сейчас все нормально.
Наше предприятие комплектует оборудование собственным OPC сервером. Сервер был написан человеком со стороны примерно за два месяца. Цена вопроса не более 1000$. Да, человеку были дадены исходники какогото опенсорсного OPC и коечто из документации с www.opcfoundation.org
Здравствуйте, Аноним, Вы писали:
А>Наше предприятие комплектует оборудование собственным OPC сервером. Сервер был написан человеком со стороны примерно за два месяца. Цена вопроса не более 1000$. Да, человеку были дадены исходники какогото опенсорсного OPC и коечто из документации с www.opcfoundation.org
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, XShura, Вы писали:
XS>>Поднимаю тему. XS>>Готова демо версия сервера XS>> старничка http://www.integralplus.ru/inga/ XS>> прямой линк http://integralplus.ru/inga/out/IngaOPCSetup.exe размер: 2256Кб (2,309,860 байт) XS>>Буду рад выслушать критику, пожелания и т.д. XS>>Спасибо.
XS>>P.S. насчет странички пока ниче говорить не надо... это временно
XS>че то не ощущаю никакой активности .... неужели никому неинтересен этот продукт ? XS>кстати, в самой программе, в окне "О программе" адрес почты, был недоступен (на сервере че то не так было), сейчас все нормально.
Нда — решил вот перед новым годом отматать форум назад и посмотреть — вдруг что не прочитал в отмеченных форумах?
Вот и нашёл только что.
Имхо, вам бы стоило по новой, может быть, запостить сообщение, или написать тем, кто раньше отмечался в топике лично.
Хотя, наверное, не всем бы это понравилось? Впрочем — будет время апосля нового года — посмотрю поближе
(дома, ессно).
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, Аноним, Вы писали:
А>>Наше предприятие комплектует оборудование собственным OPC сервером. Сервер был написан человеком со стороны примерно за два месяца. Цена вопроса не более 1000$. Да, человеку были дадены исходники какогото опенсорсного OPC и коечто из документации с www.opcfoundation.org
XS>и? Я так и не понял, что вы хотели сказать то?
Скорее всего, имеется в виду, что вряд ли кто покупать будет.
Хотя, имхо, товарищ не прав — меня вот всегда от COM воротило
(да и вообще от большинства мелкмягких интерфейсов).
Так что, некоторая аудитория у продукта, наверное, есть.
Здравствуйте, azzx, Вы писали:
A>Здравствуйте, XShura, Вы писали:
XS>>Здравствуйте, Аноним, Вы писали:
А>>>Наше предприятие комплектует оборудование собственным OPC сервером. Сервер был написан человеком со стороны примерно за два месяца. Цена вопроса не более 1000$. Да, человеку были дадены исходники какогото опенсорсного OPC и коечто из документации с www.opcfoundation.org
XS>>и? Я так и не понял, что вы хотели сказать то?
A>Скорее всего, имеется в виду, что вряд ли кто покупать будет. A>Хотя, имхо, товарищ не прав — меня вот всегда от COM воротило A>(да и вообще от большинства мелкмягких интерфейсов). A>Так что, некоторая аудитория у продукта, наверное, есть.
Я основную ставку делаю как раз на то, что бы пользователь моего сервера "ушел" от COM, потоков и т.д., и сосредоточился именно на протоколе обмена с устройством, все остальное сделает сервер
Здравствуйте, Zhenya_, Вы писали:
Z_>Здравствуйте, XShura, Вы писали:
Z_>А сколько будет стоить данный OPC-сервер?
думаю около 500-550$ хотя ... тут руководство решает
Z_>Опят же цена будет: Z_>- на рабочеее место?
да
Z_>- на количество тегов?
в демо версии есть ограничение на 24 тэга. Исходил из кол-ва поддерживаемых типов данных. В рабочей версии ограничений на кол-во тэгов нет
Z_>- как-то иначе?
нет
Z_>Как-то ненаглядно выглядят типы данных. BYTE, BOOL, INTEGER и т.д. были бы нагляднее имхо
думаете надо перечислить все 24 типа ?
Здравствуйте, azzx, Вы писали:
A>Имхо, вам бы стоило по новой, может быть, запостить сообщение, или написать тем, кто раньше отмечался в топике лично.
думаю может вы и правы .. я честно признаюсь немного ламер в этих вопросах, по поводу как поступать в таких случаях
A>Хотя, наверное, не всем бы это понравилось? Впрочем — будет время апосля нового года — посмотрю поближе A>(дома, ессно).
с наступающим вас и всех кто читает !
Здравствуйте, azzx, Вы писали:
A>Нда — решил вот перед новым годом отматать форум назад и посмотреть — вдруг что не прочитал в отмеченных форумах? A>Вот и нашёл только что. A>Имхо, вам бы стоило по новой, может быть, запостить сообщение, или написать тем, кто раньше отмечался в топике лично.
а может действительно создать новую тему, в ней дать ссылку на эту ветку и там уже ссылки на сервак дать ?, как вы считаете ?
...я немного ламер в этих вопросах
A>Хотя, наверное, не всем бы это понравилось? Впрочем — будет время апосля нового года — посмотрю поближе A>(дома, ессно).
насчет нового года ... с наступающим вас и всех кто читает
Здравствуйте, XShura, Вы писали:
XS>думаю около 500-550$ хотя ... тут руководство решает
Тогда должны быть существенные плюсы по сравнению с Fastwel UniOPC. А этот сервер стоит около 165 евро.
XS>думаете надо перечислить все 24 типа ?
Считаю, что да. Для меня например не совсем понятны типы данных VT_R4 и VT_R8. Подозреваю, что это float и double
А догадаться о значении типа VT_CY вообще не предоставляется возможным. (сам программист С++ и три года опыта работы со SCADA и OPC)
Можно конечно описать все в руководстве к серверу, но зачем вводить новые сокращения для типов данных.
Можно взять обозначения из Platform SDK — Windows Data Types.
Но если ориентироваться на рядового пользователя, то лучше обыкновенные названия:
целое, битовое, действительное, булевое, строка и т.д.
Надо помнить, что разработчику dll к вашему серверу придется разрабатывать эксплуатационную документацию.
Относительно к порке:
Открытый список выбора типа данных AlwaysOnTop независимо от того в какое из приложений переключиться.
Здравствуйте, Zhenya_, Вы писали:
Z_>Здравствуйте, XShura, Вы писали:
XS>>думаю около 500-550$ хотя ... тут руководство решает Z_>Тогда должны быть существенные плюсы по сравнению с Fastwel UniOPC. А этот сервер стоит около 165 евро.
Fastwel UniOPC реализует только все интерфейсы OPC DA, в драйвере же необходимо реализовать опрос устройств- создать очереди опроса, сформировать команды, необходимые для считывания того или иного сигнала, заниматься синхронизацией потоков и т.д. У меня же все это уже реализовано в сервере. Конечно в нем нужно будет писать обработчики тех или иных событий, но это будет довольно тривиальный код, свободный от критический секций и т.д. Так же и в драйвере получается довольно простой код, но это конечно же зависит от протокола обмена (к примеру если обмен ведется по TCP/IP то в драйвере все же появятся дополнительные потоки )
XS>>думаете надо перечислить все 24 типа ? Z_>Считаю, что да. Для меня например не совсем понятны типы данных VT_R4 и VT_R8. Подозреваю, что это float и double Z_>А догадаться о значении типа VT_CY вообще не предоставляется возможным. (сам программист С++ и три года опыта работы со SCADA и OPC)
Я просто делал по документации, и включил все типы, которые заложены в ней.
Z_>Можно конечно описать все в руководстве к серверу, но зачем вводить новые сокращения для типов данных. Z_>Можно взять обозначения из Platform SDK — Windows Data Types. Z_>Но если ориентироваться на рядового пользователя, то лучше обыкновенные названия: Z_>целое, битовое, действительное, булевое, строка и т.д.
подумаю...
Z_>Надо помнить, что разработчику dll к вашему серверу придется разрабатывать эксплуатационную документацию.
Ну от этого никуда не уйдешь, и не только применительно к моему серверу
Z_>Относительно к порке: Z_>Открытый список выбора типа данных AlwaysOnTop независимо от того в какое из приложений переключиться.
исправим
кстати, чтобы проверить именно интерфейсы OPC DA, то в сервере можно добавить лишь тэги не назначая им никаких обработчиков и добавить устройство, где прописать любой драйвер (он все равно не будет использоваться). В этом случае все что пишет и читает клиент, будет сохраняться в кеше сервера.
Надо будет это в документацию внести...
Здравствуйте, XShura, Вы писали:
XS>Fastwel UniOPC реализует только все интерфейсы OPC DA, в драйвере же необходимо реализовать опрос устройств- создать очереди опроса, сформировать команды, необходимые для считывания того или иного сигнала, заниматься синхронизацией потоков и т.д. У меня же все это уже реализовано в сервере. Конечно в нем нужно будет писать обработчики тех или иных событий, но это будет довольно тривиальный код, свободный от критический секций и т.д. Так же и в драйвере получается довольно простой код, но это конечно же зависит от протокола обмена (к примеру если обмен ведется по TCP/IP то в драйвере все же появятся дополнительные потоки )
Тогда не совсем понятно как например реализовать обмен с несколькими однотипными устройствами по нескольким коммуникационным портам, например RS-232/485.
В чем кардинальное отличие от фаствеловского сервера?
В принципе организовать отдельный поток для обмена по COM-порту несложно. А по времени для программиста WinAPI наверное получится побыстрее, чем вникнуть в новый скриптовый язык.
Z_>>Надо помнить, что разработчику dll к вашему серверу придется разрабатывать эксплуатационную документацию. XS>Ну от этого никуда не уйдешь, и не только применительно к моему серверу
Я не к тому, что ваш сервер сложнее или проще в плане документирования.
А к тому, что незачем переписывать в руководство часть спецификации OPC DA или описание вариантных типов OLE.
Здравствуйте, Zhenya_, Вы писали:
Z_>Здравствуйте, XShura, Вы писали:
XS>>Fastwel UniOPC реализует только все интерфейсы OPC DA, в драйвере же необходимо реализовать опрос устройств- создать очереди опроса, сформировать команды, необходимые для считывания того или иного сигнала, заниматься синхронизацией потоков и т.д. У меня же все это уже реализовано в сервере. Конечно в нем нужно будет писать обработчики тех или иных событий, но это будет довольно тривиальный код, свободный от критический секций и т.д. Так же и в драйвере получается довольно простой код, но это конечно же зависит от протокола обмена (к примеру если обмен ведется по TCP/IP то в драйвере все же появятся дополнительные потоки )
Z_>Тогда не совсем понятно как например реализовать обмен с несколькими однотипными устройствами по нескольким коммуникационным портам, например RS-232/485. Z_>В чем кардинальное отличие от фаствеловского сервера? Z_>В принципе организовать отдельный поток для обмена по COM-порту несложно. А по времени для программиста WinAPI наверное получится побыстрее, чем вникнуть в новый скриптовый язык.
Приметр:
Квартирная сигнализация.
В каждой квартире стоит устройство (контроллер) который следит за 4мя датчиками (boolean: d1,d2,d3,d4). Создаем шаблон устройства, куда добавляем эти четыре сигнала (тэга), в скриптах формируем команды для считывания этих тэгов. Далее пишем драйвер, который сформированные команды посылает на устройство и ждет ответ от него, допустим это будет обмен по RS232, при инициализации драйвера открываем порт и т.д. Затем, в редакторе устройств, добавляем сколько нам нужно устройств (квартир), обзываем их как то и присваиваем им вышенаписанный шаблон и драйвер. Со стороны клиента адресное пространство будет выглядеть примерно так:
Квартира1\d1
Квартира1\d2
Квартира1\d3
Квартира1\d4
Если же необходимо часть устройств опрашивать по одному порту, а часть по другому, просто добавляем тот же самый драйвер, но под другим именем и так же заботимся чтобы этот драйвер открывал другой порт (ну например Ini файл). И другой части устройств прописываем уже этот драйвер. В этом случае опрос по разным драйверам будет вестись по разным потокам.
Вот примерно так.
Все эти рассуждения вполне понятны.
Вобщем, отличие вашего сервера от фаствеловского в том, что он поддерживает несколько dll в разных потоках, а не одну dll с несколькими потоками.
XS>Если же необходимо часть устройств опрашивать по одному порту, а часть по другому, просто добавляем тот же самый драйвер, но под другим именем и так же заботимся чтобы этот драйвер открывал другой порт (ну например Ini файл). И другой части устройств прописываем уже этот драйвер. В этом случае опрос по разным драйверам будет вестись по разным потокам. XS>Вот примерно так.
А вот чего нет ни у вас, ни у фаствела — это наличия интерфейса для вызова специфического диалогового окна для настройки кастомных свойств устройства.
Вот хочу я настраивать свойства подключения устройства прямо из сервера, а не через ini файл или отдельную программу
Пусть эта форма может храниться в той же dll.
Здравствуйте, Zhenya_, Вы писали:
Z_>А вот чего нет ни у вас, ни у фаствела — это наличия интерфейса для вызова специфического диалогового окна для настройки кастомных свойств устройства. Z_>Вот хочу я настраивать свойства подключения устройства прямо из сервера, а не через ini файл или отдельную программу Z_>Пусть эта форма может храниться в той же dll.
Думал об этом... более того вызов формы был, но я сознательно убрал это, т.к. тут появляется языковая привязка, т.е. вызов форм в разных языках по разному происходит.
А вашу хотелку в моем сервере можно реализовать следующим образом: пишем шаблон типа "Настройка COM порта" , в драйвере при приходе команды, проверяем поле "Номер команды", и, если в номере команды в начале к примеру будет стоять маркер '_', то интерпертируем его по особому. В шаблоне же создаем команды "Сменить скорость" и присваиваем ей номер "_Baud","Сменить порт" — номер "_NoCOM" и т.д. Затем создаем устройство "Настройка" и присваиваем ему шаблон "Настройка COM порта" .... ну вот примерно так. Теперь с клиента можно будет рулить настройками порта
Здравствуйте, XShura, Вы писали:
XS>Думал об этом... более того вызов формы был, но я сознательно убрал это, т.к. тут появляется языковая привязка, т.е. вызов форм в разных языках по разному происходит.
А почему появляется языковая привязка?
Почему не возникает таковой в функциях OpenDriver, CloseDriver, Read и Write?
Достаточно же реализовать функцию инициализации окна и функцию закрытия окна с получением кода возврата (OK, Cancel, Apply ...)
XS>А вашу хотелку в моем сервере можно реализовать следующим образом: пишем шаблон типа "Настройка COM порта" , в драйвере при приходе команды, проверяем поле "Номер команды", и, если в номере команды в начале к примеру будет стоять маркер '_', то интерпертируем его по особому. В шаблоне же создаем команды "Сменить скорость" и присваиваем ей номер "_Baud","Сменить порт" — номер "_NoCOM" и т.д. Затем создаем устройство "Настройка" и присваиваем ему шаблон "Настройка COM порта" .... ну вот примерно так. Теперь с клиента можно будет рулить настройками порта
Моя хотелка заключается в том, чтобы рулить настройками из сервера, а не из клиента.
А для руления из клиента можно добавить теги настройки устройства.
Поясню:
1. Библиотеку разрабатывает предприятие-разработчик устройства.
2. Клиентские мнемосхемы в OPC-клиенте разрабатывает предприятие-интегратор.
3. Эксплуатирует систему совсем другое предприятие
Если предприятие-разработчик внесло какие-либо дополнения или изменения в библиотеку, то нужно пройти всю цепочку dll-скрипт-мнемосхема.
Это займет некоторое значительное время (звонки, переговоры, согласования, разрешения ...)
Если внести окошко настройки в библиотеку, то процесс обновления пройдет более быстро и безболезненно.
Цепочка получится разработчик_изделия-эксплуатирующая_организация.
Z_>А почему появляется языковая привязка? Z_>Почему не возникает таковой в функциях OpenDriver, CloseDriver, Read и Write? Z_>Достаточно же реализовать функцию инициализации окна и функцию закрытия окна с получением кода возврата (OK, Cancel, Apply ...)
... типа такого — function ShowSetup:HResult; stdcall; ?
Думать надо .... чувствую что проблемы будут с этим, т.к. DLL работают во вторичных потоках и надо будет синхронизироваться при показе окна ....
Здравствуйте, XShura, Вы писали:
XS>... типа такого — function ShowSetup:HResult; stdcall; ? XS>Думать надо .... чувствую что проблемы будут с этим, т.к. DLL работают во вторичных потоках и надо будет синхронизироваться при показе окна ....
При настройке можно останавливать вторичный поток. И выполнять функцию настройки в первичном.
Здравствуйте, XShura, Вы писали:
XS>Здравствуйте, Zhenya_, Вы писали:
Z_>>А почему появляется языковая привязка? Z_>>Почему не возникает таковой в функциях OpenDriver, CloseDriver, Read и Write? Z_>>Достаточно же реализовать функцию инициализации окна и функцию закрытия окна с получением кода возврата (OK, Cancel, Apply ...) XS>... типа такого — function ShowSetup:HResult; stdcall; ? XS>Думать надо .... чувствую что проблемы будут с этим, т.к. DLL работают во вторичных потоках и надо будет синхронизироваться при показе окна ....
Есть кстати вариант вызывать настройки из DLL в формате "Имя параметра=значение" , запихивать их все в массив и отдавать серверу. Там уж я разберусь как их предоставить пользователю , а потом измененные параметры опять передать в DLL :
function GetParams(out ArrayParams:... , count:dword):HResult;
function SetParams(ArrayParams:..., count:dword):HResult;
XS>а может действительно создать новую тему, в ней дать ссылку на эту ветку и там уже ссылки на сервак дать ?, как вы считаете ? XS>...я немного ламер в этих вопросах
Думаю, модераторы не будут против.
Я бы сделал что-то вроде новой темы "тестирование ..."
В связи с релизом, бетой или что там у вас.
Здравствуйте, XShura, Вы писали:
XS>>>думаете надо перечислить все 24 типа ? Z_>>Считаю, что да. Для меня например не совсем понятны типы данных VT_R4 и VT_R8. Подозреваю, что это float и double Z_>>А догадаться о значении типа VT_CY вообще не предоставляется возможным. (сам программист С++ и три года опыта работы со SCADA и OPC) XS>Я просто делал по документации, и включил все типы, которые заложены в ней.
В принципе, раз уж тулз создаётся "для простых смертных", которым в этом копаться совершенно
не хочется — проще предусмотреть какой-то вариант хинтов или переключения названий типов
данных с человеческого на вот VT_R8 и т.д.
Правильно мотивированный программист — сродни рыцарю джедаю
