Как сделать энергонезависимый счётчик? (решено)

[Alex1966]

Чей то ничего не получается. Сохраняю значение счетчика в памяти.
И вижу его на экране. Выключаю матрикс . После перезагрузки вижу то же значение на экране. Посылаю еще один импульс для счета , на экране опять единица, а не то значение что нащелкало раньше.
Помогите плиз.

[1exan]

Ну так после перезагрузки счётчики то начинают опять считать с 0, а не с сохранённого значения

[Ilya J.]

А что вы пытаетесь реализовать?

[Alex1966]

Счетчик срабатываний энергонезависимый


Добавлено через 3 минуты


Ну и вообще не только его.
Например есть в памяти 2 значения = время удержания. И есть 4 кнопки +\- и +\- для одного и второго значения. Когда включаешь вроде все ок считывается из смарта, но если нажать на любую кнопку то буде значение 1 единица.

[Arsie]

Сообщение от Alex1966

Чей то ничего не получается. Сохраняю значение счетчика в памяти.

Значение счётчика сохраняете, но при включении не загружаете обратно в счётчик. Он с нуля и считает.

Но у вас в любом случае много лишнего в программе.


Безымянный.png


PS. Делая подобные схемы, всегда держите в голове, что ресурс памяти конечен.

[Gel]

Сообщение от Arsie

PS. Делая подобные схемы, всегда держите в голове, что ресурс памяти конечен.

А вы в новых устройствах не планируете добавить память от батарейного питания на чем-нибудь, типа DS1307?

Было бы здорово, проблемы с ресурсом счетчиков бы решились бы раз и навсегда.

[Arsie]

Сообщение от Gel

А вы в новых устройствах не планируете добавить память от батарейного питания на чем-нибудь, типа DS1307?

Было бы здорово, проблемы с ресурсом счетчиков бы решились бы раз и навсегда.

Нет. Задача батарейной памяти не так проста, как кажется, да и правильно пользоваться ею 90% людей не умеют. Единственное хорошее решение для любой квалификации исполнителя - это внутренняя система "гибернации" от внутреннего источника питания. Но это матрикс раза в 2-3 дороже станет. И больше размерами.

[Gel]

Сообщение от Arsie

Нет. Задача батарейной памяти не так проста, как кажется, да и правильно пользоваться ею 90% людей не умеют. Единственное хорошее решение для любой квалификации исполнителя - это внутренняя система "гибернации" от внутреннего источника питания. Но это матрикс раза в 2-3 дороже станет. И больше размерами.

Так людям, вроде, и не нужно давать возможность напрямую писать в память, учитывать атомарность операций и т.п. Должен быть простой интерфейс по типам для пользователя, а вы с железом/специфичными вещами сами все разрулите.

[LordN]

флешка на пару террабайт и нормальный менеджер памяти который не даст писать в одну ячейку миллион раз подряд проблему не решит?

[Arsie]

Сообщение от Gel

Так людям, вроде, и не нужно давать возможность напрямую писать в память, учитывать атомарность операций и т.п. Должен быть простой интерфейс по типам для пользователя, а вы с железом/специфичными вещами сами все разрулите.

У меня есть пара мыслей, как сделать хорошо на текущей аппаратуре.

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

[Gel]

Сообщение от LordN

флешка на пару террабайт и нормальный менеджер памяти который не даст писать в одну ячейку миллион раз подряд проблему не решит?

Наверняка решит, вопрос в эффективности и надёжности.

Просто, всякие счётчики моточасов и т.п. -- это же типовая задача автоматизации. По идее, должно предоставляться готовое решение для простого использования.

[LordN]

про моточасы. и вообще всякие ЭЭ счетчики чего-нибудь.
я уже высказывался на эту тему как-то, но повторюсь:
нужна функция, подсчитывающая разности соседних отсчетов и суммирующая их в исторических блоках. это сразу даст возможность не париться за память, её сохранность, и все такое прочее.
и облегчит юзеру создание всевозможных счетчиков всевозможных событий.
в такой фб можно будет сразу писать значение какого-нить счетчика периодом в час, например, и на выходе получать сумму наработки.

[Arsie]

Сообщение от LordN

про моточасы

С моточасами, если это именно моточасы, а не мотосекунды, проблем нет никаких на Trim/SMH4/Matrix. Можно на аррэях считать.

[Gel]

Сообщение от Arsie

С моточасами, если это именно моточасы, а не мотосекунды, проблем нет никаких на Trim/SMH4/Matrix. Можно на аррэях считать.

А каким образом мотоЧАСЫ можно считать, не посчитав мотосекунды?

[ATS]

Сообщение от Gel

А каким образом мотоЧАСЫ можно считать, не посчитав мотосекунды?

Зачем их считать. Считаем изменение десятков минут реального времени.

[Arsie]

Сообщение от Gel

А каким образом мотоЧАСЫ можно считать, не посчитав мотосекунды?

Считать можно что угодно, сохранять нужно часы, а не секунды.

[Gel]

Сообщение от Arsie

Считать можно что угодно, сохранять нужно часы, а не секунды.

Если сохранять только часы, то будет накапливаться большая погрешность.

[Arsie]

Сообщение от Gel

Если сохранять только часы, то будет накапливаться большая погрешность.

Даже если питание неожиданно рубится раз в день каждый день, то средневзвешенная погрешность будет 1/36, т.е. около 3%. Можно записывать раз в полчаса, это уже менее 1.5% погрешности.

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

Значимость мотосекунд, как и значимость гальванической изоляции, сильно преувеличены.

[Gel]

Сообщение от Arsie

Даже если питание неожиданно рубится раз в день каждый день, то средневзвешенная погрешность будет 1/36, т.е. около 3%.

А в сценарии, когда утром установку включают, она работает равновероятно от 0 до 6 часов и вечером выключают, погрешность будет 20%.

И техническая возможность сделать нормальное хранение счетчиков есть с широкой областью применимости: и батарейное питание, и FRAM...

Может быть виде отдельного модуля, как NA-017 какой-нибудь в Matrix.

Или задокументировать распиновку модулей расширения, кому надо, тот сам сделает.

[Arsie]

Сообщение от Gel

А в сценарии, когда утром установку включают, она работает равновероятно от 0 до 6 часов и вечером выключают, погрешность будет 20%.

А никто не мешает записывать состояние счётчика при отключении насоса. Не вводным автоматом же всё рубят.

[ATS]

Сообщение от Arsie

А никто не мешает записывать состояние счётчика при отключении насоса.

Именно так.

Сообщение от Gel

И техническая возможность сделать нормальное хранение счетчиков есть с широкой областью применимости: и батарейное питание, и FRAM...

Не пойму зачем этот сыр-бор. Достаточно контроля питания и успеть аварийно записать в память.

[Arsie]

Сообщение от ATS

Не пойму зачем этот сыр-бор. Достаточно контроля питания и успеть аварийно записать в память.

А я считаю, что для моточасов это лишнее. Вот для коммерческого учёта ЭЭ или тепла - это да. Но кто делает коммерцию на ПЛК? Да даже если и так, то пара аккумов на 12В + БП, рассчитанный на аккумы, дешевле всех этих прыжков с батарейной памятью.

[Gel]

Сообщение от ATS

Достаточно контроля питания и успеть аварийно записать в память.

Работать в предположении, что значение само сохраняется намного проще.

Могут быть счетчики, например, метража лебедки на спуск/подъем.

Кроме этого, счетчик может пережить форматирование контроллера. Часы же не сбрасываются при форматировании.

[Arsie]

Сообщение от Gel

Работать в предположении, что значение само сохраняется намного проще.

Могут быть счетчики, например, метража лебедки на спуск/подъем.

Кроме этого, счетчик может пережить форматирование контроллера. Часы же не сбрасываются при форматировании.

SD-карта. Настроить тренд в истории и писать. Карту на 16 гигов по кругу раз 50 точно можно писать. На сколько её хватит, если писать 4-8 байт в секунду?

[Gel]

Сообщение от Arsie

SD-карта. Настроить тренд в истории и писать. Карту на 16 гигов по кругу раз 50 точно можно писать. На сколько её хватит, если писать 4-8 байт в секунду?

Как-то эта куча слоев (БД, файловая система, кэши, контроллер SD-карты) не способствует надежности.

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

[LordN]

я тоже за фбд "моточасы/счетчик чегонибуть типа вода, ээ, или одометры" который можно прочитать всегда и получить на выходе все что захочешь


Добавлено через 3 минуты

Сообщение от Arsie

А я считаю, что для моточасов это лишнее. Вот для коммерческого учёта ЭЭ или тепла - это да. Но кто делает коммерцию на ПЛК? Да даже если и так, то пара аккумов на 12В + БП, рассчитанный на аккумы, дешевле всех этих прыжков с батарейной памятью.

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

[Пятница]

Вопрос:
если записывать в блок EEPROM() одно и тоже значение по сигналу на start wr будет ли производиться физически запись в ячейку? Или этот момент учтён в Лоджике и записи как таковой не будет?

[LordN]

Сообщение от Пятница

Вопрос:
если записывать в блок EEPROM() одно и тоже значение по сигналу на start wr будет ли производиться физически запись в ячейку? Или этот момент учтён в Лоджике и записи как таковой не будет?

в библиотеках или на форуме есть макрос fronts(int/long/real) используйте его для разрешения записи по изменению

[Arsie]

Сообщение от Пятница

Вопрос:
если записывать в блок EEPROM() одно и тоже значение по сигналу на start wr будет ли производиться физически запись в ячейку?

Блок EEPROM() - это стек FIFO, в него невозможно записать "одно и то же" в общем случае. Как минимум каждый раз нужно обновлять указатель за текущую ячейку.

Судя по вашему вопросу, вы перепутали блоки EEPROM() и ARRAY(). Но всё равно, если нужно избежать записи повторяющихся данных, то это блок сравнения + AND, блокирующий сигнал записи.

[Пятница]

Поменял блок на ARRAY.
Вот по такой схеме будет исключена запись одного и того же значения в ячейку памяти?
1 на входе lenght - это число байт или номер записи для long ?