Gnevko

Проблема с потерей микросекунд пролечилась заменой формулы _deltaTimeForNextStep = 1000000 / ((speed * 100) / 625); на _deltaTimeForNextStep = 1000000.0 / ((speed * 100.0) / 625.0); Сейчас посмотрим, как это повлияло на конечный результат

делал, точность до сотки ... но кажется я нашел проблему (см комментарий выше), только не понятно пока как её решить.

Давайте ка я опишу весь алгоритм расчета и выполнения шагов для шагового двигателя в случае синхронной подачи, возможно это так же поможет мне увидеть проблему. Итак 1) Первый этап - вычисление скорости вращения шпинделя: - при срабатывании прерывания измеряем текущее время в микросекундах; - вычитаем полученный результат из предыдущего, получая тем самым разницу между срабатываниями прерываний - вычисляем скорость вращения шпинделя в секунду: 1000000 * 100 / spindleDeltaPhase. Умножение на 100 необходимо, что бы избавиться от чисел с плавающей точкой. Результат, для примера, 146 (то есть 1.46 оборотов шпинделя в секунду) или 87.6 оборотов в минуту. - далее идет вычисление миллиметров, которые должен сделать суппорт за одну секунду: _spindleRevolutionsPerSecond * zAutoFeedSyncSpeed, то есть наши 146 (не забываем про умножение ранее на 100) умножаем на заданную скорость, так же умноженную на 100: 146 * 8 (или 1.46 * 0.08) и получаем, 1168, с учетом умножений на 100 двух множителей - реальное значение 0.1168 мм на оборот. 2) Второй этап - вычисление промежутков между шагами двигателя - Вначале мы делим расстояние, которое необходимо пройти суппорту в секунду на расстояние которое проходит суппорт за один шаг: speed / 0.000625 тем самым получая количество шагов в секунду времени. - Затем делим секунду на это количество шагов: 1000000 / (speed / 0.000625), но помня о том, что переменная speed у нас увеличена в 10000 раз, и желая здесь так же избавиться от плавающей точки в итоги получаем формулу: _deltaTimeForNextStep = 1000000 / (speed * 100 / 625). На нашем примере это должно было бы быть 1000000 / (1168 * 100 / 625) = 5351, а ардуино говорит там, что 5376, что на 25 микросекунды больше чем нужно ... хм ... если резать резьбу на 30мм, то это займет 48000 шагов двигателя, если на каждом шаге терять по 25 микросекунд, то общие потери составят 1,2 секунды ... вот тебе и раз. Теперь бы понять, с какого испугу теряются здесь по 25 микросекунд! 3) Третий этап - собственно алгоритм выполнения шагов выполняется таймером, который тикает каждые 20 микросекунды. - запоминаем последнее время, когда был сделан шаг - если при очередном срабатывании таймера прошло больше времени, чем было вычислено на втором этапе - делаем еще один шаг. - поскольку скорее всего промежуток между шагами на 20 ровно делиться не будет, то вычисляем дельту - на сколько микросекунд шаг был задержан, и делаем следующий шаг с поправкой на эту дельту - то есть быстрее. Задача - найти куда теряются 25 микросекунды на шаг!

Вооружившись измерителем оборотов (пришлось съездить к товарищу за прибором), выяснил следующее: 1) на низких оборотах - показания прибора 168.3 - 168.4 (здесь и далее оборотов в минуту), показания с ардуино - 168.0 - 168.6 2) на "высоких" оборотах - показания прибора 723,1, показания с ардуино - 772.2 - 724.6 3) на сверх низких оборотах - показания прибора 65.4, показания с ардуино 65.4 Таким образом можно сделать осторожное утверждение, что скорость вращения шпинделя вычисляется более или менее точно, и не может повлечь за собой вышеописанное безобразие (во всяком случае в полном объеме оного).

Дык в том то и дело, что все давно уже на прерываниях... https://github.com/Gnevko/Lathe-Arduino-Assistant Правда там я за одно и скорость вычисляю, но по идее времени на расчеты там предостаточно ....

Болт в студию! Ну или резьба для него, M10. И не было бы моей радости, если бы не пришла мне в голову сравнить его с покупным экземпляром. Хм ... шаг, если я правильно понимаю, оказался немного короче выставленного, что означает потерю н-го количество шагов на оборот при вычислениях, осталось только понять где и по какой причине: 1) проблема может уходить корнями в расчет скорости; 2) перевод скорости в шаги двигателя; 3) алгоритм исполнения шагов. Хм ...

Немного подправил

Схема подключения компонент

Добавил описание основных возможностей, реализованных на сегодня: https://github.com/Gnevko/Lathe-Arduino-Assistant/wiki/Описание-возможностей

Спасибо за теплые слова! Сегодня закончил более или менее причесывать код. Старался писать наиболее просто и "читабельно". Однако, пожалуйста не забывайте, что это лишь начало пути и впереди еще много работы как по документированию, так и по расширению функционала. https://github.com/Gnevko/Lathe-Arduino-Assistant

Вы совершенно правы, с этой точки зрения - проблемы нет никакой. Но если вам хочется ориентироваться на показание пройденного расстояния, да еще что бы эти показания были с точностью до сотки, и не трех десятков, то прийдется бороться с люфтом. Так же если выставлять электронные упоры от текущей позиции, то тоже хотелось бы, что бы они соответствовали тому расстоянию, которое потом пройдет суппорт. Думаю, что во многих ситуациях это было бы полезно.

Попробую реализовать второй вариант. Однако при включении системы прийдется всегда делать "тестовое" движение суппортом.

Он самый. Возможно пару соток добавляет и растяжение ремня, но по сравнению с люфтом ходового винта это ничто.

Работа над ошибками. 1) Ловля Бога за бороду оказалась совершенно излишним занятием, после серии экспериментов выяснилось, что второй энкодер для определения скорости вращения шпинделя совершенно излишен и не влияет на качество синхронизации. Последнее видео было снято уже с одним энкодером и соотвественно с одним срабатыванием прерывания на оборот шпинделя (RISING прерывание вызывается только при смене значения на порту с LOW на HIGH). От использования библиобеки в данных целях так же отказался - оказалось это совершенно ненужным. 2) "Дребезг" оптического энкодера. Это стало для меня сюрпризом, особонно тот факт, что срабатывания происходили даже при снятых ремнях (то есть при включенном моторе, но не вращающемся шпинделе), только от того, что выключался мотор! Пришлось использовать конденсатор, подключенный к сигналу энкодера и "земле". Это помогло с дребезгом, но при включенном моторе (постоянного тока) все равно происходили ложные срабатывания энкодера. Проличилось это парой витков сигнального провода от энкодера вокруг ферритового кольца. Все это позволило отказаться от программной ловли ложных срабатываний и еще больще разгрузить Мегу. 3) Отказ от переменных типа float в пользу long и int. Это значительно повысило скорость вычислений, но конечно же снизило "прозрачность" кода, так как некоторые переменные пришлось умножать на 100 или даже 10000. Вобщем - документация и комментарии - это наше всё. Открытый вопрос - что делать с люфтом? При использовании электронных упоров этот люфт не сильно и напрягает (нужно просто задать один из упоров на 0.27мм больше), с другой стороны хотелось бы с ним разобраться на програмном уровне ... Так же присутствует еще пара известных багов, но они не критичны.

Небольшой тест на повторяемость при нарезке резьбы шагом 1.5 мм. (Прошу прощения за качество фокусировки камеры).

Прошу прощения за опечатку - шаг подачи 1мм.

Первые тесты на повторяемость, синхронность и точность. Как видно на видео, левый упор выставлен на 6 мм, правый - -1. Движение осуществляется синхронно со скоростью вращения шпинделя (шаг 1.5 мм/оборот). Использовалось как непрерывное движение од одного упора до другого, так и с паузами, правда без смены направления движения. Результат более чем приличный. Для наглядности демонстрации синхронности начала движения суппорта к патрону приклеен кусочек цветного скотча, движение всегда начинается при одном и том же положении патрона (на последних кадрах я постарался поймать пару таких моментов). Легко так же увидеть и люфт в системе - приблизительно 0.275мм.

Сбылось! Приехали энкодеры! И очень уж мне хочется снова использовать библиотеку для считывания абсолютного положения энкодера: https://github.com/PaulStoffregen/Encoder Однако этой библиотеке нужно два сигнала, что бы она могла определять направление вращения (в нашем случае) шпинделя: Зазоры в можно в нашем случае распределить "кучно", а можно попытаться поймать Бога за бороду. Так как при прохождении одной "позиции" энкодера мы получим увеличение счетчика на 4 единицы, то разместив зазоры равномерно по кругу мы получим 4 точки, которые можно будет использовать для вычисления скорости и направления вращения шпинделя! Сказано - сделано: Как видите - все условия последовательности поступления сигналов соблюдены, при этом использование 3Д принтера конечно же упрощает и облагораживает конечный результат, однако не является чем то необходимым, наверняка подобную деталь можно изготовить и другими методами и средствами. По задумке это должно в итоге выглядеть как то так: Монтаж на станок: И общий вид: Вы конечно же можете спросить, а как же теперь быть с меткой для начала движения суппорта при нарезке резьбы!? Ведь идея то была именно в том, что бы при одном сигнале на оборот (скажем при переходе с 1 на 0) начинать движение суппорта? На самом деле метка никуда и не делась - так как за полный оборот шпинделя мы всегда получаем 4 сигнала и соответственно увеличение счетчика на 4, то при делении значения счетчика на 4 с остатком ноль мы имеем "сигнал" о том, что был совершен полный оборот, и соответственно можно начинать движение суппорта. (Можно обойтись и без деления, а просто отсчитывать 4 сигнала). Итак установка ключевого узла закончена и можно переходить к программной реализации. Дали буде!