Заказ-выдача управляющих программ

[NGM 267]

Всех с наступившей зимой. Ура.

Большие предприятия, несколько цехов, в каждом - не по одному десятку станков... Наряду с программистами в группе технологов в поте лица трудятся наладчики, пытаясь всеми силами сократить машинное время избежать срыва производственного плана.

Рано или поздно, ситуация подбивает к тому, чтобы заказ управляющих программ шел цивилизовано и централизовано. Хотелось бы поинтересоваться - как у кого решена проблема заказа, выдачи и отслеживания УП? В тонкости объединения станков в ЛВС не затрагиваю, интересна только технология заказа-выдачи файлов на стойку. Быть может, у кого-нить эта тема реализована в САПР ТП или PDM? Мало ли.

Раз уж завел тему - у нас со времен Царя Гороха существует аксессовская приблуда, с помощью которой программисты в СГТ вроде как выгружают программы в цех и вроде как принимают из цеха то, что написано самими наладчиками. Технология несовременная, неактуальная, и находится в активной фазе совершенствования. Отсюда сабж.

[volodja 77]

Существует: <noindex>вот</noindex> и <noindex>вот</noindex>. На сегодняшний момент, видимо, оптимальный путь - параметризированная САМ-сборка.

[ilya_w 85]

У нас никак. Герой-наладчик ждёт, что кто-нибудь ему принесет, или сам идёт. Вообще, это сильно зависит от способа ввода программы в станок. Нужно организовать, например, вывод на перфоленту, записи в различные носители типа DNC-терминалов, на флешки и т.д. Когда имеется вся эта радость, хорошо это свалить на цехового технолога, он же и обратно внедрённые программы куда-то пристраивает. Это, естественно, если нет централизованного электронного хранилища. С ним ещё больше проблем, имхо...

[NGM 267]

Существует: <noindex>вот</noindex> и <noindex>вот</noindex>. На сегодняшний момент, видимо, оптимальный путь - параметризированная САМ-сборка.

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

У нас никак. Герой-наладчик ждёт, что кто-нибудь ему принесет, или сам идёт. Вообще, это сильно зависит от способа ввода программы в станок. Нужно организовать, например, вывод на перфоленту, записи в различные носители типа DNC-терминалов, на флешки и т.д. Когда имеется вся эта радость, хорошо это свалить на цехового технолога, он же и обратно внедрённые программы куда-то пристраивает. Это, естественно, если нет централизованного электронного хранилища. С ним ещё больше проблем, имхо...

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

[Елена 116]

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

[volodja 77]

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

Как выписывать заказ - не особо знаю. А хранение и передача в цех: это так называемое "безбумажное" производство - просмотрщик (Viewer) у стойки, CAD-модели хранятся на сервере. Оператор подгружает CAD-модель, выбирает и процессирует нужную актуальную программу. Весь этот процесс управляется PDM; в той или иной мере реализовано у всех немецких автопроизводителей (БМВ впереди всех по степени автоматизации) и у большинства крупных поставщиков комплектующих/пресс-форм/штампов. Закажите экскурсию, приезжайте и посмотрите.

[Сайлар 41]

Георгий, я уже рассказывал, как сие реализовано у нас. Самодельная программка + база данных. Допустим есть заказ на 1000 каких-то изделий (1) и 500 изделий (2). Сам процесс кратко по пунктам:

1. Конструктора рисуют сборки изделий (1) и (2) в Proe.

2. Технологи вешают в параметрах подсборок и деталей этих изделий в том же Proe операции - фрезерная, токарная, пробивная, покупная и тдрд, сварка тоже там, покраска или несколько операций сразу.

3. Главный по заказу в программке формирует собственно заказ, выбирая соответствующие asm (или prt, если заказали детали) и указывая их количество, сохраняет заказ.

4. Программеры ЧПУ открывают этот заказ в той же программке, и в своей вкладке смотрят на какие детали уже есть УП, не устарели ли они (разные методы проверки, допустим по индексу) - все это программка подсвечивает, и на недостающие или измененные детали пишут УП (mfg в Proe), программка пропускает их через постпроцессоры и если всё окей выдает на участки задание по мере готовности.

5. Операторы станков на участках на компах открывают свою часть программки, выбирают соответствующий заказ и получают список деталей и УП на них (ну в случае пробивки листового металла может быть на одном листе 100 деталей сразу), из программки качают УП в станок. По мере изготовления деталь отмечается выполненной, предусмотрен брак и тдрд.

6. На участках сварки и сборки и тдрд мастера открывают на компах свои вкладки в заказах, видят сборки которые нужно варить или собирать или красить и прочее, а также изготовлены ли уже на предыдущих участках детали входящие в эти сборки и загружают своих рабочих. В программке отмечается изготовленная сборка/подсборка.

7. Главный по заказу мониторит весь процесс в программке.

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

Минус всего этого дела - на каждом участке и возле каждого станка с ЧПУ должен стоять комп (если он не встроен в станок). Но вполне хватает слабенького компа, это себя оправдывает. И к черту бумажки.

Если нужно могу показать скрины, впрочем на cad.ru я их уже постил.

[MFS 248]

Если нужно могу показать скрины

Я бы посмотрел. А что вы смотрели из покупных решений? Чем не устроило?

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

Такое на одной из прошлых работ было реализовано в Search. Хорошо работало, но вот до станка не дотягивалось - лицензии по 1500 долларов за место, куплено их было мало и даже на конструктрсукий отдел не всегда хватало((.

[NGM 267]

Георгий, я уже рассказывал, как сие реализовано у нас. Самодельная программка + база данных. Допустим есть заказ на 1000 каких-то изделий (1) и 500 изделий (2). Сам процесс кратко по пунктам:

1. Конструктора рисуют сборки изделий (1) и (2) в Proe.

2. Технологи вешают в параметрах подсборок и деталей этих изделий в том же Proe операции - фрезерная, токарная, пробивная, покупная и тдрд, сварка тоже там, покраска или несколько операций сразу.

3. Главный по заказу в программке формирует собственно заказ, выбирая соответствующие asm (или prt, если заказали детали) и указывая их количество, сохраняет заказ.

4. Программеры ЧПУ открывают этот заказ в той же программке, и в своей вкладке смотрят на какие детали уже есть УП, не устарели ли они (разные методы проверки, допустим по индексу) - все это программка подсвечивает, и на недостающие или измененные детали пишут УП (mfg в Proe), программка пропускает их через постпроцессоры и если всё окей выдает на участки задание по мере готовности.

5. Операторы станков на участках на компах открывают свою часть программки, выбирают соответствующий заказ и получают список деталей и УП на них (ну в случае пробивки листового металла может быть на одном листе 100 деталей сразу), из программки качают УП в станок. По мере изготовления деталь отмечается выполненной, предусмотрен брак и тдрд.

6. На участках сварки и сборки и тдрд мастера открывают на компах свои вкладки в заказах, видят сборки которые нужно варить или собирать или красить и прочее, а также изготовлены ли уже на предыдущих участках детали входящие в эти сборки и загружают своих рабочих. В программке отмечается изготовленная сборка/подсборка.

7. Главный по заказу мониторит весь процесс в программке.

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

Минус всего этого дела - на каждом участке и возле каждого станка с ЧПУ должен стоять комп (если он не встроен в станок). Но вполне хватает слабенького компа, это себя оправдывает. И к черту бумажки.

Если нужно могу показать скрины, впрочем на cad.ru я их уже постил.

Ну что тут можно сказать... Здорово, просто здорово. Возможно, какие-то идеи сплагиатим в своей разработке. К слову, сегодня очередное совещание по вопросу. Ладно, сейчас отвечу ув. MFS и побегу искать скрины.

Такое на одной из прошлых работ было реализовано в Search. Хорошо работало, но вот до станка не дотягивалось - лицензии по 1500 долларов за место, куплено их было мало и даже на конструктрсукий отдел не всегда хватало((.

Как Сорч? Где Сорч? У кого Сорч? Тык этож наше все. Ради такого дела, возможно, съездить лично поглазеть будет не грех (да и к Сайлару можно будет заехать в ближайший визит в Белоруссию). Если не секрет, кто разрабатывал - Интермех или "сторонние" программисты?

[MFS 248]

Ради такого дела, возможно, съездить лично поглазеть будет не грех

Хм...не уверен, что смогу организовать. Конторка там довольно строгая в плане информбезопасности.

(да и к Сайлару можно будет заехать в ближайший визит в Белоруссию)

Дык там бы Сёрча и взглянули, ммм?

[NGM 267]

Дык там бы Сёрча и взглянули, ммм?

Search я лицезрею на экране своего рабочего компьютера от 8 до 12 часов в сутки (как повезет ). Собственно, его и предполагается взять за основу.

[Сайлар 41]

Я бы посмотрел.

Нет проблем. Вот надергал немножко скриншотов (делал по удаленнику, поэтому качество не очень) с попутными комментами. Предположим конструктора нарисовали требуемые для заказа сборки в Proe. Далее так:

1. Открываем программку, жмем "Новое задание", добавляем сборки или детали.

2. Указываем на proe-шный asm-файл.

3. Указываем нужное для заказа количество сборок.

4. При желании добавляем еще сборок или деталей (на скрине деталька швеллер)

5. Сохраняем заказ.

6. Теперь при его открытии программка строит дерево заказа и разбивает детали и подсборки по типу операций.

7. Как передается задание в цех на скринах на примере пробивных деталей из листового металла. Идем на вкладку "Пробивка ЧПУ", программка уже составила список деталей на пробивку.

8. Нажимаем "ЧПУ" - видим какие УП уже есть (зелененькие, если УП устарела, то светит красным). На некоторые детали УП вообще нет. Программеры соответсвенно рисуют mfg, после чего жмут "Обновить", программка находит новую mfg и запускает пост, получая УП. В принципе программка может запустить автораскладку и разложить нужные детали на деловые отходы, полученные от прошлых заказов (они автоучитываются, на дачу стащить невозможно) или на листы. Жмем "Задание оператору", оно уходит в цех.

9. Оператор пробивного станка в своей программке открывает нужное задание.

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

11. А это скрин программки на сборочном участке. Они сразу видят на компе состав сборок/подсборок (внизу), какие из уже есть в наличии (пришли с пробивки или токарки и тдрд) и чертежи.

Мы пробовали Search года четыре назад, тогда еще 6 версию, но он не умел кушать файлы Proe, подтормаживал и стоил дороговато, а еще неслабо глючил, причем разработчики о половине багов знали и исправляли на ходу, а половину решить быстро не удавалось. Сейчас может уже всё получше. Также пробовали прикрутить WindChill, но он оказался труден в понимании пользователями и требовал много лишних движений, а у нас сроки изготовления вещь критичная.

и к Сайлару можно будет заехать в ближайший визит в Белоруссию

С живой демонстрацией к сожалению крайне тяжело, не разрешается руководством в принципе...

[Dimasik-ola 37]

У нас в одном предприятии тоже был некий "самопал" с БД из акцесса.

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

Станочник в цехе открывал программу, наглядно все смотрел. Если деталь ставили на другой станок, оператор кидал программу на другой станок и все. Она сама перепостпроцессировалась.

Оператору оставалось лишь найти УП на станке и запустить ее.

Нет проблем. Вот надергал немножко скриншотов (делал по удаленнику, поэтому качество не очень) с попутными комментами. Предположим конструктора нарисовали требуемые для заказа сборки в Proe.

Интересненько. Но софт привязан к вашему типу производства, я правильно понимаю?

Для раскроя и пробивки хороший подход.

[Гость Magarec]

Сайлар

[Сайлар 41]

Но софт привязан к вашему типу производства, я правильно понимаю?

Под другое производство надо адаптировать конечно. Большой красной кнопкой занимаются другие товарищи ))

[ilya_w 85]

Были добавлены типовые обработки.

Также были подцеплены станки. Была возможность кидать одну УП на разные станки с разными стойками.

Станочник в цехе открывал программу, наглядно все смотрел. Если деталь ставили на другой станок, оператор кидал программу на другой станок и все. Она сама перепостпроцессировалась.

Оператору оставалось лишь найти УП на станке и запустить ее.

Для раскроя и пробивки хороший подход.

На типовых обработках можно построить 100% автоматизацию вообще всего.

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

Весь гемор в том, чтобы иметь достаточно гибкую к изменениям и максимально приближенную к станкам базу управляющих программ.

[Dimasik-ola 37]

На типовых обработках можно построить 100% автоматизацию вообще всего.

Типовые обработки (пыльнуть плоскость, фрезернуть карман,...), а не детали.

Автоматизацию всего?! Ну-ну...

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

Ну для данного производства не тупиковый, а оптимальный. Станки со стойками Fanuc и Sintec примерно схожи. Различие в них нивелировалось данной программой, чем многим облегчало жизнь. Естественно, деталь, которая идет на горизонтальный центр с вращением по В не встанет просто так на 3-х осевой вертикальный станок.

Вообще данная прога систематизировала УП. Можно было посмотреть кто и когда сделал/изменил. Достаточно удобный поиск и просмотр. И вообще, когда есть хранилище, это хорошо.

Весь гемор в том, чтобы иметь достаточно гибкую к изменениям и максимально приближенную к станкам базу управляющих программ.

А как это, максимально приближенная к станкам система? Поясните пжста.

[Елена 116]

Организация работы операторов ЧПУ инструментального цеха и мех.цеха основного производства разная. Во втором случае все прописано техпроцессом, согласованным с ВП, в котором указано на какой именно стойке будет изготавливаться деталь по данным программам, вся работа пронормированна, что используется при планировании загрузки оборудования. Вольностей тут меньше. В инструменталке тоже пишется техпроцесс, но это в основном маршрут без особых подробностей и производство там единичное. И если оператор ЧПУ в инструменталке и сам иногда пишет программы и может режимы поменять по своему усмотрению, то для основного производства требование следовать техпроцессу - обязательно. И там в отличии от инструменталки существует акт внедрения программы.

[ilya_w 85]

Тут речь идет об общем решении. А так я могу привести пример как "полностью автоматизировал" это дело на участке сверления печатных плат. А кто-то не одном станке...

Я точно знаю только, что, если делаю программу на детальку стоимостью в десяток моих годовых зарплат, я её никому не отдам "перепостпроцессировать".