Главная › Форумы › Конструкторское бюро › Автоматизация › Автоматика LuckyBox › Универсальные весы самогонщика
-
АвторСообщения
-
24.10.2019 в 23:41 #51564
Андрей
Попробуй еще добавит цифровую фильтрацию для измерений:
scaleOut = scaleOut – (scaleOut/n) + (scaleIn/n);
где:
scaleOut – вес для обработки результата (он же на экране и остальных расчетов)
scaleIn – вес полученный при измерении ( units = scale.get_units(1) * 0.035274 )
n – степень фильтрации/сглаживания (на практике от 2 до 6, далее уже перебор по времени получения искомого результата, я использую 4-ю степень фильтрации)p.s. Забыл добавить, в данной формуле есть некоторые нюансы при старте измерений малого веса. Если заинтересует и будет что то не понятно, поясню далее.
25.10.2019 в 20:23 #51590Я на эту фильтрацию потратил уйму времени. Для измерения спиртуозности нужна очень высокая точность, поэтому
Сначала медианный фильтр на 7 значений, который позволяет отбросить до 3 нестроевых значений, причем с задержкой всего в 1 период измерения.
Потом такая же как у тебя формула но с n=10 и приведенными значениями
scaleOut =9* scaleOut/10 + (scaleIn/10); Конечно задержка секунд 15 до устаканивания результата.
А для скорости отбора просто среднее арифметическое всех scaleOut за 10 сек. /точное время между отсчетами. За 10 сек. значений 80-100 усредняется, этого достаточно.
Однако для 10 кг тензодатчика 0,1 гр. это предел. Дальше в погрешность определяется температурным дрейфом нуля
25.10.2019 в 22:41 #51595Однако для 10 кг тензодатчика 0,1 гр. это предел
Для 10кг и 1гр вполне достаточно, зато пляска меньше будет.
Мы же не навеску специй для настоек делаем на этих весах 🙂
25.10.2019 в 23:07 #51599Конечно задержка секунд 15 до устаканивания результата.
Значит “что то не так в Датском королевстве”. Вот специально сейчас снял видосик.
25.10.2019 в 23:55 #51602Значит “что то не так в Датском королевстве”
Походу не в только в “Датском королевстве” что то не так, небольшая пляска показаний всё-равно присутствует. На колличество отбора она вроде бы не влияет, а вот скорость отбора визуально плавает довольно прилично.
Если интересно, в следующий раз сниму и покажу какая пляска на дисплее в окне скорости отбора
26.10.2019 в 09:19 #51613Так с точностью до грамма так и будет. А до 0.1?
Что касается “пляски” скорости отбора. Точность 0.1 Период между замерами массы для определения скорости 10 сек. за 1 час (скорость определяется в мл. час) таких периодов периодов 3600/10=360. Ошибка приведенная к часу будет 0.1*360=36мл. Т.е. даже для самых притязательных это 10% от скорости отбора тела (360мл/час).
Далее к этой ошибке добавится, дергающийся шланг отбора лежащий на краю банки, неравномерность отбора и пр. В вообще то скорость носит скорее справочный характер особенно при дистанционном контроле. Когда просто смотришь на струю скорость наврятли можно определит. А с мензуркой секундомером и калькулятором на это потребуется не 10 секунд , а 3-5 минут. При этом точность будет не выше. Только пляски не будет, поскольку не будет и второго замера.
Если кто решит использовать скорость отбора для автоматики, но ее необходимо усреднять. Тогда время до ее устаканивания возрастет многократно, и такие показания для текущего контроля и/или регулировки станут совершенно непригодны.
26.10.2019 в 23:24 #51636Период между замерами массы для определения скорости 10 сек.
А зачем брать интервал в 10 сек. и пытаться повышать точность единичного измерения? Я же вроде писал, что делаю 2 замера в секунду и накапливаю их в массиве на 120 измерений. Все это естественно со сдвигом при каждом последующем измерении. В итоге расчет скорости отбора производится 2 раза в секунду, но за минутный интервал. В решении любой задачи, должен присутствовать с одной стороны реалистичный, но так же и оптимальный алгоритм.
Далее, Ваша формула: scaleOut =9* scaleOut/10 + (scaleIn/10); совершенно не эквивалентна приведенной мной: scaleOut = scaleOut – (scaleOut/n) + (scaleIn/n);. Вроде капелька отличий, а результат отличается кардинально. Т.к. в Вашем случае, просто усреднение до десятка псевдо измерений с принудительной погрешностью 9* scaleOut/10. Проще было сделать так: scale.get_units(10), почти абсолютно эквивалентно вашей формуле, только что Вы производите усреднение с пред идущим измерением а не текущим. У меня же именно сглаживание результата, до эквивалентного логарифмической функции со степенью n, плюс небольшие “хитрости” на резкое изменение веса.
p.s. Забейте в Excel свою и мою формулы, и занесите хотя бы десяток значений. Будете просто удивлены, что с моей формулой сумма предыдущих значений сойдется, а у Вас нет.
26.10.2019 в 23:48 #51637Андрей
Дополню немного свою “писанину” с пред идущего сообщения. Я ни капли не принижаю Ваш труд, просто немного пытаюсь помочь. Т.к. Ваш вариант, в текущем исполнении, может быть очень полезен дистилляторщикам, особенно на самых простейших аппаратах.
27.10.2019 в 10:29 #51658Далее, Ваша формула: scaleOut =9* scaleOut/10 + (scaleIn/10); совершенно не эквивалентна приведенной мной: scaleOut = scaleOut – (scaleOut/n) + (scaleIn/n);.
Не нужно быть большим математиком чтобы понимать что, scaleOut – (scaleOut/n)=(1-1/n)*scaleOut
Подставьте туда n=10, и получтие 9* scaleOut/10. Или в полном виде scaleOut =9* scaleOut/10 + (scaleIn/10);
А зачем брать интервал в 10 сек. и пытаться повышать точность единичного измерения? Я же вроде писал, что делаю 2 замера в секунду и накапливаю их в массиве на 120 измерений.
Для измерения спиртуозности нужна очень высокая точность, поэтому
Поэтому к измерению скорости точность “единичных” измерений никакого отношения не имеет.
делаю 2 замера в секунду и накапливаю их в массиве на 120 измерений
А почему только два? hx711 позволяет делать 10 в секунду. А зачем накапливать 120 значений целую минуту, если их можно накопить за 10-12 секунд? А зачем вообще расходовать оперативную память на накопление 120 значение да и еще наверное float, если их можно сразу суммировать(накапливать) и хранить в памяти 1 переменную. Зачем накапливать целую минуту и в результате получить задержку от изменения скорости до его отображения в минуту, если это можно сделать за 10-12 секунд?
И вообще, как вы отнесетесь к тому, что я в ветке форума с вашими весами напишу
Ваш вариант, в текущем исполнении, может быть очень полезен дистилляторщикам, особенно на самых простейших аппаратах.
27.10.2019 в 11:44 #51662И вообще, как вы отнесетесь к тому, что я в ветке форума с вашими весами напишу
Абсолютно ни каких проблем в этом не вижу, если сообщение будет относится именно к опубликованным весам )))
А формулы все же в Excel проверь…
А почему только два? hx711 позволяет делать 10 в секунду.
Что то точно с математикой не то. Тактирование цифрового интерфейса либо 80 Гц либо 10 Гц, результат 24-х битный…
p.s. Я так понимаю что советы по доработке Вам не интересны. Больше в данной теме не пишу.
27.10.2019 в 16:03 #51672А формулы все же в Excel проверь…
Проверил, убедился что ты не прав, вложил. Смотри.
Что опять же касается математики, то мои 10 раз в секунду много ближе к 10 Гц чем твои 2. А 80 Гц я пробовал, выигрыша не дают поскольку нужно 8 значений усреднить, чтобы получить разброс значений такой же как при 10 Гц.
Однако посмотрел твой код, и мне ОЧЕНЬ понравилась и твоя “хитрость” и значение скорости как среднее между тем что было минуту назад, и сейчас. С одной стороны это задерживает вывод реальных показаний на более чем 60 секунд против моих 10, и для целей автоматизации процесса как бы зло, но для наблюдателя это комфортно, поскольку все эти 60 секунд, он наблюдает непрерывное изменение значения вплоть до истинного. Это раз. А второе, период изменения 60 секунд, позволяет получить в 6 раз большее разрешение по скорости. Т.е. те самые 6 мл/час, которые нужны некоторым форумчанам.
Так что не премину воспользоваться твоим советом, в разумной его части:)
Вложения:
Вы должны войти для просмотра вложений.27.10.2019 в 17:33 #51677Я же вроде писал, что делаю 2 замера в секунду и накапливаю их в массиве на 120 измерений.
Ну не 2 замера в секунду Вы делаете, а столько сколько возможно пока по вашей терминологии не “гребет” АЦП. А потом эти усредненные значения, два раза в секунду добавляете в массив. И я нахожу все это очень интересным. Пардон.
28.10.2019 в 04:27 #51695Выводы контроллера D1 и D2 свободны, как раз на них датчик давления и можно повесить. На них же желательно и OLED дисплей перевесить, т.к. это выводы аппаратной шины I2C, а не программной как у Андрея реализовано. Вывод контроллера D0 можно использовать как управляющий аварийной группой на отключение силовой части. Освободившиеся D3 и D4 тоже можно куда то приспособить, тут уже пусть остальные хотелки высказывают. Если Андрей надумает ввести в программу корректировку от датчика давления, формулы выдам, чтобы велосипед не изобретать.
Чем больше я в это вникаю тем больше чудес.
Сергей у Esp8266 нет аппаратного I2C и Gpio в принципе это маркетинг, он программный к кому же еще и кривоватый давно и править разрабы не торопятся. Есть пофиксенные библиотеки, если уж совсем криво работает можно заменить стандартные.
modern distiller, разрушаем "каноны")
https://vk.com/club173629256
Я хочу синего джина, я хочу чёрного рома....28.10.2019 в 16:17 #51742Сергей у Esp8266 нет аппаратного I2C и Gpio в принципе это маркетинг
Ну да, и тут китаёзы кинули, глянул их “twi” в либах, действительно ногодрыг (((. Я то глядя на их блок схему модуля решил что I2C как и SPI аппаратный, нормальной документации то на модуль нет.
28.10.2019 в 18:10 #51748А , что значит ногодрыг ) Много где встретил это слово . Но не понял, что это значит)
modern distiller, разрушаем "каноны")
https://vk.com/club173629256
Я хочу синего джина, я хочу чёрного рома.... -
АвторСообщения
- Для ответа в этой теме необходимо авторизоваться.