Как повысить точность подсчета используя интегратор? пример: Создал для проверки пустые каналы,где задал "расход" отработать при старте 0.000278(х 3600= 1м3/час) и подал это значение на вход интегратора накопление величины (и её обнуление)происходят 20 часов последующих суток. Таким образом должно получиться 24,0192 но интегратор выдает 23.029509 что составляет около 4%процентов
Posted by Baikal_1 (Участник № / Member № 3959) on :
Валерий Б, а почему вы умножаете на 24, т.е. 0.000278*3600*24? Вы же пишете, что 20 часов последующих суток, т.е. должно быть 0.000278*3600*20, так ведь? Тогда и результат будет другой = 20.016, что тоже отличается от ваших реальных значений Posted by Валерий Б (Участник № / Member № 377) on :
В спешке, возможно моя мысль была выражена не совсем ясно. Я хотел сказать, что пересчет канала делается каждую секунду. Наступление события (обнуление интегратора) происходит в 20часов. Сам период подсчета составляет 24 часа, просто окончание/начало суток у нас принято делать в восемь вечера.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Причин для появления погрешности 2.
1. Нестабильность цикла обработки канала с интегратором. Это можно в значительной мере устранить, задав цикл обработки канала 1 сек. при общем цикле обработки базы каналов, строго целое число раз умещающемся в 1 сек., например, 10*0.01.
2. Вычисление в блоке интегратора осуществляется в формате FLOAT. Когда накопленная сумма на несколько порядков превышает интегрируемую величину, за счет выравнивания порядков при суммировании возникает естественная погрешность. В перспективе такой процесс может вообще перестать суммировать. Надо в таком случае менять алгоритм интегрирования. Например, для приведенной конкретной задачи надо ограничить интегрирование величиной "1" (сбрасывать интегратор по достижении 1), а затем отдельным блоком считать количество сброшенных единиц. Конечным результатом будет сумма счетчика и интегратора. Накапливаемой погрешности не будет, но точность результата все равно будет ограничиваться форматом FLOAT (6 значащих цифр).
Кстати говоря, в Trace Mode 6 внутренние арифметические операции осуществляются в формате DFLOAT, поэтому в интеграторе точность вычислений существенно выше.
Posted by Валерий Б (Участник № / Member № 377) on :
1.Мой канал обрабывается -1 раз секунду, период пересчета базы по умолчанию стоит 10, изменю разрешение на 0.01 (выясню для себя,насколько это в % выражении отразится на результирующей величине)
2 Однако мудрено получается...и не совсем понятно для описанного модуля, какой у него все таки будет доверительный интервал (класс точности). Точность результата шесть значащих цифр- это мантисса?
ТМ6..., что значит существенно выше, как это будет выражено в относительной погрешности?
Хотелось бы подчеркнуть, что в приведённом мною примере входная величина статическая - идеальная. В реальности такое найти трудно. Как известно выборка динамических величин осуществляется разными методами, отсюда будут дополнительные искажения, что в целом ухудшает метрологические характеристки такого тега
Почти риторический вопрос... Почему нельзя написать и сертифицировать модуль для учета пара, воды, газа? Сделайте и продавайте его в дополнение к своим продуктам, желающих думаю будет достаточно. Сегодня на рынке почти(совсем?) невозможно найти сетевых вычислителей, т.к. цифровая метрология, как класс существует лишь в виде баек о снежном человеке. Что мешает Адастра программно построить вычислитель на базе того же ТМ6 (в качестве HOST узла)и распределенной сети используя сетевые датчики расхода, давления температуры..? Мне кажется эта потребительская ниша очень востребованна,а поляна у производителей совсем не топтана
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
2. Trace Mode 6 использует Double Float. Т.е. по идее точность выше в десятки миллионов раз.
Если бы суммируемая величина не использовала такое количество знаков после запятой (а они значащие), то точность была бы выше.
Попробуйте суммировать 278, а потом делить на миллион.
3. Отдел ТП не может рассуждать на эту тему. Если есть заинтересованность в таком модуле, напишите на эту тему на sales@adastra.ru. Возможно при обсуждении этого вопроса сгенерируются какие-то идеи или продукты.
Posted by Валерий Б (Участник № / Member № 377) on :
Изменил алгоритм интегрирования по вашей методике(2), точность интегратора изменилась и стала лучше 0.5% Единственное, в чем пока не разобрался,это с источником случайной погрешности. В целом полученными результами доволен,спасибо.
![[duno / незнайка]](graemlins/duno.gif)