cnc-club.ru

Подскажите как настроит поворотную ось в LinuxCNC для вот такой задачи:

https://www.youtube.com/watch?v=qYKLiQyM6Eo.

присоеденяюсь

Элементарно Ватсон . Самое простое - в stepconf тип станка XYZA и дальше все как обычно.
Начинайте со степсоконфа, потом как обычно пишите, что получилось, что надо исправить и конфиги в студию .

Наверное я поторопился и неточно задал вопрос.
Какой софт применяется для создания УП для подобный работ, и исходя из этого как настраивать поворотную ось.

Ну если как на видео, только три оси, то можно ARTCAM, Vectric Aspire, JDPaint. А вот если 4ре оси, нужны программы посерьёзней , из простого знаю только Desk Proto.

Долго для себя подбирал софт для этого дела, остановился на VisualMill.

Тоже долго для себя подбирал софт для этого дела, терпения хватило только с VisualMill,правда точить еще не пробовал.

Я пробовал, на тестовом станке из лдсп, стратегий вообще нет, только вдоль, поперек, по спирали( не уверен). Не самй лучший алгоритм работы с черновыми проходами, но при всем этом мне понравилось. Вообщем вся прелесть в простоте.

Добрый день .
Пытаюсь настроить поворотку . Простая грубая обдирка цилиндра D80мм по спирали .
Сильно дергается F , как будто G61 вкл. , и от степени G64 не зависит .
Протестите , пожалуйста , файл на станке или симуляции - мож я в настройках наковырял .

А какая управляющая программа стоит?
ЗЫ может и правда g61 включен?

Nick , а ты попробовал ? Можно и без станка - у меня в DRO feedrate какая-то муть .
Точно так же на приводах . Забиваю G64P2 - без изменений . Без А все хорошо .
По УП не понял тебя .
Интерфейс Axis , CAM - Pmill , УП - 1.ngc - см. выше .

Хмм... странно скорость и правда скачет... Хотя может быть скорости отображается скорость в координатах XYZ, а она не равна реальной скорости перемещения инструмента...

Nick писал(а):Хмм... странно скорость и правда скачет...

Приятно слышать .
Не поможешь перевести из мануала :

The rate at which the controlled point or the axes move is nominally a steady rate which may be set
by the user. In the Interpreter , the interpretation of the feedrate is as follows unless “inverse time
feed” or “feed per revolution” modes are being used(see Section 15.44).
1. If any of XYZ are moving , F is in units per minute in the XYZ cartesian system ,and all other
axes (UVWABC) move so as to start and stop in coordinated fashion
2. Otherwise , if any of UVW are moving , F is in units per minute in the UVW cartesian system ,
and all other axes(ABC) move so as to start and stop in coordinated fashion
3. Otherwise , the move is pure rotary motion and the F word is in rotary units in the ABC
“pseudo-cartesian” system.

особенно первый абзац .

Скорость с которой движется контрольная точка обычно является постоянной и может быть задана пользователем. В интерпретаторе, скорость интерпретируется следующим образом, если только не включены "inverse time feed" или "feed per revolution" (обратная скорость (за какое время нужно проехать дистанцию) или подача на оборот) (см раздел 15.44):
1. если любая из осей XYZ двигается, F измеряется в единицах измерения в минуту в прямоугольной системе координат XYZ, а все остальные оси (UVWABC) двигаются таким образом, чтобы стартовать и останавливаться скоординарованно (наверное имеется в виду, что они двигаются так, чтобы движение по этим осям было согласованно с движением по осям XYZ).
2. Иначе, если UVW двигаются, то F тоже рассчитывается в прямоугольной системе координат UVW, а ABC двигаются синхронно с ними.
3. Иначе, движение чисто вращательное, т.е. только в осях ABC, и F расчитывается в псевдо картезианской системе ABC....

Чего-то я не совсем все это понял

Nick писал(а):Чего-то я не совсем все это понял

Это профессионализм - перевел-то качественно .

Из точки X0A0 кадры
G1X10A1F100
G1X10A100F100 и
G1A10F100
выполняются за одинаковое время .
В пункте 3 скорости по поворотным осям раздаются , исходя из длины псевдо-вектора
L=sqrt[A*A+B*B+C*C] .

Да, похоже на то, но как-то странно, вроде более менее равномерно все движется...

Проверил на опыте.
Все верно, работает именно так как написано. Только есть одно но, к этому всему добавляется максимальная скорость по оси, поэтому движение
G1X100A1000F1000 вышло дольше из-за ограничения по скорости оси А. https://www.youtube.com/watch?v=fq9iEyMsm60

Спасибо , Nick ! А то я , было , подумал , что подпортил свою Ubuntu в попытках о`Glade`иться .

Но больше всего огорчает то , что и в Inverse time feed mode нет плавности перемещений . Плавность растет с ростом "линейной" составляющей кадра .
ЗЫ . Буду признателен любой инфе по теме .

А откуда ты эту фразу про расчет скорости взял?
Может этот вопрос можно решить при помощи специальной кинематики...

Nick писал(а):А откуда ты эту фразу про расчет скорости взял?

Эту

DSP1 писал(а):В пункте 3 скорости по поворотным осям раздаются , исходя из длины псевдо-вектораL=sqrt[A*A+B*B+C*C] .

?
Сам придумал . Я не проверял , но почти уверен , что движение G1A100B100C100F100 займет в sqrt[3] раз
большее время , чем G1A100F100 .

Nick писал(а):Может этот вопрос можно решить при помощи специальной кинематики...

G93 тем и хороша , что учитывает конкретную кинематику . Она просто говорит интерпретатору :
" Будь любезен , ничего не интерпретируй , просто перегони оси(джойнты) в точку кадра за время 60/F сек ."
Неплавность перемещений незаметна в кадрах типа
X100A100
X0.1A0.1
X100A0.1
и становится выраженной при последовательности кадров типа
X0.1A100
Мож это связано с алгоритмом расчета разгонов/торможений ?