В ключе цифровизации и оптимизации, в компании, возник вопрос — как сократить время на закупку материалов для производства и сократить ошибки? На данный момент в подразделении разработки изделий эксплуатируется связка CREO+Windchill (замена пока не рассматривается), а в закупках трудится 1С. Компания работает в области машиностроения.
В ходе описания бизнес‑процессов, где мне довелось участвовать лично, наружу вылезло бутылочное горлышко — ручной расчет потребного количества металла (трубы и листовой прокат) и всевозможных ПКИ (покупных комплектующих изделий). Всё это годами работало с формулировкой «так исторически сложилось» и «это невозможно автоматизировать...».
На входе имеем проект выполненный в CREO несколькими группами (конструкторов по назначению) сведенный в единую модель, которая выгружается PLM в виде сборки (фактически как архив конструкторов) и чертежей (база для технологов). Детали могут быть как заимствованные (ранее использованные или принятые как стандартны в компании) так и впервые спроектированные.
На выходе требуются — файл маршрута движения деталей по переделам (участкам и этапам изготовления) и перечень ПКИ оформленный в 1С.
Итерация 1 — (неудачная) — всё возьмем из модели!
Первая идея была очевидной и топорной: если в модели Creo есть размеры и материал, надо просто залезть в файлы деталей и забрать! Фиаско был на входе — файлы.prt имеют закрытый бинарный формат. Прямой парсинг отпал.
Погуглив, наткнулся на мысль о конвертировать модели в открытый формат нейтральной геометрии ‑.neu откуда требуемые параметры можно забрать через парсинг. Появились первые проблески надежды, но вместе с ними и ворох проблем. О первых деталей в сборке несколько сотен, во вторых в разных типах деталей атрибуты полей и материалов заполнялись по разному (решаемо на будущее, но архив перерабатывать ни кто не захочет). Автосохранение в формате.neu через Modelcheck провалилась. Возможно это связано конкретно с нашей версией CREO, но факт — не работает.
Следующий кандидат — утилита пакетной обработки Distributed Pro/BATCH (ptcdbatch).
При единоразовом тестировании нормально преобразовывала файлы, но при попытке загрузки пакета (опытным путем выявлено — более 8 файлов) начинала зависать.
Пример файла пакетного задания в для ptcdbatch.
<DXC> <Group DSQM="_LOCAL" Name="NEUTRAL 3D Export" Output="2" OutputDir="C:\Users\_путь_к_папке_результатов_" PrimaryContent="0" TTD="C:\Program Files\PTC\Creo 9.0.11.0\Common Files\text\ttds\neutral_3d_export.ttd" VaultResults="0"> <Object>C:\Users\_путь_\745_файл.prt.2</Object> <Object>C:\Users\_путь_\746_файл.prt.2</Object> </Group> </DXC>
Так же на Python были написаны скрипты нарезки файлов пакетных заданий, в папке назначения, по 8 файлов и удаления копий файлов.prt а, так же, прочие вспомогательные файлы сборки которые совершенно не были нужны при копировании на сервер с обработчиком. Поясню про имена файлов — дело в том, что версии документов CREO хранит добавляя номер итерации после расширения и сохраняя в одной папке, то есть.prt.2 более свежая версия .prt.1. Для конвертации принято решение использовать самые новые версии файлов, для чего прочие надо было удалить.
Сами скрипты написаны на коленке, используя ИИ, и не являлись оптимальными. Но не это оказалось проблемой, а некорректные данные геометрии, извлекаемые из .neu файлов для гнутых изделий. Это связано с тем, как геометрия детали описывается в файле — легко можно получить только габаритный (ограничивающий) куб геометрии детали. Если деталь имеет сложную гибку в нескольких плоскостях, этот куб не имеет ничего общего с реальной разверткой листа, которую нужно заказать снабжению. Для корректности нужно было извлекать все грани из-за чего расчет размеров усложнялся до бесконечности. Это направление было признано тупиковым, и я его заморозил.
Итерация 2 – использование библиотеки прошлых расчетов
Пока я разбирался с геометрией и разбирался в тонкостях процесса оказалось, что кроме размеров и материалов для заказа ПКИ составляется карта движения детали по переделам (где деталь появляется, в какой цех сначала, куда потом). Родилась новая гипотеза: а что, если не пытаться высчитывать геометрию, а брать имена/шифры деталей, сопоставлять их с базой прошлых заказов (ведь детали часто типовые или повторяющиеся) и вытягивать готовые данные оттуда? Да, для абсолютно новых деталей (их у нас порядка 30%) это не сработает — их придется добивать руками. Но 70% повторяемости — это уже огромная победа. (На будущее я отложил мысли прикрутить сюда нейросеть для поиска аналогов по геометрии или жестко доработать систему шифров деталей, но пока решили делать MVP).
Встал вопрос: откуда дергать исходную структуру изделия для анализа?
Гипотеза 1: Выгружать отчет прямо из Creo (там есть такой функционал). К сожалению, вытащить код материала из 1С не получилось (опишу далее почему) и при сохранении файла встроенный браузер зависал (но это можно было обойти)
Гипотеза 2: Забрать данные напрямую из Windchill. И — удалось найти штатный способ выгрузки структуры представления изделия в чистый .xlsx.
Итерация 2.1 – (почти удалось) – выгружаем прямо из CREO
Изначально в каждую деталь создаваемую конструктором заложено поле соответствующее материалу в 1С. Казалось бы – добавить в ответ, и дело в шляпе! Но изначально при внедрении конструкторской системы имя параметра было занесено на русском языке КОД1С, а CREO при формировании отчета категорически отказывается обрабатывать такие параметры. Идея с алиасами тоже не удалась, а вручную перебирать все файлы для исправления
Пример кода файла отчета format.bft
.breakdown %$type %$name contains: .row %$quantity[6]; %$type[12]; %$name[-40]; %$КОД_1С[-35s]; %PTC_COMMON_NAME[-20s] .summary Summary of items for %$name: .row %$quantity[6]; %$type[12]; %$name[-40]; %$КОД_1С[-35s]; %PTC_COMMON_NAME[-20s]
Далее все просто — в CREO перейти во вкладку «Инструменты», нажать «Ведомость материалов», выбрать верхний уровень и отметив все галочки нажать ОК. Получаем сводный отчет с разбивкой по сборкам/подсборкам и итоговую сводку. Ее уже можно отправлять в работу, но нужна библиотека прошлых расчетов.
Для формирования библиотеки были скопированы все расчеты (.xls файлы) за два последних года и по ним запущен парсер на n8n. Общее число строк превысило 36 тысяч, а после подчистки дублей — 24.
Соединение отчета выгрузки из CREO и поученной библиотеки давало приемлемый результат, сложность (для пользователей) была только в получении файла отчета.
Итерация 2.2 – (текущая) – выгружаем из Windchill
В процессе чтения может возникнуть разумный вопрос — почему не купить решение? А его нет. Интегратор, ранее продавший систему в текущих реалиях предлагает переход на другую систему, а пауза на «подумать о решении» затянулась на несколько месяцев.
В процессе решения предыдущей итерации я стал больше и эффективнее пользоваться ИИ и, в один из таких заходов, нашел еще более интересное решение — выгрузка отчета из Windchill. Это оказалось легко, если понимать где искать.
И так — сборка (верхняя сборка проекта/модели) — вкладка «Структура» — «Представления» (надо создать с требуемыми полями или выбрать требуемое) — «Развернуть все уровни» — «Экспорт» (выбрать требуемый формат).
Получаем файл в котором можно получить много интересного (наш КОД_1С не удается получить, зато есть: кто и когда менял последний раз, имя файла, количество, входимость, наименование, материал, масса, тип детали.)
Загружаем в workflow n8n на основе предыдущей итерации и получаем на выходе 3 файла.xls — листовые материалы, трубы и прочие ПКИ. В первых двух порядка 70% информации заполнено, остальное нужно добавить вручную, а, если договорится о стандартизации маркировки отдельных типов деталей (как правило у нас это каркасообразующие) то можно повысить автозаполяемость до 90%. Так же можно не заполненный пул деталей пропустить через LLM.
Во время тестовых прогонов всплыл неожиданный, но крайне приятный побочный эффект — система начала работать как автоматический нормоконтроль, и даже получилось выявить ошибки в самих 3D‑моделях конструкторов.
Результаты, человеческий интерфейс и замах на 1С
Как это выглядит для конечного пользователя прямо сейчас?
Никакого сложного софта ставить никому не пришлось. На внутреннем корпоративном портале создана простая веб-страница с формой для прикрепления файла отчета и инструкция его по получению.
Теперь ответственный сотрудник формирует отчет и подгружает его в форму, n8n крутит свои шестеренки, и ровно примерно через 1–2 минуты пользователь скачивает архив с тремя разделенными файлами и заполненностью 70%.
Очевидно, что это костыли и именно так они и задумывались.
Все эти наработки нужны были для того, что бы нащупать рабочий механизм перегрузки информации в 1С из Windchill в нашем конкретном случае. Также в процессе этой работы выявлены дополнительны пожелания к системе (например автоматизация учета сменных заданий, но это уже другая история). На данный момент, это работающий MVP который реально помогает.
А, на данный момент, это всё. Надеюсь вам было полезно или интересно)
