Heidenhain: программирование открытым текстом VS ISO.

[NGM 267]

Коллеги, здравствуйте.

 

Возникла дилема: для недавно закупленной CAM-системы планируется заказ нескольких постпроцессоров на станки с системой управления Heidenhain 530. Станки фрезерные, 3, 4, и 5-осевые, 95% обработки с позиционированием, 5% - непрерывная многоосевая фрезеровка. Детали самые разные, от мелочи с допуском ±0,005 до сложнейшей корпуснины высотой в полтора метра.

 

До настоящего момента не можем прийти к консенсусу - заказывать разработку постпроцессоров в родном формате "открытого текста" хейденхайна или в более универсальных кодах ISO? Якобы первый вариант более приемлем в случаях, когда программы приходится перекидывать с одного станка на другой, да и наладчикам он более понятен. Я работал с 530 стойкой только в ISO, поэтому мое личное мнение по вопросу не может претендовать на объективность.

 

Хотелось бы поинтересоваться - какой вариант более предпочтительный для Вашего производства, и могут ли возникнуть существенные проблемы с постпроцессором, который будет выводить УП в формате "открытого текста".

И, да, вариант "заказывайте оба поста" не рассматривается 

[Aleksandr65 10]

Добрый день,

 

ISO - код у Хэйда сильно отличается от фанука. Если честно, лично я вообще не вижу смысла в нём что-то делать, уверяю вас, что обучиться языку Хэйда не займёт много времени, а о проблемах я даже не представляю, в чём они могут проявиться. Я за язык Хэйда. А если не секрет какой САМ?

[dutiful 4]

Соглашусь, у данной стойки в формате ISO остается слишком много функций от Heidenhain (Циклы, развороты систем координат, задание нулевых точек) и сама стойка (Клавиши) они также заточены под написание программ в формате .h. На ней сложно найти стандартные G2, G3....c G0 вообще беда).

 

Также стоит отметить, что часть функций доступна только при программировании на Хейдене. Ну и маленькие нюансы, типа отсутствия необходимости в нумерации кадров, также говорят в пользу Heidenhain.

 

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

 

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

Изменено 16 июля 2014 пользователем dutiful

[vladimir_ 34]

ISO код разрабатывался еще под технику 60-х

да и собственно САМ-систем тогда еще не было

за пол-столетия мир изменился

 

в Вашем случае, это все равно что "купить шикарный мерс и возить в багажнике кирпичи и мешки с цементом" :)

технически можно, но зачем???

[avd 73]

Я голосую на Хайд! Переносить программы ИСО с хайда на другие стойки нет практического смысла.

[Irish 31]

Возникла дилема: для недавно закупленной CAM-системы планируется заказ нескольких постпроцессоров на станки с системой управления Heidenhain 530

зачем много постов? если все машины под хайном! Станку-то фиолетово, что 5 осей крутить, что  3.

 

 

 

До настоящего момента не можем прийти к консенсусу - заказывать разработку постпроцессоров в родном формате "открытого текста" хейденхайна или в более универсальных кодах ISO?

В родном, возможности стойки таки нужно пользовать.

 

 

 

Якобы первый вариант более приемлем в случаях, когда программы приходится перекидывать с одного станка на другой,

если все машины под хайном! то бред, если системы разные, тем более.

 

 

 

да и наладчикам он более понятен

отправьте на обучение для понимания.

Изменено 16 июля 2014 пользователем Irish

[Dimasik-ola 37]

Однозначно *.h более удобен и функционален.

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

А какие там циклы, м-м-м-м-... И со стойки работать одно удовольствие.

[NGM 267]

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