самодельный станок с ЧПУ, отзывы duxe.ru |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » самодельный станок с ЧПУ, отзывы duxe.ru » Схема контроллера, шаговые двигатели » Контроллер станка с ЧПУ на PIC с возможностью автономной работы
Можете сказать название такой программы? И какая фирма её выпускает?
VRI-CNC. Начиная с первой версии. Выпускает Роман Ветров.
Точность коррекции не более 1 шага в любой точке любой траектории. Проверено!
Точность коррекции не более 1 шага в любой точке любой траектории.
А что, VRI уже позволяет иметь разные поправки бы для одной оси? Программа в состоянии скорректировать люфт, если он только в конце хода стола, скажем?
А что, VRI уже позволяет иметь разные поправки бы для одной оси?
Программа в состоянии скорректировать люфт, если он только в конце хода стола, скажем?
Разные поправки для каждой оси программа делает.
Поправки на разный шаг резьбы подачи или на ее износ естественно не делаются, на это способны только сервоприводы.
Программа также делает поправку на люфт при каждой смене направления движения по оси(реверсе), как это делает токарь или фрезеровщик.
Это же самое программа делает и в конце хода стола, как только упрется в концевик, сразу "вспоминает", что при движении от концевика надо выбрать люфт.
Отредактировано Трудоголик (2008-03-19 23:26:51)
Точность коррекции не более 1 шага в любой точке любой траектории. Проверено!
Чем измеряли доли микрона при проверке?
выбрать люфт передачи - дело нехитрое, такое любой МК может. Причем, часть параметров есть смысл загнать в прошивку, поскольку, после обкатки они уже не меняются. Их не надо каждый раз настраивать.
А вот выбрать люфты направляющих уже сложнее, но тогда это действительно можно назвать коррекцией и достижением, imho
Чем измеряли доли микрона при проверке?
А вот выбрать люфты направляющих уже сложнее, но тогда это действительно можно назвать коррекцией и достижением, imho
Господа хорошие, речь идет о точности программы, а вы про кривые направляющие и доли микрона!
Станок то здесь причем?
Может вам еще коррекция биений кривой фрезы нужна на каждом ее обороте?
Подумайте сами, как по входному файлу и выходному сигналу с порта можно определить, точно ли работает программа.
Господа хорошие, речь идет о точности программы, а вы про кривые направляющие и доли микрона!
Речь идёт о том, что если шаг станка не кратен шагу координат файла, то будет возникать ошибка перемещения от половины до шага перемещения. Пример с шаблоном вы сами же и приводили. А вы тут какую-то мифическую точность программы зачем-то пытаетесь приплести. Если программа не точна, то это просто плохая, негодная программа. Такой случай даже не обсуждается.
Господа, глянте на ссылочку:
Это интересно
По моему почти то что нужно, жаль на Си. Ничего не понятно, но главное алгоритм чтения.
Речь идёт о том, что если шаг станка не кратен шагу координат файла, то будет возникать ошибка перемещения от половины до шага перемещения. Пример с шаблоном вы сами же и приводили. А вы тут какую-то мифическую точность программы зачем-то пытаетесь приплести.
Именно такую точность программа и обеспечивает, "от полушага до шага", я сказал "не хуже шага",
что одно и то же.
Причем такая точность вычислений гарантируется при любой, произвольной длине шага и произвольной траектории. И никаких мифов, просто правильный алгоритм, и все дела.
Если говорить о станке без ОС, то точность зависит от железа. Остальные ошибки на порядок ниже.
Алгоритм выборки люфта приводов интереса не представляет, тем более там разрезная гайка и нет люфтов шестеренок, как в обычном станке.
Упрощенный алгоритм перемещений такой:
х/у=к - определяем через сколько шагов по Х сделать шаг по У /*здесь ошибка округления
Потом ходим "конем", накапливая ошибку округления. Если шаг кратен сетке отверстий, то МК справится и без ошибок. Но это очень частный случай 
В РС остаток от деления умножается на число "коней" и округляется до целого - это дополнительный корректирующий ход.
В принципе, точность позиционирования РС программой +/- 0,5 шага на отрезке. А за счет беготни в разные стороны она примерно такой и остается.
В принципе, точность позиционирования РС программой +/- 0,5 шага на отрезке.
Эта относительная точность, то есть точность сверления одной точки относительно другой.
Но программа Романа и абсолютную точность (то есть точность относительно нуля) имеет такую же - не более одного шага.
Согласен с приведенным вами алгоритмом,он действительно является частным случаем общего алгоритма, по которому даже космонавты "совершают посадку в точно заданном районе":
1. Находясь в исходной точке, расчитай путь до следующей.
2. Придя в следующую точку сориентируйся в пространстве.
3. Расчитай путь до следующей точки с учетом предыдущей ошибки.
4. Двигайся до следующей точки.
5. Если не добрался домой, вернись к строке 2,
иначе - принимай поздравления.
Разница между станками с ОС и "без ОС" заключается только в способе ориентации в пространстве,
станки с ОС учитывают истинное положение, а
станки без ОС - расчетное местоположение в пространстве.
Согласен, эти самые +/- 0,5 шага на отрезке тоже стоит учитывать.
Вариант с ОС значительно интересней, поскольку здесь компенсируется больше погрешностей, в т.ч. и пропущенные шаги. Принтеры, НDD, CD и хорошие актуаторы (поправка на уровень сигнала) сейчас так и работают.
Господа, глянте на ссылочку:
Это интересно
По моему почти то что нужно, жаль на Си. Ничего не понятно, но главное алгоритм чтения.
Ссылочка действительно интересная. Жаль только, что перевод не полный.
А то, что Си - так это просто здОрово. Зря вы так расстраиваетесь:) Переходите на Си, давно пора.
Сообщаю результаты своих изысканий. 
В целях ускорения процесса никаких оптимизаций не делал.
Со сверлением проблем нет.
Можно проверять хоть сейчас.
С рисованием (G01) пока застрял
Занято около 65% памяти 16F628(2к).
То есть в 1к чипы уже не влезет.
Дальше продолжать смысл есть?
Наиболее универсальными стоит признать G коды в мм, т.е. *.tap, которые подходят для всех видов обработки. *.plt хороши для 2D, причем ArtCam сразу прописывает несколько проходов с заданным заглублением и возвратом в Home. Учитывая, что эта прога имеет и хорошую визуализацию, то она и будет базовой для проекта и конвертации.
Задача СОМ транслятора - принять tap/plt и сбросить их в МК/ЕЕPRОМ в удобном формате, с поправками на передачи, скорости, углы и люфты. Раскладку по осям, управление ключами и форсажем осуществляет МК. Start/stop и ручное управление стоит тоже переложить на него.
В итоге имеем нечто похожее на драйвер, только не принтера, а CNC и модуль стыковки на микроконтроллере. В зависимости от исполнения, этот модуль сможет управлять как полевиками (мой вариант), так и всякими step/dir, ТМ5 и т.п.
Формат для железа оставляем прежним из 2byte: ssss lrdd + nnnn nnnn
ssss - избыточны, но это 15 скоростей + sleep=0000
lr=11 и 00 можно использовать для включения шпинделя
dd = 00 оставим для 4 оси
Наиболее универсальными стоит признать G коды в мм, т.е. *.tap, которые подходят для всех видов обработки.
Позволю себе небольшую поправку. *.tap - это файлы для сверловки. В них нет команд перемещения по оси Z.
Для фрезерования на фиксированную глубину мне также понравился формат файла *.rou, который выдаёт CAM350. Очень похож на *.plt, только вместо плоттерных PU, PD используются герберовские M15, M16.
Формат для железа оставляем прежним из 2byte: ssss lrdd + nnnn nnnn
ssss - избыточны, но это 15 скоростей + sleep=0000
lr=11 и 00 можно использовать для включения шпинделя
dd = 00 оставим для 4 оси
Уже в который раз здесь упоминаются какие-то sss, lrdd и т.д...
Мне например ни о чём это не говорит. Можете привести пример реального файла в таком формате с расшифровкой что всё это значит? Сейчас еще раз постараюсь подробно рассказать про свой вариант и объяснить на примере что я имею в виду. Итак, примеров файлов 3D обработки у меня не было. Поэтому я постарался для начала ввести поддержку сверления и фрезерования плат(рисования). Посмотрев имеющиеся у меня варианты форматов файла сверления, я остановился на формате Excellon. Файл генерил в формате 2.4. Значения координат - относительные. Незначащие нули спереди не подавляются. Система - метрическая. При этом файл получается с координатами в микронах.
M48
METRIC,TZ
FMT,1
ICI,ON
%
T0
X050800Y038100
X-019050Y317500
.....
M30
Так как формат прост и понятен, я просто решил немного его модифицировать в части заголовка. Всё, что находится до первой координаты, я просто удалил. В принципе M48 можно оставить для управления включением шпинделя. Команды смены инструмента Tх я тоже удалил, но их можно оставить и легко обрабатывать (если это кому-то нужно).
Получилось так:
d
001600
000255
000005
X050800Y038100
X-019050Y317500
.....
M30
d(rill) - означает, что будем дЫрить.
001600 - глубина сверления (в микронах)
000255 - частота следования импульсов step(на данный момент в "у.е" от 1 до 255. можно сделать в микросекундах. опять же на данный момент для простоты одинакова для всех осей)
000005 - шаг перемещения станка (в микронах)
Т.е. начальный заголовок настраивает контроллер на определенную работу с определённым станком.
Далее считываются координаты. После окончания каждой строчки осуществляется перемещение на указанную величину по оси Z туда и обратно, после чего считываются координаты из следующей строки и так до тех пор, пока не будет считан код M30. После этого двигатели останавливаются и моргает лампочка. В симуляторе всё работает прекрасно, в железе к сожалению проверить не могу.
Что касается фрезеровки на фиксированную глубину(рисования), то у меня нашёлся только файл от CAM350.
Выглядит так:
M48
METRIC
VER,1
FMAT,2
T01C0.5F042B423S6H2000
CP,1,000500
DETECT,ON
ATC,ON
%
T01
G00X011430Y013970
M15
G01Y-001905
X001270Y-001270
X006350
M16
...
M30
Заголовок модифицировался аналогичным образом и файл приводился к виду
m
001600
000255
000005
G00X011430Y013970
M15
G01Y-001905
X001270Y-001270
X006350
M16
...
M30
Здесь всё то же самое, только вместо d(rill) используется m(ill). И после конца строки никаких движений по Z не делается. Они осуществляются после считывания M15(перемещаемся по оси Z от начала координат на указанную величину) и М16 - в обратную сторону соответственно. Прошу заметить - в обоих случаях использовались стандартные, широко распространённые типы файлов. Велосипед не изобретался, просто модифицировался заголовок. С такими файлами на данный момент реализовано только G00,M15,M16,M30.
Теперь скажите пожалуйста, Bolt, как вы будете приводить стандартные файлы сверления и фрезерования к виду "ssss lrdd + nnnn nnnn ssss" и что все эти "ssss lrdd + nnnn nnnn ssss" означают? Можете расписать так же подробно на конкретном примере?
Отредактировано koolhatcker (2008-03-22 22:06:05)
Позволю себе небольшую поправку. *.tap - это файлы для сверловки. В них нет команд перемещения по оси Z.
Вы вероятно не очень внимательно читаете, я приводил кучу примеров файлов *.tap. Специально для Вас:
X0.086
X75.014
Y2.063
Y2.196
X74.929
X24.554
X24.300Z-5.929
X24.046Z-5.943
X23.876Z-6.000
Все координаты присутствуют.
Задача СОМ транслятора - принять tap/plt и сбросить их в МК/ЕЕPRОМ в удобном формате, с поправками на передачи, скорости, углы и люфты.
Лично я буду использовать для переноса MMC. Комп пересчитывает мм в шаги и переводит в HEX-файл, файл через картридер в ММС, ММС в станок. Пока так.
Я для пробы кружок нарисовал, команды врезки G1X0.926Y5.225Z-1.400F3.0 там явно присутствуют, а подробно с 3D еще не разбирался
Все переводы в шаги, оси ,направление вращения и скорости делает наш СОМ драйвер. Посылка состоит из байта перемешения и байта команды, которые расписаны по битам.
Для строчки из PLT: PA37,209; транслятор выдаст (подача 0,0125мм*шаг)
01001010 - перемещение 74 шага
11110101 - максимальная скорость (подвод), правое вращение, ось Х
11111111 - 255 шагов
11110110 - максимальная скорость (подвод), правое вращение, ось У
00000000 - Z
00000000
flag
00h
00h
10100011 - еще 163 шага
11110110 - опять по У
00h
00h
flag
Входной файл (нет проблем расписать все нужные форматы) переведен в удобный для МК и ЕЕПРОМ вид, правда без учета люфтов, углов и ошибок. Отработав команды МК выставил флаг и получил очередную порцию данных.
4 бита скорости можно вывести на 1..4 свободных вывода МК для управления форсажем. Вариантов исполнения и прошивки модуля стыковки может быть много.
Сейчас мне удобно для теста задействовать pic628 на 2 оси (8 полевиков) с управлением вручную и по СОМ. Тот же 628 с другой прошивкой уже сможет управлять тремя step/dir + форсаж
Скорости можно задать как прошивкой, так и настройками в трансляторе. Передавать их удобно вместе с шагами, что позволяет менять скорость и токи по ходу работы.
При старте МК должен опросить шину на наличие ЕЕПРОМ, если памяти нет, то работаем с портом РС.
*кроме кнопок ручного управления, должна быть стартовая и аварийная.
Более интересного варианта пока не придумалось. Надо проверять, тогда видно будет
Вы вероятно не очень внимательно читаете, я приводил кучу примеров файлов *.tap. Специально для Вас:
X24.300Z-5.929
X24.046Z-5.943
X23.876Z-6.000
Все координаты присутствуют.
Мне таких *.tap файлов не встречалось. Скажите пожалуйста, какая программа их создаёт?
Лично я буду использовать для переноса MMC. Комп пересчитывает мм в шаги и переводит в HEX-файл, файл через картридер в ММС, ММС в станок. Пока так.
При таком варианте придётся ещё написать программу на PC для пересчёта мм в шаги и к тому же потеряется совместимость со стандартными файлами. Как считаете, совместимость со стандартными файлами не нужна?
Насколько я понимаю простенький вариант с 24ххх уже никого не устраивает? 
Сможете организовать работу с FAT MMC?
Мне таких *.tap файлов не встречалось.
выше есть фрагмент G-code-mm из ArtCam, координата Z там присутствует. Тот же проект в plt имеет несколько команд PD. Для наших 2D задач вполне подходит и HPLG
Комп пересчитывает мм в шаги и переводит в HEX-файл
Все верно, потому тип ЗУ может быть любым.
Отредактировано bolt (2008-03-23 11:54:21)
Все переводы в шаги, оси ,направление вращения и скорости делает наш СОМ драйвер.
Он уже существует? На мой взгляд если идти по этому пути, то начинать нужно именно с него.
Для строчки из PLT: PA37,209; транслятор выдаст (подача 0,0125мм*шаг)
01001010 - перемещение 74 шага
Почему 74?
11110101 - максимальная скорость (подвод), правое вращение, ось Х
Из каких бит следует, что скорость максимальная, вращение правое, а ось именно Х?
11111111 - 255 шагов
А если нужно больше? Т.е. может быть всё-таки распишете всё это детально?
выше есть фрагмент G-code-mm из ArtCam, координата Z там присутствует.
И файл имеет расширение *.tap? Почему переспрашиваю - ArtCam у меня нет, а под *.tap я всю жизнь подразумевал только Drill tape.
Он уже существует?
Имею две проги. В одной реализован весь нужный нам алгоритм управления + визуализация, но сделана под LPT. Вторая просто сбрасывает пару байт пользователя по СОМ и предназначена для проверки алгоритма управления ШД через PIC.
CNC экспериментальный и он уже слеплен под LPT. После проверки интересующих меня моментов, хочу сделать нормальный вариант с СОМ, более мощными двигателями и пинолью.
1111- максимальная скорость [ssss]
01- правое вращение [lr], 10=левое
01 - ось Х [dd]
Предлагаемый формат расписывал уже раз несколько, поскольку именно он задает совместимость PC и железа. В посте №168 есть пример трансляции. Спецом для случая, где нужно больше.
ArtCam всем рекомендую, очень удачная для нас программа. На выходе выдает ~50 вариантов разных УП + видеосимулятор процесса обработки. Мне пока хватает plt, при необходимости, легко добавить другие расширения, файлы то под разные ЧПУ похожие.
ArtCam всем рекомендую, очень удачная для нас программа.
А её формат для работы с компортом известен?
ArtCam - рисовалка, заточенная под CNC. На выходе УП-управляющая программа для станка, т.е. те самые G коды.
Ясно. А я почему-то решил, что он через ArtSpool на станок по компорту данные передаёт...
у кого есть ArtCam с лекарством-поделитесь..для пробы
все есть в нете, только вес большой. Лучше сразу CD
на http://cryolite.ath.cx/i/pcb-router есть релиз на pic877. На входе Excellon file *.drd, который по СОМ сбрасывается в ПИК, который рулит полевиками осей. Имеется вся необходимая для повторения/модификации информация.
делал год назад на аттини2313 контроллер 2 шд, т.е. 4 входа - по 2 степ/дир на каждый движок, на выходе - ключи и дальше движки, особенно не загонялся, поэтому, схема получилась жутко простой, с недостатками, но рабочей (проверено).
по идее, после сдачи диплома планирую доделать агрегат, сделать его на меге8535 или 64, в нём по замыслу ШИМ + токоизмерение и регуляция, возможность загрузки небольших программ с флешки , вывод на ЖК экран сделать не сложно, определиться бы что выводить 
, и самое главное - чтобы всё работало))
И вообще по моему, взваливать всю работу по декодированию Г кодов, вторых, третьих форматов на МК нехорошо, если проект достаточно бюджетный, проще купить старый комп и взвалить на него,+ и софт проще будет заменить и отладить,из недостатков наверное только -энергии побольше будет есть, габариты увеличатся,+ заставка окошек от дяди билли гейтса всё время будет при загрузке агрегата ))
хотя каждому своё... тут только моё мнение)
удачи,умельцы!
Вы здесь » самодельный станок с ЧПУ, отзывы duxe.ru » Схема контроллера, шаговые двигатели » Контроллер станка с ЧПУ на PIC с возможностью автономной работы
