Перейти к публикации

HEIDENHAIN 530 LN-кадры 3D-коррекция


DJ Astro

Рекомендованные сообщения

Знатоки Vericut'a, помогите, пожалуйста!

Vericut 7.3. При отработке LN-кадров (с 3D-коррекцией, кадр вида LN X... Y... Z... NX... NY... NZ...) на стойке HH 530, взятой из библиотеки, станок крутит поворотными осями, хотя в реальности не должен. Поворотные оси должны реагировать на вектор нормали только при активной функции M128.

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

Смотрю в настройках G-Code-Processing... Там и LN c NX есть, и макрос в NX есть - Tool3dOffset. Пробую удалить в NX этот макрос, остаётся только MotionLinear - ничего не меняется. И почему обычное перемещение L описано в ветке Specials, а LN - в ветке States?

Ссылка на сообщение
Поделиться на других сайтах


Кроме NX,NY,NZ в программке должны быть TX,TY,TZ и именно от них зависит, будет станок крутить головами-столами или нет. Должны быть определены параметры инструмента (диаметр и радиус скругления, если есть), должна быть задана величина коррекции.

Ссылка на сообщение
Поделиться на других сайтах
Кроме NX,NY,NZ в программке должны быть TX,TY,TZ и именно от них зависит, будет станок крутить головами-столами или нет.

Вот тут немного не соглашусь. По мануалу от HH530 может быть 3 варианта.

Кадр содержит:

1. NX,NY,NZ - инструмент стоит вертикально (оси-столы не вращаются), смещается в направлении вектора для 3D-коррекции.

2. NX,NY,NZ M128 - инструмент становится вдоль вектора нормали (оси-столы вращаются), смещается вдоль вектора для 3D-коррекции (т.к. вектор нормали и ось инструмента в этом случае совпадают, то смещение коррекции происходит вдоль оси инструмента).

3. NX,NY,NZ,TX,TY,TZ M128 - инструмент становится вдоль вектора TX,TY,TZ (оси-столы вращаются), смещение коррекции происходит вдоль вектора NX,NY,NZ.

 

Программа написана по первому варианту.

И да, после добавления в прогу принудительно M128 в начало и TX+0 TY+0 TZ+1 в каждый кадр - станок ездит как надо, но это мне кажется слегка неправильно... :g:

Ссылка на сообщение
Поделиться на других сайтах

:(

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

Ссылка на сообщение
Поделиться на других сайтах

Да можно, родной...

В VERICUT можно настроить все, что угодно. И если в твоей программе НИГДЕ не указано, как должен быть ориентирован инструмент (странно, не правда ли?), то можно подсказать VERICUT - используй вектор 0,0,1

А вот станок - он настолько умный, что если вдруг, в силу разных причин, стартует твою программу БЕЗ КАКОГО ЛИБО УКАЗАНИЯ ВЕКТОРА ИНСТРУМЕНТА, и при этом столы-головы (в силу разных причин - сброшено выполнение предыдущей программы на "полу-слове") не обнулены - так эта программа так и пойдет в кривых осях.  

Ссылка на сообщение
Поделиться на других сайтах

В VERICUT можно настроить все, что угодно. И если в твоей программе НИГДЕ не указано, как должен быть ориентирован инструмент (странно, не правда ли?), то можно подсказать VERICUT - используй вектор 0,0,1

Не вижу ничего странного, если такое допускается правилами программирования станка. В начале программы идёт сброс всех поворотов, наклонов и вывод осей в исходное (это же можно считать указанием, как должен быть ориентирован инструмент?). Далее идёт обычная 3х обработка. Потом включается коррекция - кадры L становятся LN и добавляется NX NY NZ. Что тут плохого? Зачем еще где-то указывать ориентацию инструмента?

Но смысл я уловил, куда копать понял...  только не знаю, какой лопатой  :rolleyes:Ug_user, помогите, пожалуйста разобраться. :worthy:

 

В наcтройках G-code processing команда LN описана так (в исходном варианте у Tool3DOffset почему-то не  было Value=1, добавил):

e285b7bb40610ed6f65537c55f70538e.jpg

 

NX, NY, NZ описаны так:

910f2f682cc1e5b95794e9bca611bef1.jpg

 

Тут прописаны макросы IVector, JVector, KVector, которые рассчитывают углы и поворачивают оси. Убрал их - станок перестал крутить осями в кадрах LN NX NY NZ. Смещения инструмента вдоль вектора происходят (на весь радиус сферы инструмента). Пусть пока так, хорошо, пока это хоть немного похоже на то, что нужно. 

Копаю дальше...

Теперь нужно, чтобы после M128 станок по этим кадрам ориентировал инструмент по заданному вектору. Под М128 дописываю новую переменную "M128_STATE", которая до M128 равна 0, после того, как встретится М128 она равна 1. В описания NX NY NZ добавляю еще один пункт, что если M128_STATE =1, тогда использовать макросы IVector, JVector, KVector.

Теперь описание NX NY NZ выглядит так:

89b887811f8863084764d323bcf78c15.jpg

 

 В этом случае после М128 станок начинает крутить осями по кадрам LN NX NY NZ, но едет чёрти куда (возможно из-за неправильно настроенной собранной кинематики и настроек инструмента??? В случае, когда М128 идет с обычными кадрами L - всё работает хорошо, едет куда нужно.). 

Что я делаю неправильно?

 

И вот вопрос по инструменту.

Начальное положение станка. Точка привязки где-то внути шпинделя.

739a6e8c12b61f7ef5587a9872cc94c8.jpg

 

Станок после вызова инструмента. Точка привязки смещается на вершину инструмента.

0be0e4020fd90bc643ce8e20e24d138b.jpg

 

По кадру L X0 Y0 Z0 станок едет как надо, вершиной инструмента в ноль.

По следующему кадру LN X0 Y0 Z0 NX0 NY0 NZ1 (отрабатывает макрос Tool3DOffset) станок едет в ноль точкой, которая ниже точки начального положения на ту величину, которая указана в Gage point инструмента в таблице инструмента.

e730b5734b21c653ae4a15529523fb40.jpg

 

Как это победить?

Я так понимаю, что это всё взаимосвязано с положением (координатами) элементов Tool, Spindel в исходной сборке станка, настройками точек привязки самого инструмента, настроек различных G-code Offset'ов. Как всё это правильно настроить?

Ссылка на сообщение
Поделиться на других сайтах

Возможно, немного понял, где сидит проблема... но не знаю, как ее решить. :(

При смене инструмента задействованы два макроса TurnOnOffGageOffset (смещает DrivenPoint инструмента на величину из Gage Point из таблицы инструментов) и TurnOnOffGagePivotOffset (смещает DrivenPoint инструмента на расстояние между компонентом Tool станка и нулём поворотных осей). 

Изначально DrivenPoint находится в центре поворотных осей. Если покадрово просмотреть работу смены инструмента, то DrivenPoint сначала смещается на торец шпинделя макросом TurnOnOffGagePivotOffset (т.к. Tool находится там) и потом TurnOnOffGageOffset сместит управляющую точку еще на длину инструмента из таблицы.

В LN-кадрах, когда отрабатывает макрос Tool3DOffset - такое ощущение, что TurnOnOffGagePivotOffset становится неактивным и станок перестает учитывать расстояние от центра осей до Tool, хотя перекрестие DrivenPoint остается на кончике инструмента и никуда не смещается.

Изменено пользователем DJ Astro
Ссылка на сообщение
Поделиться на других сайтах

Если бы макро TurnOnOffGagePivotOffset выключился, то DrivenPoint также бы смещалась обратно на величину плеча, как мне кажется.

Вообще, при отладке я всегда говорю - отображать все оси. Картина более прозрачна

Ветка, в которой описан макро, в Word/Adress не имеет значения.

Тяжело наощупь что-то насоветовать.

Надо найти просто пример, где это реализовано. Я в стандартных семплах не нашел.

По кинематике станка у вас, на первый далекий взгляд, все в порядке. Дело, вернее всего, в настройках макро.

Ссылка на сообщение
Поделиться на других сайтах
  • 3 года спустя...

Наконец-то решил задачу 4-хлетней давности! :biggrin: Всё закрутилось, заработало. Но пока только для сферы. Для фрезы с радиусной кромкой не могу придумать, куда воткнуть корректор на радиус кромки. Кроме как вторым значением в Cutter Compensation инструмента ничего не придумал. Но теперь как прочитать значение под нужным номером из списка Cutter Compensation? Макрос "AutosetToolManCutComVars" пробовал - результат не очень нравится.

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • gudstartup
      вы тоже думаете что можно все компоненты чпу заменить и ничего не изменится и предупреждение о том чтобы oprminf не восстанавливали на другой машине которое фанук встроил даже в загрузчик это просто алармисткий текст и ничего не будет..... ну и ну и где написано что она mate как например здесь с чего тогда базовый чпу mate если гл.плата не mate мне непонятно из-за экрана что ли
    • статист
      Охренеть, ни за что бы не догадался. Хоть бы словом где обмолвились об этом в документации. Короче нужна команда EMODIF, E_ID, 3, N_ID где E_ID - номер элемента, который мы собираемся модифицировать. Так как используется BEAM188, то у него не два узла оказывается рассматривается, а три, где первые два принадлежат элементу, а третий узел - направляющий. И соответственно число 3 - это номер узла балки, который мы собираемся модифицировать, то есть направляющий узел. И мы этот узел соответственно заменяем на узел с номером N_ID. И тогда сечение реально вращается. Разобрался по этому видео.    
    • Александр1979
      Материнка такая в руководстве есть. На 0i-D я менял материнку, опции не слетели. 
    • gudstartup
      @Viktor2004 кстати конкретно модели автора в руководстве нет хотя оно последней редакции 18 года
    • Viktor2004
      конкретно на этой не менял. На каких менял, написал выше
    • gudstartup
      какие платы и на каких системах вот в чем ворос конкретно на этой возникут проблемы
    • Viktor2004
      ну да. А то что я менял платы это мои бредовые фантазии   Ну исправили в паспорте. И что?
    • gudstartup
      это догадки и гадание на кофейной гуще а япривожу документ где написано про то что прочитайте пункт 4.11 а там представляете вот что 4) Замена печатной платы может привести к изменению идентификационного номера ЧПУ. Проверьте это на Экран ЧПУ. Если оно отличается от описанного в техническом паспорте, исправьте его.  
    • Viktor2004
      я менял все платы. И на форуме наверное не я один их менял. И никто еще не писал что при этом у него слетел сертификат Возможно ID номера проверяются только в момент установки опции, а когда они уже установлены и мирно хранятся в OPRM INF возможно ти уже на ID наплевать
    • gudstartup
      для кого это написано CAUTION Before replacing a printed circuit board, be sure to read Section 4.11, “OPTION INFORMATION FILE” to confirm the procedure.  
×
×
  • Создать...