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

Отработка команды G7 стойкой MillPlus


alexey_br

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

При создании станка DMU 125P hi-dyn со стойкой MillPlus появилась проблема отработки команды G7 (наклон рабочей плоскости).

При симуляции программы ошибки не появляются но поворот осей не происходит. Стойка используется из библиотеки - heimplus.

 

В меню отработки G-кодов (G-Code Processing) команда G7 расписана - есть списки макросов которые должны выполнятся при разных вариантах задания команды. Среди них есть макрос CAxisMotion с аргументом Value=#122 и макрос BAxisMotion с аргументом Value=#121.

Подскажите пожалуйста, #121 и #122 это переменные? Если да, то откуда они должны брать значения?

 

Также в библиотеке Vericut есть подпрограмма heimplus.sub предназначенная для выполнения команды G7, но обращения к ней в стойке heimplus я не нашел, хотя переменные используемые подпрограммой в стойке описаны.

 

Подскажите как должен задаваться вызов подпрограммы при выполнении симуляции обработки?

 

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


При создании станка DMU 125P hi-dyn со стойкой MillPlus появилась проблема отработки команды G7 (наклон рабочей плоскости).

При симуляции программы ошибки не появляются но поворот осей не происходит. Стойка используется из библиотеки - heimplus.

 

В меню отработки G-кодов (G-Code Processing) команда G7 расписана - есть списки макросов которые должны выполнятся при разных вариантах задания команды. Среди них есть макрос CAxisMotion с аргументом Value=#122 и макрос BAxisMotion с аргументом Value=#121.

Подскажите пожалуйста, #121 и #122 это переменные? Если да, то откуда они должны брать значения?

 

Также в библиотеке Vericut есть подпрограмма heimplus.sub предназначенная для выполнения команды G7, но обращения к ней в стойке heimplus я не нашел, хотя переменные используемые подпрограммой в стойке описаны.

 

Подскажите как должен задаваться вызов подпрограммы при выполнении симуляции обработки?

121 и 122 это переменные, они скорее всего считываются при разборе команды G7. Посмотрите разбор слов A, B, C. Вызов подпрограмм надо смотреть видимо при разборе слова G7

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

При создании станка DMU 125P hi-dyn со стойкой MillPlus появилась проблема отработки команды G7 (наклон рабочей плоскости).

При симуляции программы ошибки не появляются но поворот осей не происходит. Стойка используется из библиотеки - heimplus.

 

В меню отработки G-кодов (G-Code Processing) команда G7 расписана - есть списки макросов которые должны выполнятся при разных вариантах задания команды. Среди них есть макрос CAxisMotion с аргументом Value=#122 и макрос BAxisMotion с аргументом Value=#121.

Подскажите пожалуйста, #121 и #122 это переменные? Если да, то откуда они должны брать значения?

 

Также в библиотеке Vericut есть подпрограмма heimplus.sub предназначенная для выполнения команды G7, но обращения к ней в стойке heimplus я не нашел, хотя переменные используемые подпрограммой в стойке описаны.

 

Подскажите как должен задаваться вызов подпрограммы при выполнении симуляции обработки?

В начале считываются углы

post-9003-0-45665800-1396370988.png

Потом обрабатывается сама команда G7

post-9003-0-69163000-1396370983.png

При обработке команды G7 и происходит вызов подпрограммы

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

спасибо за ответ.
 
от версии к версии разработчики активно развивают эту функцию.
 
нашел такую отработку

post-19074-0-47812900-1396419233.jpg
так функция работает. но поворачивает правильно только при длине инструмента равной 100мм (видимо это обусловлено формулами пересчета в подпрограмме)
 
 
 
а в версии 7.3 уже так:
post-19074-0-36814400-1396419264_thumb.jpg
 
В версии 7.3 вызова подпрограммы нет. переменные #121 и #122, я так понял, должны определяются макросом WorkingPlane, но этого не происходит(поворота осей нет). Если вместо #121 и #122 прописать углы то поворачивает.

 

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

 

спасибо за ответ.

 

от версии к версии разработчики активно развивают эту функцию.

 

нашел такую отработку

так функция работает. но поворачивает правильно только при длине инструмента равной 100мм (видимо это обусловлено формулами пересчета в подпрограмме)
 
 
 
а в версии 7.3 уже так:
 
В версии 7.3 вызова подпрограммы нет. переменные #121 и #122, я так понял, должны определяются макросом WorkingPlane, но этого не происходит(поворота осей нет). Если вместо #121 и #122 прописать углы то поворачивает.

 

переменные в принципе можно посмотреть в отдельном окне, чему они равны в пошаговом режиме запуска программы

Сами переменные надо поискать наверняка они где присваиваются.

7.3. версии не имеем могу посмотреть только на 7.1

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

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

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

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

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

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

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

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

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

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

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




  • Сообщения

    • lem_on
      ну с дуру известно что сломать можно.
    • Viktor2004
      руку привязки так сломать легко
    • lem_on
      По моему вполне логично если станок вывалится в ошибку если рука не доехала до места. У меня так же если кулачки или деталь на пути, просто пихаеш ее до места и станок опять активен. Но нынешние пановья даже не могут написать модель станка.
    • Viktor2004
      Я согласен что скорее всего проблема механическая Но если логика прописана криво и возможно не предусмотрела остановку в промежуточном состоянии, разве не логично будет попробовать принудительно подав напряжение дернуть эту руку вверх-вниз? Возможно то что туда попало выпадет  
    • Guhl
      Если оставить за скобками вопрото том, что до м19 работает нормально, а после нет, то вы не считали сколько у него реально импульсов на оборот? с помощью стороннего плк, например  А если ориентацию м5 снимать, а не м20?
    • lem_on
      Что это за станок такой в котором сразу ладер ковырять надо, даже не смотря на возможность механической проблемы? Или профдеформация?
    • Viktor2004
      не сразу я понял в чем вопрос. Долго соображал что такое режим управления скоростью. При завершении ориентации PMC снимает сигнал G70.6 ? И если он после снятия сигнала продолжает удерживать шпиндель, при каких условиях эта ориентация все же снимается? После нажатия аварийного грибка или еще как?
    • Viktor2004
      Ладдер пришлите. Будем принудительно пробовать поднимать и опускать
    • streamdown
      Коллеги приветствую! IPS 8. Подскажите пожалуйста, кто какое серверное железо использует? Интересуют параметры при одновременной работе, ну например, 400 пользователей онлайн
    • gudstartup
      так он так и позиционируется по m19 pmc выдает g70.6 а чпу отвечает f45.7 но ориентацию и смещение в 4077 он отрабатывает нормально шпиндель встает ровно и смена происходит хорошо. вопрос почему после ввода команды управления скоростью он все еще продолжает контролировать число импульсов между нуль метками хотя в принципе уже должен отменить позиционный контроль и просто считать обороты по 0 метке как он это делает без М19? это все понятно но почему оно продолжает проверять это после завершения ориентации мне непонятно
×
×
  • Создать...