Просмотр полной версии : CODESYS 2.3 Помогите очень нужно СЧЕТЧИК ВОДЫ
Помогите пожалуйста новичку кодесис 2.3 CFC неполучается собрать схемку по подсчету расхода воды. Счет суточный , часовой, мгновенный. Неделю бьюсь не получается форум овен весь перелопатил. Помогите пожалуйста повторяю я новичок , способ какой нибудь попроще. Заранее спасибо
Владимир Ситников
08.01.2016, 23:45
Неделю бьюсь не получается
Показывай чего удалось достичь за неделю. Хоть какой-то проект получился?
_Mikhail
08.01.2016, 23:50
что получаем с счетчика? импульсы или аналоговый сигнал?
С счетчика получаем импульс примерно 1 импульс в 10 с такой расход. использую обычныый дискретный вход ПЛК. Сейчас скину свои наработки. Пожалуйста помогите
21680 Вот такое убожество у меня написано, там все не так уж и правильно. на in5 поступает сигнал с счетчика
Владимир Ситников
09.01.2016, 20:09
21680 Вот такое убожество у меня написано, там все не так уж и правильно. на in5 поступает сигнал с счетчика
Простой счётчик работает и вопрос только с "суточный , часовой"?
Сергей Мих
09.01.2016, 20:25
Обычно водосчетчики выдают импульс(замыкание геркона)- в зависимости от прошедшего через этот водосчетчик обьема жидкости(воды) и от коэффициента 1/10/100, указывается в паспорте на данный прибор. На корпусе, на бирке тоже указывается этот коэфф.( для примера 100дм3/имп.). Но никак не от времени
@С счетчика получаем импульс примерно 1 импульс в 10 с такой расход. использую обычныый дискретный вход ПЛК. @
У Вас же получается просто подсчет количества импульсов, без какой либо привязки к расходу. Да и к тому же до максимального значения CTU счетчика .
Да все верно, мы хотим знать расход текущий и суточный цена одного импульса 0,814*10(-5 степени) , получается суточный расход мы просто к суточному плюсуем все импульса т.е. суммируются все импульсы и перемножаем на цену импульса и в 24:00 счетчик обнуляется , а текущий вообще не понимаю как реализовать.
Простой счётчик работает и вопрос только с "суточный , часовой"?
да, и сброс суточного в 24:00 а часового каждый час
Обычно водосчетчики выдают импульс(замыкание геркона)- в зависимости от прошедшего через этот водосчетчик обьема жидкости(воды) и от коэффициента 1/10/100, указывается в паспорте на данный прибор. На корпусе, на бирке тоже указывается этот коэфф.( для примера 100дм3/имп.). Но никак не от времени
@С счетчика получаем импульс примерно 1 импульс в 10 с такой расход. использую обычныый дискретный вход ПЛК. @
У Вас же получается просто подсчет количества импульсов, без какой либо привязки к расходу. Да и к тому же до максимального значения CTU счетчика .
Хорошо а как привязать обнуление счетчика в 24:00 и пересчет импульса в кубы и суммирование каждого импульса к суточному расходу?
Владимир Ситников
09.01.2016, 21:00
Хорошо а как привязать обнуление счетчика в 24:00
"получаем текущую дату", "если наступил новый час, то сбрасываем почасовой счётчик", "если наступили новые сутки, то сбрасываем суточный".
Так понятно?
Точно нужны именно сбрасывающиеся счётчики, а не "усреднённый расход за последние сутки/последний час"?
А как будет точнее мне кажется усредненный расход не совсем точное значение выдаст.
Владимир Ситников
09.01.2016, 22:19
А как будет точнее мне кажется усредненный расход не совсем точное значение выдаст.
Для каких целей будут использоваться значения?
Если "глазами посмотреть сколько примерно был расход в последнее время", то, по-моему лучше усредненный показатель.
У "сбрасывающихся" будет неприятное поведение сразу после сброса.
Просто глазами посмотреть в управление участия данные не принимают
Я так понимаю помощи мне тут искать не стоит, самому что то придумывать(
Я бы делал бы так. Считал время между импульсами для текущего расхода (обновление по импульсу), а часовой и суточный уже количество импульсов за час и сутки соответственно.
Я так понимаю помощи мне тут искать не стоит, самому что то придумывать(
Это точно -самому .Вам ПЛК нужно изучить или задачу подсчета и индикации решить ,если да ,то на ПР давно уже куча макросов расходомеров ...:cool:
Владимир Ситников
10.01.2016, 10:06
Собственно, пример: 21686
Задача по вычислению средних запускается каждые 10.
averages.last1m -- "среднее количество импульсов за последние 10с".
Аналогично, last1h, last1d.
Все показатели -- "расход в секунду, усреднённый за последнюю минуту/час/сутки".
Т.е. если будет расход "1 импульс в секунду", то через какое-то время, все три показателя придут к значению 1.
Умножаете это на 0,814*10(-5 степени) и переводите в нужные вам единицы.
странный какой-то счетчик воды. цена импульса не 10л, не литр а какая-то абстрактная цифра 0,814*10-^5
Что за счетчик такой ?
Владимир Ситников
10.01.2016, 13:44
Либо цифра с потолка взята, либо счётчик сломался.
В личке vovtrof написал, что счётчик СХВ-15д Бетар, а у него 1 импульс -- 0.01 м3
странный какой-то счетчик воды. цена импульса не 10л, не литр а какая-то абстрактная цифра 0,814*10-^5
Что за счетчик такой ?
Бетар СХВ-15д
Сергей0308
10.01.2016, 18:17
Подобная задача в ОЛ решается элементарно:
http://www.owen.ru/forum/showthread.php?t=22608&page=4
21688
http://www.owen.ru/forum/showthread.php?t=22511
CFC на сколько знаю, мало отличается от ОЛ, но если решите это сделать на ПР, буду рад помочь, вернее всё уже придумано, просто останется выбрать, что Вам больше понравится!
Владимир Ситников
10.01.2016, 18:40
Подобная задача в ОЛ решается элементарно
И что считает эта схема? Без каких-то личных претензий, но как применить ваш пример для "среднего расхода за последние сутки" как-то неясно.
Если я правильно прочитал вашу схему, то вы считаете "общее количество импульсов/общее время". Верно?
Такой подход будет работать только при постоянной скорости. Если же расход меняется со временем, то ваш алгоритм будет показывать погоду.
Если что, то я выше экспоненциальное сглаживание для ПЛК (http://www.owen.ru/forum/showthread.php?t=23057&page=2&p=192163&viewfull=1#post192163) выложил. Оно адаптируется к изменяющимся скоростям.
И кода там 15 строк. Открываем статью в Wikipedia, сверяем алгоритм. На всякий пожарный проверяем в симуляции.
Наверное, это можно переделать в CFC или даже ПР, но, на мой взгляд, на ST нагляднее (да и сравнить с оригиналом в wikipedia проще).
PROGRAM averages
(* https://en.wikipedia.org/wiki/Exponential_smoothing#Basic_exponential_smoothing *)
VAR CONSTANT
sampling_interval: REAL := 10; (* seconds, should be equal to interval in task configuration *)
END_VAR
VAR_OUTPUT
last1m: REAL;
last1h: REAL;
last1d: REAL;
END_VAR
VAR
a1m: REAL;
a1h: REAL;
a1d: REAL;
prevCnt: INT;
delta: REAL;
END_VAR
delta := (PLC_PRG.CV - prevCnt)/sampling_interval; (* current flow ITEMS PER SECOND *)
prevCnt := PLC_PRG.CV; (* <-- интересно, тут может возникнуть ошибка из-за того, что мы 2 раза читаем переменную PLC_PRG.CV ? *)
a1m := 1-EXP(-sampling_interval/60); (* можно вычислить заранее и прямо константой забить *)
a1h := 1-EXP(-sampling_interval/3600);
a1d := 1-EXP(-sampling_interval/86400);
last1m := a1m*delta + (1-a1m)*last1m;
last1h := a1h*delta + (1-a1h)*last1h;
last1d := a1d*delta + (1-a1d)*last1d;
PROGRAM PLC_PRG
VAR_INPUT
inp: BOOL;
END_VAR
VAR_OUTPUT
CV: INT;
END_VAR
VAR
cntr: CTU;
END_VAR
cntr(CU := inp); (* тут просто считаем импульсы *)
CV := cntr.CV;
Если сглаженное значение нужно довольно часто (например, раз в секунду-две-три), то можно сделать без "отдельных программ для усреднения".
Нужно всего несколько строк и одна переменная, в которой будет хранится усреднённое значение -- avg_period:
period := new-old; (* т.е. время, прошедшее с прошлого раза, в миллисекундах *)
a := 1.0 - EXP(-period / 200.0); (* тут 200.0 мс это как раз период усреднения -- его можно менять *)
avg_period := a*Period + (1.0-a)*avg_period; (* тут накапливается усреднение *)
rate := 1000/avg_period; (* Результат, "оборотов в секунду". Что выводить в случае "деления на ноль" предлагаю рассмотреть отдельно *)
Вот пример, как оно может выглядеть: https://docs.google.com/spreadsheets/d/1DyBgCH-cyGu5R4crAURZ24H9LK1rkQ7uJk4EahgJc0A/edit?usp=sharing
Видно, что при увеличении константы результат сглаживания меняется более плавно, но медленнее.
Если характерная частота -- 5-20Гц, то, судя по графику, значение 200 должно неплохо работать. За секунду-полторы оно "выходит на режим", и потом несильно колбасится.
Сергей0308
10.01.2016, 18:50
И что считает эта схема? Без каких-то личных претензий, но как применить ваш пример для "среднего расхода за последние сутки" как-то неясно.
Если я правильно прочитал вашу схему, то вы считаете "общее количество импульсов/общее время". Верно?
Такой подход будет работать только при постоянной скорости. Если же расход меняется со временем, то ваш алгоритм будет показывать погоду.
Если что, то я выше экспоненциальное сглаживание для ПЛК (http://www.owen.ru/forum/showthread.php?t=23057&page=2&p=192163&viewfull=1#post192163) выложил. Оно адаптируется к изменяющимся скоростям.
И кода там 15 строк. Открываем статью в Wikipedia, сверяем алгоритм. На всякий пожарный проверяем в симуляции.
PROGRAM averages
(* https://en.wikipedia.org/wiki/Exponential_smoothing#Basic_exponential_smoothing *)
VAR CONSTANT
sampling_interval: REAL := 10; (* seconds, should be equal to interval in task configuration *)
END_VAR
VAR_OUTPUT
last1m: REAL;
last1h: REAL;
last1d: REAL;
END_VAR
VAR
a1m: REAL;
a1h: REAL;
a1d: REAL;
prevCnt: INT;
delta: REAL;
END_VAR
delta := (PLC_PRG.CV - prevCnt)/sampling_interval; (* current flow ITEMS PER SECOND *)
prevCnt := PLC_PRG.CV; (* <-- тут может возникнуть ошибка из-за того, что мы 2 раза читаем переменную PLC_PRG.CV? *)
a1m := 1-EXP(-sampling_interval/60); (* можно вычислить заранее и прямо константой забить *)
a1h := 1-EXP(-sampling_interval/3600);
a1d := 1-EXP(-sampling_interval/86400);
last1m := a1m*delta + (1-a1m)*last1m;
last1h := a1h*delta + (1-a1h)*last1h;
last1d := a1d*delta + (1-a1d)*last1d;
PROGRAM PLC_PRG
VAR_INPUT
inp: BOOL;
END_VAR
VAR_OUTPUT
CV: INT;
END_VAR
VAR
cntr: CTU;
END_VAR
cntr(CU := inp); (* тут просто считаем импульсы *)
CV := cntr.CV;
Сбрасываешь по каждому импульсу со счётчика - текущий расход, раз в час - часовой, раз в сутки - суточный, при этом до сброса показывает расход за преведущий интервал времени, разумеется потребуется три экземпляра, чтобы это одновременно отображать! И расход будет средний за период с соответствующим периодом обновления!
Владимир Ситников
10.01.2016, 18:56
Сбрасываешь раз в час - часовой
С этого и начинали.
Сразу после сброса цифры будут плавать.
Вот пример где "ругаются" на то, что "первое время после сброса цифры плавают": http://www.owen.ru/forum/showthread.php?t=18573
И неужели добавленные сбросы упростят программу?
Или, может, упростят поддержку?
Или, может, ещё что-то?
Сергей0308
10.01.2016, 19:04
С этого и начинали.
Сразу после сброса цифры будут плавать.
Вот пример где "ругаются" на то, что "первое время после сброса цифры плавают": http://www.owen.ru/forum/showthread.php?t=18573
И неужели добавленные сбросы упростят программу?
Или, может, упростят поддержку?
Или, может, ещё что-то?
Это я выложил пример решения подобной задачи, и ничего там плавать не будет, просто показания обновляются по каждому импульсу со счётчика или каждый час, сутки!
Если что, то я выше экспоненциальное сглаживание для ПЛК (http://www.owen.ru/forum/showthread.php?t=23057&page=2&p=192163&viewfull=1#post192163) выложил. Оно адаптируется к изменяющимся скоростям.
..
...
И где тама мгновенный расход хотя бы ? ))
Владимир Ситников
10.01.2016, 19:45
И где тама мгновенный расход хотя бы ? ))
Ну троллить-то зачем?
Взрослые люди же.
last1m -- "мгновенный расход"
last1h -- "усреднённое за час"
last1d -- "усреднённое за сутки"
В начале темы говорилось, что на конкретном объекте счётчик выдаёт 1 импульс в 10 секунд (http://www.owen.ru/forum/showthread.php?t=23057&p=192120&viewfull=1#post192120).
Я из этого и решил, что "мгновенным показателем" в данном конкретном случае будет "усреднение за минуту".
last1m -- "мгновенный расход.
Это - мгновенный расход ? :):)
Взрослые люди же.
Владимир Ситников
10.01.2016, 20:05
Это - мгновенный расход ? :):)
Ваши предложения? :)
В конце концов, поменять период усреднения тут проще простого, и сделать "среднее за 5 секунд" тут раз плюнуть.
Надеюсь, не нужно рассказывать, что способа вычислить "частоту" импульсов без усреднений вообще не бывает?
Ах, да, есть способ, когда частота просто "дана свыше" и мы просто выводим на экран заложенное заранее значение. Но
взрослые люди же.
Надеюсь, не нужно рассказывать, что способа вычислить "частоту" импульсов без усреднений вообще не бывает?
Не нужно рассказывать - не бывает.
Просто - есть.
Сергей Мих
10.01.2016, 20:16
FREQ_MEASURE
Данный функциональный блок измеряет (усредненную) частоту (в Герцах) входного сигнала типа BOOL. Вы можете задать количество периодов для усреднения. Под периодом понимается время между двумя передними фронтами сигнала.
А Уж частоту перасчитываем в объём от веса импульса.
Так как же всетаки все это можн оприменить в CFC?
...
Ну вот, здравые голоса. С ключевыми словами
время между... фронтами сигнала
Так как же всетаки все это можн оприменить в CFC?
Так же как и в ST. Вызвать с передачей параметров.
Сергей Мих
10.01.2016, 20:41
См. мой проект, в нём Функц. блок "Freq_metr" на CFC для подсчёта мгновенного расхода, накопительного за предыдущий час ...
21693
Владимир Ситников
10.01.2016, 21:44
FREQ_MEASURE
Данный функциональный блок измеряет (усредненную) частоту (в Герцах) входного сигнала типа BOOL
Вы его код видели?
Как думаете для чего у FREQ_MEASURE выход VALID?
И знаете, что если между двумя импульсами будет "очень большая задержка", то блок просто перейдёт в VALID=FALSE состояние и значение OUT вообще меняться перестанет.
А после этого блок опять станет копить "нужное количество импульсов" для усреднения.
Посмотрел проект -- там вообще PERIODS==1.
Т.е. использовать блок FREQ_MEASURE для того, чтобы вычислить 1/интервал_между_двумя_импульсами это сильно.
В проекте "Объём прогозируемый за час" это "текущая скорость * 3600с".
Понимаете чем это отличается от "средний расход за последний час"?
Просто - есть.
И какой же ваш простой способ?
Я смотрел на код freq_measure, и понял, что он может иметь смысл только для каких-то специфических требований. А если "просто посчитать частоту", он непригоден.
Так как же всетаки все это можн оприменить в CFC?
В чём вопрос?
Создаёшь program и task для вычисления средних (см мой код или приложенный проект).
Результат используешь как averages.last1m в том месте, где нужно. Хоть в cfc, хоть где.
Сергей Мих
10.01.2016, 23:17
Вы его код видели?
Как думаете для чего у FREQ_MEASURE выход VALID?
И знаете, что если между двумя импульсами будет "очень большая задержка", то блок просто перейдёт в VALID=FALSE состояние и значение OUT вообще меняться перестанет.
А после этого блок опять станет копить "нужное количество импульсов" для усреднения.
Посмотрел проект -- там вообще PERIODS==1.
Т.е. использовать блок FREQ_MEASURE для того, чтобы вычислить 1/интервал_между_двумя_импульсами это сильно.
.
Это стандартно.
Если- Расхода нет? Вы идеалист . Но конечно, Freq_measure выходит на максимум-65535, которые я отсекаю в Скаде. А в качестве показометра текущего расхода его хватает. Узел учета- не комерческий. Для ответственных дел- ВКТ-шки, Питерфлоу...
Владимир Ситников
10.01.2016, 23:48
Если- Расхода нет? Вы идеалист . Но конечно, Freq_measure выходит на максимум-65535
Я программист. Если что-то плохое может случиться, то оно обязательно случается.
Поэтому и считаю, что "экспоненциальное усреднение" должно быть базовым блоком.
Два умножения и одно сложение. Просто как, простите, валенок, и ломаться там нечему.
Т.е. использовать блок FREQ_MEASURE для того, чтобы вычислить 1/интервал_между_двумя_импульсами это сильно.
Это не сильно. Это максимально точное получение мгновенного расхода в общем случае.
А для некоторых частных - есть еще там PERIODS. А совсем узкие (высокочастотные) задачи - решаются другим железом (например модули с 10кГц) или аппаратно (см. быстрые di)
Как думаете для чего у FREQ_MEASURE выход VALID?
1. До второго импульса - расход не валид. Абсолютно правильно.
2. Нет импульсов в течении 3периодов. Это да - не гибко. Ну так и свет клином на freq_measure не сошелся. Все мы тут - программисты. Или Вы думали что форум проктологов ?
А если "просто посчитать частоту", он непригоден
Боюсь сказать - Ваш способ не то чтобы не пригоден, вообще непонятно что касаемо мгн.расхода. В отличие от адекватных, в определенных пределах, показаний freq_measure.
Почему не понятно ? Так определитесь с размерностью Вашего результата.
Господа споры спорами а до дела так и не дошло ни у кого. Дайте же уже кто нибудь кусок кода cfc для счетчикаи не замудреного для чайника!!:cool: либо чтоза библиотека где этот блок лежит
Ваш вопрос зажил отдельно от Вас ))
Какой блок-то ? freq_measure в util.lib
Владимир Ситников
11.01.2016, 00:35
Это не сильно. Это максимально точное получение мгновенного расхода в общем случае.
Можно ссылку на источник информации о "максимальной точности"?
Я приводил пример, когда:
что при обнулении количества импульсов (а происходит это раз в 30 секунд) частота плавает в диапазоне +/- 30% первые 3 секунды, пока не наберется достаточно количество импульсов для точного подсчета.
И где хвалёная "точность" по всего двум импульсам? Там человеку 3 секунд не хватает. А тут предлагается "по двум точкам оценивать скорость".
Боюсь сказать - Ваш способ не то чтобы не пригоден
А чего же этот способ везде используют?
https://en.wikipedia.org/wiki/Exponential_smoothing
Exponential smoothing is a rule of thumb technique for smoothing time series data, particularly for recursively applying as many as three low-pass filters with exponential window functions. Such techniques have broad application that is not intended to be strictly accurate or reliable for every situation. It is an easily learned and easily applied procedure for approximately calculating or recalling some value, or for making some determination based on prior assumptions by the user, such as seasonality...
Переводить слова "rule of thumb" нужно?
А теперь давайте поищем в wikipedia что-нибудь на тему freq_measure?
Почему не понятно ? Так определитесь с размерностью Вашего результата.
Размерность результата -- "импульсы/сек".
У всех трёх переменных last1m, last1h, last1d одинаковая размерность.
Чего тут неопределённого-то?
Если расход стабилен, то все три переменные будут одинаковые.
Если прорвало трубу, то показатель "last1m" быстро поползёт вверх, а last1d будет какое-то время на старом значении.
Владимир Ситников
11.01.2016, 00:36
Дайте же уже кто нибудь кусок кода cfc для счетчикаи не замудреного для чайника!!
Зачем CFC-то? Есть пример ST кода. Чем он не подходит?
Уточню: никто не запрещает на ST иметь одну-единственную программу именно для "вычисления средних", а всё остальное делать на CFC.
В чём необходимость усреднять именно на CFC?
Можно ссылку на источник информации о "максимальной точности"?.
Я. Просто я.
Хоть я и программист, но не забыл физику и математику.
Обратите внимание на размерность частоты : Гц. Они же с^-1
А в какой момент мы получаем информацию об очередном герце ? только по фронту импульса.
В другие моменты мы может только фантазировать.
И только в момент очередного "герца" мы может получить информацию о самом последнем и наисвежайшем интервале между последними "герцами"
Я приводил пример, когда: Там человеку 3 секунд не хватает..
Ключевые слова. "Там человеку .. не хватает". Другим хватает.
А теперь давайте поищем в wikipedia что-нибудь на тему freq_measure?
.
Про меня (и Вас) там тоже ничего нет. И про суслика нет. А он есть.
-------------------------------------
Вот Вам генератор
t(in:=not t.q, pt := t#1s);
А теперь давайте поищем.
...просто прямую частоты. Прям в визуализации. Прям в эмуляции. (на незначительные колебания глаза закрою ессно, всеж нг только/только)))
Увеличим время раза в два - поищем снижение прямой примерно на столько же.
А чего же этот способ везде используют?
https://en.wikipedia.org/wiki/Exponential_smoothing
.
Дикие люди. Чего с них взять.
Герц - частота повторения сигнала во временном промежутке = 1 секунде.
Как можно определить частоту по двум фронтам сигнала с неизвестным временем ?
И еще вопрос, в течении секунды несколько раз открывали и закрывали краны и расход менялся, то есть мы за секунду получаем не меандр а хаотичные во времени импульсы - на кой тут мерять частоту, если она изменчива ?
Владимир Ситников
11.01.2016, 10:05
Я. Просто я.
Хоть я и программист, но не забыл физику и математику.
Обратите внимание на размерность частоты : Гц. Они же с^-1
Теорему Котельникова (https://ru.wikipedia.org/wiki/Теорема_Котельникова) помните?
Теорема Котельникова: ...Разумеется, реальные сигналы (например, звук на цифровом носителе) не обладают такими свойствами, так как они конечны по времени и обычно имеют разрывы во временно́й характеристике. Соответственно, ширина их спектра бесконечна.
Перевожу с русского на русский: в реальном сигнале бесконечно много частотных гармоник.
И их там много не из-за того, что "не бывает источника постоянной частоты", а из-за того, что невозможно измерить сигнал бесконечной длительности.
А в какой момент мы получаем информацию об очередном герце ? только по фронту импульса.
В другие моменты мы может только фантазировать.
Не существует способа <<получить информацию "о герце">>.
Спектр сигнала можно выяснять математически, но "напрямую снимать герцы" невозможно.
Проблема выяснения плотности вероятности является фундаментальной проблемой в науке: https://en.wikipedia.org/wiki/Kernel_density_estimation
Если бы был известен способ "напрямую снимать герцы", он непременно появился бы в этой статье.
-------------------------------------
Вот Вам генератор
t(in:=not t.q, pt := t#1s);
...просто прямую частоты. Прям в визуализации. Прям в эмуляции. (на незначительные колебания глаза закрою ессно, всеж нг только/только)))
Увеличим время раза в два - поищем снижение прямой примерно на столько же.
Вот что получается у меня в эмуляторе.
Исходный вариант.
21695
Ну, ждать несколько минут "выхода на режим у меня терпения нет", поэтому на двух следующих я показываю 10с-усреднение.
Вот генератор "1Гц"
21696
Вот генератор "2Гц"
21697
Зоркий глаз заметит, что "1Гц" при усреднении получается 0.9Гц (см первую и вторую картинку -- там last1m равно 0.9).
Как же так? А всё просто: глючит CoDeSys -- неправильно работают таймеры.
На графиках красные линии идут раз в минуту.
1-ая картинка: за чуть большее чем 5 минут время насчиталось 289 импульсов.
Т.е. реальная частота заведомо меньше, чем -- 289/(5*60) == 0.96. Результат усреднения -- 0.9
2-ая картинка: за 4 минуты 225 импульсов. 225/(4*60) == 0.93Гц максимум. Результат усреднения -- 0.9
3-я картинка: за 4 минуты 404 импульса. 404/(4*60) == 1.68Гц. Результат усреднения -- 1.6.
Во всех случаях показатель last1m сошёлся к "delta". Переменная delta -- это количество импульсов за "последние 10 секунд".
Тут я опираюсь на то, что если указал T#10s в task configuration, то считаю, что задача раз в 10 секунд и будет выполняться.
Возможно, не стоит доверять task configuration'у, а при усреднениях явно получать текущее время.
Владимир Ситников
11.01.2016, 10:35
И еще вопрос, в течении секунды несколько раз открывали и закрывали краны и расход менялся, то есть мы за секунду получаем не меандр а хаотичные во времени импульсы - на кой тут мерять частоту, если она изменчива ?
Не-не-не, Девид Блейн.
В тех задании сказано "измерять расход" -- надо измерять. И отмазка "частота импульсов изменчива" липовая.
Другое дело, что во многих случаях нужно использовать не сырые измерения, а сглаженные: скользящее среднее, эксп. сглаживание, фильтр низких частот. Все эти механизмы об одном и том же.
Будет ли лучше, если брать показатели "1/интервал_между_последними_импульсами" и сглаживать их? Хз. Но гонять функции даты/времени/математику только ради того, чтобы обработать каждый импульс может и быть расточительным.
не, надо считать количество импульсов в секунду и измерять расход, принять мгновенный расход исходя из времени = 1 секунды и не заморачиваться частотой, которую высчитать невозможно.
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot