Здравствуйте, 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 смотреть
Можно, хотя это не есть хорошо. На компе может быть нет никакой базы.
