Здравствуйте, 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 и т.д.
