Валерий Б
Forum Professor / Завсегдатай форума
Участник № / Member № 377
отправлено / posted
Как повысить точность подсчета используя интегратор? пример: Создал для проверки пустые каналы,где задал "расход" отработать при старте 0.000278(х 3600= 1м3/час) и подал это значение на вход интегратора накопление величины (и её обнуление)происходят 20 часов последующих суток. Таким образом должно получиться 24,0192 но интегратор выдает 23.029509 что составляет около 4%процентов
Сообщения / Posts 262 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Baikal_1
Junior Member / Новичок
Участник № / Member № 3959
отправлено / posted
Валерий Б, а почему вы умножаете на 24, т.е. 0.000278*3600*24? Вы же пишете, что 20 часов последующих суток, т.е. должно быть 0.000278*3600*20, так ведь? Тогда и результат будет другой = 20.016, что тоже отличается от ваших реальных значений Сообщения / Posts 18 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Валерий Б
Forum Professor / Завсегдатай форума
Участник № / Member № 377
отправлено / posted
В спешке, возможно моя мысль была выражена не совсем ясно. Я хотел сказать, что пересчет канала делается каждую секунду. Наступление события (обнуление интегратора) происходит в 20часов. Сам период подсчета составляет 24 часа, просто окончание/начало суток у нас принято делать в восемь вечера.
Сообщения / Posts 262 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Причин для появления погрешности 2.
1. Нестабильность цикла обработки канала с интегратором. Это можно в значительной мере устранить, задав цикл обработки канала 1 сек. при общем цикле обработки базы каналов, строго целое число раз умещающемся в 1 сек., например, 10*0.01.
2. Вычисление в блоке интегратора осуществляется в формате FLOAT. Когда накопленная сумма на несколько порядков превышает интегрируемую величину, за счет выравнивания порядков при суммировании возникает естественная погрешность. В перспективе такой процесс может вообще перестать суммировать. Надо в таком случае менять алгоритм интегрирования. Например, для приведенной конкретной задачи надо ограничить интегрирование величиной "1" (сбрасывать интегратор по достижении 1), а затем отдельным блоком считать количество сброшенных единиц. Конечным результатом будет сумма счетчика и интегратора. Накапливаемой погрешности не будет, но точность результата все равно будет ограничиваться форматом FLOAT (6 значащих цифр).
Кстати говоря, в Trace Mode 6 внутренние арифметические операции осуществляются в формате DFLOAT, поэтому в интеграторе точность вычислений существенно выше.
Сообщения / Posts 17316 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Валерий Б
Forum Professor / Завсегдатай форума
Участник № / Member № 377
отправлено / posted
1.Мой канал обрабывается -1 раз секунду, период пересчета базы по умолчанию стоит 10, изменю разрешение на 0.01 (выясню для себя,насколько это в % выражении отразится на результирующей величине)
2 Однако мудрено получается...и не совсем понятно для описанного модуля, какой у него все таки будет доверительный интервал (класс точности). Точность результата шесть значащих цифр- это мантисса?
ТМ6..., что значит существенно выше, как это будет выражено в относительной погрешности?
Хотелось бы подчеркнуть, что в приведённом мною примере входная величина статическая - идеальная. В реальности такое найти трудно. Как известно выборка динамических величин осуществляется разными методами, отсюда будут дополнительные искажения, что в целом ухудшает метрологические характеристки такого тега
Почти риторический вопрос... Почему нельзя написать и сертифицировать модуль для учета пара, воды, газа? Сделайте и продавайте его в дополнение к своим продуктам, желающих думаю будет достаточно. Сегодня на рынке почти(совсем?) невозможно найти сетевых вычислителей, т.к. цифровая метрология, как класс существует лишь в виде баек о снежном человеке. Что мешает Адастра программно построить вычислитель на базе того же ТМ6 (в качестве HOST узла)и распределенной сети используя сетевые датчики расхода, давления температуры..? Мне кажется эта потребительская ниша очень востребованна,а поляна у производителей совсем не топтана
Сообщения / Posts 262 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
2. Trace Mode 6 использует Double Float. Т.е. по идее точность выше в десятки миллионов раз.
Если бы суммируемая величина не использовала такое количество знаков после запятой (а они значащие), то точность была бы выше.
Попробуйте суммировать 278, а потом делить на миллион.
3. Отдел ТП не может рассуждать на эту тему. Если есть заинтересованность в таком модуле, напишите на эту тему на sales@adastra.ru. Возможно при обсуждении этого вопроса сгенерируются какие-то идеи или продукты.
Сообщения / Posts 17316 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Валерий Б
Forum Professor / Завсегдатай форума
Участник № / Member № 377
отправлено / posted
Изменил алгоритм интегрирования по вашей методике(2), точность интегратора изменилась и стала лучше 0.5% Единственное, в чем пока не разобрался,это с источником случайной погрешности. В целом полученными результами доволен,спасибо.
Сообщения / Posts 262 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[duno / незнайка]](graemlins/duno.gif)
