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

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 пользователей

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




  • Сообщения

    • fenics555
      Уважаемые Дамы и Господа!  Есть библиотечные изделия, которые почему-то очень доооооолго грузятся в сборках. Я хочу попросить Вас потестить их и сказать в чем причина, ибо совсем невозможно работать. gost18829-73.prt.1 pin_split.prt.1 Как это всё можно ускорить?
    • gudstartup
      а вы хоть станок проверяли по программе на изделии на точность прежде чем товарищей этих выгнать? если нет то грешите на самих себя! система в наших краях еще не распространенная поэтому и тем тут нет надо в поднебесную писать
    • AlexArt
      Ну допустим, ты и на другом ресурсе это опубликовал. А не коммуниздил. Но вот продвигать воровство от государства, ворующее из Вики, это верх мерзости.
    • maxx2000
      Ах, да. Фильтры выбора добавили. Теперь можно выбрать только то что видно на первом плане, а не вместе с тем что с обратной стороны детали. В общем надо обновляться. Как раз работёнка на прессформу нарисовалась 
    • maxx2000
      Причина того - Кроилово. Кроилово всегда приводит к попадалову. Месяц простоял сколько мильонов деревянных потеряли? Вопрос риторический. И ещё будет стоять. Как памятник человеческой глупости и жадности.
    • AlexKaz
      "9 июля 1968 года на мышах был проведен самый знаменитый эксперимент американского ученого-этолога Джона Кэлхуна «Вселенная-25». Суть опыта заключалась в создании идеальных условий, где мыши могли бы жить и размножаться, не ведая никаких забот, вдали от хищников и в отсутствие эпидемий и заболеваний. Для этих целей ученый построил специальный загон, куда были помещены четыре пары белых мышей (самцов и самок). В распоряжении мышей всегда была чистая вода и еда в изобилии, специальные гнезда, где можно обустроить себе жилище ― гнезд в загоне хватало для проживания нескольких тысяч мышей. Температура в загоне в среднем составляла около 20 ℃ и была комфортной для мышей. Животные не подвергались никаким влияниям извне и жили в идеальных условиях в свое удовольствие. А дальше началось самое интересное. На первом этапе эксперимента мыши хорошо размножались, вели активный образ жизни, охотно играли. На следующей фазе эксперимента мыши стали есть меньше, перестали наедаться до отвала. На третьей фазе эксперимента, когда в загоне были уже сотни мышей, произошло распределение социальных ролей, стала ярко выраженной иерархия, клановость. Появились так называемые отверженные ― молодые особи, которых другие, взрослые мыши сгоняли в центр загона, не давали им вести нормальный образ жизни, причиняли физический вред. В природе такое, наверное, было бы невозможно, ведь эти мыши-агрессоры просто не дожили бы до старости: их бы съели хищники. Но в загоне Кэлхуна хищников не было, и взрослые мыши начали попросту издеваться над молодняком. Образовались две большие группировки: самцы-одиночки и самки-одиночки. При этом самки-одиночки отказывались спариваться <с менее статусными многочисленными молодыми самцами и с оставшимися старыми статусными> и отвергали ухаживания самцов. У мышей стал проявляться тотальный индивидуализм, мыши не стремились создать семью. На последней, четвертой стадии мышиная популяция стала сокращаться. Появились самцы, которых сам Кэлхун назвал «красивыми» (англ. beautiful ones), из-за отсутствия ран и рубцов. <В оригинале: They never engaged in sexual approaches toward females, and they never engaged in fighting, and so they had no wound or scar tissue. Thus their pelage remained in excellent condition. - Дословный перевод: Они никогда не прибегали к сексуальным подходам к самкам, и они никогда не участвовали в боях, и поэтому у них не было ран или рубцовой ткани. Таким образом, их шерсть сохранилась в отличном состоянии.> Эти мыши не вступали в борьбу за самок и территорию, не проявляли активности к размножению и только питались, спали и чистили шёрстку. У мышей стали проявляться различные формы девиантного поведения, вспышки агрессии. Самки стали проявлять агрессию, защищать себя сами, стали умерщвлять своих детенышей, а затем окончательно отказались размножаться. На пике эксперимента в загоне одновременно проживало чуть более двух тыс. мышей. Еды и гнезд было достаточно для дальнейшего роста популяции, но через четыре года после начала эксперимента Кэлхун остановил свой опыт, потому что в загоне осталось чуть более сотни мышей, и все они уже вышли из репродуктивного возраста. По итогам эксперимента Кэлхун пришел к выводу, что достижение определенной плотности населения и заполнение социальных ролей в популяции приводит к распаду общества" https://physicsoflife.pl/dict/pic/calhoun/calhoun.. https://scientificrussia.ru/articles/utopiya-dlya-mys.. https://ru.wikipedia.org/wiki/Кэлхун,_Джон_(этолог)
    • gudstartup
      @Koels вот в чем дело пока ds609 это предупреждение поэтому F может и не появится если sv601 это значит ошибка. возможно при нагреве радиатора серво определяет это как предупреждение или ваш вентилятор крутиться медленнее чем оригинальный и серва думает что он встал хотяпри этом обычно на экране в строке состояния FAN.мигает больше у меня вариантов нет....  
    • ДОБРЯК
      Решите любым алгоритмом. Тогда будет конструктивный разговор. :=)
    • Fedor
      https://en.wikipedia.org/wiki/List_of_numerical_analysis_topics#Eigenvalue_algorithms     :) 
    • Юрий К.Ф.
      Добрый день. Не нашёл тут тему по стойке Китайско Китайской)) Lynuc N3ME. Видать мне так повезло с её наличием)) Приобрели 5-ти осевой Китаец. В б/у состоянии после удара по оси Z. Отремонтировали по механике, заменили батареи на драйверах, выставили лимиты. Всё Ок. Пригласили со стороны людей которые бы разобрались по операторской части. Те два выходных ковырялись, после сказали покажут расскажут, но за огромные деньги. Не сошлись. После месяц станок простоял, когда включили перестал реагировать на регулировку скорости шпинделя. То есть в режиме Jog, включаем обороты, которые стандартно 2140-2149 об/мин. При регулировке процетности не меняются (сама процентность показывает на мониторе). Так же при включении оборотов через команду M03S300 или другое значение, скорость так же показывает 2140-2149 об/мин. Грешить на тех товарищей с которыми не сошлись по деньгам для обучения, как то не хочется. Поковырялся в настройках шпинделя, вроде всё в норме. Проводку на шпинделе прозвонил, целая. В чём причина, не понятна. Кто нибудь сталкивался с подобным, или с подобной стойкой? Может подсказать варианты причины подобного?
×
×
  • Создать...