cnc-club.ru

psha писал(а):Здесь она разбивается на четыре строчки (x0-\epslion, 0), (x0, 1), (x1, 1), (x1+\epsilon, 0)

Да, все таки ПО придется написать. Но ничего, это не так страшно .

PKM писал(а):Это не так плохо, но на картинку 100х100 мм с постоянно изменяющейся насыщенностью могут понадобиться миллионы строк кода (даже при дискретности 1 мм по Y)

А чтобы сократить количество строк, нужно сократить количество цветов. Какое количество цветов действительно актуально, 256, 128, 64, 32, 16?

aftaev писал(а):Тогда делаем так:Я дам настройки станка с Мачем, нарисуешь HAL под мой станок. Поставлю ЕМС с твоим HAL и будем проверять теорию на практике

Давай свои настройки. Ты управляешь через LPT?
И еще такая просьба, кто-нибудь может сгенерить стандартный конфиг через stepconf с 3-мя осями и управлением шпинделем?

Nick писал(а):Мф же не знаем, сколько времени уйдет на перемещение к следующей точке (и следующей строчке), а стримеру пофигу, он будет читать без остановки, в итоге картинка поплывет.

А чего это он будет без остановки? Пусть считывает текущие координаты и привязывает интенсивность к ним.

Да, все таки ПО придется написать. Но ничего, это не так страшно .

Для начала попробовать image2gcode, думаю картинку можно будет разобрать

Если его не тормозить, он будет раз в определенный период (период своего потока) считывать значение и запихивать его в определенный пин. Вне зависимости от того, есть там что-то или нет. А для того, чтобы привязать интенсивность к координатам, нам нужно иметь громадный массив (пикселей) с поиском по нему в реалтайме, вот это и создает проблему. Поэтому предлагается использовать стример.

PKM писал(а):Для начала попробовать image2gcode, думаю картинку можно будет разобрать

Там он точно будет тормозиться, т.к. в image2gcode заглубление идет под прямым углом, а не по наклонной. Поэтому, вне зависимости лот скорости 3-ей оси будет остановка на угле.

psha писал(а):Я несколько не в курсе что и как там происходит, поэтому могу пороть чушь
Разве фокус устанавливается не один раз?

У нас лазер не будет подыматься по оси Z. Идея была такая: берем рисунок, привязываемся к глубине цвета. В Gcode мощь лазера приявзана к глубине цвета например к координате Z(непроблема взять другую). В Граверах оси Z нету, там только стол подъемный. Положили заготовку, поймали фокус подъемом стола или ручками опустили лазерную головку и пошла гравировка. Потому фокус выставляется в начале работы.

Вообще кстати вариант с текущими координатами может быть очень даже ничего, если мы умеем быстро включать лазер.
Поиск по массиву пикселей делается совершенно тривиально, но занимает какой-то объем памяти.
Делаем компоненту с двумя входами (x, y) и выходом (интенсивность), грузим в неё картинку (1024x1024 8 бит цвет будет жрать всего 8кб памяти)
и соединяем правильным образом.
Но я бы попробовал вначале с гкодом.

2aftaev
Ну да, я так и думал. Поэтому и удивился что упоминули необъодимость фокусировки, ведь Z у нас "мнимая"...

upd
не 8 кб, а 8 мб, обсчитался
Но это всё равно немного

psha писал(а):(1024x1024 8 бит цвет будет жрать всего 8кб памяти)

Чего-то маловато ты насчитал, это ровно 1Мб получается. А на нормальную картинку надо минимум 300dpi, это на 10х10см получается 1.3Мб, хотя в принципе не так уж и много.
А мы сможем написать такой компонент, который сможет быстро искать по такому массиву, точнее у которого будет столько памяти?

Требования по фокусировке луча очень жесткие. Малейшее отклонение это потеря мощности. Ручная фокусировка возможна только на безупречно параллельных поверхностях.
Я все таки не могу понять почему вы так упорно хотите привязаться к ЕМС.
Что мешает просто через ЛПТ порт передавать сигналы на шаговые двигатели. При растровом способе рисования картинки ЕМС вообще не нужен.
Ведь работает только одна координата. И нет необходимости ничего интерполировать.

А чтобы получить цветную картинку надо поставить три лазера с разными цветами

Nick писал(а): А чтобы сократить количество строк, нужно сократить количество цветов. Какое количество цветов действительно актуально, 256, 128, 64, 32, 16?

Существует мнение, что если использовать экспоненциальную шкалу, то достаточно всего 64 значения яркости.

Impartial писал(а):Я все таки не могу понять почему вы так упорно хотите привязаться к ЕМС.
Что мешает просто через ЛПТ порт передавать сигналы на шаговые двигатели. При растровом способе рисования картинки ЕМС вообще не нужен.
Ведь работает только одна координата. И нет необходимости ничего интерполировать.

В общем да, логично, ЕМС2 тут не особо нужен. Нам он просто нравится

А чтобы получить цветную картинку надо поставить три лазера с разными цветами

Это будет уже лазерное шоу

Impartial писал(а):Я все таки не могу понять почему вы так упорно хотите привязаться к ЕМС.

Это готовый, надежный обвес в котором реализовано очень много чего. Допиливать его под произвольные нужды гораздо проще, чем что-то делать с нуля.
Никто не заставляет использовать от него интерфейс или еще какие вещи, которые не нужны.

Impartial писал(а):Малейшее отклонение это потеря мощности.

И как это влияет на то, как мы осуществляем включение/выключение? Как двигаемся? Ну да, фокусировка важна. Но не будем жы мы делать её в процессе гравировки.

Nick писал(а):А мы сможем написать такой компонент, который сможет быстро искать по такому массиву, точнее у которого будет столько памяти?

Можем наверное. Особенно если квантование цветов ввести. Правда, разницы между 64 и 256 цветами особой нету (6 бит и 8 бит занятых).
Вечером точнее скажу.

psha писал(а):Можем наверное. Особенно если квантование цветов ввести. Правда, разницы между 64 и 256 цветами особой нету (6 бит и 8 бит занятых).Вечером точнее скажу.

Эта разница может быть ощутима, если мы делаем управление Gкодом, меньше цветов = меньше изменений мощности = меньше строк Gкода.

Impartial писал(а):Я все таки не могу понять почему вы так упорно хотите привязаться к ЕМС. Что мешает просто через ЛПТ порт передавать сигналы на шаговые двигатели. При растровом способе рисования картинки ЕМС вообще не нужен.Ведь работает только одна координата. И нет необходимости ничего интерполировать.

Потому, что не нужно решать следующие вопросы:
1. Ускорение
2. Стабильность работы на больших скоростях
3. Интерфейс
4. Драйвера
5. ..... наверняка можно долго продолжать
335. Да, он нам нравится !

-----------------
Остается вопрос по компоненту с большим массивом....

Ну да, фокусировка важна. Но не будем жы мы делать её в процессе гравировки.

Именно это и надо делать иначе это будет не гравировка а процесс с непредсказуемым результатом.

Хммм.... не видел, чтобы на подобных станках (простых лазерных граверах) стояла автоматическая система фокусировки. Перед началом работы - да фокусировка есть, но не во время.
Тем более, как ее проводить на таких скоростях?

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

Почти точно так же как в пишущем DVD. В больших пределах именно осью Z.

А как оценивать расстояние до поверхности?

Impartial писал(а):В больших пределах именно осью Z.

И откуда брать эту информацию? Заранее сканировать поверхность?
Иметь постоянно работающий "дальномер" и от него корректироваться?
Как-то это странно звучит...
Пример с DVD не показателен

Иметь постоянно работающий "дальномер" и от него корректироваться?

Да, постоянно работающий триангуляционный дальномер на вспомогательном лазере. А что вас смущает?

Не вопрос, сделать можно и для такой системы. Есть пример такого станка?
-----------

Скиньте кто-нибудь стандартный конфиг на три оси со шпинделем!

Impartial писал(а):Да, постоянно работающий триангуляционный дальномер на вспомогательном лазере. А что вас смущает?

Запаздывание смущает. Дальномер нам может только сказать что "сейчас мы стоим на неправильном расстоянии", а о том какое
будет на следующем шаге ничего не говорит. Так что всё время будем расфокусированы, если сначала не проведем сканирование
и не построим траекторию движения в зависимости от формы детали. Это если исходить из того, что малейшая расфокусировка смерти подобна.

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

Вообще, какой угол расхождения (или в даном случае схождения) пучка? Если градусов 20, не так уж страшна ему расфокусировка.