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

G-POST, много вопросов. Хочется понять логику работы.


DJ Astro

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



В разделе Rotary Axis Type активируйте поле -n and +n

 

Прежде чем задать вопрос здесь довольно долго штудировал хелп по ж-посту.

Видел, что для использования ограничений перемещений нужно выбирать вариант "-n and +n". Попробовал, но  к своему изумлению увидел огромное количество warningов и такую же кучу недопустимых значений координаты "B".  Но все равно спасибо! Вопрос остается открытым.

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

Да, в моём варианте обработки для проверки правильности работы кода таких вариантов не встретилось (когда B=+-90). А проверка правильности расчетов в экселе оказалась не совсем правильной. Для проверки я задавал углы, по ним вычислял матрицу поворота и затем обратно по матрице вычислял углы. Раз значения совпадали значит всё ОК!  Только теперь, когда начал разбираться понял, что при вычислении матрицы, там где должны были быть нули получались очень маленькие числа типа 0,11Е-17, (но не ноль!). И поэтому при обратных вычислениях исходные углы вычислялись правильно, а не обнулялись. А я сразу не придал значения этому... :(

 

Bastion, добавил в код для CAMERA такие условия для проверки предельных случаев:

теперь ваша обработка работает правильно

....

.....

AVAL=ATAN2F(YK,ZK) $$ plane spatial A

BVAL=ASINF(-XK) $$ plane spatial B

CVAL=ATAN2F(XJ,XI) $$ plane spatial C

IF (XK.EQ.-1) THEN $$ if B=90

 CVAL=ASINF(YI)

ELSE

  IF (XK.EQ.1) THEN $$ if B=-90

    CVAL=ASINF(-YI)

  ENDIF

ENDIF 

AVAL=TEXT/CONVF,AVAL,10,5,1,0,5 $$ convert to text

BVAL=TEXT/CONVF,BVAL,10,5,1,0,5

CVAL=TEXT/CONVF,CVAL,10,5,1,0,5

.....

...

В этих случаях А будет всегда =0, а С будет вычисляться правильно.

Или, если хотите, то можно поменять наоборот - А -вычисляется, С=0. Результат работы цикла PLANE SPATIAL будет одинаковый.

А это на фануке работает ?

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

Этот расчёт не привязан к определенному станку или стойке. Это чистая математика по повороту одной системы координат в другую. Можно ли использовать эти вычисленные пространственные углы на фануке - я не знаю.
 

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

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

Сиквенс реализован как 3-х координатная обработка, но входит в операцию содержащую сиквенсы с 5-ти координатными обработками. При этом переход в котором возникает данная проблема реализован в плоскости XY (G17).

2016-12-21_16-09-35.png

Ссылка на сообщение
Поделиться на других сайтах
12 часа назад, Mysterious сказал:

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

Скорее всего для постпроцессора нужно 3 точки для окружности, поэтому ВСЕГДА в последовательностях задавайте NUMBER_OF_ARC_PTC 3!

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

Скорее всего для постпроцессора нужно 3 точки для окружности, поэтому ВСЕГДА в последовательностях задавайте NUMBER_OF_ARC_PTC 3!

Спасибо за отклик!

В справке нашел следующее:

NUMBER_OF_ARC_PTS: количество точек, выводимых в файл CL, если параметр CIRC_INTERPOLATION имеет значение ARC_ONLY. По умолчанию имеет значение 3.

Что интересно данный параметр отсутствует в обработках типа "черновая", присутствует в "траектория", но имеет значение по умолчанию 1.

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Mysterious сказал:

отсутствует в обработках типа "черновая", присутствует в "траектория", но имеет значение по умолчанию 1.

Так помогло или нет?

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

Проверьте настройки в пост-процессоре.

настройка поста  

circular_ijk_setup.PNG

Hide  
Изменено пользователем zeppelin
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, fenics555 сказал:

Так помогло или нет?

Не могу опробовать ваш совет т.к. не получается добраться до параметра "NUMBER_OF_ARC_PTS". В черновой обработке его нет (по крайней мене у меня).

3 минуты назад, zeppelin сказал:

Проверьте настройки в пост-процессоре.

В точности такие же.

Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, zeppelin сказал:

Проверьте не то что у меня, а то что нужно для вашего станка.

Именно такие и нужны.

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

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

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

Хм, интересно, при чём здесь ось C, если проблема появляется в простом трёхосевом CL ?

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

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

После выбора вышеуказанной опции пост стал выставлять оси "B" и "C" в ноль и корректно вычислять расположение центра дуги.

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

А с чего 

15 часов назад, Mysterious сказал:

Видимо это как то мешало посту корректно вычислять координаты центра дуги.

После выбора вышеуказанной опции пост стал выставлять оси "B" и "C" в ноль и корректно вычислять расположение центра дуги.

А с чего вы взяли, что пост неправильно вычислил координаты центра дуги - вы на станке это проверяли? Просто в таких ситуациях как ваша, пост просто "подвернет" обработку таким образом, чтобы компенсировать математически угол поворота по С. Иными словами, он в развернутом виде вам все сделает так, как бы это выглядело при угле поворота С0. Просто при С0 программу читать проще - в этом лишь и удобство. Если вы прорисуете вашу программу по траектории, например, в CimcoEdit - то увидите, что и в начальном варианте, вероятнее всего, все было правильно...

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

В крео есть PPRINT с помощью которого можно вывести список инструментов. Можно ли с помощью FIL реализовать точно такой же список, только с дополнительным параметром "Z глубина" который бы показывал глубину на который опускается каждый из инструментов? Может у кого-нибудь есть готовое решение, или может кто посоветует что, как это можно реализовать. Пока что на ум приходит только _OUTPT , сверка каждого Z поинструментно? не знаю , сложна :smile: (:sad:)

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

Я бы делал так:
В каждом переходе в PPRINT можно вывести Z_MAXIMUM_TOOL_TRAVEL и Z_MINIMUM_TOOL_TRAVEL.
Каждому используемому в программе инструменту сопоставить параметр. В начале каждого перехода сравнить этот параметр текущего инструмента и величины из PPRINT. Если меньше - то переписать параметр инструмента новым значением. В конце проги всё собрать в кучу и вывести в tool list.
 

Ссылка на сообщение
Поделиться на других сайтах
В 24.12.2016 в 02:01, LxCoder сказал:

вы на станке это проверяли?

Собственно это на станке и обнаружилось, а точнее на его стойке. Стойка отказалась принимать файл программы, указывая на ошибочные строки. Об этом я упомянул в своем сообщении #245.

Ссылка на сообщение
Поделиться на других сайтах
18 часов назад, DJ Astro сказал:

Я бы делал так:
В каждом переходе в PPRINT можно вывести Z_MAXIMUM_TOOL_TRAVEL и Z_MINIMUM_TOOL_TRAVEL.
Каждому используемому в программе инструменту сопоставить параметр. В начале каждого перехода сравнить этот параметр текущего инструмента и величины из PPRINT. Если меньше - то переписать параметр инструмента новым значением. В конце проги всё собрать в кучу и вывести в tool list.
 

А я подумал сделать массив (Номер инстр. / ZMIN) , в CIMFIL LOADTL переключать переменную-флаг, использовать этот флаг чтобы переключаться в _OUTPT между пересчетом ZMIN и загрузкой результирующего ZMIN в массив. Сделать макрос вывода содержимого массива текстом. Как то так :g:

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

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

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

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

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

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

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

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

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

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

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




×
×
  • Создать...