cnc-club.ru

после долгого перерыва взялся за работу.
делал на зубчатых ремнях Т5, с диаметром шкива 15.9мм. кстати, спасибо за послыку

несколько проблем, с которыми столкнулся:
- предложенная и обсуждаемая связка Ubuntu 10 - EMC - Inkscape - GCodetools мне не подходит. В основном, это личные предпочтения, но есть несколько объективных - из-за реальной конструкции софт не подходит.

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

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

В третьих, в роли исполнительного механизма я использую третий шаговый двигатель (ось Z), который плавно нажимает на кнопку баллончика. по задумке, это должно давать регулировку толщины линии. Поэтому, в моем случае конечный G-code выглядит по-другому. Также мне нужна будет обработка заливки фигур (уже сейчас) и градиент (в будущем).

В итоге переписал софт заново (выкинул матлаб, написал на Java), учел реальную геометрию, заказал датчики PLL01 (индуктивные) для точного позиционирования. Там тоже не все просто. Придется делать расчеты по другому - смещать начало координат (в треугольной системе) или учитывать минимальную длину ремня в точке касания. Может на следующей неделе поборю.

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

Что-то я эту тему потерял...

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

Что-то не верится, что это сильно влияет на результат... Особенно то, что перемещение каретки меняет точку зацепления на ремне и это сильно влияет на результат...
А есть какие-то практические результаты по этому поводу???
То, что балончик висит ниже точки ремней - это можно компенсировать простым смещением по Y.
То, что ремни присоединяются не в одной точке, а в двух разнесенных по горизонтале точках имхо можно компенситровать просто внесением поправки в "растояние между шкивами", т.е. вычесть из этого расстояния растояние между ремнями.

k2m30 писал(а):В итоге переписал софт заново (выкинул матлаб, написал на Java), учел реальную геометрию, заказал датчики PLL01 (индуктивные) для точного позиционирования. Там тоже не все просто. Придется делать расчеты по другому - смещать начало координат (в треугольной системе) или учитывать минимальную длину ремня в точке касания. Может на следующей неделе поборю.

Как оно? Покаж результаты!

k2m30 писал(а):И еще, я сейчас делаю обработку плавных переходов между элементами, но не могу формализовать задачу в терминах математики. расскажи, если несложно с какой стороны к этому подойти? я смотрел по ветке, у тебя тоже были с этим вопросы.

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

Nick писал(а):Что-то я эту тему потерял...

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

Что-то не верится, что это сильно влияет на результат... Особенно то, что перемещение каретки меняет точку зацепления на ремне и это сильно влияет на результат...
А есть какие-то практические результаты по этому поводу???
То, что балончик висит ниже точки ремней - это можно компенсировать простым смещением по Y.
То, что ремни присоединяются не в одной точке, а в двух разнесенных по горизонтале точках имхо можно компенситровать просто внесением поправки в "растояние между шкивами", т.е. вычесть из этого расстояния растояние между ремнями.

Результат очень простой - длинная прямая оказывается кривой при ближайшем рассмотрении. Сейчас вероятно наибольшая проблема это калибровка и начальные значения, но и то, что я перечислил тоже. Я моделировал. По Y согласен, вопросов нет, в вот по Х - серьезные. Вычесть из "расстояния между шкивами" не получится.

Nick писал(а):

k2m30 писал(а):В итоге переписал софт заново (выкинул матлаб, написал на Java), учел реальную геометрию, заказал датчики PLL01 (индуктивные) для точного позиционирования. Там тоже не все просто. Придется делать расчеты по другому - смещать начало координат (в треугольной системе) или учитывать минимальную длину ремня в точке касания. Может на следующей неделе поборю.

Как оно? Покаж результаты!

Попробую приложить файлы.

Nick писал(а):

k2m30 писал(а):И еще, я сейчас делаю обработку плавных переходов между элементами, но не могу формализовать задачу в терминах математики. расскажи, если несложно с какой стороны к этому подойти? я смотрел по ветке, у тебя тоже были с этим вопросы.

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

Хм.. я пошел глубже. Анализирую значение второй производной X(t) и Y(t) в треугольной системе координат. И если оно превышает определенное значение, то пытаюсь нарисовать кривую Безье в месте изгиба.
Пока, правда, получается плохо

Вот так теперь работает софт. В архивах примеры работы, их просмотр, плюс исходные svg файлы.

Я делал круги - потому, что круги это постоянная сила... хотя кривая безье может быть и лучше получится - это кривая 3-го порядка.

k2m30 писал(а):Результат очень простой - длинная прямая оказывается кривой при ближайшем рассмотрении.

Ну не без этого , но разве это так сильно заметно?

k2m30 писал(а): Вычесть из "расстояния между шкивами" не получится.

Вроде как должно получиться, или я что-то не так себе представляю?

Nick писал(а):Я делал круги - потому, что круги это постоянная сила... хотя кривая безье может быть и лучше получится - это кривая 3-го порядка.
Круги - это хорошо, но фишка в том, что круги (или кривые Безье) нужно рисовать в треугольной системе координат, а не в прямоугольной, поскольку важно изменение скорости шагового двигателя, а не форма траектории как таковая.

k2m30 писал(а):Результат очень простой - длинная прямая оказывается кривой при ближайшем рассмотрении.

Ну не без этого , но разве это так сильно заметно?
Моя цель - рисунок на торце десятиэтажного дома. И там, таки-да, заметно

k2m30 писал(а): Вычесть из "расстояния между шкивами" не получится.

Вроде как должно получиться, или я что-то не так себе представляю?

Нет, не так, я постараюсь нарисовать чуть позже.

Nick писал(а):Вроде как должно получиться, или я что-то не так себе представляю?

И я согласен. Разве что сдвигать нужно оба шкива к баллончику.

И да, эта штука может висеть криво. Поэтому лучше все-таки соединять в одной точке.
Хотя для масштабов десятиэтажного дома это мелочи, рамка должна быть с окно, чтобы заметно было

У меня тоже работает только с последней dev версией

k2m30 писал(а):С dev заработало вроде. Подробно буду уже завтра смотреть. Вроде пока похоже, спасибо большое.

Думаю будет интересно в этой теме.



http://www.flickr.com/photos/91789568@N ... mm-eoYLVC/

PS Зебра атакует

А это чисто с зебры или отдельно через Gкод?

Зебра генерирует SVG. Затем в блендер. Что дальше я не знаю.
По ссылке есть описание.

Блендер... хммм интересно... щас мы его попытаем

Сообразил простейшую рисовалку.
Подскажите, как сделать из картинки/фотографии G-код

мммм.... покаж рисовалку
И какой gкод тебе нужен?
А то мы сейчас напредлагаем image-to-gcode

Пока что это 2 моторчика по углам и ниточка с грузиком, перо еще надо прицепить. Кинематику взял отсюда http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Koppi's_Toy

Хочется рисовать картинки типа http://www.flickr.com/photos/91789568@N ... otostream/
Это что-то сложноватый путь, да и для обычных фото не годится http://www.marginallyclever.com/blog/20 ... bot-gcode/

PKM писал(а):Хочется рисовать картинки типа

Это надо зебру смотреть... http://maxim-s-barabash.github.io/ZebraTrace/
Хммм... что-то она у меня не запустилась... хотя, у меня система старая и я не особо старался, времени мало...

Зебра у меня запустилась. Но как из нее сделать G-код для переменной толщины линии... gcodetools должен помочь, по идее?

Вроде как в зебру добавили генерацию готового Gкода...

Сохранение в ngc не работает, дает пустой файл...