Фичи и баги OWEN Logic

[kaftanati]

Попробуйте оставить эти поля пустыми.

Конечно же, это сработает. Но, я бы хотел использовать эти поля для валидации. У меня есть генерируемая карта регистров/параметров, где для каждого параметра есть его пределы допустимых значений, в т.ч. для R-only. Не особо сомневаясь я их экспортировал внутрь ПР и обнаружил указанное поведение OwenLogic, которое посчитал ошибкой: указанные границы не "подрезают" входные сетевые принятые значения, как указано, а "подрезают" в т.ч. и выходные сетевые значения.

Пример внешней валидации:

Например для слово флагов, у которого только 2 значимых первых бита - ожидаемые валидные значения для слова 0..3. Если внешнее ПО прочитает что-то другое - будет считаться ошибкой передачи.
UniControl_scr.png

[Емельянов Кирилл]

Обнаружил интересное поведение:

ПР205***
Сетевой регистр, в настройках которого задано Min = 0, Max = 0, в комментарии указано, что эти поля задают ограничения для внешних редактирований по сети или ПО.
Этот регистр сохраняет в себе набор флагов (не предполагает внешнего редактирования), потому границы ему и установлены такие.
При отладке этот регистр получает значение, например 125, не суть, любое ненулевое значение.
И вот если опросить этот регистр по сети (ModbusTCP) - внешнее ПО получает - 0.

Мне кажется, либо здесь неверное поведение либо неверное описание этих полей регистра, и тогда непонятно их назначение. Склоняюсь, что это ошибка.

Даже, если поведение этих настроек было бы таким же, как вы планировали, то при записи в регистр "0" все ваши флаги бы затёрлись.

[Dimensy]

Конечно же, это сработает. Но, я бы хотел использовать эти поля для валидации. У меня есть генерируемая карта регистров/параметров, где для каждого параметра есть его пределы допустимых значений, в т.ч. для R-only. Не особо сомневаясь я их экспортировал внутрь ПР и обнаружил указанное поведение OwenLogic, которое посчитал ошибкой: указанные границы не "подрезают" входные сетевые принятые значения, как указано, а "подрезают" в т.ч. и выходные сетевые значения.

[SPOILER=Пример внешней валидации]
Например для слово флагов, у которого только 2 значимых первых бита - ожидаемые валидные значения для слова 0..3. Если внешнее ПО прочитает что-то другое - будет считаться ошибкой передачи.

Косяк с описанием есть - сравните, что в справке написано и что Лоджик показывает
Безымянный.png
Но смысл задавать мин=0 и макс=0? Тем более, что в ПР205 read only - это действительно только для чтения, фиг ты что туда запишешь

[kaftanati]

Косяк с описанием есть - сравните, что в справке написано и что Лоджик показывает
Безымянный.png
Но смысл задавать мин=0 и макс=0? Тем более, что в ПР205 read only - это действительно только для чтения, фиг ты что туда запишешь

Конкретно у меня туда пролезло [0..0] случайно, потому и заметил влияние именно нулей при отладке.
И описание логики применения этих полей как в OL - как подрезка входных значений, для меня логична. А вот зачем подрезать выходные (хоть и написано для конфигуратора/облака) не понимаю. Теряется консистентность данных - внутри прибора одно, а снаружи может быть другое и сбивать с толку.

Было бы интересно узнать мнение разработчиков OL по этому моменту

[kaftanati]

Когда же исправите импорт переменных (чтоб без дублирования), а с обновлением по имени адресов и описаний?
Дайте надежду, что это хотя бы у вас в TODO!

P.S. крик души после экспорт/импорта/переназначений адресов вручную при агрегации с внешней диспетчеризацией

[Умурзаков Денис]

Конкретно у меня туда пролезло [0..0] случайно, потому и заметил влияние именно нулей при отладке.
И описание логики применения этих полей как в OL - как подрезка входных значений, для меня логична. А вот зачем подрезать выходные (хоть и написано для конфигуратора/облака) не понимаю. Теряется консистентность данных - внутри прибора одно, а снаружи может быть другое и сбивать с толку.

Было бы интересно узнать мнение разработчиков OL по этому моменту

Данный функционал создавался прежде всего для взаимодействия с Owen Configurator. Понимаю ваше негодование, подумаем, что с этим сделать.

[Умурзаков Денис]

Когда же исправите импорт переменных (чтоб без дублирования), а с обновлением по имени адресов и описаний?
Дайте надежду, что это хотя бы у вас в TODO!

P.S. крик души после экспорт/импорта/переназначений адресов вручную при агрегации с внешней диспетчеризацией

Данная задача действительно есть в TODO, ожидается, что к концу года это будет реализовано. Сейчас прорабатываем требования. Пока что планируем доработать импорт переменных, сделав выбор из нескольких вариантов при совпадении имен:
1. Дублировать переменные с совпадающими именами
2. Пропустить переменные с совпадающими именами
3. Заменить переменные с совпадающими именами

К п.3 пока больше всего вопросов, так как не очень ясны сценарии, где это может пригодится. Я так понимаю, вы хотели бы это видеть при импорте сетевых переменных. А при импорте стандартных это может пригодиться?

[kaftanati]

Данная задача действительно есть в TODO, ожидается, что к концу года это будет реализовано. Сейчас прорабатываем требования. Пока что планируем доработать импорт переменных, сделав выбор из нескольких вариантов при совпадении имен:
1. Дублировать переменные с совпадающими именами
2. Пропустить переменные с совпадающими именами
3. Заменить переменные с совпадающими именами

К п.3 пока больше всего вопросов, так как не очень ясны сценарии, где это может пригодится. Я так понимаю, вы хотели бы это видеть при импорте сетевых переменных. А при импорте стандартных это может пригодиться?

Поясню по п.3 - почему именно он самый важный:
1. Создается программа с картой регистров (локальных/сетевых, не суть).
2. Привязывается к блокам/выходам, на холсте.
3. Потом, требуется подвинуть часть регистров из-за добавления новых/удаления старых - для задач диспетчеризации/панели/внешние источники данных, тоже не суть.
4. И встает вопрос, как обновить адреса для имеющихся параметров (или только описание/пределы) - если при импорте внешней карты они дублируются.
5. А все привязки на старых регистрах.
6. И не выпускает с редактора параметров, пока не уберешь дубли. Только удалять/переадресовывать тут же.

Получается, что в текущей реализации воспользоваться импортом (с пользой) можно только один раз - при импорте из внешнего источника в пустую программу, чтобы не возникло конфликтов адресов/имен и привязок.

Возможно эта проблема у большинства пользователей не встает, но при сложных распределенных системах, когда количество ПР в одном проекте измеряется десятками, а карты регистров из внешнего единого источника - это важный функционал в разработке.

Спасибо за ответ и очень прошу не откладывать с реализацией (готов тестировать хоть прям сейчас в формате бета-версий).

P.S. А вот п.1 и п.2 как раз не представляю, когда нужны. Не сталкивался

[FPavel]

3. Заменить переменные с совпадающими именами

К п.3 пока больше всего вопросов, так как не очень ясны сценарии, где это может пригодится. Я так понимаю, вы хотели бы это видеть при импорте сетевых переменных. А при импорте стандартных это может пригодиться?

Да, соглашусь во всём с kaftanati - именно эта реализация и нужна.
Впервые такой импорт встретил в панелях оператора Weintek - сразу увидел, как это удобно.

Мне кажется, что механизм импорта одинаков и для стандартных и для сетевых переменных.
Где может пригодиться - массовый перенос из одной логической папки в другую, смена уставок, смена энергонезависимости и других атрибутов, применение собственной сортировки переменных в логической папке (т.к. вновь добавленная переменная оказывается внизу, а хотелось бы для удобства разместить её среди связанных логикой).

Чтобы сделать удобным встроенный редактор переменных - понадобится воспроизвести часть функций Excel и удобной надстройки над ним Ёxcel - таких как протягивание с нумерацией, массовые операции копирования (столбцами и строками), дополнения текстом начала или конца содержимого множества ячеек, поиска и замены.

Для сетевых переменных возможность будет востребована в сценарии - во время выполнения проекта или зарезервировал много переменных или отказался от некоторых - в адресации появились пропуски, которые мешают групповому чтению. Неиспользованные переменные можно удалить, а адреса пересчитать (очень просто в Excel) и импортировать со сплошным использованием.

При видеоинтервью я может быть явно не озвучил причину, но всячески подчёркивал, что переменные буду объявлять (импортировать) лишь после завершения всех остальных работ (создания необходимых макросов и размещения всех ФБ на холсте) - т.е. переменные это самый конец работы. И причина этому - одноразовый импорт.

Правда, это нужная возможность - обновление свойств сетевых и стандартных переменных при импорте. Затрудняюсь сказать, как быть при смене типа - наверное, если переменная не использована - обновить вместе с типом, иначе - предупредить и игнорировать обновление.

[SmSerg]

Добрый день.
При использовании OWEN Logic, внизу экрана начало подсвечиваться поле Системное ОЗУ. Сейчас уже показывает занято 90%.
Ни где не нашел объем этого ОЗУ для ПР103.
При наведении курсора показывает: " занято 9544 из 10624. Для оптимизации попробуйте уменьшить количество сетевых переменных или количество модулей ПРМ."
По документации для ПР103 можно установить 2 модуля ПРМ и возможно использование 2000 байт для передачи по сети.
В проекте установлены модули ПРМ24.1 и ПРМ24.4.
Сетевых переменных используется 365, из них 31 с плавающей запятой, остальные целочисленные.
В соответствии с документацией :"Объем памяти под сетевые переменные в режиме Slave — 2040 байт".

Так вот вопрос - используется не весь объем сетевых переменных, почему система показывает ограничение по памяти Системное ОЗУ?
Для чего тогда эти цифры в 2040 байт под сетевые переменные, если их использование ограничено другой памятью?

111.jpg