Алгоритм обработки числоимпульса.

[ASUTP_PLC]

Подскажите с алгоритмом обработки.

Типичный распространенный пример: имеем расходомер. Как я понимаю каждый импульс приходящий просто эквивалентен определенной порции объема.

Сумматор ясно легко реализуется. А как перейти к расходу? Ведь полюбому надо считать время таймером. Ведь импульс может прийти через черте сколько времени, а может и быстро. И расход однозначно разный.

Какие требования нужны чтоб точно выдать расход? Как я понимаю, это как счетчик электроэнергии советских времен. Типа 50 оборотов - 1 кВт/час.

Но разве можно от таких щелчков получать измерение той же мощности если мощность будет 1 оборот в два часа (три, ..... десять)? Разве так можно?

[alex_ugrumov]

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

[ASUTP_PLC]

Были такие заказчики... Кто и как и где решил что это все просто и ясно...

Нихрена это не просто и не ясно. Может я букварей не читаю. Но когда говорят что это элементарные вещи мне это вообще не понятно. Ткните в буквари где
эта элементарщина описывается.

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

Можно ли считать дискретно время как целочисленные тики, чтоб в итоге получить расход?

Вопросов к сумматору тут нет. Суммируем, и в сумме имеем тоталный счетчик. Но насчет даже обычного замера времени /если это 60 дискретных входов/, это помоему сродни сумашествию.

[alex_ugrumov]

мы делали так. под каждый ввод заводите буфер например на 10 точек (конкретная величина определяется при наладке). Точка состоит из значения счётчика и метки времени. Метку времени можно сохранять как целочисленное значение, с максимально возможной для Вашего контроллера точностью (например 1мкс) из RTC часов. Таймер не нужен.
Буфер работает как циклический, нужно сохранять указатель куда сохранили последнюю точку.
Работает это так: на каждом цикле Вы записываете новую точку (значение и метку времени)на место самой старой сточки, перемещаете указать конца. Для получения расхода нужно разделить разницу в значения счётчика между новой точкой и самой старой на разницу времени. Вычисление в принципе можно вести целочисленные (может предварительно приращение счётчика умножить на повышающий коэффициент 10,100,1000). Всё. Нагрузка на процессор никакая. Ну только ещё нужно проработать момент запуска когда статистика не накоплена ещё.
Из плюсов - обновление расхода на каждом шаге. Нет всплесков вызванных малым приращением времени. Нет дикой пульсации скорости.
Минус - привнесение инерционности.
Ещё мощный плюс: возможность простым методом повысить точность. В этом расчёте скорость определяется по линейной интерполяции. Но у нас много точек. Сейчас мне формулу лень соображать но идея такая: берём самую старую точку, самую новую и посередине. по ним строим параболу и сморим её наклон (производную) в самой молодой точке. Я уверен что если это расписать, то к приведенным выше расчётам прибавиться пара сложений/умножений. Я сейчас вспомнил, так мы и считали, по производной от интерполяции 2-й степени (конечно считали по заранее подготовленной формуле, параболу каждый раз разумеется не строили, но идея именно такая), но лень искать сейчас формулу.
Если известно из начальных условий , что расход меняется медленно можно сохранять новую точку не каждый раз, а с прореживанием.

[Никита]

Вы бы это.. Заказчику-то пояснили что с сертификацией на коммерческий учет будут проблемы... И Вас же с вашими алгоритмами они потом во ВНИИМС и отправяь. Лучше взрослое УСПД предгагать, а там это все уже есть...
А то повадились гады - нам только технический учет, никаких документов, все только для себя... А через год начинается...

[Михайло]

Расход = число импульсов / промежуток времени
Устройства измерения времени обычно считают время с о-о-очень большой точностью, а вот дискретность числа импульсов дает о себе знать довольно прилично. Число импульсов отклоняется от измеряемой величины максимум на полкванта в ту или иную сторону, поэтому погрешность, связанная с квантованностью числа импульсов равна:
погрешность измерения расхода = плюс/минус 0,5 * (1 / промежуток времени).

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

[Владимир Кузнецов]

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

[ASUTP_PLC]

А именно на языке релейных схем ее и нужно решать. Было бы все попроще, если бы это не с бумаги надо было решать. Слишком общее решение и без конкретной детализации все помоему теряет смысл.

[ASUTP_PLC]

Вы бы это.. Заказчику-то пояснили что с сертификацией на коммерческий учет будут проблемы... И Вас же с вашими алгоритмами они потом во ВНИИМС и отправяь. Лучше взрослое УСПД предгагать, а там это все уже есть...
А то повадились гады - нам только технический учет, никаких документов, все только для себя... А через год начинается...

Что такое есть УСПД? Как я вас понимаю... Вначале только технический учет... дескать решение технологических задач, а потом и все метрологические проблемы уже оказываются на вашей шее...

[Barsik]

Дурацкий вопрос у меня. В каждом приличном расходомере есть аналоговый выход расхода 4-20 ма, почему его не использовать? Если конечно задача ставится типа "как из веревочной петли и палки создать продукт мирового уровня" то тут конечно да, есть над чем подумать))

[ASUTP_PLC]

Вопрос кстати не дурацкий. Там где этот самый аналоговый выход имеется, он и задействован.
А такие расходомеры /где только импульсы/ как раз таки модификации того самого... И чего с этим делать х.з.

Кстати, именно такие претензии на мировой уровень/мировое господство/ может и не случайно, но для очень крупных объектов.
Уж почему так. Мелкие заказы как то просто проходят, ну не купят н-дцать/или н-сотен/, ладно достанут немного /того чего надо/, и без претензий /а деньги появятся так докупят/.

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

[Михайло]

А именно на языке релейных схем ее и нужно решать. Было бы все попроще, если бы это не с бумаги надо было решать. Слишком общее решение и без конкретной детализации все помоему теряет смысл.

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

[Никита]

Дурацкий вопрос у меня. В каждом приличном расходомере есть аналоговый выход расхода 4-20 ма, почему его не использовать? Если конечно задача ставится типа "как из веревочной петли и палки создать продукт мирового уровня" то тут конечно да, есть над чем подумать))

По той же причине, о которой я писал выше. Данные с аналогового выхода, если их интегрировать, будут отличасться как минимум на последние разряды АЦП. В преобразователях с двойным преобразованием это будет всегда, даже если сам токовый выход повторяет сигнал идеально... И попробуйте объяснить теткам из Сбыта про классы точности и допустимую погрешность...
Я с этим столкнулся на узле из двух расходомеров, извиняюсь, говна на очистные. Тоже сначала подход"нам для себя видеть", подешевле, без сертификатов... А потом почему данные с ваших приборов та сторона не принимает? А там такие же простые тетки приходят и с индикатора расходомера списывают накопленный объем, а потом сравнивают его с ведомостью. И если про то, что списывать надо в определенной время удалось объяснить, то про разницу в крайних разрядах - ну ни в какую... Пришлось убирать синнал 4-20, ставить дискретный счетчик и с него данные уже передавать наверх...

[ASUTP_PLC]

Я сталкивался и с интегрированием аналогового сигнала. Хорошо что технологических задач это касалось.
Поползновения были и есть на метрологию. Просто это было более внутреннее дело, чем подсчет объемов канализации для ЖЭКа...
Я сам незнаю, если б ко мне такие бы тетки пришли, я бы им кориолиссы бы насоветовал... Был бы точный массовый расход... Еще бы и плотность бы снимали...
Только я не знаю таких теток с ЖЭКа, цену на корриолис узнают сразу уйдут...

[Никита]

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

[Владимир Кузнецов]

В каждом приличном расходомере есть аналоговый выход расхода 4-20 ма, почему его не использовать?

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

Не совсем так (совсем не так :)).
Дело даже не в погрешности преобразования аналогового сигнала (десятые доли процента), а в самом принципе.
При интегрировании мгновенного расхода основная погрешность возникает по причине замены реальной функции q(t) ее дискретными значениями в узлах аппроксимации.
Для точного интегрирования нужно что бы значения мгновенного расхода получались максимально часто и через строго определенные интервалы времени.
Частота опроса должна превышать время за которое расход может измениться.
Не желательно что бы время опроса каждого конкретного счетчика превышало одну секунду.
Вот примеры оценок вносимых погрешностей применительно к учету в ЖКЖ:
http://www.sempal.com/fileadmin/Documen ... a_ISPR.pdf
http://cherryblack.ru/sir/Part02/metrology0906.htm

В обоих случаях авторы приходят к выводу, что интервал опроса нужен не более 0,5 с.

[Никита]

Вот эти десятые доли процента и давали разницу в единицы литров говна. Причем в разные стороны в разное время. И когда это все надоело - уже было предложение все за месяц подбить, а оставшуюся разницу в ведре перенести в нужную сторону... А с опросом все нормально, на два канала можно было смело 200мс опрос делать...
Тож самое и по теплу.. Но когда подача больше обратки - проще, можно списать на подпитку... А вот если наоборот .Это уже начинают искать дыры в теплообменниках...

[Looker]

Расход = число импульсов / промежуток времени

Еще один таймер нужен! С временем бОльшим, чем промежуток времени, иначе при малых расходах одиночный импульс будет давать иголку, а надо "размазать" на несколько промежутков времени.
См. Lad для Logix (код Add-On Instruction), deltaTime определяется один раз для всех вызовов этой AOI, FlowCounter - значения с аппаратного счетчика импульсов (32 разряда), "размазывание" идет с учетом времени TimeBetweenPulse:

[Никита]

Я сам незнаю, если б ко мне такие бы тетки пришли, я бы им кориолиссы бы насоветовал... Был бы точный массовый расход... Еще бы и плотность бы снимали...
Только я не знаю таких теток с ЖЭКа, цену на корриолис узнают сразу уйдут...

Там хорошо работали корреляционные ДРК. Они вообще разрабатывались на всякое дерьмо и чем его больше - тем лучше. Проблема была другая - после узла учета - длинные дюкеры под Волгой и постоянные войны службы КИПиА и службы сетей. Первым нужны тонкие участки и большие скорости, вторым - минимальные потери напора и, соответственно, минимальные сужения на участках.
Единственное - только напорные сети, с воздухом эти приборы не работали. А в канализации такое иногда бывает, даже не воздух а метан. Но как только решили вопрос с его сбросом - все отлично стало... Воздух сбрасывали прямо в насосной... Вонишща - на триста метров вокруг :)
Но и кориолисовы таких режимов не любят...

[Barsik]

Не совсем так (совсем не так :)).
Дело даже не в погрешности преобразования аналогового сигнала (десятые доли процента), а в самом принципе.
При интегрировании мгновенного расхода основная погрешность возникает по причине замены реальной функции q(t) ее дискретными значениями в узлах аппроксимации.
Для точного интегрирования нужно что бы значения мгновенного расхода получались максимально часто и через строго определенные интервалы времени.
Частота опроса должна превышать время за которое расход может измениться.
Не желательно что бы время опроса каждого конкретного счетчика превышало одну секунду.
Вот примеры оценок вносимых погрешностей применительно к учету в ЖКЖ:
http://www.sempal.com/fileadmin/Documen ... a_ISPR.pdf
http://cherryblack.ru/sir/Part02/metrology0906.htm

В обоих случаях авторы приходят к выводу, что интервал опроса нужен не более 0,5 с.

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

[Владимир Кузнецов]

Ни фига не могу понять что за задачи вы решаете.

Лично мы - расходометрии.
Различные узлы учета углеводородных сред - СИКН, СИКГ.
И различное аналитическое оборудование (поточные хроматографы, влагомеры, анализаторы точки росы).

А что конкретно нужно автору не совсем понятно, но все ему насоветовали чего знали :)
Возможно из-за недопонимания термина "расход".

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

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

[Бондарев Михаил]

А что конкретно нужно автору не совсем понятно

Автору нужен алгоритм скользящего среднего.

[Владимир Кузнецов]

А что конкретно нужно автору не совсем понятно

Автору нужен алгоритм скользящего среднего.

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

[ASUTP_PLC]

Я тут.
Как бы так сказать... Есть определенный набор решений в моем опыте работы в промышленности.
Я понимаю, что нужен нормальный адекватный технолог, асс своего дела.
Он выдвигает требование того что должна делать система, я как интегратор подбираю решение.
На деле обстоит дело так: технологов как таковых не имеется в принципе /именно к этому проекту и к этим задачам/.
Есть хотелки которые выдвигают люди которые работают на этом оборудовании.

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

[Владимир Кузнецов]

Я тут.
Как бы так сказать...

Опишите, если возможно, поподробнее систему.
Что за процесс, учет чего ведется, какие расходомеры и контроллеры применены, чего хотят местные.
Так будет гораздо интереснее :)