Gnevko

1) Делаем проход. 2) Выключаем подачу 3) Выводим резец 4) Не останавливая шпинделя, включаем реверс для суппорта 5) Суппорт отъезжает чуть левее начала заготовки и выставляем новую глубину прохода. 6) Включаем снова подачу 7) Шаговик ждет определение скорости (то есть один оборот шпинделя), что бы выяснить его скорость 8) По метке начинает движение, 8.1) если скорость вращения спинделя малая, то шагаем как есть. 8.2) если скорость высокая, а суппорт все же инерцию имеет (или шаговик слабоват), то расчитываем ускорение, что бы через один-два оборота выйти на нужную скорость с учетом метки. Дополнение: 1) Пункт 8.2 спорный и требует еще проработки, но позволяет не останавливать шпиндель 2) понятие "Скорость шаговика" вас не должно вводить в заблуждение, шаговик все равно делает шаги и весьма точно, только в расчете не на импульс экодера, а в единицу времени. По сути (с допущениями) - это одно и тоже.

Понятно, мне показалось, что вы имели введу немного другое ... что экономило бы много времени, но не возможно при люфте. Поскольку есть начальная метка (она же и единственая), то любое движение суппорта будет начинаться в одно и тоже положение шпинделя, что позволит "нарезать с реверсом", даже возможно не останавливая шпиндель. Если есть вопросы, то будем искать и ответы. Главное не прыгать выше головы и не хвататься за все и сразу.

Здесь в первую очередь наверное нужна жесткая связь между ходовым винтом и суппортом (без люфтов), что на станках такого класса, да и классами повыше практически не встречается (без дополнительных танцев с бубнами и заменой винта). Собственно поэтому на реверсе очень не советуют нарезать резьбы.

Просто замечательный ответ! И замечателен он не только своей развернутостью, но и возможностью для меня опираясь на него объяснить разницу в подходах согласования скорости вращения спинделя и подачи суппорта. @DimonDSS Реализовал, если я правильно конечно же понял идею, некое подобие делительного аппарата. На каждый имульс энкодера делаем нужное кол-во шагов. Чем больше импульсов энкодера, тем меньше ког-во шагов на импульс, и соответственно тем "плавнее" подача суппорта. При таком подходе просто жизненно необходимо огромное число импульсов (особенно на малых оборотах). И как следствие повышенное требование к тактовой частоте процессора. Предлагаемый мною подход основывается не на принципе делителя, а на принципе согласования скоростей. Я предлагаю не говорить шаговику сколько ему сделать шагов, я предлагаю задавать ему скорость, с которой он должен делать шаги в единицу времени, а так же изменять/адаптировать это значение скорости с каждым оборотом шпинделя. Для этого достаточно лишь одного импульса на оборот. И как все в этом мире, оба подхода имеют право на жизнь, каждый со своими достоинствами и недостаткими.

Много я вам рассказать про эту штуку не смогу, пока не возьму в свои руки. Судя по видео на ютубе крутится легко, но с фиксацией на каждом делении. Обычно к ней заказывают в придачу еще энкодер на 3-4 позиции при помощи которого можно будет выбрать масштаб/цену одного деления, к примеру: 1мм, 0.1мм и 0.01мм (для особо точных маневров).

Панове, побольше патриотизма, как же можно допустить, что бы на .ру было больше поломаных спиц, чем здесь!? А если серьезно, то давайте дождемся практических испытаний, от них и будем плясать.

Замысел в том, что бы вычислять скорость "на лету" при получении каждого импульса с энкодера или что в данном случае пока что одно и тоже - при каждом обороте шпинделя. Я не большой специалист в токарном деле, да и вообще слово "специлист" ко мне не применимо в этом контексте, однако, что то мне подсказывает, что то ли обработку поверхности, то ли нарезание резьбы не начинают прямо вот у самой заготовки, обычно отводят резец немного левее заготовки (как минимум что бы выбрать холостой ход винта), включают подачу ... ну и так далее. В нашем же случае это так же будет способствовать выходу шаговика на нужные обороты. Здесь нужно учитывать так же несколько моментов: 1) резбы не режут на больших скоростях (обычно) 2) шпиндель так же не разгоняется мгновенно - вот вам и плавный набор скорости у шаговика 3) в случае, если удасться реализовать автоподачу без остановки главного шпинделя, то отвот резца влево с определенным запасом - это наше все. Как то так.

Теория теорией, а практика расставит все на свои места Возможно в итоге прийдется таки использовать прерывания, возможно, что прийдется увеличить число "окон" до пары десятков - все мои рассуждения ничего не стоят, до тех пор пока не пройдут проверку практикой. ЗЫ: записывать прийдется не только время изменения, но и кол-во таких изменений, что бы исключить их пропуск. Пример: время первого изменения сигнала энкодера было записано, основная программа не успела приступить к обсчёту результатов как случилось второе изменение, время которого переписало время первого. И вот наконец то основной цикл дошел до обработки полученной информации, а теперь вопрос - сколько изменений было на самом деле? Или другими словами на сколько успел провернуться шпиндель? Так что прийдется считать кол-во изменений и сбрасывать этот счетчик в ноль после каждой обработки результатов.

Такая мысль имеет право на жизнь. Однако преимущества не очевидны (в этом конкретном случае), а недостатки могут вызвать относительно негативные последствия. Позвольте пояснить. Прерывание не является заменой параллельности вычислений. Процессору все равно прийдется на него отвлечься, остановив выполнение основной программы и место такой остановки не предсказуемо. К примеру, процессор начал посылать на драйвер сигнал, но тут случилось прерывание и этот сигнал оказался слишком долгим ... и так далее. В нашем же случае "окно" для энкодера будет достаточно широким, что бы успеть считать сигнал с него (но не слишком широким, что бы это влияло на вычисление скорости). Другое дело, если таких окон под одну, а то и две тысячи на один оборот шпинделя - в этом случае без прерываний действительно не обойтись, так как риск "не успеть считать" сигнал с энкодера очень велик. В любом случае конечно же нужно стремиться свети занятость основного цикла программы к минимуму. Например опрашивать положение джойстика и других органов управления не каждый цикл, а с интервалом в 100 миллисекунд (а то больше), причем постараться разнести по времени опрос разных органов управления таким образом, что бы за один цикл опрашивался только один из них. Вычислительных мощностей Arduino Mega для такой задачи должно хватить с головой.

Спасибо за отзывы и за то, что не прошли мимо. Проект находится в самой начальной стадии и конечно же ради пары секунд видео "с як воно крутится" городить огород не стоило (есть много других способов потешить свое ЧСВ). Так шо дали буде Сейчас последует много букв, за что прошу за ранее прощение, но без теоретических размышлений и выкладок все равно не обойтись. Так же я постараюсь излагать возможно излишне подробно, но это позволит быстрее вникнуть в тему людям, далеким от данной предметной области. 1) Цель проекта - это не только 4-3 килограмма, стоп, не то .... это не только собственно электронные шестерни на моем станке, но и возможность повторить их и на других станках. Ведь по сути изменить нужно будет только силовую часть, вся логика управления останется прежней. Не все первоклассные токари - прирожденные программисты и не все программисты - прирожденные токари, так что ваше мнение очень важно и нужно. 2) Шаговый двигатель: NEMA23 (это один из стандартов размеров шаговиков). Вот подробная информация о нем. Для маленького настольного станка это, наверное, более чем достаточно, но больше мощности никому еще не мешало. 3) Драйвер для шагового двигателя: тип PUL/DIR/ENA Такому драйверу необходимо по сути три сигнала и соответственно три пина на Arduino: PUL - каждый импульс на этот пин будет принуждать драйвер сделать один шаг(или микрошаг, об этом ниже), DIR - определяет направление вращения вала по часовой или против часовой стрелки, ENA - включает или выключает подачу напряжения на обмотки двигателя. Очень часто можно встретить мнение, что ENA не нужно вообще трогать - я с этим не согласен. Пример: вы оставили джойстик в положении автоматической подачи, или случайно задели его перед включением гитары. В этом случае, при включении, Arduino проверит положение джойстика и автоматически обесточит шаговик, если положения джойстика отличны от нейтрального. Для управления драйвером я буду использовать библиотеку AccelStepper (http://www.airspayce.com/mikem/arduino/AccelStepper/). Конечно же можно было бы обойтись и без нее, но изобретать велосипед в этой области как то не хочется: #define Z_STEP_PIN 53 #define Z_DIR_PIN 52 #define Z_ENABLE_PIN 46 //инициализация шагового двигателя AccelStepper zStepper( AccelStepper::DRIVER, Z_STEP_PIN, Z_DIR_PIN); //interface, pin1 - Step, pin2 - Dir //определение ENA пина zStepper.setEnablePin(Z_ENABLE_PIN); //для моего драйвера необходимо было инвертировать сигнал на ENA пин zStepper.setPinsInverted(false, false, true); //подача напряжения на двигатель zStepper.enableOutputs(); Драйвер позволяет выставить кол-во микрошагов, так как шагать в полные 200 шагов на оборот вала двигателя - это слишком грубо и рывками. На разных ресурсах, посвященных ЧПУзации станков, советуют выставить 1/16 шага или 3200 микрошагов на оборот. Так и сделаем (переключатели SW5 - SW8), в дальнейшем эта цифра (3200 оборотов в секунду) нам пригодиться в расчетах. Кол-во ампер (переключатели SW1 - SW3) подбирается экспериментальным путем, главные критерии - отсутствие пропусков шагов с одной стороны и избежание чрезмерного перегрева двигателя - с другой. 4) Согласование скорости вращения шпинделя и скорости вращения шагового двигателя. Этот пункт наверняка вызовет одни из самых горячих дискуссий, но зима близко и лишнее тепло не помешает. Есть несколько мнений по поводу того, с какой частотой считывать скорость вращения шпинделя: а) Чем чаще тем лучше. Это казалось бы очевидный вывод, но он имеет как ряд недостатков так и преимуществ: большое кол-во импульсов способно очень сильно "затормозить" микропроцессор Arduino, а ему еще ж и шаговиком в реальном времени управлять нужно. Что бы решить эту проблему люди (в небезызвестной теме в другом форуме) выделяют дополнительный микроконтроллер только для обработки импульсов с энкодера. Так же становиться проблематично определить конкретное положение шпинделя (что бы при повторном включении гитары сново "попасть" в резьбу), обычно для этого ставят дополнительный энкодер. Положительный момент - это позволяет вычислять угол поворота шпинделя. б) Достаточно одного импульса на поворот шпинделя. К примеру Mach3 требует именно одного импульса на оборот, так это уже уровень ЧПУ станка, а у нас всего то электронные шестерни. Один импульс на поворот убирает сложность в обработке большого числа импульсов, упрощает тем самым всю архитектуру проекта, и является достаточным что бы определить скорость вращения шпинделя (а это в общем то нам и нужно), так же решается проблема с начальной меткой (так как она всего одна), но не позволяет определить угол наклона (однако создание делительной головки в цель проекта не входит). Как вы уже догадались, я остановился на втором варианте. В подтверждение своего решения приведу ссылку на один немецкий источник, так как раз переделывался "мой" станок в ЧПУ под Mach3: http://www.einfach-cnc.de/paulimot_pm190.html (там очень много фотографий и очень мало текста, так что знание немецкого не обязательно для общего понимания процесса). А вот и нужная нам фотография с этого ресурса: Как видите, люди обходятся и одним достаточно "широким" импульсом. 5) Определение скорости вращения шагового двигателя. Итак, у нас есть два входных параметра: а) скорость вращения шпинделя: обороты в минуту (определяется по сигналам с энкодера) б) заданная скорость подачи суппорта: мм на оборот ( то ли для обработки детали, то ли для резьбы - разницы то по сути никакой). В начале мне казалось правильным предусмотреть не только синхронную подачу суппорта, но и асинхронную - но это быстро прошло. Вычислить нам нужно же скорость вращения шагового двигателя: шаги в секунду, что бы передавать это значение в библиотеку AccelStepper. После недолгих раздумий получилась следующая формула: /* spindleSpeed - обороты в минуту. Пример - 360 оборот/мин supportSpeed - mm за один оборот. Пример - 0.08 мм/оборот Формула: ((spindleSpeed / 60) * supportSpeed) / mmPerZStep = stepsPerSecond */ float convertSpindleToZStepperSpeed(float spindleSpeed, float supportSpeed) { float spindleRevolutionsPerSecond = spindleSpeed / 60; //revolutions per second. Example - 360 / 60 = 6 revolutions float forcedSupportMMPerSecond = spindleRevolutionsPerSecond * supportSpeed; // mm per second. Example 6 * 0.08 = 0.48 mm float stepsSecond = forcedSupportMMPerSecond / mmPerZStep; // steps per mm per second. Example 0.48 / 0.000625 = 768 steps return stepsSecond; //итог вычисления 768 шагов в секунду } Устанавливаем скорость вращения шаговика в основном цикле программы: zStepper.setSpeed(stepsSecond * zFeedDir); //где zFeedDir - может быть 1 или -1 и определяет направление вращения zStepper.runSpeed(); Здесь нужно пояснить значение переменной mmPerZStep, равной 0.000625мм. Шаг винта подачи суппорта в моем случае - 2 мм, шагаем мы микрошагами в 3200 шагов на оборот вала шагового двигателя, таким образом за один шаг суппорт передвигается на 2мм / 3200 = 0.000625мм. По итогам вычислений можно привести следующую таблицу зависимости скорости шаговика (в шагах в секунду) от скорости вращения шпинделя : Поскольку реальная гарантированная скорость вращения шаговика не превышает 5000-6000 шагов и секунду, то можно сделать вывод, что нарезать резьбу с шагом 3 на скорости 1700 оборотов в минуту навряд ли удасться Если же это будет необходимо, то нужно понижать кол-во микрошагов, скажем с 3200 до 800. Продолжение будет следовать по мере поступления деталей из Поднебесной и установки их на тестовый стенд.