ПР200. Проверить макрос. Снова энергонезависимый счетчик наработки.

[Shiryaevo]

Доброго дня.

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

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

Задача: считать наработку в течении 1 суток.
От макроса из библиотеки отказался, так как нет в нем секунд.
67659

Материалы по ссылкам изучил, по материалам все понятно.
по ссылкам не раскрыта тема есть ли особенности если макрос с "энергонезависимостью" используется в других макросах.
В примерах приведены только программы на "главном" листе.

https://youtu.be/LrpQqC7F9d4
https://owen.ru/forum/showthread.php?t=26681&page=3

[Dimensy]

А что сбрасывается в ноль? И зачем переменной "сброс" энергонезависимость?
У вас счетчик считает не за последние сутки, а за последние 24 часа. Сутки - это, все-таки время с полуночи до полуночи.
Счетчик автоматически сбрасывает накопленное каждые 24 часа - может в этом проблема?
Не понятно зачем три выхода "Секунды - Минуты - Часы". Они же показывают одно и то же, только в разных единицах

[Shiryaevo]

А что сбрасывается в ноль? И зачем переменной "сброс" энергонезависимость?

Это «защита»
Переменная СБРОС в режиме энергонезависимости с настройкой по умолчанию 0 для того чтобы при инициализации программы, после запуска на приборе первый раз, не получить неоднозначного значения.
Изменение этой переменой происходит на 1 цикл программы. В 99,999% она в состоянии 0.

Сброс приходит от «внешнего» источника.
Из общего макроса, который энергонезависимо проверяет наступление новых суток.

[1exan]

Это «защита»
Переменная СБРОС в режиме энергонезависимости с настройкой по умолчанию 0 для того чтобы при инициализации программы, после запуска на приборе первый раз, не получить неоднозначного значения.
Изменение этой переменой происходит на 1 цикл программы. В 99,999% она в состоянии 0.

Сброс приходит от «внешнего» источника.
Из общего макроса, который энергонезависимо проверяет наступление новых суток.

Неоднозначности не будет, будет точно 0.

[Shiryaevo]

Неоднозначности не будет, будет точно 0.

может и так....
программисты системы тоже люди :)
и конденсаторы высыхают.
привык "НЕ доверять/ перепроверять" входные параметры.
иногда фанатично... издержки опыта создания промышленных систем :)

Однако ж, вернемся к сути моего сообщения...

На мой вопрос не получил пока ответа: "Является ли схема источником проблемы перезаписи "энергонезависимой" переменной при подаче напряжения?"

Мое мнение: не является, потому что
1) переменная "Секунды" в рамках первого цикла (первого просчета входов и выходов интеппретатором) сохраняет значение сама себя.
2) Умножение на "0" возникает только в предусмотренных случаях.

Что-то еще я не учитываю?

Или все верно, то есть это правильно составленная схема и работать должна как задумывалось.

И на второй вопрос:"Есть ли какие то особенности использования энергонезависимых переменных в маркосах?"

Откуда второй вопрос?
Мне не известны особенности реализации интерпретора на уровне ядра для коммутационных реле, но по общему правилу, если пользователь (разработчик кода для интерпретатора) использует вложенные процедуры (в данном случае макросы), то в стеке (интерпретатора) создаются локальные переменные (с локальной видимостью).
Однако если в процедуре используется "энергонезависимая" переменная, это значит что разработчик интерпретатора должен предусмотреть управления такими переменными:
- включать в цепочку (список/таблицу) таких же переменных ( с контролем доступности ресурса) - другими словами включать эти переменные в данные блока "управление записью и чтения из энергонезависисомй памяти"
- при инициализации ядра (при включении прибора) восстанавливать цепочку с учетом того, что переменные являются локальными для нескольких экземпляров макроса.

Та же мысль, но другими словами: реализация функции ядра по управлению локальными (для макроса) "энергонезависмыми" переменными задача не то чтобы сложная, но с учетом особенностей и разнообразия аппаратной начинки может потребовать высокой аккуратности и заметного времени на отладку.
И, возможно, чтобы не связываться с этим (в первую очередь из-за времени на отладку интерпретатора), архитектор (руководитель разработки) ядра мог принято решение: "ПР200 - это не промышленный прибор, для его ценовой категории мы "сервис интерпретатора" поддерживать не будем"

Меня "подталкивает" к этой мысли три факта:
1) только ФБ (некоторые) содержат параметр "энергонезависимость" (возможно разработчик иннтерпретатора реализовал функцию с описанными выше особенностями только для фиксированного, контролируемого, списка блоков)
2) Описанные в документации особенности использования локальных переменных функций (не макросов, / функций на скрит-языке)
3) демонстрируемые Активистами форума примеры не "опускаются" на уровень макроса, то есть примеры приводятся на "главной" странице (реализация на "главной странице "не требует от разработчика интерпретатора вышеописанного функционала)

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

Когда прибор будет у меня снова в руках, я сам проверю свою теорию :)
Пока что обращаюсь к опыту сообщества и особенно к Активистам форума, за усилия которых мои искренние слова Благодарности!

[Сергей0308]

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

[melky]

насколько помню, внутри макроса будет работать криво... правда сужу еще по 114-му ПР... Чтобы сохранять и иметь возможность управлять, нужно делать входные/выходные переменные и связывать их между собой. Вкладывать подобный макрос внутрь другого макроса не пробовал.

Но сейчас в ОЛ многое изменилось... Проверяется на железе легко.

[Василий Кашуба]

Доброго дня.

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

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

Задача: считать наработку в течении 1 суток.
От макроса из библиотеки отказался, так как нет в нем секунд.
67659

Материалы по ссылкам изучил, по материалам все понятно.
по ссылкам не раскрыта тема есть ли особенности если макрос с "энергонезависимостью" используется в других макросах.
В примерах приведены только программы на "главном" листе.

https://youtu.be/LrpQqC7F9d4
https://owen.ru/forum/showthread.php?t=26681&page=3

Для сброса счётчика на сумматоре нужно не ФБ MUL использовать, а SEL.

[Shiryaevo]

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


решил задачу.
Поставил ловушку для события «СБРОС».
Событие прилетало, но не должно было. Также и там (в источнике события) все правильно сделал.
Но «летело”.

Изучение причин появления помогло сделать «открытие»:
конкретно в моей программе, если переменную из макроса, минуя манипуляции на «главном листе», сразу передавать в другой макрос, то интерпретатор OL видимо содержит ошибку.
Потому как только «приземлил» событие в «ловушку», то сразу заработало. Убираешь «ловушку» - неожидаемое поведение.
(это прямо по теории наблюдаемого События и Наблюдателя .... из квантовой физики ... если что :))

После того как заработало, то поставил дополнительную «защиту»: после включения прибора 2 секунды игнорирую события.

Это не беда, Софта без ошибок не бывает.
И это Очередной наглядный пример :)
Так что проверяйте и не доверяйте входным данным.


Для того, кто в будущем прочтёт.

Моя схема рабочая.
Но для практического применения обложитесь проверками как описал выше.

Тема закрыта, глюк пойман и блокирован ;)
Спасибо.

[Shiryaevo]

Для сброса счётчика на сумматоре нужно не ФБ MUL использовать, а SEL.

MUL (операция умножения) графически компактнее.
SEL - теоретически уместнее.
Однако результат в конкретном случае будет тотже.
Обоснуйте, пож-та, почему нужно выбрать SEL?
Я не против, у Вас больше опыта работы с прибором.

[Сергей0308]

MUL (операция умножения) графически компактнее.
SEL - теоретически уместнее.
Однако результат в конкретном случае будет тотже.
Обоснуйте, пож-та, почему нужно выбрать SEL?
Я не против, у Вас больше опыта работы с прибором.

Бывает задаваемое значение принимаемое при сбросе не всегда ноль требуется. Например я кольцевой счётчик заданного диапазона делал, там задаются максимальное значение диапазона и минимальное и минимальное значение можно задать отличное от ноля. Короче, лучше иметь возможность назначать(задавать) значение принимаемое счётчиком при сбросе, если это универсальное решение!

[Василий Кашуба]

MUL (операция умножения) графически компактнее.
SEL - теоретически уместнее.
Однако результат в конкретном случае будет тотже.
Обоснуйте, пож-та, почему нужно выбрать SEL?
Я не против, у Вас больше опыта работы с прибором.
Вот посмотрите.

[Shiryaevo]

Вот посмотрите.

Согласен
Если нужно уставку менять ( «нулевое» значение).

Спасибо.
Принято.