Duyệt cây Assembly bằng NXOpen: tránh nhầm Component và Part

Duyệt cây Assembly bằng NXOpen: tránh nhầm Component và Part

Nhiều công cụ tự động hóa NX bắt đầu bằng một yêu cầu tưởng đơn giản: lấy toàn bộ component trong assembly để xuất BOM, kiểm tra thuộc tính, đổi tên, tính khối lượng hoặc xuất STEP. Sai lầm phổ biến là coi Component, occurrence, prototype và Part là cùng một đối tượng. Chương trình có thể chạy với assembly nhỏ nhưng cho kết quả trùng, thiếu hoặc lỗi khi gặp subassembly, component chưa load và nhiều occurrence dùng chung một prototype.

1. Hiểu cây assembly trước khi viết vòng lặp

Trong NXOpen, Component là một occurrence nằm trong cây lắp ráp. Nó có vị trí, hướng, tên occurrence, trạng thái suppress và quan hệ với component cha. Prototype của occurrence thường là một Part hoặc đối tượng đại diện cho thiết kế nguồn.

Một file part có thể xuất hiện nhiều lần trong assembly. Khi đó có nhiều Component nhưng chỉ một prototype. Nếu mục tiêu là BOM theo vị trí lắp, phải xử lý từng occurrence. Nếu mục tiêu là xuất mỗi file duy nhất một lần, phải nhóm theo prototype hoặc đường dẫn nguồn.

2. Bắt đầu từ RootComponent

Điểm vào thông dụng là ComponentAssembly.RootComponent của Display Part hoặc Work Part phù hợp. Root không phải một chi tiết bình thường; nó đại diện cho cấp gốc của cây. GetChildren chỉ trả về các con trực tiếp, vì vậy muốn lấy toàn bộ cấp sâu phải duyệt đệ quy hoặc dùng stack/queue.

Trước khi duyệt, kiểm tra RootComponent có null hay không. Một part đơn lẻ không có cấu trúc assembly có thể không cung cấp cây như mong đợi.

3. Duyệt depth-first bằng đệ quy

Mẫu tư duy cơ bản:

• Nhận một component hiện tại.

• Lấy danh sách children.

• Với mỗi child, xử lý dữ liệu cần thiết.

• Gọi lại hàm cho child đó.

Thứ tự này phù hợp khi cần giữ quan hệ cha-con hoặc tạo đường dẫn như Root/SubA/Part01. Tuy nhiên, cần tránh lỗi phổ biến là push cả mảng children thay vì phần tử children[i], hoặc quên truyền collection kết quả theo tham chiếu trong C++.

4. Khi nên dùng stack thay cho đệ quy

Assembly công nghiệp có thể sâu hoặc rất lớn. Duyệt lặp bằng stack giúp kiểm soát bộ nhớ và dễ dừng giữa chừng. Mỗi phần tử stack có thể chứa component, depth và đường dẫn cha. Cách này cũng thuận tiện để cập nhật progress bar và hỗ trợ hủy tác vụ.

Đệ quy vẫn rõ ràng cho công cụ nội bộ nhỏ; vấn đề không nằm ở cú pháp mà ở việc có giới hạn, log và xử lý ngoại lệ hay không.

5. Occurrence và prototype

Các thuộc tính như vị trí lắp, reference set hoặc thuộc tính instance thuộc occurrence. Hình học, body và nhiều thuộc tính part nằm ở prototype. Nếu gọi hàm đo thể tích với tag của Component, API cấp thấp có thể từ chối vì nó yêu cầu Part hoặc solid Body.

Quy trình đúng là xác định mục tiêu dữ liệu. Muốn lấy mass của hình học nguồn, truy cập prototype Part rồi duyệt các Body hợp lệ. Muốn tổng khối lượng assembly, phải tính đến số occurrence, trạng thái suppress, đơn vị và khả năng mỗi occurrence có override hoặc arrangement khác nhau.

6. Tránh đếm trùng

Có ba kiểu đếm thường gặp:

• Đếm occurrence: mỗi vị trí lắp là một dòng.

• Đếm prototype: mỗi part nguồn chỉ xử lý một lần.

• BOM tổng hợp: nhóm theo mã part nhưng cộng quantity.

Hãy chọn khóa rõ ràng. Đường dẫn file có thể dùng trong native mode nhưng không đủ trong Teamcenter. Part number, item revision hoặc persistent identifier phù hợp hơn tùy hệ thống. Không dùng display name làm khóa duy nhất vì người dùng có thể đổi tên occurrence.

7. Component chưa được load

GetChildren và truy cập prototype có thể cho kết quả khác khi assembly dùng partial loading, lightweight representation hoặc component bị lỗi đường dẫn. Công cụ không nên tự động load toàn bộ assembly nếu không cần, vì có thể gây chậm và tiêu thụ bộ nhớ lớn.

Thiết kế hai chế độ: đọc metadata sẵn có và chế độ yêu cầu hình học. Chỉ load component khi operation thực sự cần Body, feature hoặc mass properties. Ghi lại PartLoadStatus và báo riêng component không thể mở.

8. Suppressed, arrangement và reference set

Một component suppress trong arrangement hiện tại có thể vẫn tồn tại trong cây. Tùy mục tiêu, bạn cần bỏ qua hay ghi nhận nó. Công cụ xuất BOM kỹ thuật có thể cần cả component suppress; công cụ kiểm tra va chạm thì thường chỉ xét component đang hoạt động.

Reference Set quyết định hình học nào được hiển thị trong occurrence, nhưng prototype có thể chứa nhiều body hơn. Nếu tính mass từ toàn bộ prototype trong khi assembly chỉ dùng một reference set chuyên biệt, kết quả có thể không phản ánh cấu hình hiển thị.

9. Đọc thuộc tính an toàn

Trước khi lấy thuộc tính theo title, kiểm tra nó tồn tại, kiểu dữ liệu và phạm vi instance/prototype. Cùng tên “PART_NO” có thể là string ở part nhưng là instance attribute ở component. Tránh catch exception rồi trả chuỗi rỗng mà không log; như vậy dữ liệu thiếu và lỗi API trở nên không phân biệt được.

Một record kết quả nên chứa status, value và source. Ví dụ: FoundOnOccurrence, FoundOnPrototype, Missing, TypeMismatch hoặc LoadFailed.

10. Quản lý lỗi theo từng nhánh

Không để một component lỗi làm dừng cả assembly. Bao mỗi bước xử lý node trong try/catch có log đường dẫn node, nhưng vẫn cho phép duyệt các nhánh còn lại. Phân biệt lỗi có thể bỏ qua với lỗi làm kết quả không đáng tin.

Cuối tác vụ, xuất báo cáo tổng: số occurrence, số prototype duy nhất, số suppress, số chưa load, số lỗi thuộc tính và thời gian xử lý. Đây là dữ liệu cần thiết để người dùng quyết định có chấp nhận đầu ra hay không.

11. Hiệu năng

Không chuyển Work Part liên tục cho từng component nếu API không yêu cầu. Chuyển part có thể kích hoạt update, display và callback. Gom các thao tác đọc trước, sau đó mới thực hiện thao tác ghi theo batch.

Cache dữ liệu theo prototype để không đọc lại body, thuộc tính hoặc mass cho hàng trăm occurrence giống nhau. Nhưng cache vị trí và thuộc tính instance theo occurrence. Cập nhật giao diện theo khoảng thời gian, không sau mỗi node.

12. Mẫu kiến trúc đầu ra

Tách chương trình thành bốn lớp:

• Traversal: tạo stream node theo thứ tự xác định.

• Resolver: ánh xạ occurrence sang prototype và trạng thái load.

• Extractor: đọc thuộc tính, body, mass hoặc dữ liệu cần thiết.

• Writer: xuất CSV, Excel, database hoặc file trung gian.

Cấu trúc này cho phép kiểm thử traversal bằng cây giả mà không cần chạy mọi thao tác NX. Nó cũng giúp đổi đầu ra mà không sửa logic duyệt.

Checklist trước khi triển khai

• Xác định đếm occurrence hay prototype.

• Chọn RootComponent từ đúng Display/Work Part.

• Xử lý trường hợp root null.

• Giữ depth và parent path cho mỗi node.

• Có chiến lược với component suppress và chưa load.

• Phân biệt attribute instance và prototype.

• Cache dữ liệu theo đúng loại đối tượng.

• Không dùng tên hiển thị làm khóa duy nhất.

• Log exception theo component và tiếp tục khi an toàn.

• Đối chiếu số lượng với Assembly Navigator trên file mẫu.

Kết luận

Duyệt assembly không chỉ là gọi GetChildren nhiều lần. Một công cụ đáng tin phải hiểu Component là occurrence trong cây, Part là prototype chứa dữ liệu thiết kế và cùng một prototype có thể xuất hiện nhiều lần. Khi làm rõ mục tiêu đếm, trạng thái load, arrangement và nguồn thuộc tính, mã NXOpen sẽ ổn định hơn trên assembly thực tế và dễ mở rộng sang BOM, kiểm tra dữ liệu hoặc xuất file hàng loạt.

Nguồn gợi ý chủ đề: UGAPI – “递归方式获得装配下指定节点下的所有子组件Component”: https://www.ugapi.com/thread-6114.html ; “遍历装配体并且得到质量体积”: https://www.ugapi.com/thread-6216.html ; NXOpen Component reference: https://www.ugapi.com/doc/nxopen/a00563.html

Nội dung được biên soạn lại và mở rộng theo hướng kiến trúc công cụ; không phải bản dịch hay sao chép mã nguyên văn.