Комментарии 5
Я правильно понял, что в посте речь про софтину (или класс софта), которая позволяет работать в одной среде, не выгружая результаты в эксель?
Тогда почему бы не воспользоваться макроязыком, который по моей памяти есть и в инвенторе. Это ведь будет бесплатно и решит задачу, причем решение может юыть индивидуальным, а значит максимально автоматизированным, чего не добиться с помощью готового софта
К сожалению, автор поста решает нерешаемую задачу. Могу судить, т.к. сам являюсь и тем, и другим, я инженер-прочнист и кафедральный сотрудник одновременно. Позиция «программируй всё что шевелится» не работает в сферах интеллектуального труда. Реальный обобщённый сферический научный сотрудник тратит не так много времени на снятие экспериментальных данных как описывает топикстартер, очень много времени уходит на анализ литературы, откидывание мусорных статей и книг, проработку текстов и продумывание смысла работы вообще. То же самое относится к инженерам — не поверите, но инженер большую часть времени а) чертит и обсуждает задачи и возникающие проблемы с другими инженерами б) пишет много-много отчётов и заполняет тонны бюрократических бумажек. А то, что описал ТС — это очень-очень частная задача, где нужно стать фактически частью механического конвейера (а деятельность вне этого конвейера ТС не описывает т.к. ещё недостаточно с ней знаком). Реальная жизнь сложнее чем одна частная задача. Реальная жизнь инженеров-научников — не компьютерная игра, нельзя упростить целеполагание и смысл до реализации рефлексов амёбы.
Программирование очень сильно упростило жизнь в той же расчётной сфере, это я про кады-сапры-кае и прочий софт. Но программы так и не смогли заменить человеческие мозги. Руки частично заменили роботами, это да. Но, извините, никаким кадом и кае за один пресест и за время на выпить чашку кофе авиадвижок не обсчитать. Это фантазия сродни киберпанку. Повторяю, я знаю людей которые считают реальное железо и сам вхожу в их число и поэтому имею право на подобную критику =)
Если же кого заинтересует вообще тема глобальной автоматизации в инженерии, то рекомендую ознакомиться вот с этим вот феерическим персонажем, который продолжает вводить людей в заблуждение касательно всесильности ИИ, софта и роботов cccp3d.ru/topic/91595-%D1%81%D0%BF%D0%B8-%D0%BE%D1%82-%D1%82%D1%83%D1%80%D1%82%D1%8B/?do=getNewComment
Если кто подумает что перс по ссылке предлагает дельные вещи — взгляните на количество страниц в том топике…
Программирование очень сильно упростило жизнь в той же расчётной сфере, это я про кады-сапры-кае и прочий софт. Но программы так и не смогли заменить человеческие мозги. Руки частично заменили роботами, это да. Но, извините, никаким кадом и кае за один пресест и за время на выпить чашку кофе авиадвижок не обсчитать. Это фантазия сродни киберпанку. Повторяю, я знаю людей которые считают реальное железо и сам вхожу в их число и поэтому имею право на подобную критику =)
Если же кого заинтересует вообще тема глобальной автоматизации в инженерии, то рекомендую ознакомиться вот с этим вот феерическим персонажем, который продолжает вводить людей в заблуждение касательно всесильности ИИ, софта и роботов cccp3d.ru/topic/91595-%D1%81%D0%BF%D0%B8-%D0%BE%D1%82-%D1%82%D1%83%D1%80%D1%82%D1%8B/?do=getNewComment
Если кто подумает что перс по ссылке предлагает дельные вещи — взгляните на количество страниц в том топике…
Позиция «программируй всё что шевелится» не работает в сферах интеллектуального труда.
Есть две причины, почему иногда нужно «программировать все, что шевелится»:
- программируй все, что шевелится — и по обратной связи найдешь 1 реально хороший кейс. И да — это будет 1 кейс из 100 вариантов/гипотез. «Программирование» здесь не столько прям прикладное и полезное, сколько исследовательское. Успешный кейс передаем в настоящую разработку и доводим его до нового работающего средства автоматизации. Неуспешные кейсы анализируем. Исследования виток за витком помогают прояснить принципы успешного кейса — так постепенно инновация превратится в технологию. Или наоборот, ляжет в стол до лучших времен.
- программируй все, что в интеллектуальном труде является рутиной. Наша как ИТ-аналитиков задача — находить рутинные элементы даже в самых творческих процессах. Пример — обход электронных библиотек и выгрузка референтных источников. И снова обратная связь подскажет, правильно ли мы (ИТ) понимаем нужды пользователей.
Настоящая статья — это плод такого микроисследования. А ваше мнение, ваш комментарий — это та самая обратная связь.
Реальный обобщённый сферический научный сотрудник тратит не так много времени на снятие экспериментальных данных как описывает топикстартер, очень много времени уходит на анализ литературы, откидывание мусорных статей и книг, проработку текстов и продумывание смысла работы вообще. То же самое относится к инженерам — не поверите, но инженер большую часть времени а) чертит и обсуждает задачи и возникающие проблемы с другими инженерами б) пишет много-много отчётов и заполняет тонны бюрократических бумажек.
Так сложилось, что в проектах я всегда был частью команды, с распределением ролей. И на своем опыте бюрократии я действительно не хлебнул. Занимался как раз моделированием и расчетами, их было много.
Про анализ литературы/очистку мусора/проработку текстов — это очень интересный кейс, который пересекается с «анализом конкурентов» в бизнесе. Тема активно развивается: там можно встретить и про ИИ, и про роботов, и про статистику. И здесь мы должны разделить функции. Роботам и ИИ — обход сайтов и изданий, сбор и упорядочение информации в файловой системе, группировка, классификация, грубая сортировка. Человеку — интерпретация, анализ, обобщения, гипотезы, выводы.
Программирование очень сильно упростило жизнь в той же расчётной сфере, это я про кады-сапры-кае и прочий софт. Но программы так и не смогли заменить человеческие мозги. Руки частично заменили роботами, это да. Но, извините, никаким кадом и кае за один пресест и за время на выпить чашку кофе авиадвижок не обсчитать. Это фантазия сродни киберпанку.
Где подписаться? ))) Согласен с каждым словом! Именно так мы и понимаем круг «обязанностей» роботов, ИИ и прочих средств автоматизации. Да, ИИ и RPA — маркетингом позиционируется как некий «новый уровень». Но это новый уровень «рук», а не «мозгов».
Повторяю, я знаю людей которые считают реальное железо и сам вхожу в их число и поэтому имею право на подобную критику =)
Кости растут правильно, если есть нагрузка. Мышцы без нагрузки атрофируются. Критика со стороны профессионалов — это как нагрузка для костей и мышц. Без нее мы не сможем правильно развивать свои продукты. Критика нужна.
Я правильно понял, что в посте речь про софтину (или класс софта), которая позволяет работать в одной среде, не выгружая результаты в эксель?
RPA — это действительно класс ПО, этакое следующее поколение кликера, макроса или скрипта.
Много статей о применении в бизнесе можно найти в интернете. Еще лучше — посмотреть демонстрации на ютубе. В роликах очень наглядно на живых примерах разъясняются возможности этого рода программ.
Тогда почему бы не воспользоваться макроязыком, который по моей памяти есть и в инвенторе. Это ведь будет бесплатно и решит задачу, причем решение может юыть индивидуальным, а значит максимально автоматизированным, чего не добиться с помощью готового софта
Согласен, если речь идет об автоматизации внутри одной среды, например, Inventor. Разработчик среды заложил в нее VBA для автоматизации внутренних потребностей. По COM можем взаимодействовать из VBA и с Excel, и с другими приложениями. Во многих других средах поставщики закладывают такие возможности автоматизации.
Одна тонкость: чтобы работать в том же VBА, специалист должен знать объектную модель своей среды и объектную модель той среды, с которой завязывает взаимодействие.
C RPA переносить данные из одной среды в другую легче. Для этого используется запись действий пользователя в графическом интерфейсе. Обычно пользователь хорошо знает и графический интерфейс своих инструментов, и порядок работы.
Встроенный в Inventor и Autocad макрорекодер не записывает действия в стороннем приложении. RPA же базируется на собственной платформе, поэтому автоматизировать можно работу в любых приложениях. А на данные робот будет смотреть через GUI целевого приложения.
Не забываем и об ограничениях RPA.
Конечно, робот не построит пресс-форму по сложной детали. Также средствами RPA не получится достать данные, которые на низком уровне вычисляет геометрическое ядро.
Но он может последовательно обойти все дерево построения с целью, например, переименовать элементы в соответствии с какой-то логикой. Или затянуть в библиотеку инструментов HSM-модуля каталог фрез и резцов с рекомендуемыми режимами прямо с сайта производителя. Это рутина, и именно для рутины RPA и рассчитан.
Интересно было бы посмотреть подробнее про RPA.
Задачи научных работников автоматизируются плохо, потому что они постоянно меняются.
Я наконец-то придумал какие расчеты мне надо сделать — да, несколько сот штук однотипных расчетов. Дальше я за два дня написал программу которая бы автоматизировала мне эти расчеты… всё посчиталось за ночь, я построил графики и дальше несколько дней я на них смотрел, думал, обсуждал с коллегами, думал что считать дальше… Сегодня понял, надо изменить программу — на это уйдет полдня и опять ночь посчитать. И дальше опять… думать… обсуждать… пить чай…
Лучше всего для автоматизации подходит умненький студент которого обучили работе в нужной среде и который как-то знает Mathcad/Excel/Maple/Origin/С.
Задачи научных работников автоматизируются плохо, потому что они постоянно меняются.
Я наконец-то придумал какие расчеты мне надо сделать — да, несколько сот штук однотипных расчетов. Дальше я за два дня написал программу которая бы автоматизировала мне эти расчеты… всё посчиталось за ночь, я построил графики и дальше несколько дней я на них смотрел, думал, обсуждал с коллегами, думал что считать дальше… Сегодня понял, надо изменить программу — на это уйдет полдня и опять ночь посчитать. И дальше опять… думать… обсуждать… пить чай…
Лучше всего для автоматизации подходит умненький студент которого обучили работе в нужной среде и который как-то знает Mathcad/Excel/Maple/Origin/С.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение RPA в научных и инженерных расчетах