Доступ к данным

[Sharachov 1]

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

И насколько это было бы желательно для пользователей САМ систем ?

PS

То, что можно менять траекторию во время генерации УП на станок, об этом, наверное, все знают и пользуются. А вот во время генерации траектории ?

[Гость sapr2000]

Вопрос весьма интересный.

Мне представляется, что подход к генерации траекторий, принятый в подавляющем числе современных САМ-систем не предполагает online-вмешательства в процесс расчета траектории. Что вы имеете - выбираем типовой переход(например, подрезка торца), вводим параметры расчета траектории, кликаем на некий предварительно созданный контур. Все дальнейшие флуктуации допускают лишь изменения параметров в диалоговых окнах. Т.е. вы можете, конечно, поднастроить алгоритм расчета, но в тех лимитах, которые вам оставил разработчик. Не более. А более? Для этого созданы корректоры траектории. Корректируй в рукопашную траекторию инструмента, вставляй техкоманды или CL-записи.

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

Понимаете, многие технологи любят, чтобы расчет траектории был предсказуемым и управляемым на 100%. Поэтому часть из них так "преданна" языковым средствам описания траектории инструмента. Именно в них технолог может "вставлять" собственные средства расчета траектории в виде  типовых решений или макропроцедур, даже вызовом exe-задач!!!

[Sharachov 1]

Наверное, ситуация схожа с такой в САД:

Есть масса способов генерации стандартных для системы геометрических элементов (через VisualLISP, VB, ActiveX(СОМ) и т.п.), но нет (я не встречал) способа заставить САД систему использовать мой сгенерированный и поддерживаемый извне геометрический элемент.

Таким же образом, я могу заавтоматизировать процесс создания в САМе тех.маршрута в той или иной степени, но не могу задействовать свой объект в маршруте или подключиться к существующему объекту.

В такой постановке, задача, по-видимому, не решена и/или не решалась.

[Гость sapr2000]

Давайте вспомним 70-80 годы... Больших тяжелых и прочих CAD/CAM-ов не было. Технологи писали программы на языке АПТ и производных от него. Опытные технологи пытались обобщить типовую обработку в виде процедур АПТа. Постепенно на заводе(значит серия или мелкосерия) создавалась библиотека типовых технологических решений. Это и геометрия детали и технология ее обработки. В итоге, программа обработки стала похожа на вызовы функций.

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

Далее в 90 годах в пору увлечения CAD/CAM системами технологи столкнулись с другой идеологией - все старое забыть, вот вам 10-20 типовых технологичесих переходов(с менюшками, диалогами, подсказками и пр.) из них будете строить обработку детали, а для удобства построения и особенно корректировок придумали дерево последовательности обработки. Все, конечно, здорово и продуманно. Но как же быть производственнику -у него десятилетиями накопленный багаж типовых схем обработки, а ему только "подрезать торец" или "фрезеровать плоскость". Т.е. все с нуля?

[Sharachov 1]

Ну и как же "пополнять CAD/CAM своими решениями?"

[Гость sapr2000]

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

Почему же не сделать подобное в части проектирования технологии, т.е. расчета пути движения инструмента в  CAD/CAM системе? Все разработчики так стремительно убежали от трансляторов в сторону графического интерфейса, что забыли

о пополняемости и расширяемости технологических решений со стороны пользователя.

Мне представляется, что выход - это более высокий уровень автоматизации. Т.е. предоставление клиенту средств для описания новых типовых переходов, процедур их "имплантации" в базу знаний САМ-системы, добавления в меню, увязывания с процедурами ввода и редактирования параметров и прочее...

Очень давно, еще в начале 90 я делал такую работу. Сейчас она смотрится весьма примитивно, но функционал работает. Теперь я в глубокой задумчивости, как это "прицепить" в новый проект.

[Гость bigBUG]

2 Константин

- совершенно согласен, что современные КАМы весьма негибки (да и вообще не шибко зрелые пакеты), и работы вэтом направлении практически не ведется. Я могу назвать навскидку только 2 проекта - CASE.CAD и пакет от фирмы "СПРУТ-технология" (с последним советую ознакомиться). Собираюсь как раз "пополнить" PowerMill парой прикладух, благо они расширили в этом плане совместимость, но все равно доступиться до ядра иногда надо, ан нет, нельзя.

2 Sharachov - что вы имеете в виду под "влиять на генерацию векторов нормали в процессе расчетов"?

[Гость AK]

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

[Sharachov 1]

2 Sharachov - что вы имеете в виду под "влиять на генерацию векторов нормали в процессе расчетов"?

Я это привел как пример возможной задачи. (Исходя из прдыдущего обсуждения в 3Д Коррекции).

Я так думаю, что дискуссия свернет в сторону - в сторону интегрированных решений, в сторону количества разных кирпичей. А я хотел бы по поводу качества одного кирпича.

(Отредактировал(а) Sharachov - 19:59 - 5 Фев., 2002)

[Гость sapr2000]

Quote: from sapr2000 on 9:29 - 6 Фев., 2002

А интересно, есть ли САМ системы, которые позволяют вмешиваться в процесс вычисления траектории и выводить в траекторию нужные данные из расчетных ? ... Т.е. не путем задания неких параметров на диалоговых панельках, а другим путем: - допустим, программным, внешним и т.п.

Давайте вернемся к сути вопроса. Я посмотрел с 10-ок зарубежных систем и на мой, субъективный взгляд, я бы на ваш вопрос ответил отрицательно. По-видимому изначально предполагается, что функционал систем самодостаточен и нет необходимости пользователю его наращивать . А если по-простому, то не хотят они юзера пускать к ядру системы. Странная позиция.

Заканчивая,  выскажу мое мнение по двум вопросам.

1. Безусловно были и будут случаи в практике технолога, когда ему нужно вычислить что-либо для построения траектории или последующей генерации УП. Пример с векторами нормалей, конечно, частный, но зато весьма показательный. Технолог лишен таких инструментов в современных САМ-ах, где контур строится из кирпичиков (три-пять примитивных способов задания), а траектория генериться на основе последовательного выбора черных ящиков(типовых переходов). В этих системах у технолога нет инструмента для выполнения какого либо расчета, ровно как и использования полученных данных скажем для изменения траектории или конкатенации данных(траектория + вектора нормали из вашего примера)...

2.Конечно, строить как контур обработки, так и технологию его обработки, легко и красиво из кирпичиков и типовых решений.  Это так нравиться новичкам, студентам и начальникам САПР.

Грамотный технолог, "зубр" в своем деле, наработавший десятки отточенных и проверенных технологических решений, не сможет обойтись тремя способами задания точек и 10 типовыми переходами. Это, простите, возврат в прошлое. Поэтому ваш вопрос - это на самом деле вопрос к разработчикам САМ-систем со стороны более "старой" по возросту, но весьма зрелой части технологов России( ИМХО)

[Гость AVD]

Уважаемые коллеги,

В UG всегда была и есть возможность создавать собственные операции (С и С++). Слова словами, но я сам видел сделанную пользовательскую фрезерную операцию.

[IBV 112]

В MasterCAM тоже есть возможность "пополнять CAD/CAM своими решениями". Делается это тоже на С и С++. Там эта технология называется C-Hooks. Применима и для CAD и для САМ части. Сам ничего на эту тему не делал, но в инсталляшку включены наиболее удачные C-Hooks пользователей. Кастати, есть даже некоторые C-Hooks сторонних разработчиков, которые продаются отдельно.

[Гость sapr2000]

Ну понятно, что есть С, С ++ (в UG, MasterCAM) и макроуровень в CATIA...

А нельзя попроще? Для того что бы элементарно настроить постпроцессор UG/Post или IMSPost  нужно изучать целый язык. Что бы дополнить MasterCAM новым способом задания - учить C++? Другими словами, около САПР-а нужно содержать программистов, которые его обслуживают, настраивают и расширяют. Я, конечно, утрирую, но согласитесь - доля  правды в этом есть?

И  вы не задумывалсиь над тем, что под термином "открытый код" нам предлагают купить всего лишь старые "инструменты" самого  разработчика САПРа - профессионального программиста?

[IBV 112]

"Ну понятно, что есть С, С ++ (в UG, MasterCAM) и макроуровень в CATIA... А нельзя попроще?"

  Хорошо бы конечно, но по-моему никто не знает как это попроще сделать.

"Для того что бы элементарно настроить постпроцессор UG/Post или IMSPost  нужно изучать целый язык. Что бы дополнить MasterCAM новым способом задания - учить C++? "

  Ну да, пока выходит так...

"Другими словами, около САПР-а нужно содержать программистов, которые его обслуживают, настраивают и расширяют. Я, конечно, утрирую, но согласитесь - доля  правды в этом есть? "

  Мне кажется, что уж очень сильное упрощение. Если САПР выбран правильно (возможности устраивают), то необходимость создать что-то свое возникает очень редко. Проще заказать кому-то решение задачи, чем пытаться "рожать" что-то самому или держать в штате программиста. У меня недавно была задачка, которая не вписывалась в возможности моих CAD/CAM систем. CAD-овская задачка. Так мне коллеги с Питера помогли (Анатолий, спасибо еще раз) - написали программку и проблема закончилась. Ну мог бы я конечно сам засесть изучать С++, но нафига? Что б написать одну программу и сразу начать его забывать? И вообще, сколько бы мне пришлось на это времени угробить? Ведь программистами за день не становятся...