Вопрос Опытным Программистам!

[lxmVoid 0]

Не факт, что просто убедишь. Если тупорылые дубы, то в ответ услышишь "Наши деды так делали, и мы будем". А тебя может еще и за колдунство на костре сожгут.

Дело то вобщем не в том, что кому нравиться. Я не фанатик ни макропрограммирования, ни CAM'ов. Просто нужно каждую методу применять по месту.

Никто на тракторах не гоняет на гонках "F-1". И никто на болидах "F-1" поля не пашет. Каждый на своем месте.

Как только потребность в макропрограммировании действительно пропадет - оно само уйдет со сцены истории. Естественный отбор еще никто не отменял

[spartanec 0]

Вот я вам выложил деталь!!!! См. 1стр. В основном делаем детали такого типа (на токарке) и вот мне хочется узнать, ну где все-таки лучше ее делать в САМ или вручную!!! Деталь не такая простая как кажется (в тех процессе заложено около 15 операций 3или4 из них только термообоработка).

Кстати уже нашел один недостаток составление программы (для данной детали) в САМ, так как он просто обходит траекторию по точкам, и не генерирует углы, а как вы знаете часто приходится вносить коррекцию инструмента, в данном случае по Х, и вот результатом такой коррекции в программе, выполненной с помощью САМ может стать неправильный обход угла, т.е. вместо 6градусов, после коррекции он может сделать 7градусов и т.д. Возможно это вовсе и не проблема, но зато весомый аргумент в пользу ручного программирования от моего босса :(( !!!

[Osiris 1]

в тех процессе заложено около 15 операций

Кажется напильником ее можно выпилить быстрее.

Кстати уже нашел один недостаток составление программы (для данной детали) в САМ, так как он просто обходит траекторию по точкам, и не генерирует углы, а как вы знаете часто приходится вносить коррекцию инструмента, в данном случае по Х, и вот результатом такой коррекции в программе, выполненной с помощью САМ может стать неправильный обход угла, т.е. вместо 6градусов, после коррекции он может сделать 7градусов и т.д.

Чушь

Возможно это вовсе и не проблема, но зато весомый аргумент в пользу ручного программирования от моего босса :(( !!!

О дубах уже было сказано.

[spartanec 0]

2Osiris

Ну может конечно 15 операций я загнул и то для того, чтобы с акцентировать внимание. На самом деле 8 операций мех. обработки + термичка (2 операции)!!!! Тем не менее пластины летят только так после первой термообработки. Так, что не так она проста как кажется!!! :)

Насчет чуши я не понял!!!! В чем именно, в том, что САМ не видит углов, или в том, что после коррекции может сбиться угол???

[Osiris 1]

В том, что после коррекции может сбиться угол.

Какая связь между коррекцией оффсета и геометрией программы?

При желании можно подправить пост и заставить САМ выдавать

геометрию с углами только это не имеет смысла.

[spartanec 0]

Кстати, возможно вы и правы!!! Ведь если мы ставим 0,5мм по Х, то это ведь значит, что он по всей траектории будет корректироваться, а не в точке начала или конца угла, вот черт, чтож я затупил так сильно!!!

[mori 0]

Mori-Seiki NZ имеет 2 шпинделя и 3 суппорта с осю Y. Всего 12 осей.

Суппорта точат и фрезеруют вместе и раздельно. Настоящий луна-парк.

Некоторые модели Накамуры имеют по 4 суппорта.

Даже в мазатроле симультанная работа 2 суппортов появилась недавно.

Раньше их двухголовочная модель "квадрекс" шла с iso.

САМ тут слаб.

:g: Вот посмотреть бы программу к этому луна-парку!!!

обработка простенькой детали (с коментариями)

:blink: Сам работаю на Mori Seiki SL154 SY

Изменено 27 октября 2007 пользователем mori

[mori 0]

Вот я вам выложил деталь!!!! См. 1стр. В основном делаем детали такого типа (на токарке) и вот мне хочется узнать, ну где все-таки лучше ее делать в САМ или вручную!!! Деталь не такая простая как кажется (в тех процессе заложено около 15 операций 3или4 из них только термообоработка).

Кстати уже нашел один недостаток составление программы (для данной детали) в САМ, так как он просто обходит траекторию по точкам, и не генерирует углы, а как вы знаете часто приходится вносить коррекцию инструмента, в данном случае по Х, и вот результатом такой коррекции в программе, выполненной с помощью САМ может стать неправильный обход угла, т.е. вместо 6градусов, после коррекции он может сделать 7градусов и т.д. Возможно это вовсе и не проблема, но зато весомый аргумент в пользу ручного программирования от моего босса :(( !!!

:bleh: на Mori Seiki SL154 SY, с встроеным MAPPSом,1-2 сторана програмирование займёт 25-30 минут,MAPPS все углы сгенерирует и радиус выщетает.

:thumbdown: А в(Editor--e)как ты говориш вручную,,,,это каменный век.

Изменено 2 ноября 2007 пользователем mori

[twiddle 8]

ИМХО. По исходной теме - остальное не читал.

Расширенное программирование, если не ошибаюсь, сделано лишь для упрощения программирования руками со стойки. Вывод: если есть CAM-система, то изучать эту часть вообще нет смысла (разве что для самообразования и роста над собой), ибо эти системы (по моему все, хотя один раз слышал, что якобы есть одно исключение) не поддерживают чего-либо кроме минимума G-кодов. То же по всяким подпрограммам в 2D обработке - некоторые софты это делают, но это сокращение длины конечной программы по барабану (если только не древняя стойка с ограниченями объема мозгов).

[Genya_ms 0]

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

Книжку хотябы просмотри, эти вещи очень интересны. Организация циклов, условий принятий решений, я с этим столкнулся после шклолы года ч/з 3 когда на первом HAаSE программы писал, здорово было эксперементировать. Ведь на учебе у нас только основные G M команды рассматривались. А тут такое раздел для творчества открылся... Хотя сейчас с современными CAM это уже и неактуально в работе, а только для кругозора знать надо.

[s_liam 66]

Так то ясно базовое ручное программирование в любом случае должен каждый, но вот стоит ли заморачиваться с этим расширенным программированием, нужно ли оно вообще, в принципе, я думаю, если выучить на зубок тот же edgecam или pmill, mastercam, то зачем углубляться во все эти сложные команды и т.д.

Рано или поздно, освоив базовое, расширенное программирование стоит начать изучать и использовать. Маленький пример.

Есть у нас написанный постпроцессор. Написан был, приблизительно, год назад. На тот момент, реализовано в нем было все, что требовалось нам. Уволился человек, который его разрабатывал. Спустя этот год выплыл неприятный случай. Оператор станка, работая по программе с коррекцией, поставил неверное значение на коррекцию диаметра инструмента. Деталь ушла в брак. Дорогостоящая деталь.

Зная на тот момент расширенное программирование, можно было этого легко избежать. Достаточно было при выводе программы с коррекцией на постпроцессор, задать условие проверки значения введенной в стойку коррекции. поскольку этого не было реализовано в существующей версии поста, об этом никто не задумывался. Отредактировать этот пост, конечно, можно, но нужно, что бы этим занимался знающий человек или заказать пост на доработку... Это понятно. Но, зная это наперед, можно было спокойно реализовать. И, с другой стороны, этот случай дал поводы к размышлению о более глубоком изучении стойки. (речь идет про Siemens 840D, возможности которой весьма широки). Пришлось корректировать программы вручную, вставляя в каждой программе это условие, смотреть документацию по расширенному программированию.

Ну, это лишь один из примеров. Вообще, знание расширенномго программирование, дает вам более широкие возможности и простое решение задач.

[Pingvin man 29]

В трёх координатах никогда не лезу в готовую программу. А вот во многокоординатке - частенько. Но, и в этом случае лезу только для того, чтобы поставить останов в нужном месте, или подправить переход с одной траектории на другую. После этого ВСЕГДА проверяю готовую программу в симуляторе на наличие зарезов, столкновений. Вообще, все многокоординатные обработки проверяю в симуляторе.

Насчёт знания кодов - считаю, что знать коды нужно. Вообще, нужно ориентироваться в коде как рыба в воде.

Простенькие программы иногда пишу руками. И заставляю операторов это делать иногда. Нужно там паз пропилить, или диском отрезать. Чтобы не ждали , когда им принесут обработку, а писали программку ручками.

[ilya_w 85]

.... Достаточно было при выводе программы с коррекцией на постпроцессор, задать условие проверки значения введенной в стойку коррекции. поскольку этого не было реализовано в существующей версии поста, об этом никто не задумывался...... (речь идет про Siemens 840D, возможности которой весьма широки). Пришлось корректировать программы вручную, вставляя в каждой программе это условие, смотреть документацию по расширенному программированию.

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

[s_liam 66]

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

Вот как оно выглядит

N540 LABEL1:

N550 M0

N560 MSG("Проверь коррекцию на радиус инструмента")

N570 IF $P_TOOLR > 0 GOTOB LABEL1

N580 IF $P_TOOLR < -0.5 GOTOB LABEL1

N590 MSG()

[apline87 0]

A ja o4en' 4asto ru4kami korrektiruju,osobenno v 4 osjah.

[ilya_w 85]

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

Вот как оно выглядит

N540 LABEL1:

N550 M0

N560 MSG("Проверь коррекцию на радиус инструмента")

N570 IF $P_TOOLR > 0 GOTOB LABEL1

N580 IF $P_TOOLR < -0.5 GOTOB LABEL1

N590 MSG()

Могбыть, могбыть. Т.е износ у вас в пределах 0.5. а не радиус? А корректор на длину не проверяете? И вообще у Сименса море значений коррекции на разные типы инструмента. Я это к тому что в постпроцессоре всё не учтешь, ведь тогда нужно анализировать тип инструмента и решать о чем спрашивать и какие значения должны быть

[s_liam 66]

Да, здесь проверяется значение, забитое на радиус инструмента

Не. На длину не проверяем... Значение коррекции на длину забивается один раз. А на радиус можно два-три раза изменить, что бы получить необходимый размер. Так как по диамтру инструмент изнашивается и по диаметру инструмент отгибает. По длине то он куда денется? Инструмент в оправке сидит, а она в свою очередь в шпинделе закреплена.. по оси инструмента все жестко. А вот если инструмент длинный или на оправке длинной, то отгиба не избежать...

[Badi 1]

Рано или поздно, освоив базовое, расширенное программирование стоит начать изучать и использовать. Маленький пример.

Есть у нас написанный постпроцессор. Написан был, приблизительно, год назад. На тот момент, реализовано в нем было все, что требовалось нам. Уволился человек, который его разрабатывал. Спустя этот год выплыл неприятный случай. Оператор станка, работая по программе с коррекцией, поставил неверное значение на коррекцию диаметра инструмента. Деталь ушла в брак. Дорогостоящая деталь.

Зная на тот момент расширенное программирование, можно было этого легко избежать. Достаточно было при выводе программы с коррекцией на постпроцессор, задать условие проверки значения введенной в стойку коррекции. поскольку этого не было реализовано в существующей версии поста, об этом никто не задумывался. Отредактировать этот пост, конечно, можно, но нужно, что бы этим занимался знающий человек или заказать пост на доработку... Это понятно. Но, зная это наперед, можно было спокойно реализовать. И, с другой стороны, этот случай дал поводы к размышлению о более глубоком изучении стойки. (речь идет про Siemens 840D, возможности которой весьма широки). Пришлось корректировать программы вручную, вставляя в каждой программе это условие, смотреть документацию по расширенному программированию.

Ну, это лишь один из примеров. Вообще, знание расширенномго программирование, дает вам более широкие возможности и простое решение задач.

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

[apred 7]

Мне кажется, что хороший програмист должен знать и то и другое, и принимать решение как ему писать в зависимости от того, как ему выгоднее. Я например стороник прописания геометрмм в САМ (с коррекцией или без) и использовать это как подпрограммы. А программу собирать из подпрограмм вручную. Особенно это важно на токарке, где время обработки соизмеримо со временем смены инструмента. Иногда свердение приходится делать на три -четыре детали. Наружную обработку, можно сделать на две, а внутреннюю на одну. Вот и попробуйте написать программу в САМе или вручную без параметров.

Или другой пример, фрезерный. Вы ставите заготовку на стол. и далее выполняеете привязку вручную. Другой вариант, Вы ставите заготовку на стол и далее по программе датчик RENISHAW (или другой) привязывает деталь доворачивает координаты и запускает обработку. Попробуйте написать это в САМе. Второй вариант особенно предпочтителен при доработке готовой детали.