- В этой теме 31 ответ, 5 участников, последнее обновление 1 год, 3 месяца назад сделано
.
-
Записи
-
Тут собственно возродилась одна идея, но пока нет понимания ее реализации.
Реализация будет в виде Модуля, настройки там и т.д.
НО, нужно чтобы модуль напрямую мог взаимодействовать с плагином.
1. Учитывая, что Web часть может стоять отдельно от Серверной
2. Библиотеки располагаются в разных папках системы.Так же понадобятся кнопочки, текстовые поля для ввода и прочее на web, аналогично тому, что будет реализовано в модуле на WinForms
При этом не очень хотелось бы делать реализацию обмена данными между ними собственную, а хотелось бы задействовать механизмы самой Scada
Какие есть идеи и возможности для реализации?
Глупые замечания:
>>модуль напрямую мог взаимодействовать с плагином
Именно модуль взаимодействует с плагином, а не наоборот?>>хотелось бы задействовать механизмы самой Scada
Тогда по такому принципу нужно, чтобы теги Scada являлись настройками плагина.
По типу
Тег ModSystemSettingsColor — #FFFFFF
Тег ModSystemSettingsSize — 16То есть теги хранят, отдают и записывают в себя настройки и значения.
Модуль вроде с плагином не связан. Так как модули устанавливаются в папку Сервера, а плагины в папку Web, который может быть развернут на другом ПК.
Взаимосвязь только через Сервер, через каналы предположим. Нужна прямая связь, так как каналы лишнее.
Предположим у меня есть конфиг файл модуля в котором все настройки, в том числе и глобальные. Мне нужно из плагина менять часть настроек в своем конфиг файле.
Нужно реализовать что-то типа DrvDSBasic — типа какой-то промежуточный механизм, который позволит связывать ModMyMode и PlgMyPlg и позволять обмениваться данными.
Так же плагин должен читать конфиг модуля для отображения нужной информации.
Вся логика будет в модуле. Плагин — отображение и изменение.>>какой-то промежуточный механизм
>>не очень хотелось бы делать реализацию обмена данными между ними собственнуюНу это противоречит как бы друг другу. 🙂
Михаил скажет, что есть ScadaClient, а другого функционала нет.
Поэтому я и предложил конфиг хранить в тегах т.к.
— Модуль всегда находится там где сервер и видит все его теги.
— Web всегда видит теги сервера, как и его значения.
— А вот плагин может через ScadaClient обратиться к тегам не важно, где находится Server.Тут основной вопрос какая стоит задача? Возможно достаточно уже существующего функционала и не нужно заново изобретать велосипед. В плагине Вы по сути реализуете собственный бэкэнд, который взаимодействует с сервером, а сервер в свою очередь с модулем. Цепочку обмена данными можно построить, вопрос в конкретной задаче и от этого зависит как сделать проще.
У меня похожая идея тоже есть, пока отложена в долгий ящик :). Суть в том, что и плагин и модуль читают один конфиг, по которому плагин отрисовывает схему, а модуль производит расчеты и кладет данные в расчетные каналы. Чем-то похоже на визуальное программирование контроллера, но задача другая.Мне надо, чтобы плагин не был бэкендом, а использовал и изменял работу бэкенда модуля.
У Михаила есть протокол обмена данными между приложениями, даже описание его.
Интересует возможность его использовать между моим плагином и моим модулем.
Например модуль, запускает открывает порт 10001, а плагин обращаясь к Агенту запрашивает данные через данный порт, Агент кидает данные в Сервер, тот видит кому предназначены данные отправляет сразу в модуль и возвращает ответ.Вот примерный механизм, который я хочу получить и есть ли такая возможность в Сервере или в Агенте текущем, то есть обернуть свои данные с указанием для кого, все это завернется в протокол обмена между Scada Приложениями?
>>модуль, запускает открывает порт 10001
Если модуль поднял TCP-сервер, то в любом случае, вы придумываете свой протокол, по какому принципу и как вы парсите поступаемые данные и каким способом плагин их будет разбирать.
Это и есть по сути протокол. 🙂Просто ваш протокол будет проще, чем у Михаила, где он обрабатывает нюансы и вам их реализация как бы не совсем нужна.
Вот распарсить
[команда][tagname][значение]
на вашем протоколе будет проще. 🙂Я имею ввиду не совсем изобретение протокола, а возможность использовать существующий в Scada, который есть для общения между приложениями.
@romiros уже подсказал методы обмена файлами между web и сервером. Вероятно это подойдёт.
Ну и парсить мне собственно ничего не надо, я так же могу сериализацией создавать xml и передавать их.
Просто мне надо гонять туда сюда данные, которые в каналы особо не запишешь, так как они всегда меняются.Сервер и клиенты (Вебстанция) взаимодействуют по протоколу, который описан по ссылке. Следовательно, использовать встроенные механизмы Rapid SCADA можно в рамках этого протокола. Если его недостаточно, то потребуется как-то ещё общаться.
Вот. нет там таких понятий как
Отправить данные(файл) Получателю (тут модуль, драйвер, плагин)
Получить данные(файл) от Источника (тут модуль, драйвер, плагин)Есть доступ к event, данным каналов.
Ну вот есть File operations — но так пониманию без указания кому и от кого.
Возвращаясь к вопросам.
1. кого лучше делать инициатором запросов, модуль или плагин?
Если плагин, то модуль предварительно должен передать в web конфиг — как модулем переслать файл в папку storage веб сервера?
Когда плагин с ним поработает — как сказать модулю, что файл изменен и тот должен с ним работать?
Ну или в обратную сторону если модуль инициатор — как он сообщит плагину что файл обновлен?Штатными средствами через протокол это можно сделать? какую-то из комбинаций?
Модуль читает служебные теги свои из Сервера.
Плагин записывает в служебные теги изменения.
Число int или путь до нового конфига.ну там файл xml вообще.
А, типа через теги говорить получи новое?, типа перегрузись? и т.д. ?блин, это придется городить каналы дополнительные, хотелось бы обойтись без этого, чтобы не создавать почем зря каналов, там и так их может быть как грязи для программ
- Для ответа в этой теме необходимо авторизоваться.