- В этой теме 21 ответ, 3 участника, последнее обновление 8 лет, 6 месяцев назад сделано
.
-
Записи
-
В настройках входящих каналов есть поле, для которого имеется возможность указать номер канала управления. Изначально я предполагал, что указав в этом поле номер необходимого канала управления, в него начнут поступать значения из соответствующего входного канала и тем самым будет происходить циклическая отправка команд необходимому КП, но по факту так не происходит. Возможно это поле используется как ключ для связки с таблицей каналов управления и имеет только информационное назначение.
Вопрос: Для чего необходимо поле номер канала управления в настройках входящего канала?
Если сделаете таблицу, то на данном входящем канале появится «Ракета» 🙂
Вызов канала управления, в котором в зависимости от настроек можно послать команду напрямую или так же через формулу.В табличном представлении сразу идет связь входящего канала и канала управления.
В схемах можно прописать отдельно канал управления, совершенно для другого входного канала.Ясно. Значит это поле задействовано в возможностях ПО для визуализации. А в функционале сервера его можно задействовать с помощью формул.
Это поле указывает какой канал управления вызвать — «Выполнить команду», а уже от наличия формулы в канале управления будет зависеть что вы сделаете с данными команды, можете просто передать Cmd (не меняя и не устанавливая формулу), а можете используя формулу переставить байты в Cmd и только потом отправить в прибор, или превратить в текст и отправить куда-то.
Тогда это совсем не то, о чем я подумал. Правильно ли я понимаю, что на основании данных поступающих во входящий канал, сгенерировать команду управления не получится? Посмотрел сейчас файл с формулами функции отправить команду КП нет.
Постфакт редактирования команды мне пока не нужен.Для автоматической отправки команд необходим Модуль автоматического управления. Из формул отправить команду не получится.
Какая у Вас стоит задача по управлению в контексте этой темы?
Я занимаюсь разработкой нового драйвера КП KpWorkflow. Если будет достаточно времени, то скоро выложу первую версию. Это будет также как и KpMQTT открытый проект. Функциональность данного КП будет позволять программировать логику различных задач при помощи декларативной разметки на базе XML. Каждый КП будет представлять из себя законченный рабочий процесс с внутренней логикой загружаемой из XML файла. Экземпляр такого КП можно например будет использовать в качестве бота следящего за технологическим процессом или осуществляющего его запуск по некоторому алгоритму с условиями и ветвлениями. Задач думаю можно придумать много.
В контексте данной темы я хотел обследовать решение по запуску необходимого рабочего процесса по команде, формируемой на основании данных поступающих во входящий канал. Но раз этот механизм в базовом функционале отсутствует, думаю пока достаточно будет ручного варианта формирования команды, основным оставлю режим цикла КП.База входных каналов по сути является аналогом ПЛК и языка LD. Я использую различные формулы для этого (Ton, Tof, Tp, Hysteresis, Scaler, Rtrig, Ftrig и т.д.) вместе с Модулем Автоматического управления позволяет управлять устройствами.
Михаил вроде планировал в скором времени доработать модуль, чтобы можно было посылать произвольные данные, а не только фиксированные.
то есть уже сейчас есть возможность задавать логику.
Опишите подробнее, что ваш модуль сможет сделать ? если тоже самое и еще придется изучать как составлять xml то есть ли в этом смысл ?
Было бы интересно рассмотреть несколько примеров применения драйвера Workflow, пока трудно представить, в каких случаях его применять.
в скором времени доработать модуль, чтобы можно было посылать произвольные данные, а не только фиксированные
Версия модуля, которая работает с каналами управления, сейчас тестируется.
Примеры будут.
КП готов уже на 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 в необходимый канал рапид скада. При вызове этого процесса произойдет остановка насоса (точнее завершится рабочий процесс с помощью которого мы эмулировали в первом приближении работу насоса). Таких эмуляций оборудования может быть столько на сколько хватит мощности той машины на которой будет установлен КП.
Понятно что в дальнейшем развитии появятся обобщенные задачи отправки почты, файлов, веб запросов и так далее что позволит придумывать гибкие алгоритмы информирования о событиях технологического процесса.
Рабочие процессы запускаемые по таймеру можно использовать в качестве агентов следящих за процессом и информирующих или выполняющих запуск других процессов по условию. Идеалистически такой процесс (агент) может запустить производство в виде одной кнопки ))).Конечно будут и минусы о них напишу в доках к проекту.
Вот бы не SFC а CFC как в CodeSys (или FBD как в Logo или ZelioLogic или OwenLogic)
Цены не было бы…
SFC не очень лучший вариант, в нем шаги могут быть зациклены.Очень интересно.
Вы не используете при реализации КП WWF?Вы не используете при реализации КП WWF?
Нет, не подошло как минимум по 2 условиям:
1. До сих пор не реализовано в моно.
2. WWF больше ориентирован на бизнес процессы документооборота.В качестве ядра я использую открытый проект Wexflow . Этот проект позволяет выполнять рабочий процесс в памяти, что очень хороше подходит для задач автоматизации.
Он модифицирвоан в части дополнительных объектов для прямого взаимодействия с Rapid Scada из задач внутри рабочего процесса. Вместо родного таймера используется цикл опроса КП. Запуск рабочих процессов типа триггер осуществляется по команде из Rapid Scada. Для каждого рабочего процесса настраивается 3 канала управления (Старт,Стоп,Пауза)
Код без документации я уже выложил на на githubПозже добавлю документацию и бинарные файлы драйвера.
- Для ответа в этой теме необходимо авторизоваться.