Макрос OperTimer

[lord2210]

Макрос содержит три входные переменные:
ob_on - состояние основного процесса вкл/откл;
st_Sec - системное время в секундах от внутреннего таймера программируемого реле;
cmd_Reset - команда сброса наработки.
На выходе получается время наработки в минутах или часах и количество включений.

На обьекте, раз в несколько недель, самопроизвольно сбрасывается время наработки. В чем может быть причина? cmd_Reset заведена на дискретный вход с задержкой включения TON на 3 сек. Кнопку сброса специально никто не нажимает. Неужели длительные наводки более 3 сек на дискретном входе ПР200-220 при включении оборудования? Или, может быть, системное время в секундах может кратковременно обращаться в ноль?

Попробуйте повесить на 5 вход нагрузку на 10 кОм, или лампочку светодиодную, контрольку, очень часто на пр200 с наводкой проблемы, а у Вас там ещё наверно и сыро.

[Ревака Юрий]

Ну у меня с этим макросом проблема другая. У меня они отстают. Я делал проект управления уф лампами с учетом наработки на каждую лампу .При симуляции больше 6 макросов тормозит жутко . И это на 8 Винде и при 16гигах озу.

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

[dan75]

В проекте только две энергонезависимые переменные: lv_ Timer (h) и lv_ Num_ of_Inc или наработка в часах и количество включений. Обе образуются на выходе макроса OperTimer и эпизодически обе сбрасываются в ноль. Сброс отмечается удаленно по OwenCloud. На первом обьекте кнопка сброса была подключена к дискретному входу ПР200 и, далее, ко входной переменной макроса cmd_Reset. Наработка и количество включений иногда обнулялись. На втором обьекте ввел задержку TON 3 сек между дискретным входом ПР100 и макросом (может быть какие-нибудь кратковременные импульсные помехи при включении оборудования замыкают дискретный вход?!). Не помогло...

А как задаются сетевые переменные для Cloud? На скрине не видно.

[Vyacheslav]

Сетевые переменные просто копируются из локальных, при этом двоичные переменные преобразуются в integer. Прилагаю сходный проект на ПР100.
Наверное, Юрий Ревака прав: могут затираться значения энергонезависимых переменных при помехах по питанию. Длительные наводки, приводящие к закорачиванию дискретного входа, тоже возможны, но кажутся менее вероятными.

[dan75]

Тогда переменные hours и num можно сразу сделать сетевыми и назначить им адреса, которые были у var5 и var6. Возможно, станет стабильнее. А все булевые переменные, кстати, можно собрать в одну; Cloud умеет работать с битовыми масками.

[Vyacheslav]

Переменная hours используется также в другом месте программы. Подставить вместо нее сетевую не получится.

"Нужно ли упаковывать битовые переменные в integer перед отправкой на сервер OwenCloud?". Когда-то даже хотел создать отдельную тему для обсуждения на форуме. Запаковать, конечно, можно. Однако, на сервере придется распаковывать, т.е считывать integer переменную несколько раз для того чтобы выделить конкретные биты. В итоге трафик не экономится, а задача немного усложняется. Складывать несколько битовых переменных или целых - практически одно и тоже для малых обьемов. Сетевые пакеты дополнительно нужно во что-то оборачивать. В итоге, выиграша от упаковки практически нет.

[Ревака Юрий]

Переменная hours используется также в другом месте программы. Подставить вместо нее сетевую не получится.

"Нужно ли упаковывать битовые переменные в integer перед отправкой на сервер OwenCloud?". Когда-то даже хотел создать отдельную тему для обсуждения на форуме. Запаковать, конечно, можно. Однако, на сервере придется распаковывать, т.е считывать integer переменную несколько раз для того чтобы выделить конкретные биты. В итоге трафик не экономится, а задача немного усложняется. Складывать несколько битовых переменных или целых - практически одно и тоже для малых обьемов. Сетевые пакеты дополнительно нужно во что-то оборачивать. В итоге, выиграша от упаковки практически нет.

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

[игорь68]

Вот тестовая программка для проверки работы таймера с выводом на экран. На табло выводим минуты: часы для всех восьми таймеров. Для чистоты теста запустите таймеры в одно время например в 12:00 и наслаждайтесь.

[dan75]

Вот тестовая программка для проверки работы таймера с выводом на экран. На табло выводим минуты: часы для всех восьми таймеров. Для чистоты теста запустите таймеры в одно время например в 12:00 и наслаждайтесь.

Так что мы там должны увидеть-то? И ещё: эту программу надобно в симуляторе смотреть или в ПРку заливать?

[dan75]

Переменная hours используется также в другом месте программы. Подставить вместо нее сетевую не получится.

"Нужно ли упаковывать битовые переменные в integer перед отправкой на сервер OwenCloud?". Когда-то даже хотел создать отдельную тему для обсуждения на форуме. Запаковать, конечно, можно. Однако, на сервере придется распаковывать, т.е считывать integer переменную несколько раз для того чтобы выделить конкретные биты. В итоге трафик не экономится, а задача немного усложняется. Складывать несколько битовых переменных или целых - практически одно и тоже для малых обьемов. Сетевые пакеты дополнительно нужно во что-то оборачивать. В итоге, выиграша от упаковки практически нет.

Она используется в блоке индикации наработки из трёх ламп, ага. Не вижу препятствий, чтобы читать значение из сетевой переменной.
Про несколько раз вообще не понял. Переменная считается 1 раз в виде битовой маски, дальше Cloud выделит все нужные биты. Ты же сам отправил в виде маски переменную lamps. Насколь понимаю, Cloud при этом показывает, какие конкретно лампы неисправны.