Ну во-первых: это оригинал, видимо с чего драл китаец. Во-вторых: всё равно колхозить, на макетку паяешь и вперёд... В третьих: сам просил предлагать, а теперь не нравится, определись уже. Я бы вообще попробовал для начала использовать LTC1864 (с которыми я раньше игрался и использовал их для обработки звука, может по разрешению бы подошли при грамотной отстройке операционника по входу (хотя может и Vref-а было бы достаточно).
Я просил то что просил, готовый модуль который можно использовать с тензодатчиком. Иначе это превратится в бесперспективный для меня квест по разработке и запуску платы ацп с наступанием на грабли по питанию и чёрт знает ещё каких. вот там намекают что с LTC1864 слишком просто не будет https://www.arrow.com/en/reference-desi ... d5eca09af5
ЗЫ Долбаные перекупы. В прошлый четверг сделал заказ,обещали в понедельник отправить сдеком, но сегодня уже кончилась среда и заказ ещё в статусе "формируется" Они видимо в китае заказали и ждут теперь.
Заказал бы у меня, я бы смотался в fastnvr на моноколесе и послал бы тебе по почте. Я бы не много накрутил сверху, мне всего-то надо кормить пятерых детей
Myp писал(а):А у тебя ещё остались такие резюки? если в нём например зажав в двух деревяшках дырочку просверлить в центре диаметром 3 мм, он сдохнет или будет работать? по идее если аккуратно просверлить, то у него просто сместится диапазон рабочий.
Ну чтож предварительные результаты - работает. прикрутил миньку чтобы можно было следить за цифрами, срабатывание настроил на 30 у.е. сдвиг оси на 0.1 даёт примерно 400 у.е. с датчика.
на видео проба, срабатывает на лёгкое поглаживание.
заведены параллельно безсенсорный датчик и датчик веса. даже если весы отвалятся, то остановится на безсенсорном датчике, ничего не должно выломать по идее.
надо разобраться с тарировкой щас выставление нуля происходит в момент нажатия ресета на плате. дёргания конструкции приводят к тому что ноль убегает и датчик срабатывает в воздухе. провода по другому провисли и привет, калибровка сбилась. у меня боуден и поэтому в разных точках стола разный натяг буденовой трубки в зависимости от положения может убегать до -200 у.е.
возможно делать после срабатывания? ON/OFF и калибровка в ноль.
как-то так тест повторяемости если предварительно обнулить.
Добавлено спустя 2 часа 20 минут 36 секунд: вобщем надо обрабатывать сырые данные фильтровать всякое разное, в том числе и отрицательное, чтобы срабатывать только когда реально идёт пробинг.
на вентилятор пофиг, от него шум в дробной части, можно просто отбросить.
вот ещё 2 картинки проверка повторяемости M48 с 10 пробами с пределом срабатывания в 100 у.е.
касания очень чётко видно.
и простая парковка по всем осям сначала паркуем X, потом Y, потом едем в центр стола и ось Z паркуем по соплу 2 раза, сначала быстро, а потом точно.
видно плавный уход в минус, это трубка боудена натягивается, потом резкое падение - это при ударе в раму хотенд по инерции покачивается. потом движение в ноль по Y и опять увеличение натяга боудена, ползёт дальше в минус. короткое плато на 900 - пауза перед тем как ехать в центр стола. далее резкий возврат к нулю - резкое движение каретки в центр стола для парковки. Натяг боудена ослабляется и даже видно как коса с боуденом и проводами покачивается плавно затухая в районе 1000. ну и потом 2 сильно положительных пика - быстрая парковка и медленная парковка.
Добавлено спустя 25 минут 45 секунд: Вы наверное спросите, а что там с дрейфом при прогреве? а ничего собственно, при прогреве до рабочей температуры ноль уползает до -10, а после стабилизации температуры возвращается обратно и ползёт к +4. видимо это провода и сама констуркция прогревается и деформируется, можно не обращать внимания.
круто, тока у меня по математике тройка была. как мне теперь из этого зоопарка точек, надёжно детектировать резкий скачок? я все 10 проб засунул в одну картинку, они само собой довольно похожи друг на друга.
как мне в коде имея первые 3 точки, понять что это нужный мне резкий скачок? нужна какаято высокоматематическая магия.
я пока вижу только одно решение, запоминать 3 последние точки и если (val3-val2)-(val2-val1) больше 20, то имеет место быть резкий рост и надо триггерить.
Добавлено спустя 12 минут 58 секунд: но я вот нифига не уверен что это разумно...
//триггерим if (Delta_val > 20) { digitalWrite(LED_BUILTIN, HIGH); } if (i < 80) { digitalWrite(LED_BUILTIN, LOW); } Serial.print("val: "); Serial.println(i); }
ЗЫ сам контроллер кажется тупой, после срабатывания сенсора шаговик успевает сделать ещё несколько шагов до остановки хотелось бы включить прерывание на пробинг оси Z. Но нет //TMCStepper includes SoftwareSerial.h which is incompatible with ENDSTOP_INTERRUPTS_FEATURE
Myp писал(а):круто, тока у меня по математике тройка была.
Myp писал(а):я пока вижу только одно решение, запоминать 3 последние точки и если (val3-val2)-(val2-val1) больше 20, то имеет место быть резкий рост и надо триггерить.
Вас, глубокоуважаемый Фёдор Анатольевич, можно поздравить, Вы только что открыли для себя дифференцирование. Нахождение производной функции Вычитанием одной последовательной точки из другой, ты находишь скорость ИЗМЕНЕНИЯ функции. Если продифференцировать твой график, то получится такое:
Чтоб было нагляднее, я зеленый график сместил на уровень 200, для этого графика это ноль. Красные метки - это где функция изменяет скорость, горизонтальные участки на моем графике - это где скорость изменения функции минимальна. Дальше все просто, компаратор на фиксированный уровень. Но есть маленькие ньюнсы Может понадобиться фильтр низких частот, т.к. дифференцирование очень сильно усиливает высокочастотный шум. Но с твоей смекалкой это не будет проблемой. Подсказка: "фильтр скользящего среднего" Если сложно это представить математикой, можно сравнить с последовательным конденсатором небольшой емкости, которая нагружена на резистор. Всплески напряжения на выходе будут ровно как на графике, т.е. конденсатор пропускает только быстрые фронты и спады напряжения...
Добавлено спустя 35 минут 17 секунд: Кста, очень интересная производная более раннего твоего графика
для красоты ещё digitalWrite заменил на PORTB = PORTB | B00100000; ато в интернетах пишут что медленно работает, мы же за каждый чих процессорный боремся. ну и от флоата пожалуй надо отказаться, атож небось тоже жрёт такты на вычитания и перекладывания.
кстати, вот так выглядит давление если пробовать холодным соплом с торчащей из него соплёй =) не сразу понял откуда такие артефакты, увидел тока случайно нагнувшись торчащую завитушку из сопла.
Myp писал(а):для красоты ещё digitalWrite заменил на PORTB = PORTB | B00100000;
Так можно только для записи "1" Но мысль правильная... Все digitalWrite(пин, HIGH) заменить на как у тебя, а все digitalWrite(пин, LOW) заменить на PORTB = PORTB & B11011111
А вообще надо все задефайнить как в исходниках моего датчика:
вот кстати я ещё не лазил в библиотечку работы с датчиком. там при выводе данных например число во флоате забирается из датасета и делится на коэффициент, чтобы получить граммы. ужс прям.
float HX711_ADC::getData() // return fresh data from the moving average dataset { long data = 0; lastSmoothedData = smoothedData(); data = (lastSmoothedData >> divBit) - tareOffset ; float x = (float)data / calFactor; return x; }
но сам забор из датасета вроде не медленный, датасет у меня размером 1, H=L=0 то есть вроде должно быстро забираться.
long HX711_ADC::smoothedData() { long data = 0; long L = 0xFFFFFF; long H = 0x00;
for (uint8_t r = 0; r < (samplesInUse + IGN_HIGH_SAMPLE + IGN_LOW_SAMPLE); r++) { if (L > dataSampleSet[r]) L = dataSampleSet[r]; // find lowest value if (H < dataSampleSet[r]) H = dataSampleSet[r]; // find highest value data += dataSampleSet[r]; } if(IGN_LOW_SAMPLE) data -= L; //remove lowest value if(IGN_HIGH_SAMPLE) data -= H; //remove highest value return data; }
Где отладчик? я требую отладчик чтобы такты на бумажке посчитать.
Добавлено спустя 46 минут 36 секунд: Ах да, забыл добавить принудительное срабатывание при превышении почему-то последний пик получился слишком плавный, получил "маленький" перелёт...