Думаю, что надо считать в целочисленном формате (32 битным счётчиком), с плавающей запятой будут проблемы больше 5 значного числа, в любом случае.
Даже по варианту Алгоритм_Кэхэна. И дело тут не в реле, а в представлении Float.
В промышленных счётчиках используют комбинированный вариант, целое до запятой и Float после запятой.
Последний раз редактировалось kondor3000; 02.03.2024 в 17:59.
kondor3000, 1exan, спасибо за идеи, ушел в реализацию )
ошибка действительно вылезает в блоке fMUL, а там есть оговорка - "Если во время выполнения операции функции значение числа получается больше 4294967295 (32 бита), то биты, выходящие за разрядность 32 бита, отсекаются."
придется вычислять целую и дробную отдельно,...
У меня получилось так 1 Вывод счётчика.jpg
kondor3000, спасибо, красивое решение!
пока закину счетчиком в целых (на панели будет основная - как и было в кубах = счетчик, для ввода = в литрах) - за то простопросто )))
Последний раз редактировалось nnov4k; 02.03.2024 в 23:11.
она мне не нужна - чтоб базу не засорять я забираю её модбасом один раз в час и строю почасовой лог потребления воды, газа, электричества (это "домашняя" автоматизация, на работе да - каждое изменение по МЭК 104 с дискретом 0,1% ДИ с хранением в 3 года с десятков тысяч приборов)
в ситуации с, считаю, запланированной ущербностью математики, закрепленной оговоркой в РЭ в целях загнать всех с ПР на ПЛК, я ошибался с точностью и у меня не сходились, условно, накопительные итоги - Вы правы, это критически важно и потребовало внесения изменений в алгоритм для корректной обработки в рамках МОИХ диапазонов измерений, а сейчас накопления считаются точно, могу получить ошибку исключительно при снятии показания в 5м знаке при разрядности эталонного счетчика в 3 знака после запятой, при этом не накапливая ошибку... в общем то не принципиально
Что не так в строке ?