Học Automation cùng MINATA #41: PLC làm gì trong máy — Chu kỳ quét, bộ nhớ và tín hiệu vào/ra

Người mới thường hình dung PLC “thấy cảm biến là bật van ngay”. Thực tế, chương trình PLC được thực thi theo task, dữ liệu vào/ra được cập nhật theo cấu hình và một tín hiệu có thể thay đổi giữa hai lần chương trình đọc nó.

Với Delta AX-308E chạy trên nền CODESYS, hiểu chu kỳ thực thi quan trọng hơn việc thuộc nhiều câu lệnh. Nó giải thích vì sao một xung quá ngắn bị bỏ lỡ, vì sao hai đoạn chương trình cùng ghi một output tạo kết quả khó đoán và vì sao task 2 ms không có nghĩa toàn bộ máy phản ứng trong 2 ms.

Dòng chảy một chu kỳ điều khiển PLC

1. PLC nối thế giới thật với logic điều khiển

Một hệ PLC có bốn phần chính:

Đầu vào (input): nhận trạng thái nút nhấn, cảm biến, encoder hoặc giá trị analog.
Chương trình: xử lý điều kiện, trình tự, cảnh báo và lệnh.
Đầu ra (output): điều khiển đèn, van, contactor, servo hoặc gửi dữ liệu.
Truyền thông và chẩn đoán: trao đổi với HMI, remote I/O, biến tần, robot và hệ thống cấp trên.

PLC không thay thế thiết kế an toàn điện, bảo vệ quá dòng hay cơ cấu dừng an toàn. Nó điều khiển trong phạm vi kiến trúc điện và an toàn đã được thiết kế.

2. “Scan cycle” là mô hình tốt để bắt đầu, nhưng chưa đủ

Mô hình PLC cổ điển thường được dạy như sau:

Đọc input → chạy chương trình → ghi output → lặp lại

Mô hình này hữu ích, nhưng CODESYS tổ chức chương trình bằng task (tác vụ thực thi). Mỗi task gọi một hoặc nhiều chương trình (Program Organization Unit — POU) theo thứ tự đã cấu hình.

Task có thể là:

Loại task	Khi chạy	Dùng cho
Chu kỳ (cyclic)	Theo khoảng thời gian cố định	Logic máy, điều khiển tuần tự
Tự do (freewheeling)	Lặp lại không có chu kỳ cố định	Công việc nền không yêu cầu định thời chặt
Sự kiện (event)	Khi xuất hiện cạnh của biến sự kiện	Xử lý sự kiện phù hợp với runtime
Trạng thái (status)	Chạy khi biến điều kiện còn TRUE	Tránh bỏ lỡ điều kiện quá ngắn theo cách dùng phù hợp

Manual AX-3 và CODESYS đều cho phép cấu hình tên task, độ ưu tiên, loại kích hoạt và watchdog.

3. Một task chu kỳ 10 ms thực sự nói gì?

Nếu MainTask được đặt T#10ms, scheduler cố gắng khởi động task theo nhịp 10 ms.

Điều đó không tự động đảm bảo:

Input vật lý được cập nhật đúng tại đầu mỗi 10 ms trong mọi cấu hình.
Output vật lý đổi ngay tại dòng lệnh gán biến.
Toàn bộ mạng EtherCAT, chương trình, cơ cấu khí và sensor phản hồi trong 10 ms.
Thời gian chạy không bao giờ dao động.

Cần phân biệt:

Khoảng task (task interval): nhịp yêu cầu.
Thời gian chu kỳ thực tế (cycle time): thời gian runtime đo được.
Độ dao động chu kỳ (jitter): sai lệch thời điểm thực thi so với nhịp mong muốn.
Độ trễ toàn hệ thống (end-to-end latency): từ thay đổi vật lý ở input đến tác động vật lý ở output.

Trong CODESYS, tab Monitoring của Task Configuration có thể hiển thị thời gian chu kỳ cuối, trung bình, lớn nhất, nhỏ nhất và jitter. Đây là số cần xem khi commissioning.

4. Input, bộ nhớ và output

Chương trình không nên trộn ba khái niệm:

Lớp dữ liệu	Ví dụ	Ý nghĩa
Input vật lý	`diPartPresent`	Trạng thái đọc từ thiết bị
Trạng thái nội bộ	`xCycleActive`	Bộ nhớ logic của chương trình
Lệnh output	`doClampValve`	Yêu cầu gửi tới phần cứng

Đặt tên rõ giúp tránh dùng output làm bộ nhớ trạng thái. Output có thể bị khóa bởi interlock, mất module hoặc bị task khác ghi đè; nó không phải bằng chứng cơ cấu đã hoàn tất.

Ví dụ:

// Lệnh kẹp chỉ được phát khi chu kỳ đang chạy và không có lỗi.
doClampValve := xCycleActive
    AND diPartPresent
    AND NOT xFaultActive;

// Phản hồi thật phải đến từ cảm biến.
xClampConfirmed := diClampExtended;

Ở đây, doClampValve = TRUE chỉ nói PLC đang ra lệnh. Máy chỉ được chuyển bước khi diClampExtended = TRUE trong thời gian cho phép.

5. Thứ tự chương trình tạo ra kết quả

CODESYS xử lý các program call theo thứ tự trong cấu hình task. Nếu cùng một biến được ghi nhiều lần trong một chu kỳ, phép ghi sau có thể thắng.

Ví dụ không tốt:

// POU_A
doMotorRun := xAutoRequest;

// POU_B, chạy sau POU_A
IF xFaultActive THEN
    doMotorRun := FALSE;
END_IF;

Logic có vẻ đúng, nhưng quyền sở hữu output bị chia đôi. Khi dự án lớn, rất khó tìm tất cả nơi ghi.

Cách rõ hơn:

xMotorPermissive :=
    xSafetyReady
    AND NOT xFaultActive
    AND diDriveReady;

doMotorRun := xAutoRequest AND xMotorPermissive;

Mỗi output nên có một nơi quyết định cuối cùng. Các phần khác cung cấp request, permissive hoặc interlock.

6. Xung input có thể bị bỏ lỡ

Giả sử input chỉ bật trong 3 ms nhưng task đọc logic mỗi 10 ms. Nếu xung xuất hiện và biến mất giữa hai lần task quan sát, chương trình có thể không thấy nó.

Giải pháp tùy trường hợp:

Kéo dài xung bằng phần cứng hoặc cấu hình cảm biến.
Dùng input tốc độ cao hoặc latch phần cứng.
Dùng task nhanh hơn nếu phần cứng và tải CPU cho phép.
Dùng counter/encoder chuyên dụng.
Giao tiếp theo cơ chế handshake thay vì xung ngắn.

Không nên chỉ giảm task xuống 1 ms mà không đo thời gian thực thi và tải CPU.

7. Watchdog bảo vệ task, không bảo vệ toàn bộ máy

Watchdog giám sát task vượt quá giới hạn thời gian cấu hình. Nó giúp phát hiện vòng lặp vô hạn, hàm chặn hoặc tải xử lý bất thường.

Nhưng watchdog không thay thế:

Mạch dừng khẩn.
Rơ-le hoặc PLC an toàn.
Giám sát contactor dính.
Timeout chuyển động.
Phản hồi cảm biến.

Watchdog trả lời “chương trình có thực thi đúng nhịp không”; an toàn máy còn cần trả lời “năng lượng nguy hiểm có được loại bỏ đúng cách không”.

8. Cấu hình khởi đầu hợp lý cho bài học AX-308E

Với một mô hình đào tạo nhỏ, có thể bắt đầu:

Hạng mục	Giá trị khởi đầu	Lý do
MainTask	Cyclic, 10 ms	Dễ quan sát, đủ cho logic tuần tự cơ bản
Watchdog	Bật, lớn hơn thời gian chạy bình thường có biên	Phát hiện task bất thường
POU chính	`PLC_PRG`	Điều phối các module
Mapping I/O	Tên có tiền tố `di`, `do`, `ai`, `ao`	Nhìn tên biết loại tín hiệu
Output owner	Một POU duy nhất	Tránh ghi đè khó tìm

Đây không phải giá trị chuẩn cho mọi máy. Motion, EtherCAT hoặc xử lý xung nhanh cần thiết kế task và bus cycle riêng theo manual thiết bị.

9. Checklist khi PLC “chạy không đúng nhịp”

Task chứa POU cần chạy là task nào?
Task là cyclic, freewheeling, event hay status?
Interval, priority và watchdog đang đặt bao nhiêu?
Thời gian cycle lớn nhất và jitter đo được là bao nhiêu?
I/O được cập nhật bởi task/bus cycle nào?
Có biến nào bị nhiều task hoặc nhiều POU cùng ghi không?
Xung input ngắn nhất dài bao nhiêu?
Logic đang dùng lệnh output thay cho phản hồi thực không?
Mạng, servo hoặc cơ cấu khí tạo thêm bao nhiêu độ trễ?

Kết luận

PLC không đơn giản “đọc hết rồi chạy hết”. Trên CODESYS, task quyết định POU nào chạy, theo nhịp nào và ưu tiên nào. I/O, bus và chương trình phải được xem như một chuỗi thời gian hoàn chỉnh.

Hiểu task, bộ nhớ và quyền sở hữu output từ đầu sẽ giúp dự án AX-308E dễ gỡ lỗi hơn nhiều so với việc viết thêm điều kiện khi máy đã bắt đầu chạy sai.

MINATA thiết kế chương trình để mỗi lệnh có một nơi quyết định, mỗi chuyển động có phản hồi và mỗi task có số liệu thời gian để kiểm chứng.

Nguồn tham khảo

Delta — AX-3 Series Operation Manual, mục Task Configuration: https://filecenter.deltaww.com/Products/download/06/060210/Manual/DELTA_IA-PLC_AX-3_OM_EN_20230524.pdf
CODESYS — Task Configuration: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_f_task_configuration.html
CODESYS — Task Monitoring: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_obj_task_config_monitor.html
CODESYS — Task Deployment và kiểm tra truy cập I/O: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_edt_device_task_deployment.html

Xem tất cả bài viết kỹ thuật MINATA