Người vận hành chỉ nhấn khởi động quá phụ thuộc vào quyết định của người khác
Tại nhiều khu vực, người vận hành máy CNC bắt đầu với quy tắc đơn giản: không chạm vào chương trình, chạy theo hướng dẫn, khi có vấn đề thì gọi thợ điều chỉnh. Đối với những ca làm việc đầu tiên, điều này là hợp lý. Không thể ngay lập tức ném người mới vào mã, các điều chỉnh và các tình huống tranh cãi bên máy. Nhưng nếu quy trình này tồn tại mãi mãi, công ty sẽ không có sự ổn định mà chỉ có sự phụ thuộc. Bất kỳ sự lệch lạc nào cũng trở thành việc chờ đợi nhân viên có kinh nghiệm hơn.
Vấn đề thường không xuất hiện trên chi tiết đầu tiên hoàn hảo. Nó xuất hiện sau đó: dụng cụ bắt đầu mòn, kích thước từ từ lệch, chương trình dừng lại không đúng chỗ như mong đợi, người vận hành thấy khung trên bảng điều khiển nhưng không hiểu điều gì sẽ xảy ra tiếp theo. Vào thời điểm này, “tôi chỉ khởi động” không còn là vị trí an toàn.
Đào tạo người vận hành đọc chương trình không có nghĩa là biến họ thành lập trình viên. Đây là một cấp độ nhiệm vụ khác. Mục tiêu đơn giản và thực tiễn hơn: để người đó hiểu logic chuyển động, thấy được những điểm nguy hiểm, biết giải thích điều gì đang xảy ra và không gọi thợ điều chỉnh cho mỗi dòng có thể phân tích một cách bình tĩnh.
Đầu tiên cần tách biệt việc đọc chương trình và viết chương trình
Nhà tuyển dụng thường nhầm lẫn hai kỹ năng này. “Biết G-code” có thể có nghĩa là người đó viết chương trình điều khiển từ đầu. Nhưng cũng có thể có nghĩa là họ hiểu các lệnh cơ bản, thấy sự thay đổi dụng cụ, phân biệt giữa tốc độ di chuyển và tốc độ làm việc, và hiểu tại sao điều chỉnh lại thay đổi kết quả. Đối với người vận hành, thường cần cấp độ thứ hai hơn.
Nếu việc đào tạo ngay lập tức được trình bày như “lập trình”, một số người vận hành sẽ bắt đầu phòng thủ. Điều này có vẻ là một bước quá lớn: CAM, bộ xử lý sau, chu trình, hình học, trách nhiệm về va chạm. Tốt hơn nên gọi nhiệm vụ một cách trung thực hơn: đọc chương trình làm việc bên máy. Không phải tạo ra quy trình từ đầu, mà là hiểu những gì đã được chuyển giao vào sản xuất.
Sự phân chia này giảm bớt căng thẳng. Người vận hành không được nói: bây giờ bạn chịu trách nhiệm cho tất cả quyết định của lập trình viên. Họ được nói điều khác: bạn phải hiểu những gì bạn đang khởi động, nơi nào cần dừng lại, điều gì cần kiểm tra và cách mô tả vấn đề mà không dùng cụm từ “máy làm gì đó không đúng”.
Phải dạy từ màn hình bảng điều khiển, không phải từ bảng lệnh trừu tượng
Bảng G-code hữu ích, nhưng không tốt như một cuốn sách giáo khoa đầu tiên. Nếu bắt đầu với danh sách dài G00, G01, G02, G03, G41, G42, G43, mã M và các chu trình, việc đào tạo nhanh chóng trở thành việc ghi nhớ các ký hiệu. Tại khu vực, người vận hành không cần phải vượt qua lý thuyết, mà cần liên kết dòng chương trình với chuyển động của máy, dụng cụ, chi tiết và rủi ro.
Tốt hơn nên lấy một đoạn ngắn của chương trình thực tế hoặc học tập và đọc nó bên cạnh máy hoặc trên mô phỏng. Nơi nào có sự tiếp cận nhanh? Nơi nào bắt đầu cắt? Nơi nào thay đổi dụng cụ? Tại sao ở đây lại bật điều chỉnh? Điều gì sẽ xảy ra nếu chu trình tiếp tục từ dòng này? Các tọa độ nào thuộc về vùng an toàn, và các tọa độ nào đã gần với chi tiết?
Một đoạn ngắn được phân tích đến cùng thường hữu ích hơn một giờ giải thích chung. Đặc biệt nếu người vận hành thấy mối liên hệ giữa khung, quỹ đạo, âm thanh cắt và kích thước kiểm soát. Vào thời điểm này, chương trình không còn là “văn bản cho thợ điều chỉnh” mà trở thành một phần của công việc thường ngày.
Cấp độ đầu tiên: hiểu tiến trình chương trình mà không có quyền chỉnh sửa độc lập
Ở giai đoạn đầu, người vận hành không cần được phép chỉnh sửa mã. Thậm chí ngược lại: cấm thay đổi độc lập có thể hữu ích, nếu nó không cản trở việc học. Người đó phải đọc và giải thích, nhưng không thay đổi chương trình mà không có sự cho phép. Điều này giảm bớt một phần nỗi sợ hãi của người thợ và giảm rủi ro chỉnh sửa ngẫu nhiên.
Ở cấp độ này, đủ để người vận hành tự tin trả lời các câu hỏi đơn giản nhưng thực tế:
- dụng cụ nào đang hoạt động và nó đang làm gì;
- ở đâu trong chương trình có các chuyển động nhanh, và ở đâu có tốc độ làm việc;
- điều chỉnh nào ảnh hưởng đến kích thước và nơi nào nó được bật;
- tại sao chương trình dừng lại hoặc yêu cầu thay đổi dụng cụ;
- từ dòng nào thì nguy hiểm để khởi động mà không kiểm tra vị trí của máy.
Nếu người vận hành có thể giải thích điều này theo chương trình của mình, họ không chỉ đơn giản là nhấn khởi động. Họ bắt đầu thấy quá trình. Điều này không biến họ thành lập trình viên độc lập, nhưng giảm số lần gọi thợ điều chỉnh không cần thiết và giúp nhận ra hành vi kỳ lạ sớm hơn.
Cấp độ thứ hai: liên kết chương trình với đo lường và điều chỉnh
Đọc chương trình trở nên thực sự hữu ích khi người vận hành liên kết nó với kích thước trên chi tiết. Ví dụ, kích thước đã đi đến giới hạn trên của dung sai. Điều gì ảnh hưởng đến nó: độ mòn của dụng cụ, điều chỉnh bán kính, chiều dài dụng cụ, kẹp, nhiệt độ, thứ tự gia công? Chương trình tự nó không cung cấp toàn bộ câu trả lời, nhưng nó cho thấy nơi cần tìm.
Tại đây, việc đào tạo phải đi kèm với việc đo lường. Người vận hành không chỉ nhìn vào lệnh mà còn vào điểm kiểm soát: lần đi nào đã hình thành kích thước này, dụng cụ nào đã tham gia, nơi nào cho phép điều chỉnh, điều gì không thể thay đổi mà không có sự đồng ý. Và rất quan trọng là họ phải hiểu giới hạn: một điều chỉnh có thể được thực hiện theo hướng dẫn, điều khác cần được đồng ý với thợ điều chỉnh hoặc kỹ thuật viên.
Dấu hiệu thực hành tốt: người vận hành có thể nói không chỉ “kích thước đã đi”, mà còn “kích thước sau dụng cụ này đang tăng dần, điều chỉnh đã được thay đổi đến mức này, sửa đổi tiếp theo cần được đồng ý”. Đây đã là một cuộc trò chuyện khác bên máy. Người thợ nhận được không phải tín hiệu lo lắng mà là thông tin làm việc.
Cấp độ thứ ba: khởi động lại và dừng an toàn
Nhiều vấn đề phát sinh không phải khi khởi động bình thường, mà sau khi dừng lại. Kiểm soát đã hoạt động, nguyên liệu đã hết, dụng cụ đã bị gãy, người vận hành đã nhấn dừng, cần tiếp tục. Người không đọc chương trình trong tình huống này hoặc gọi sự giúp đỡ mỗi lần, hoặc có nguy cơ khởi động từ vị trí có vẻ thuận tiện nhưng không an toàn.
Đào tạo đọc chương trình phải bao gồm khởi động lại. Dụng cụ ở đâu? Hệ thống tọa độ nào đang hoạt động? Điều chỉnh có được bật không? Mã M cần thiết đã được thực hiện chưa? Có an toàn để tiếp cận trước khi cắt không? Điều gì sẽ xảy ra nếu khởi động từ dòng dưới hoặc trên? Những câu hỏi này chỉ nhàm chán trên giấy. Bên máy, chúng phân tách việc khởi động lại bình thường khỏi dụng cụ bị hỏng.
Ở giai đoạn này, có ích khi thực hành không phải các sự cố anh hùng, mà là các dừng thông thường. Không cần ngay lập tức mô phỏng sự cố hiếm gặp. Đủ để phân tích hai hoặc ba trường hợp điển hình đã xảy ra tại khu vực: tạm dừng sau khi đo, thay thế lưỡi cắt, lặp lại sau khi dừng cấp liệu, quay lại hoạt động sau khi kiểm tra chi tiết.
Không phải mọi người vận hành đều phải có quyền như nhau
Đào tạo đọc chương trình không có nghĩa là cấp phép giống nhau cho tất cả. Một người vận hành có thể đọc các khung nhưng không thay đổi gì. Người khác có thể thực hiện các điều chỉnh hạn chế theo hướng dẫn. Người thứ ba sau khi kiểm tra nhận quyền thực hiện các chỉnh sửa đơn giản trong giới hạn quy trình đã được đồng ý. Nếu không phân chia các cấp độ này, việc đào tạo nhanh chóng trở nên nguy hiểm hoặc vô ích.
Tốt hơn là mô tả trước các cấp độ quyền hạn. Ví dụ: đọc và giải thích chương trình; thực hiện các điều chỉnh được phép; thực hiện khởi động lại an toàn; đề xuất sửa đổi nhưng không tự thực hiện; chỉ chỉnh sửa các đoạn mẫu đã được phê duyệt. Một bậc thang như vậy có thể ngắn, nhưng nó phải tồn tại. Nếu không, người thợ sẽ quyết định theo cảm giác, và người vận hành sẽ đoán xem điều gì đã được phép.
Sơ đồ tồi tệ nhất là dạy người ta hiểu mã, nhưng chính thức giữ họ trong vai trò “chỉ nhấn”. Họ sẽ bắt đầu thấy lỗi và bất tiện, nhưng không biết cách truyền đạt chúng đúng cách. Việc đào tạo phải bao gồm không chỉ các lệnh mà còn cả lộ trình giải quyết: ai để báo cáo, điều gì cần ghi lại, nơi nào dừng công việc, khi nào chờ sự cho phép.
Mô phỏng giúp ích, nếu không thay thế quy trình thực tế
Mô phỏng trực tuyến hoặc môi trường học tập hữu ích ở những nơi không thể an toàn để thử nghiệm trên máy. Trên mô phỏng, có thể chỉ ra quỹ đạo, các chuyển động nhanh, khởi động sai, ảnh hưởng của một số lệnh và thứ tự đọc các khung. Đối với lần làm quen đầu tiên, điều này tốt hơn là giải thích mọi thứ trên máy đang hoạt động, nơi có chi tiết, kẹp và kế hoạch thay đổi.
Nhưng mô phỏng không nên tạo ra ảo tưởng rằng người vận hành đã hiểu mọi thứ. Công việc thực tế thêm âm thanh cắt, trạng thái dụng cụ, phoi, kẹp, làm mát, đo lường và áp lực thời gian. Do đó, lộ trình học tập tốt sẽ như sau: phân tích đoạn trong môi trường an toàn, sau đó liên kết nó với hoạt động thực tế, sau đó kiểm tra sự hiểu biết bên máy dưới sự giám sát của nhân viên có kinh nghiệm.
NCPlayer có thể hữu ích như một lớp trung gian: người vận hành thấy cách văn bản chương trình biến thành chuyển động, trước khi thảo luận điều này bên thiết bị thực tế. Nhưng việc kiểm tra cuối cùng vẫn phải diễn ra trên logic sản xuất, không chỉ trên quỹ đạo đẹp trên màn hình.
Làm thế nào để biết rằng việc đào tạo đã thành công
Kiểm tra kết quả tốt hơn không phải bằng một kỳ thi lớn, mà bằng một vài hành động thực tế. Hãy cho người vận hành một chương trình quen thuộc và yêu cầu họ giải thích những gì sẽ xảy ra trong các dòng tiếp theo. Hãy yêu cầu tìm vị trí thay đổi dụng cụ, khu vực có tốc độ làm việc, dòng mà không thể khởi động mà không kiểm tra. Phân tích kích thước đã lệch và yêu cầu họ liên kết nó với dụng cụ và điều chỉnh cho phép.
Một tiêu chí tốt khác là chất lượng thông báo về vấn đề. Trước khi đào tạo, người vận hành nói: “chương trình đã dừng lại” hoặc “chi tiết không đi”. Sau khi đào tạo bình thường, họ phải nói chính xác hơn: nơi đã dừng lại, dụng cụ nào đang hoạt động, điều gì đã xảy ra trước khi dừng, kích thước nào đã thay đổi, điều gì đã được kiểm tra. Đây không phải là chi tiết nhỏ. Thông tin như vậy quyết định xem thợ điều chỉnh có đến giải quyết vấn đề hay không, hoặc trước tiên phải tìm hiểu xem điều gì đã xảy ra.
Nếu sau khi đào tạo, người vận hành bắt đầu đặt ít câu hỏi vô nghĩa hơn, nhưng nhanh chóng nêu ra các tình huống thực sự nguy hiểm, thì việc đào tạo đã đi đúng hướng. Mục tiêu không phải là để họ im lặng và tự giải quyết mọi thứ. Mục tiêu là để câu hỏi của họ trở nên chính xác hơn, và hành động bên máy trở nên bình tĩnh và an toàn hơn.
Đọc chương trình là một phần của sự độc lập chuyên nghiệp
Người vận hành không nhất thiết phải trở thành lập trình viên để mạnh mẽ hơn trong công việc của mình. Nhưng họ phải hiểu văn bản mà họ khởi động, ít nhất là ở mức độ rủi ro, thứ tự và mối liên hệ với kích thước. Nếu không, sản xuất sẽ vẫn phụ thuộc vào một vài người “hiểu mã”, trong khi những người khác làm việc một cách mù quáng.
Việc đào tạo đọc chương trình tốt hơn nên được xây dựng từng bước nhỏ: màn hình bảng điều khiển, chuyển động, dụng cụ, kích thước, điều chỉnh, dừng lại, khởi động lại, giới hạn dung sai. Khi đó, kỹ năng không có vẻ như là học thuật. Nó trở thành một phần của ca làm việc bình thường: ít chờ đợi hơn, ít hành động ngẫu nhiên hơn, nhiều sự rõ ràng hơn vào lúc máy đã hoạt động và lỗi có giá trị tiền bạc.