Управление токарным на Atmega. Электронная гитара.

Мне так сдается, что нам надо и энкодер и датчик холла.

По датчику считаем обороты и ежели они превышают скажем 1000 или 2000, то работаем с датчиком, ежели меньше, то работаем с энкодером.

Ну и синхронить можно по датчику скажем начало резьбы ежели маточную гайку разъеденить приходится. :).

Если энкодер самодельный, то теоретически, можно нанести на его диск "черную метку" и считывать ее отдельной оптопарой,

у Dmitriy_N как раз диск с дополнительными метками.

Если уж падать на покупное, я бы затеял что-нибудь с таким -

http://www.mikroe.com/ready/xmega/

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

По поводу морфинга задавал Счасливчик в той ткме.

Отдельно темы не встречал, по форумам ЧПУшников в разделах контроллеров обсуждается много где.

Ну на пальцах. форма тока в обмотке:

Полный шаг - это меандр

Микрошаг - синусоида.

Морфинг это постепенное преобразование меандра в синусоиду и обратно. Не меняя количество микрошагов :)

Ну ежели кому вопрос интересен, то можно подробнее, только это опять не по данной теме. :wink:

Вообще тема толкового драйвера ШД, это наверное отдельно, там помимо морфинга есть еще вопросы кои надо учесть. И тема разрастется довольно сильно, ежели за это браться серьезно. Ну и это драйвер скорее для ЧПУ. А соорудить и отладить драйвер со всеми чудесами без навыков и знаний...

Проще и дешевле купить готовый.

А для данного проекта, на мое ИМХО достаточно связки 297-298 (кою можно купить за 5 юсд на бэее)

Если уж падать на покупное, я бы затеял что-нибудь с таким...

а чем оно будет лучше, кроме как вдвое большей цены?

наличие пустой макетки? так и на плату от Ардуино можно на пины пустую макетку посадить.

п.с. чуть позже постараюсь еще с одной темы полезное вытянуть.

Некоторые полезности из темы Андрея, надеюсь он не будет против:

Скорость потенциометром (ограничено 200 об/мин в режиме резьбы).

Резьба/подача простым поворотным энкодером (как в бытовой технике).

Алгоритм прост - контроллер следит за энкодером серво (скорость/направление)

и выдает импульсы на ШД.

Здесь важно что количество резьб и номиналы резьб практически не лимитированы.

Контроллер способен хранить в себе еще около 100 номиналов резьб и подач.

Сейчас же прошито только 14 метрических и столько же дюймовых резьб (самых базовых)

...С комилятор CodeVisionAVR.

Прога 16Кб (из 64Кб доступных), в основном забита таблицами деления для получения резьб.

Проблема в том, что нужно в реальном времени вычислить значение делителя шага ШД,

который не может быть представлен в виде целого.

Например как поделить на 1.5? Легко - первый делим на 1, второй на 2 и т.д.

Была сделана утилита генерации таблиц. Задача - создать периодичность в 256 байт.

Это важно, если индексы таблицы размером в байт, тогда не нужно отслеживать выход индексов

за пределы таблиц (AVR -8-ми битный!). Вот фрагмент получаемой таблицы -

// *** Thread: 0.35, divisor: 9.375000 ***

{

9, 9, 10, 9, 9, 10, 9, 10, 9, 9, 10, 9, 9, 10, 9, 10, 9, 9, 10, 9, 9, 10, 9, 10, 9, 9, 10, 9, 9, 10, 9, 10,

...

...

...

9, 9, 10, 9, 9, 10, 9, 10, 9, 9, 10, 9, 9, 10, 9, 10, 9, 9, 10, 9, 9, 10, 9, 10, 9, 9, 10, 9, 9, 10, 9, 10

},

По мне, с современными однокристаллками, когда в наличии достаточно много памяти, вообще лучше не считать - шарашишь таблицы и дергаешь данные из нужного места...

Без таблиц не получится. Абсолютно нет времени что-либо вычислять...

...но всего пару сложений/вычитаний в long - не такая уж реурсоемкая операция...

...У меня делитель написан сходным образом; - на меге на 16MHz с энкодером 1000lpr (что дает 4000 прерываний на оборот) и двигателе в четвертьшаге успевает крутить 1:1 (оборот ходового на оборот шпинделя) примерно до 800 об/м.

 

// for 1.8deg, 1/4step, 4000ipr

 

const thr_t Threads[] PROGMEM=

{{ 1, 79,5242880l, 0,125}, // #0 0.125 mm

{ 3, 199,4369066l, 0,15 }, // #1 0.15 mm

...

...

...

{127, 449, 232214l,0x09,0}, // #42 9 tpi

{127, 399, 206412l,0x08,0}}; // #43 8 tpi

Сегодня разбомбил два принтера НР и не обнаружил в них энкодеров.Потом мне популярно объяснили :vava: что они только в струйниках.

Предупреждать надо.

А про морфинг шага - хорошо бы поподробнее. Потому что те драйвера от пурелиджика, на которых гордо написано "сделано в России" (поржал) и которые типа с морфингом - на них тоже джамперы полушаг/четверть и т.п....

Если морфингов управлять от контроллера - надо еще два провода как минимум. Если же сам драйвер управляет - откуда он знает, сколько ему еще ехать-то???

Это морфинг?

Ладно... Мне ехать недалече, А чо буим с Вальтером делать? :shok:

Насчет морфинга. Та нет.. Насчет нормального драйвера.

Итак что он должон уметь.

Есть драйвера полно или полушаговые. Они умеют крутить двигатели соответственно в полный шаг или полушаге.

Есть микрошаговые они умеют каждый полный шаг дробить на микрошаги.

При работе в полном шаге и даже в полушаге может возникать явление резонанса и ведущий вал будет колбасить. И двигатель начнет пропускать шаги.

Микрошаговые драйверы дают более плавный ход и снижают значительно это явление.

Драйверы которые сегодня представлены на рынке работают только в том режиме в который вы его настроили. Иными словами. Установили мы микрошаговый драйвер в режим дробления 1/8 шага он будет работать в этом режиме на всех скоростях.

Насчет трассы Одесса-Питер поясня в соседней ветке.

Солидные драйверы должны уметь стартовать на микрошаге (1-я скорость) и с повышением скорости переходить в режимы вплоть до полного шага(5-я скорость), при снижении переходить в микрошаг.

Вторая проблема дешовых драйверов это "кривой" слив тока с обмотки, которая в этот момент не под напругой.

Т.е. опять таки поскольку обмотка имеет индуктивность, ток не появляется в обмотке мгновенно и не может "уйти" мгновенно.

Посему смотря в каком положении ротор и в какой из обмоток надо слить ток, солидные драйвера применяют быстрый, медленный или смешанный спады тока. Умеют перестраивать режимы спада от скорости...

Дешовые всегда стоят в одном режиме (если он вообще у них есть) в который вы его настроили.

Потом еще одна из проблем которые не решаются в дешовых драйверах. Это при высоких скоростях движка и микрошаговых режимах ток в обмотке не успевает вырости до заданного режима. Поэтому теряют скорость и момент.

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

И наоборот снижать в несколько раз на малых скоростях. Это все снижает нагрев двигателей и повышает характеристики, т.е дает возможность удерживать момент на довольно высоких скоростях.

Ну и должны уметь снижать ток в режиме "длительного" времени удержания ротора.

Насчет как это работает это наверное все же не тема данной ветки, потому как ежели мы начнем все это обсуждать "выплеснем ребенка".

Давайте тут пока решим более глобальные вопросы. По сути это вопрос "интерфейса" Хоть к ШД, хоть к серве.

А Тему драйверов ШД наверное уместней поместить в раздел ЧПУ, потому как эти все чудеса нужны именно там. :)

З.Ы. На самом деле Вы ставите движок в какоето дробление шага - ну допустим 1/16 А контроллер вместо того, что б тупо выдаать синусоиду для каждого микрошага, смотрит на какой скорости счас двиг и в обмотку гачит ток значительно больше или меньше.

Ну эт так - на кирпичах. :hi:

Podushkin, Нет, это синусоида, ну скажем это микрошаг

http://www.cncmaster...9adbd17fa5e9017

Исходников нет, но есть прошива. Из самоделок пока лучше не видел

Прошел всю тему, а для развития и две параллельных, не нашел принципиальной схемы,

у тя нет случайно :)

http://depositfiles....files/35z2h9uhe

Ну, вот тут усе что по этому драйверу у меня сохранилось.

По мне так проще свой соорудить, аналогичный. :crazy: Правда время... как говорилось выше, не всегда есть. :wacko:

Схема там практиски класическая. Тут проблем как всегда в програмулине управления зашитой в проц. Я делал подобный драйвер со своей схемой. У него ШИМ программный, я делал аппаратный. Офф-тайм как в большинстве пром драйверов. Управляется проще и не капризный в настройках.

Пара мыслей.

1. Управляться должны минимум 2 оси + шпиндель, может и кэп :) но так к слову.

2. Энкодер нужно подбирать исходя из наибольшей скорости, то есть: допустим проц способен посчитать 10000 в минуту, а наибольшие планируемые обороты 500 в минуту, то есть 20 на оборот, с учетом что там частота в Мгц, думаю что 360 на круг вполне выдержит, для резьб уже достаточно, и по точности приемлемо, можно выполнить на коленке. Допустим на лазерном принтере распечатать на прозрачке. В качестве считывателя фотопара или как там ее, тоже не вопрос. Если при диаметре 10 см окружность 31.14 то биш 311 мм увеличить до 360, и получиться по метке на мм, не микро печать, принтер справиться.

3. Крепеж можно и универсальный, замутить, уж токари то себе переходник выточат?

Ну так надо определяться:

Максимальная скорость шпинделя:

Максимальные обороты вала (валов, как минимум 2х) (тут еще редукцию учесть надо)

Максимальное количество сигналов с энкодера? (Можно и по 2-3 метки на градус влепить, уже серьезная скорость получается, а через редуктор, можно и положение вала, каретки, контролировать, только тогда ШВП неплохо бы :)

Максимальная скорость обработки.

chkmatulla, Я давал и даю зуб, За то что, мы тут соорудим зальется в МК не зависимо от того стоит он на плате дуньки или на спец плате. И буит дергать ножками ТОЧНО так же на обоих платах. Т.е. если внутри у МК правильная прога, то ему по барабану дунька это или спец плата. И функции он буит выполнять на обоих платах одинаково.

К слову.

Когда Вы что нить точите, то необходим как минимум конкретнвй станок (для прогера конкретная плата с конкретнвм МК, не важно дунька или спец. плата), Вам необходима оснастка (для прогера это средства разработки и средсва "общения с МК"), нужен тех процесс для Вас это, как установить, как проточить, что в первую очередь, что потом, как сделать с одного установа или переворачивать, (для прогера - это алгоритм, какие действия и в какой последовательности надо обеспечить И ОЧЕНЬ КОНКРЕТНО).

Ну и дальше если развивать сию тему, то окажется, что для Вас много операций выполнить много проще, чем прогеру обеспечить Ваши требования. Ну например есть у Вас энкодер 1800 рисок Это значит, что на 3000 оборотах в минуту шпинделя частота следования сигналов будет порядка 90Кгц. И тут перед прогером встает проблема, на том проце который Вы забили ему в ТЗ обеспечить обработку на этих скоростях не возможно.....

Ну это просто иллюстрация, на самом деле проблем вылазит Гооооораздо больше. Поэтому не надо гнать на проггеров, они пытаются решить то что Вы просите.

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

Возможно не все полностью понимают процесс написания программы (надеемся никого этим не обидим).

Нужно и полное ТЗ, с указанием всех "макроусловий" (какие действия должны выполняться), какими алгоритмами (это можно отдать на откуп программистам), что подается на вход и что должно быть на выходе, все ограничения (напр. энкодер не меньше 2000 "тактов" на оборот), скорость шпинделя не больше напр. 3000 оборотов, и тд. Отсюда будут требования на кристалл, тактовую частоту (диапазоны), объем памяти для программы.

Кроме этого, как сказано выше, нужен полный UI со все менюшками, логикой переходов, типами задаваемых значений, обработкой ошибок.

И все это, т.к. проект вроде как некоммерческий, в свободное время автора :)

Это не отфонарные рассуждения, мы знакомы с процессом разработки программ, т.к. программисты (правда не МК и embedded, а мобильные платформы). Собственно поэтому и не предлагали свою помощь в написании кода, т.к. сами точно не потянем. Код тоже писать можем, но лучше чтобы его потом проконтролировал кто-то опытный в МК. А это не факт что будет быстрее написания))). Но если будут предложения о помоще, составлении ТЗ и вычитке, поиске ошибок, составлении UI -- могли бы попробовать поучаствовать. Опять же в свободное время.

P.S. Возможно мы все слишком усложняем :) Кто знает, кто знает :)

Закупился я в итоге.

Ардуина Мега 2560, драйвер шаговика на ТВ6560, экранчик с кнопками, мотор Nema 23 263Oz-in, ну и по мелочам еще разных проводочков, сенсоров, и т.д. просто поиграться. БП взял на 24В, 6А, с запасом, если решу второй движок потом подключить, для точения конусов.

Теперь осталось дождаться, когда это все приедет. Покупал через e-bay.

Павел, ты можешь накидать свое видение необходимых функций?

это касается всех заинтересованых лиц :)

не стесняемся, но лишаки будем беспощадно резать :cray:

Ну в общем... Наблюдал я неоднократно открытые проекты, кои касались ЧПУ. Кстати на нашем форуме даже не ветка, а целый раздел был отдан на откуп товарисчу, который начал проект. И что? мыльные пузыри...

Причина в общемто одна.

У всех участников свое видение проблемы. Если собрать все пожелания воедино, то это необъемлемый проект.

У каждого участника (сиречь разработчика), свое видение реализации, то биш кристал, плата, средства разработки, средства реализации....

И вот на каком то этапе это все приходит к неразрешимому конфликту... И проект дохнет.

Вот когда каждый берется за задачку и решает под себя то все ладится и получается.

Если реализовывать, как предлагал Крокодил "даешь! чипдунио", то это ужо другой проект и наверное не совсем открытый, потому как его в свободное время не решить.

Поэтому давайте както урежем аппетиты и выработаем пока минимальные требования к девайсу.

Наблюдал я неоднократно открытые проекты, кои касались ЧПУ.

Если каждый начнет требовать учесть его пожелания, то действительно начнется разброд и шатание.

Но если кто-то будет "ведущим", то остальные или смогут присоединиться (при его непротивлении), или пойдут делать свою систему с тачскрином м перебором :) И так что-то получиться может.

Вот когда каждый берется за задачку и решает под себя то все ладится и получается.

Разве что суммарные затраты времени будут очень велики. Но может быть это и не имеет значения.

Но если кто-то будет "ведущим"

Ну у нас уже есть на сайте два таких девайса созданных и запущенных.

И есть две ветки обсуждений такого же точно девайса. Кстати наша ветка еще лояльная. :)

Только вот дело в том что ребята делали под себя, без особых схемотехнических и программных извратов

И даже ежели поделятся, то что бы это все пошло"в народ" комуто надо напрячся и потрудится.

Как я понимаю настоящую тему Олег взял на себя :)

Давайте пусть он и руководит процессом.

Вопрос можно - почему Атмега?

И второй. Допустим, мы задали задачу так:

- по данным о вращении шпинделя, снятым с энкодера, обеспечить продольную подачу от Х до ХХХ мм на оборот (фактически, это и делает гитара);

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

- допустим, мы обеспечиваеи подачу шаговиком или сервой, управляемой по степ/дир.

Вопрос - чем это отличается от ЧПУ, кроме способа задания параметров резьбы?

Dr_Law, :)

Ну это ужо ближе к ЧПУ. Ежели развивать, то как раз ЧПУ и буит.

Давайте упростим все ж задачу и девайс.

От ЧПУ отличается тем, что:

1) нет компа

2) нет приводов на поперечной подаче

4) нет G-кодов и не надо готовить УП.

....

По сути, мы просто механизируем (даже наверное не автоматизируем, коробку передач-гитару)