Week 3 — Computer-controlled cutting
This week’s topic: Computer-controlled cutting.
Group assignment
Our group assignment at Shenzhen Chaihuo was built as a practical workflow: define safe operation first, then collect machine data, then validate joint fit with tolerance tests, and finally publish reproducible results through version control.
Work objective
The purpose was not only to make one successful cut, but to generate a baseline process sheet the team can reuse. We focused on focus-height behavior, cut versus mark parameter ranges, kerf estimation, and press-fit clearance under realistic lab conditions.
- Characterize how settings map to visible cut quality.
- Measure kerf and slot tolerance for press-fit design decisions.
- Document approved materials and safety constraints for repeatability.
- Keep evidence and decisions traceable through GitLab collaboration.
1) Safety and setup checklist
We treated safety as part of process control. Before each run, we completed operator sign-off, verified ventilation, checked material restrictions, and maintained supervised fire watch while the laser was active.
2) Machine characterization log
Parameters recorded during test runs and the measurement logic behind each item.
| Measured item | How we evaluated it |
|---|---|
| Focus | Run nominal and offset focus cuts, then compare edge sharpness, taper, and heat marks. |
| Power / speed / rate | Separate parameter windows for through-cut and marking, documented with controller labels. |
| Kerf | Estimate material removal from repeat coupons using caliper measurement and visual cross-check. |
| Joint clearance | Use incremental slot coupons to determine the fit interval that repeatedly assembles cleanly. |
| Approved materials | List approved materials for this site and clearly mark prohibited categories. |
3) Tolerance validation (comb-style test)
We prepared a slot-spacing sweep and tested fit behavior across incremental gaps. The accepted range was chosen by repeatability criteria: stable assembly force, no corner cracking, and consistent holding strength over multiple samples.
4) Collaboration and publishing
We used a fork -> branch -> merge request flow on GitLab to keep changes reviewable. Notes, photos, and parameter updates were committed alongside edits, so the published group record stayed synchronized with what was physically tested in the lab.
This structure makes the documentation easier to reuse in later weeks: safety rules are clear, machine settings have context, and fit decisions are supported by visible test evidence.