G-код ---> CL файл

[Гость sapr2000]

Господа!

Насколько по вашему мнению существенна и требует решения такая  проблема, как реверсивный постпроцессинг. Иными словами, преобразование G-кода в записи CL-файла?

Мой коллега по фирме изладил простейший вариант реверсивного постпроцессинга. G-код любой из систем с ЧПУ(настройка простая - укажи любой из постпроцессоров в APTIPP) может быть преобразован в CL-файл системы UG 17/18. Ограничения - работаем с тремя координатами(охват токарщины и 3D фрезерования без поворота башки станка или стола). Работа была сделана очень быстро(5 часов) в рамках реализации этапа  проекта графической верификации УП.

Дак вот, поскольку APTIPP имеет "в мозгах" сведения о структуре CL-файлов 15 CAD/CAm и CAM-систем, то открывается путь реверсирования G-кодов в CL-файл "любого вида". Хотите в UG, Catia, Pro/E ... списк можно продолжать.

[SVN 0]

По моему, ни к чему это.

[Гость UAV1]

 Присоединюсь к мнению SVN, что особой практической пользы от этого нет. Если бы по CL-файлу можно было бы G-код на другой станок получить в этих системах, хотя из пушки по воробъям это.

[Гость sapr2000]

UAV

Quote: from sapr2000 on 10:58 - 24 Янв., 2002

 Присоединюсь к мнению SVN, что особой практической пользы от этого нет. Если бы по CL-файлу можно было бы G-код на другой станок получить в этих системах, хотя из пушки по воробъям это.

Само собой, получив из G-kod файл CL, мы можем далее выдать его на любой другой станок с ЧПУ при помощи Универсального Постпроцессора. Какого? Да хоть APTIPP или других, вроде IMSPost или GPOST.

[Гость AVD]

Мне это кажется это интересно вот с какой стороны. Например у меня есть G-код программы и я хочу оптимизировать эту траекторию по подаче (т.е. изменить подачу в зависимости от припуска). Например это можно делать в Vericut'е. Конвертирую в CL-дату и запускаю Opti-path --> получаю оптимизированную траекторию --> постпроцессор --> оптимизированная УП. Хотя у Vericut есть реверсивный постпроцессор, но с ним надо разбираться.

[IBV 112]

А я бы такую примочку поимел с большим удовольствием. По-моему - вещь нужная. Иногда такие мудрёные задачки попадаются, да и организовать работу команды, которая использует несколько САМ-систем с такой "примочкой" гораздо проще и удобнее.

[Гость sapr2000]

AVD

Quote: from sapr2000 on 11:29 - 24 Янв., 2002

Хотя у Vericut есть реверсивный постпроцессор, но с ним надо разбираться.

Я попробывал и просто утонул в этой теме. Сабдж очень крутой, но весьма сложный в освоении и настройки самого реверса, особенно на наше старое оборудование, ИМХО.

IBV

А я бы такую примочку поимел с большим удовольствием.

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

[Гость UAV1]

А я не понимаю зачем это нужно в практических целях технологу, если только не для пропускания потом через универсальный ПП. Скажем в рамках создания графического верификатора понятно что такая функция нужна видимо для того, чтобы рисовать универсальный CL-файл полученный его из G-кода.  

[IBV 112]

Зачем?

Практически для тех же задач, что и верификатор. Помните мы недавно общались на эту тему? Ну вообщем примерно вот так я думаю:

 - отладка постпроцессора

 - есть большие сомнения в правильности G-кодов

 - деталь сложная и дорогая, ошибка обойдется слишком дорого

 - при использовании старой или чужой программы

 - ОЧЕНЬ пригодится для организации работы команды, использующей несколько САМ-систем.

 

(Отредактировал(а) IBV - 12:16 - 24 Янв., 2002)

[Гость UAV1]

Если я правильно понял, то фактически:

- для передачи в визуализатор СL-файла, если визуализатор не понимает данный G-код?

- для передачи в визуализатор обоих форматов и сравнением отличий?

- разные переходы на одну деталь делают в разных  CAM?

- что-то еще ?

Если это имеется ввиду то склоняюсь к мысли, что такая задача может иметь жизнь и беру слова о практической пользе назад.  

[IBV 112]

Ну в принципе "да", почти так. Подробнее просто долго писать. Кстати, в качестве верификатора при таком раскладе можно использовать визуализатор САМ-системы, в CLDATA которой возвращается G-код.

[Гость AVD]

Поностью согласен с уважаемым Админом, что изучение реверсивного постпроцессора в Vericut дело гиблое, особенно для наших станков/систем ЧПУ, но для простых (без коррекции, без еще каких наворотов, только ходы) УП возможно.

2UAV: ...еще..., в частном случае оптимизации подачи в зависимости от припуска в UG нет (или я не знаю как это делать), а в Vericut'e есть модуль оптимизации (знаю только из документации) траектории. Так что получается интересная связка.

[IBV 112]

AVD

Честно говоря сам не пользовался, но сдаётся мне, что в UG в планарной обработке оптимизация подач есть.

И ещё. Немного непонятно мне постоянное желание некоторых коллег "скрестить" современный софт и древний станок. При этом подразумевается желание получить какой-то офигительный результат. Не будет офигительного результата. Ну не кому ведь в голову не приходит на "запорожец" пришпандорить какую-нибудь адаптивную систему управления подвеской? Потому что они как бы из разной жизни. Здесь тоже самое - если мы берём станок начала 80-х и Catia5.x, то вряд ли можно ожидать ошеломляющих результатов. Станки нужно менять или upgrade делать хотя бы.

(Отредактировал(а) IBV - 13:29 - 24 Янв., 2002)

(Отредактировал(а) IBV - 14:18 - 24 Янв., 2002)

[Гость bigBUG]

По припуску оптимизирует Delcam'овская утилитка OptiFeed.

Но вот вопрос - не нарушается ли при этом условия резания? толщина стружки и т.д.

[Гость sapr2000]

Подводя итог разговору, скажу. Сабдж скорее всего имеет право на жизнь. Опытный образец буде передан IGV для опробования в  производственной практике. О результатах сообщим позже.

[Гость AVD]

2IBV: Хочу сказать, что на данный момент имеет место быть такая ситуация: сильное развитие конструкторов и слабое развитие производства (я имею ввиду наше предприятие). И получается, покупаем класные компьютеры для конструкторов иногда даже для ЧПУшников, но станки нет. Отсюда ситуация станки 70-80-х и UG18.....

[Гость sapr2000]

Quote: from sapr2000 on 9:27 - 25 Янв., 2002[br Хочу сказать, что на данный момент имеет место быть такая ситуация: сильное развитие конструкторов и слабое развитие производства... И получается, покупаем класные компьютеры для конструкторов иногда даже для ЧПУшников, но станки нет. Отсюда ситуация станки 70-80-х и UG18.....

Вот об этом я и говорил в частных письмах IBV. Понимаете ли какой парадокс часто случается - многие заводы вкладывают деньги в приобретение CAD/CAM-софта, наивно предполагая, что его внедрение сразу решит вопросы выпуска новых изделий, оживление спроса, повышения конкурентной способности товаров и т п. Но купить софт мало. Любой софт рушит технологию конструирования, изготовления, документирования и пр., годами сложившуюся на заводах.  И в технологических службах действительно имеется проблема, когда UG18 вынуждены использовать на морально устаревшем оборудовании 70-80 годов. И поверьте, это очень серъезный тормоз в использовании CAD/CAM-систем. Мне думается, что эта проблема заслуживает вынесения в новый топик, а в этом топике мы говорили о постпроцессировании, CL-файлах и тп....

[doob 14]

По-моему вопрос в эту тему. В случае современного софта и старых станков, возможно, будет удобно использовать трансляторы CLDATA различных систем в CLDATA одной системы. Той, у которой будет лучше настроить постпроцессор? Вот уж действительно все программы будут одинаковые!

[Гость sapr2000]

Этот подход собственно мы и продвигаем. Наша собственная разработка APTIPP умеет читать CL-файлы 15 типов систем и генерить G-коды на любой станок с элементарной настройкой через паспорта...

Некоторые коллеги за рубежом также идут в данном направлении - IMSPost, GPost, CAMPost. Многие участники данной конфы ими пользуются именно в данном ключе.

[Гость HAMyak]

Хочу вставить свою реплику:

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