Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Хотелось не допускать попадание заведомо не корректных данных в отчетные формы.
А именно, не выводить отрицательные значения обьема топлива на конец отчетного периода, а осуществлять замену отрицательных величин в таблице на ноль.
P.S.
Реальные данные от датчика уровня приходящие на сервер на конец периода) = НОЛЬ
GuardMagic было бы неплохо глянуть на шаблон - что и как у вас настроено + на сам объект, его сообщения.
Я так понимаю sold - это расходомер? а intial и final расчитаны на его основе?
Я так понимаю sold - это расходомер? а intial и final расчитаны на его основе?
Доброе утро!
Спасибо.
Отправлено в ЛС
бензовоз. Три независимых секции
Это датчики уровня топлива.
Initial - начальное значение на отчетный период
Sold (не правильно названо) - отпущено
Final - остаток на конец отчетного периода (как я понимаю, рассчитывается на основе "Sold" )
вы в таблицах тарировок датчиков пропишите нижние значения например 0 - 0 и у вас такого не будет
вы в таблицах тарировок датчиков пропишите нижние значения например 0 - 0 и у вас такого не будет
Разумеется это есть в тарировочной таблице.
И данные от датчика приходят валидные, = т.е. когда цистерна пустая, то и приходят нулевые значения от датчика.
Как понимаю, вся проблема состоит именно в том, что остаток калькулируется как = начальное значение - минус разгружено по датчику.
А в силу некоторых причин (начиная с того, что бензовозы разгружаются полностью, - без остатка, ит.д, )такая арифметика в бензовозах не работает и ...
И появляются в остатках цифры, которые более , чем смущают потребителей.
По этому и появилось предложение - не давать формировать в отчетах не валидные величины (а именно отрицательные значения уровней в отчетах).
И будет проще настраивать конкретные отчеты.
Спасибо за предоставленный доступ.
Как и предполагалось, в основе - таблица "сливы".
Нач. и конечн. уровень в ней - это как раз пересчет с учетом объема - т.е. при выводе данных система предполагает, что объем топлива будет именно таким.
Полечить довольно просто - ставим расход по времени и заправки/сливы по нему же. Для объекта **203*** выставил его в нужные значения. Отдельно порекомендовал бы снизить степень фильтрации с 50 до хотябы 10 + пересмотреть минимальные объемы сливов/заправок - все-таки 500 и 200 наверное многовато, но вам естественно видней, какая точность у вашего оборудования.
Данные за месяц выровнялись
Beginning End Sold Initial Final Sensor name
2016-04-02 20:00:27 2016-04-02 20:00:27 12049 л 12171 л 122 л Cargo Tank 2 (digital)
2016-04-02 20:00:27 2016-04-02 20:00:27 11932 л 12024 л 93 л Cargo Tank 3 (digital)
2016-04-02 20:00:57 2016-04-02 20:00:57 12165 л 12353 л 188 л Cargo Tank 1 (digital)
2016-04-08 16:48:44 2016-04-08 16:48:44 11432 л 11659 л 227 л Cargo Tank 3 (digital)
2016-04-08 17:27:49 2016-04-08 17:28:45 11701 л 11931 л 230 л Cargo Tank 2 (digital)
2016-04-08 23:34:20 2016-04-08 23:34:20 12047 л 12282 л 235 л Cargo Tank 1 (digital)
2016-04-16 06:55:06 2016-04-16 06:59:37 13829 л 13878 л 48.78 л Cargo Tank 3 (digital)
2016-04-16 06:54:06 2016-04-16 08:59:25 13841 л 14024 л 183 л Cargo Tank 2 (digital)
2016-04-16 08:57:40 2016-04-16 08:59:25 13921 л 14865 л 944 л Cargo Tank 1 (digital)
2016-04-16 15:38:03 2016-04-16 15:38:03 303 л 518 л 215 л Cargo Tank 1 (digital)
У второго объекта секция датчиков уровня топлива не активирована, следовательно его настройки не менял - если это будет необходимо, можете привести их в соответствие с первым.
Ну и как отдельное дополнение - доработка функционала Wialon Pro завершена в январе 14-го года. С тех пор новых функций не добавлялось, поэтому если вы не планируете менять платформу, все-же придется получать максимум возможного тем функционалом, который есть. Тем более, что в данном случае решить вашу проблему им действительно возможно.
Полечить довольно просто
спасибо, будем продолжать играться ..
Самое главное, что цистерна то после сливов на самом деле пустая совсем =
