Owen Logic: методика разработки проекта
Запись от ФедосеевПавел размещена 11.10.2025 в 14:58. Обновил(-а) ФедосеевПавел 11.10.2025 в 12:33
Показов 2718
Комментарии 0
Owen Logic: методика разработки проектаВведениеПроект из статьи является иллюстративным и никогда не проверялся на практике, поэтому нисколько не удивлюсь, если на реальном объекте он не заработает без исправления ошибок в алгоритме, если вообще скомпилируется  Для эмуляции проекта потребуются изменения:
Блог ограничивает количество вложений, поэтому иллюстраций будет мало, а архивы будут содержать по несколько файлов, демонстрирующих их эволюцию. По мере выполнения небольших проектов для малой автоматизации на основе программируемых реле производства ОВЕН модели ПР205 в среде Owen Logic выработал методику, сокращающую время разработки и сводящую значительную часть работы к механическим действиям. Для представления о применимости метода приведу характеристики выполненных проектов:
Основной критерий для выбора предлагаемого метода — количество обрабатываемых неисправностей достаточно велико и неисправности неравномерно влияют на работоспособность отдельных компонентов всей системы. Если от программы не требуется обработка ошибок, не предполагается доработка функционала и нужно, чтобы программа просто работала, то эта методика будет только мешать творческому подходу. Достоинства применения этой методики, на мой взгляд:
Используемые сокращенияFBD — (Function Block Diagram) графический язык программирования стандарта МЭК 61131-3. ST — (Structured Text) язык программирования стандарта IEC 61131-3. ПР — программируемое реле. ФБ — функциональный блок в языке программирования FBD. Краткое обоснование принятых решенийЯзык разработки — FBD Среда разработки Owen Logic предлагает работу почти исключительно на языке FBD с возможностью применения ещё и языка ST в разработанных макросах (аналогах ФБ) и функциях. Язык ST в Owen Logic реализован со значительными ограничениями и играет вспомогательную роль. Поэтому на данный момент использование ST имеет смысл только в тех макросах, которые излишне сложно реализуются средствами языка FBD. Значит основным языком разработки является FBD, а ST будет (или не будет) применяться эпизодически. Отмечу, в связи с развитием возможностей различных ИИ-помощников, появилась возможность генерации кода на ST, поэтому предполагаю улучшение положения ST в Owen Logic, что приведёт к пересмотру тезиса о выборе. Именованные связи между элементами Язык FBD позволяет организовать связи между элементами двумя способами — непосредственно соединительными линиями и при помощи именованных связей (переменных). Каждый имеет достоинства и недостатки. По моему мнению следует отказаться от соединительных линий, т.к. большинство сигналов используются неоднократно (например, измеренная температура участвует и в регулировании и в защитах), что превратит холст в невнятную паутину. Значит основным способом связи элементов выбирается — именованные связи. Использование именованных связей потребует описания множества переменных. Структура программы Выбор языка FBD и организации связей приводит к идеи декомпозиции программы на разделы, каждый из которых состоит из однотипных ФБ (т.е. требуется реализация соответствующих ФБ). А также некоторой группировке переменных по признаку выхода из одного раздела для группового применения в каком-то другом (других) разделах. С учётом некоторого опыта, мне видится создание разделов:
Несколько упрощённо структура показана на рисунке. Функциональное назначение переменных разных классов Среда разработки Owen Logic имеет три класса переменных:
На мой взгляд, удобно распределить функциональное назначение переменных в программе следующим образом:
При выбранной структуре программы, стандартные переменные, связывающие перечисленные разделы группируются следующим образом:
Например, для насосной станции из двух насосов можно выделить три подсистемы — первый насос, второй насос, общие для обоих насосов. Каждая из подсистем имеет состояния, сигнализации и блокировки, полученные команды. При этом, при неисправности одного из насосов, оставшийся исправным может продолжить работу, а при неисправности в общей части независимо от состояния самих насосов — работа невозможна. Сетевые Slave переменные группируются по критериям принадлежности к той или иной функции управления или регулирования. Удобно лишь в самом начале разместить переменные текущего состояния, которые не требуют энергонезависимости, т.к. количество таких переменных почти не будет изменяться в ходе возможных доработок алгоритма. Краткое описание методикиПоследовательность разработки:
При описании стандартных переменных в части состояния, сигнализации, блокировок и команд необходимо разделение их между общими для всей системы и индивидуальными для отдельных подсистем. Т.к. влияние срабатывания блокировки различно — на всю систему или только на отдельную подсистему. Т.к. качественной группировки сетевых переменных добиться сложно — при изменении алгоритма управления изменятся или добавятся переменные состояния, которые уже не поместятся в младшую часть адресов, т.е. исходная структура будет нарушена, то группирование среди сетевых переменных не должно превращаться в самоцель. Каждый из разделов программы создаётся почти машинально — сигналы одного назначения однообразно обрабатываются, а их группировка в дереве переменных (полученная при импорте) только упрощает однообразные действия. Единственное исключение — раздел формирования предупредительной сигнализации. Пример применения методикиОбъект автоматизации — насосная станция из двух насосов, работающих на одну магистраль поочерёдно Описание объекта автоматизации и технического задания
Этот алгоритм неоднократно реализован в настраиваемых приборах множества производителей:
Для демонстрации подходов сформулируем некоторую модификацию этого алгоритма:
Схема автоматизации показана на рисунке На функциональной схеме автоматизации обозначены: Входные сигналы:
Защитные блокировки насосов:
Защитные блокировки общие для всей насосной станции:
Технологическая сигнализация:
Т.е. система содержит независимые защитные блокировки (для каждого из насосов), а также общие для всей системы Кроме того, присутствуют сигналы, не вызывающие блокировку установки, но требующие вмешательства оперативного или обслуживающего персонала. Стиль оформления проекта Стиль оформления проекта
Именование переменныхПо разным причинам принял для себя правила именования переменных. Префикс переменной обозначает источник или приёмник сигнала, тип данных:
Оформление макросов (функциональных блоков, функций)В самом верху программы или макроса размещён текстовый комментарий, содержащий краткое описание кода, автора, имя группы, которой принадлежит макрос, дату последней редакции. Стиль соединительных линий произвольный, т.к., обычно, макрос это небольшой фрагмент кода, не отличающийся высокой сложностью ни алгоритма ни связей между элементами. Описание стандартных переменных Описание стандартных переменных
Переменные можно описывать штатным способом — по одной в окне ввода переменных.
Но можно гораздо быстрее, при помощи импорта описаний переменных из подготовленного файла. Формат файла значительно отличается от версии к версии Owen Logic, а также для различных моделей ПР в рамках одной версии. При этом тип файла csv удобно редактируется в Exel (или в Calc из LibreOffice) — заполнение «протягиванием», копированием и заменой в выделенном фрагменте и пр. Не по теме: Для Exel существует удобная надстройка, позволяющая быстро выполнять групповую обработку ячеек — Ёxel, доступная по ссылке https://www.e-xcel.ru/index.php/joxcel Для этого нужно получить образец файла импорта — объявить три переменные разных типов (целочисленная, булевская, с плавающей запятой) и выполнить экспорт переменных — получить csv файл с описанием. Для Owen Logic 2.11.368.0 и ПР205 (для других версий и моделей будут отличия) пробный экспорт приведён в файле «1_1_Экспорт_переменных_для_заготовки.csv» Каждая из подсистем насосной станции (общая, первый насос и второй насос) имеет однотипные наборы данных — переменных:
Полученный csv файл открыть в Exel (или в Calc из LibreOffice) и на основе образцов объявить требуемые переменные, пока без привязки к объекту управления (просто нумерованные состояния, сигнализации и пр.). На этапе получения заготовки описаний переменных для подсистем удобно описать их с запасом. Предпочитаю резервировать переменные в количестве кратном 16 — по числу бит в одном регистре Modbus. Данная система не очень сложная, состояний не много, достаточно будет по 16 переменных. Результат предварительного определения переменных с разделением на функциональные группы показан в файле «1_2_Заготовка_для описания_переменных.csv» Далее, нужно последовательно уточнить описания, ведь алгоритм определён ещё на этапе ТЗ. Получаем окончательный файл импорта переменных. Он окончательный не только потому, что так захотелось или переоцениваю силы — повторный импорт невозможен (он не обновляет существующие переменные, а создаёт повторно с генерацией ошибок одинакового имени), так уж устроена среда разработки. Результат окончательного определения стандартных переменных показан в файле «1_3_Импорт_переменных.csv» Именно из этого файла и выполняется импорт стандартных переменных в программу. Архив содержит все три csv файла для примера — экспорт из Owen Logic, заготовка для уточнения переменных и итог обработки в Exel. 1_Импорт_Стандартных переменных.7z Создание разделов программы (кроме рабочего алгоритма) с пропуском и резервированием места на холсте для переменных состояния или параметров настройки, которые будут добавлены после описания сетевых переменных Slave Кликните здесь для просмотра всего текста
Следующий этап — набрать основную часть программы без алгоритмов работы. Также будут пропускаться обращения к переменным, которые относятся к настройкам и результатам измерения, т.к. это сетевые переменные и их ещё предстоит создать и импортировать.
Создаются разделы:
На скрине показаны разделы инициализации и обработки аналоговых выходов без части переменных, которые будут получены импортом сетевых переменных. Дополнение программы разделом рабочего алгоритма с пропуском и резервированием места на холсте для переменных состояния или параметров настройки, которые будут добавлены после описания сетевых переменных Slave Кликните здесь для просмотра всего текста
На этом этапе реализуются алгоритмы работы. Эти алгоритмы индивидуальны для каждого проекта и не поддаются формализации. Остаётся только требование — по возможности, не объявлять новые переменные состояния, а использовать незадействованные из состава слов состояния подсистемы (в данном случае первого или второго насоса, общей части). Требование нацелено на обработку в вышестоящей системе для отображения на мнемосхеме. Если его не соблюдать, то придётся копировать вновьобъявленные биты в уже существующие биты состояний. Получаем программу без сетевых Slave переменных Добавление сетевых Slave переменных Кликните здесь для просмотра всего текста
Последовательность получения файла импорта можно проследить по файлам из архива 3_Импорт_переменных_Сетевых_Slave.7z По аналогии со стандартными переменными, следует получить образец файла экспорта сетевых Slave переменных. «3_1_Экспорт_переменных_для заготовки_Сетевые, Slave.csv» По мере создания программы дополнять переменные в этот список переменных, заполняя лишь уникальные поля — имя переменной, тип, комментарий, начальное значение, диапазон изменения. В файле «3_2_Импорт_переменных_Сетевые_заготовка, Slave.csv» из архива видно, что часть полей (например, адрес) заполнена некорректно. Когда программа уже будет завершена и потребуются сетевые Slave переменные, то в файле экспорта останется расставить строки по группам, дать имена группам, при помощи формул с условием пересчитать адреса, копированием заполнить имена путей, дополнительное описание, энергонезависимость. Эту работу очень удобно выполнять в Exel, а не в редакторе переменных Owen Logic, поэтому её выполнение займёт очень мало времени. В файле «3_3_Импорт_переменных_Сетевые_итоговый, Slave.csv» видно, что заполнены все поля и они не содержат ошибок. Завершение программы, эмуляция, исправление ошибок в алгоритмах и макросах Кликните здесь для просмотра всего текста
После импорта сетевых переменных, остаётся завершить программу — расставить пропущенные переменные.
Проверка эмуляцией позволяет выявить и устранить ошибки, поэтому в исправленных макросах уточняются даты создания. Получаем итоговый проект 2_Программа.7z Примечание. Архив содержит поэтапное развитие программы от основных разделов, добавления рабочих алгоритмов и завершения после импорта сетевых переменных. Формирование файла импорта сетевых переменных в вышестоящую систему (панель оператора) Кликните здесь для просмотра всего текста
Большое количество переменных, передаваемых в вышестояющую систему (панель оператора) есть смысл не описывать по одной, а по аналогии с другими случаями импортировать.
Форматы файлов импорта в среде разработки проекта панели оператора не совпадают с форматом экспорта Owen Logic. Решение состоит в конвертации файла экспорта в формат файла импорта. Пример для панели Weintek ранее рассматривал в статье OwenLogic: перенос сетевых переменных в панель Weintek (EasyBuilder Pro) Формирование файла импорта сетевых переменных в вышестоящую систему (облачный сервис) Кликните здесь для просмотра всего текста
Приборы производства ОВЕН часто подключают к облачному сервису OwenCloud.
На данный момент формат файла импорта для переменных является json. Среда разработки Owen Logic позволяет выполнить экспорт переменных для OwenCloud, но заполнение полей в json получается неполным и не вполне адекватным, что после импорта дополняется невозможностью редактирования некоторых полей. Пользователи разработали утилиту для конвертации csv файла экспорта сетевых переменных в формат json импорта параметров для облачного сервиса. Скачать её и ознакомиться с описанием можно по ссылке https://owen.ru/forum/showthre... post466460 В утилите требуется выбрать номера позиций в csv и выполнить конвертацию. Скрин показывает заполнение этих номеров для Owen Logic 2.11.368.0 и ПР205 Выводы и рекомендацииПриведено описание методики разработки проекта и приведён пример её применения. Суть методики заключается в формализации части программы, которая создаётся почти механистически. Негативным побочным эффектом такого подхода является резкое увеличение количества переменных. Решением для ускорения описания переменных является импорт файла описаний, который редактируется в Exel. Всё вместе — и формализация и импорт переменных — приводят к сокращению сроков реализации работы. Полученные навыки в дальнейшем приводят к решениям по сокращениям сроков разработки для других компонент автоматизации — панелей оператора и облачных сервисов. Для оценки, приведу длительность разработки с чистого холста и использованием уже готовых макросов (без учёта проведения ПНР):
|
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 0
Комментарии
