Созданные ответы форума
-
Сообщения
-
Добавлена возможность обработки сообщений в формате JSON с помощью обработчиков, написанных на JavaScript.
Обновлена документация для драйвера KpMQTT:
https://github.com/bersim/OpenKPs/tree/master/KpMQTT
Бинарная версия драйвера KpMQTT:
https://github.com/bersim/OpenKPs/releases/download/5.0.11/KpMQTT.zip
На сколько я помню Rapid Scada оперирует значениями типа Double, ну или данными в пределах размера Double. Появились к текущему моменту строки не знаю. А если появились то надо понимать их размер. Потому что будет ограничение на длину сообщения.
Для того чтобы код который вы привели выше заработал нужно добавить пространство имен в файл который отвечает за формулы и скомпилировать проект Rapid Scada с учетом этих изменений. Не могу точно вспомнить используется ли данный файл с формулами как встроенный в проект или подтягивается при каждом запуске как исходник для компиляции с учетом формул полученных из базы конфигурации.
На мой взгляд это не лучшее решение.Предложу решение как это вижу я.
Для драйвера KpMQTT нашел библиотеку парсера JS кода. В качестве параметра в топиках указывал бы ссылку на файл с JS кодом, который будет обрабатывать входящий JSON. На выходе из JS хендлера наполнял данными 3 массива в зависимости от логики. 1 массив содержит CnlData. 2 массив содержит значения комманд. 3 массив содержит значения событий. После выхода из хендлера эти данные можно отобразить в соответствующие классы RapidScada и далее стандартными методами отправить их. Это будет гибко и вся логика останется на уровне драйвера.Если вы планируете данную функциональность разрабатывать самостоятельно, то можете посмотреть на функциональность JSONPath.
Эта функциональность используется в задаче для драйвера KpWorkflow, но там используется протокол HTTP. Разместить этот парсер в драйвер KpMQTT для еще одного типа топиков вполне возможно.Если у вас есть время подождать, то данная функциональность появится в одной из будущих версий драйвера KpMQTT.
Либо можем обговорить доработку индивидуальной версии драйвера для вашей задачи.
Опубликована новая версия драйвера KpMQTT для RapidScada 5.5.1
В новой версии добавлена возможность подписываться на топики MQTT, данные из которых передаются в команды RapidScada.
Возможно настроить 4 типа команд:
1. Стандартная команда.
2. Бинарная команда из HEX строки.
3. Бинарная команда из текста.
4. Команда внеочередного опроса КП.Ссылка на бинарный файл KpMQTT
Появилось еще 2 вопроса:
1. Один из пользователей написал на почту о том что KpMQTT не передает команду внеочередного опроса КП. Подскажите для чего нужна эта команда и нужна ли она на уровне пользователя? Мне казалось что эта команда имеет значение на уровне протокола Rapid Scada и к пользовательским данным никакого отношения не имеет.2. В продолжение темы добавления поля Номер канала управления в класс Command.сs. Если есть возможность добавить метод который бы сериализовал и десериализовал команду как массив байт в формате протокола Rapid Scada. Метод десериализации соотвественно принимает массив байт и заполняет соотвествующие поля. Такой массив байт было бы удобно отправлять и принимать напрямую через MQTT (или другие протоколы) без реализации этих методов на стороне драйвера.
Изначально меня интересовала работа именно на Raspberry PI, но для удобства если это возможно можно перенести ветку в другой раздел или могу создать тему в другом разделе.
Разработка данного драйвера происходит под Linux (Mono). Тестирование работы драйвера производится для Linux и Windows.Передача команд из RS осуществляется в параметры MQTT.
Предполагается что может быть сконфигурировано более одного параметра. Соотвественно необходимо принятые команды маршрутизировать далее в соответствующие параметры MQTT по какомуто признаку. Имено для этих целей я хотел использовать номер канала управления.
В текущей реализации в качестве такого ключа используется поле номер команды.В исходном коде клиента RS присутствует метод отправки команды с параметрами. Один из этих параметров номер канала управления. В методе этот параметр сериализуется для отправки в RS. RS принимает команду (0x06) десериализует этот номер для обработки команды на сервере и добавляет эту команду в список команд клиентов. Соответственно клиенты по (0x07) забирают команды. Мое предложение собственно было в том чтобы не терять в этом методе информацию о номере канала управления на который была отправлена команда, а сохранить для возможности обработки на клиентах.
Подскажите почему класс Command.cs не предусматривает информацию о номере канала управления, на который отправляется команда управления?
При разработке функционала отправки команд для драйвера KpMQTT возникла задача связки канала управления с внешним параметром параметром MQTT. На текущий момент сделал связку через поле Номер команды, что на мой взгляд не совсем корректно или данное поле допустимо для такого применения?Добавлена новая функция публикации стандартных и бинарных команд.
Ссылка на бинарную версию драйвера: KpMQTT для Rapid Scada 5.5.0
Первый и третий вариант понятен.
Я как раз про 2 вариантХорошо будем ждать когда появится именно TLS/SSL опция.
На счет англоязычной версии, пока не знаю. По опыту драйвера KpMQTT многих устроил перевод транслятора, вопросы были чисто технические. А также все вопросы снимались после просмотра видео документации по этому драйверу.
KpWorkflow в принципе по описанию задач англоязычный и по ядру документация также англоязычная. Ссылки на нее приведены в самом начале описания драйвера.
На текущий момент я зафиксировал версию чтобы уже можно было изучать работу драйвера.
Документация будет расширяться примерами использования.
Сейчас добавлено небольшое количество задач и только для работы с Rapid Scada.
Позже также появится видео с настройкой драйвера.Вы не используете при реализации КП WWF?
Нет, не подошло как минимум по 2 условиям:
1. До сих пор не реализовано в моно.
2. WWF больше ориентирован на бизнес процессы документооборота.В качестве ядра я использую открытый проект Wexflow . Этот проект позволяет выполнять рабочий процесс в памяти, что очень хороше подходит для задач автоматизации.
Он модифицирвоан в части дополнительных объектов для прямого взаимодействия с Rapid Scada из задач внутри рабочего процесса. Вместо родного таймера используется цикл опроса КП. Запуск рабочих процессов типа триггер осуществляется по команде из Rapid Scada. Для каждого рабочего процесса настраивается 3 канала управления (Старт,Стоп,Пауза)
Код без документации я уже выложил на на githubПозже добавлю документацию и бинарные файлы драйвера.
Примеры будут.
КП готов уже на 90%.
Пока могу описать кратко.
Функционал данного КП можно сравнить в далеком приближении с SFC в Siemens.
Соответственно перед тем как приступить к работе с таким типом КП, необходимо по другому взглянуть на автоматизацию технологических процессов.
Основная идея выстраивается из сущности рабочего процесса, которая описывается в виде XML структуры. Внутренность данной сущности разделена на 3 части.
1 раздел это заголовочная часть.
2 раздел это список задач.
3 раздел это граф исполнения задач. (Если граф исполнения отсутствует то список задач выполняется последовательно)
Вторая важная сущность, которая определят функциональное наполнение рабочего процесса это задача. В большинстве типов задач реализуется какой либо обобщенный алгоритм с параметрируемыми входами и выходами с возможностью многоразового использования. Пользователи данного КП смогут самостоятельно добавлять разработанные задачи.
Рабочие процессы по сопосбу запуска будут 3 типов.
1 тип это процессы запускаемые при первом запуске КП.
2 тип это процессы запускаемые периодически через определенный интервал времени
3 тип это процессы запускаемые по команде от сервера Rapid Scada.Теперь о типовых процессах.
1. Самый простой типовой процесс это запись каких либо значений вычисленных по формуле в RapidScada.
2. Добавим в этот рабочий процесс задачу типа ожидание. получим отправку значения в рапид скада с задержкой, указанной в задаче типа ожидание.
При параметрировании задач можно будет использовать символьные ссылки на значения каналов текущего среза.
Это что касалось задач без использования графа исполнения.
Теперь другой тип задач (в принципе каждый сам сможет придумать примеры если почитает про SFC).
При формировании графа исполнения задач будут доступны типовые конструкции if else, swith, while. Это позволит создать более сложные рабочие процессы для управления технологическим оборудованием.
3. Эмуляция работы оборудования. Например в первом приближении можно реализовать неполную эмуляцию работы насоса. Структура такого рабочего процесса может быть следующей. Сначала выполняется задача установки значения канала в 1 далее идет задача компаратор которая зациклена элементом while на состояние компаратора. внутри структруы while также добавим задачу установки значения номинального расхода насоса в канал рапид скада. (В будущем будет разработана общая задача плавного изменения при переходе от начального значения к заданному) В текущем рабочем процессе у нас происходит резкий переход на номинальное значение. Рабочий процесс будет выполняться до тех пока значение канала, на котором завязано условие компаратора не сбросится в 0. Как это сделать? Можно вручную. Но в нашем случае мы создадим другой файл рабочего процесса внутри которого разместим задачу отправки значения 0 в необходимый канал рапид скада. При вызове этого процесса произойдет остановка насоса (точнее завершится рабочий процесс с помощью которого мы эмулировали в первом приближении работу насоса). Таких эмуляций оборудования может быть столько на сколько хватит мощности той машины на которой будет установлен КП.
Понятно что в дальнейшем развитии появятся обобщенные задачи отправки почты, файлов, веб запросов и так далее что позволит придумывать гибкие алгоритмы информирования о событиях технологического процесса.
Рабочие процессы запускаемые по таймеру можно использовать в качестве агентов следящих за процессом и информирующих или выполняющих запуск других процессов по условию. Идеалистически такой процесс (агент) может запустить производство в виде одной кнопки ))).Конечно будут и минусы о них напишу в доках к проекту.
Я занимаюсь разработкой нового драйвера КП KpWorkflow. Если будет достаточно времени, то скоро выложу первую версию. Это будет также как и KpMQTT открытый проект. Функциональность данного КП будет позволять программировать логику различных задач при помощи декларативной разметки на базе XML. Каждый КП будет представлять из себя законченный рабочий процесс с внутренней логикой загружаемой из XML файла. Экземпляр такого КП можно например будет использовать в качестве бота следящего за технологическим процессом или осуществляющего его запуск по некоторому алгоритму с условиями и ветвлениями. Задач думаю можно придумать много.
В контексте данной темы я хотел обследовать решение по запуску необходимого рабочего процесса по команде, формируемой на основании данных поступающих во входящий канал. Но раз этот механизм в базовом функционале отсутствует, думаю пока достаточно будет ручного варианта формирования команды, основным оставлю режим цикла КП.Тогда это совсем не то, о чем я подумал. Правильно ли я понимаю, что на основании данных поступающих во входящий канал, сгенерировать команду управления не получится? Посмотрел сейчас файл с формулами функции отправить команду КП нет.
Постфакт редактирования команды мне пока не нужен.
