Открыть список
Как стать автором
Обновить

Комментарии 18

По моему личному мнению такая система должна встраиваться в CAD/САМ систему в качестве подсистемы выбора режима резания. Примеры со скоростями резания, подачи и т.п. кстати не очень удачные: на многие материалы, обрабатываемые диметры найдутся уже подобранные оптимальные режимы резания. На похожие материалы и близкие диаметры можно использовать те же режимы резания или интерполировать.
Интересно было бы в качестве входных параметров добавить обрабатываемый материал, а в качестве выходных — материал режущего инструмента. Вот тогда в проектах, где используются сложнообрабатываемые материалы и данных о них в справочниках мало, и невозможно сразу определить твердосплавным или металлокерамическим или быстрорежущим инструментам обрабатывать.
Ещё бы в качестве выходных данных геометрические параметры инструмента (для того же сверла — угол при вершине и т.д.).
Отвечу по-порядку:

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

Вариант с предложением инструмента интересен, спасибо — надо подумать как его внедрить. Он отчасти необходим — у самого был опыт по обработке таких материалов. Когда твердый сплав не стоял, а быстрорез показал отличный рез-тат, несмотря на боьшое время работы.

Насчет геом параметров — уже продумано. я просто не стал описывать этот момент в статье. По всем элементам есть полный набор параметров и можно подбирать инструмент исходя из параметров. К слову есть даже идеи по созданию небольшого «умного» создателя инструмента, построенного на той же нейросети. Например, надо сверло приближенное по своим параметрам к каталожному (какого-либо производителя) — создается сеть, обучается на туче примеров и далее с помощью нее работает ф-ия создания сверла. Пользователю лишь остается нажать ОК или внести корректировку в предложенную конфу (а это гораздо лучше чем вбивать руками каждый инструмент)
НЛО прилетело и опубликовало эту надпись здесь
Смотря для чего они нужны? В целом все современные системы ЧПУ автоматически снимают и учитывают показатели нагрузки и усилия на шпинделе.
Но ничего не мешает ввести эти параметры, насколько я знаю — там корреляция физики и математики.
НЛО прилетело и опубликовало эту надпись здесь
Вопросы адаптивности систем не рассматривался. Ведь САПР — это программное обеспечение, а оно зачастую может даже и не видеть живой станок.
Однако ваши мысли мной уже давно продуманы-то есть внедрить разработку можно не только в Софт, но и на стойку системы чпу. А там уже и параметры явлений в процессе обработки можно снимать и учитывать. К примеру стойки станком Мазак обладают такими отдаленно поХожими Функциями, однако средства по созданию на самих стойках программ-ограниченны. Я общался с Понцем, который в отделе разработки софта для стойки-они далековаты в плане интеллектуализации именно процессов написания программ. Хотя железо стойки умеет многое.
Очень интересная тема! Хотелось бы знать, какое будущее проекта ожидает? будет ли он опенсурсным или вы планируете поддерживать разработку самостоятельно?
Спасибо. Ну самостоятельно силенок точно не хватит. И проект будет сусолиться так долго, что попросту какая-либо крупная компания внедрит что-то подобное в свою очередную версию системы.

Пока я вижу проект в виде подпрограммы (модуля, плагина — как удобнее называть) к CAM-системам. Это вполне реально, т.к. много систем обладают открытыми API и возможность интеграции своего кода.

А вот насчет опенсурсности — хорошая идея, я задумался;)
Если решитесь его открыть, я бы с удовольствием присоединился и помог чем смог. И пожалуйста, пишите все новости о проекте сюда, с нетерпением жду продолжения.
Огромное спасибо! Буду писать этапы выполнения. Если не трудно — напишите чем владеете в личку.
Реальное и полезное дело. Успеха вам и внедрения наработок на практике.
Спасибо. Насчет практики думаю как же это лучше реализовать. Можно сделать модуль для существующих нескольких систем, можно попробовать построить новую систему, но второе — не особо конкуренто-способно. т.к. нужны ресурсы для реализации.
Применять нейронные сети везде где только можно не факт что есть наилучшее решение _конкретной_ задачи. Возможно ваша задача не _прогнозирования_, а _оптимизации_. А поэтому и порыть можно в несколько иные направления: графы (наикратчайший путь от отверстия к отверстию с учетом их _стоимости_), динамическое программирование и т.д…

Куда интереснее не придумать _очередной_ алгоритм для задачи, а показать и доказать что он — единственно верный или значительно превосходит другие.
Соинтеграция различных математических решений возможно, но я начал с мелкого — с элементарной автоматизации. Задача пока — не сократить траектории перемещения (как умеет делать тот же VeriCut), а уменьшить количество действий и кликов юзера. И чтобы юзеры с минимальной квалификацией могли использовать все возможности сложных систем.
САПРовцы на Хабре есть ;-)

Юниграфикс довольно дорогая платформа.
Как насчет Солидворкс или Инвентор?

С нетерпение буду следить за развитием проекта.
Обращайтесь, может и помочь нужно?
Это замечательно, что есть — попробуем создать хороший и интересный уголок для общения и возможно даже реализации проектов совместно! Просто лезть на форум сапр2000 — неинтересно. Тут атмосфера более приятная.

Ёжик (UG) достаточно удобен в плане написания подпрограмм через открытые библиотеки, а также в нем — очень сильный CAM. В солиде есть так называемый солидкам, но он общепризнанно слабоват. Насчет инвертора — честно не думал.

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

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

Мдет — это материал детали. При обучении использовалась пока упрощенная таблица основных материалов, используемых в промышленности. Можно естественно ее расширить, но это уже тонкости и мелочи.

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