Tiếp nhận chương trình PLC của người khác: 4 việc nên làm trước
Bạn nhận một chương trình mà không ai giải thích được — kỹ sư trước đã nghỉ, tài liệu gốc thất lạc, hoặc đơn giản là “chạy được trước đã”. Sai lầm phổ biến nhất lúc này là mở TIA Portal ra và sửa ngay.
Vì sao không được sửa trước
Trong một chương trình đang chạy, phần logic “trông có vẻ thừa” rất có thể là miếng vá được thêm vào sau một sự cố. Động vào nó khi chưa có bản gốc đối chiếu và chưa có bằng chứng không làm mất vấn đề — mà đổi vấn đề cũ thành vấn đề mới, và vấn đề mới khó tìm hơn vì chính bạn tạo ra nó.
4 việc nên làm trước
- ① Thu thập bằng chứng — chưa sửa gì
- Lưu lại mọi thứ lấy được ngay lúc này: chương trình upload từ PLC, bộ đệm chẩn đoán (Diagnostic buffer), lịch sử báo động, trạng thái thực tế của các I/O chính, và mô tả của người vận hành về việc “khi nào thì lỗi xuất hiện”. Đây là nguyên liệu cho mọi phán đoán về sau — một khi bạn bắt đầu sửa, trạng thái hiện trường không lấy lại được nữa.
- ② Tạo bản gốc (baseline) cho phiên bản
- Lưu chương trình vừa upload thành một bản lưu trữ có ngày và ghi chú nguồn, kèm một dòng: “bản này upload từ máy ngày … , chưa chỉnh sửa”. Nghe nhỏ nhặt, nhưng đây là căn cứ duy nhất để sau này bạn nói rõ đã sửa gì và vì sao — và cũng là điểm bắt đầu để người kế tiếp tiếp nhận được.
- ③ Phân tích tĩnh + suy luận logic để thu hẹp phạm vi
- Đừng đoán từ hiện tượng. Cho chương trình chạy qua công cụ (nguy cơ chia cho 0, truy cập mảng ngoài biên, độ sâu gọi khối, biến không dùng, đặt tên lộn xộn) để thu hẹp vùng nghi ngờ xuống vài khối. Sau đó liệt kê các nguyên nhân có thể và xếp theo khả năng, thay vì thử lần lượt.
- ④ Xác minh kết luận rồi mới sửa
- Chỉ sửa sau khi nguyên nhân gốc được xác nhận bằng mô phỏng hoặc chạy từng bước tại hiện trường. Sau khi sửa phải chạy lại kiểm tra hồi quy để chắc chắn không có ảnh hưởng dây chuyền (sửa A làm hỏng B là bình thường, không phải ngoại lệ). Mỗi lần sửa đều phải lưu vết như nhau.
Một kinh nghiệm: khi tiếp nhận chương trình cũ, 90% thời gian nên dành cho việc “hiểu nó thực sự đang là gì”, chỉ 10% cho việc “làm cho nó thành cái tôi muốn”. Làm ngược lại, thường hai tuần sau bạn quay về đúng điểm cũ — kèm theo nhiều vấn đề hơn.
Nên yêu cầu những gì (có thì lấy, không có vẫn phải hỏi)
- Bản sao chương trình — bản nào cũng được, càng cũ càng giá trị (dùng để đối chiếu)
- Model PLC và phiên bản firmware (số đặt hàng là chính xác nhất)
- Bảng I/O hoặc bản vẽ điện (dù chỉ là bản nháp)
- Trước đây đã từng có lỗi gì và xử lý thế nào (kể miệng cũng ghi lại)
- Có ai biết vì sao đoạn logic đó lại được viết như vậy — người đó giá trị hơn mọi tài liệu
Chúng tôi làm việc này thế nào
Cứu chương trình và chẩn đoán lỗi thuộc phạm vi dịch vụ của chúng tôi (Cải tạo · chẩn đoán · cứu chương trình). Cách làm của chúng tôi chính là 4 bước trên: bằng chứng trước, kết luận sau, không đoán mò. Một ranh giới cần nói rõ: đấu dây và thay thiết bị, thu thập dữ liệu vận hành thực tế và kiểm chứng độc lập chức năng an toàn bắt buộc phải làm tại hiện trường — phần chương trình có thể làm từ xa, vấn đề vật lý thì không.