Cứ vài ngày, SLC lại chuyển sang trạng thái lỗi. Lỗi nghiêm trọng 0020. Người vận hành nhún vai, bộ phận bảo trì xóa lỗi, sản xuất tiếp tục—cho đến khi cùng một lỗi tính toán lại xảy ra trong ca đêm. Mô hình này chính là bit bẫy tràn S:5/0 hoạt động đúng như Rockwell thiết kế: chốt lỗi để bạn không thể giả vờ rằng phép tính sai chưa từng xảy ra.

Trên dòng 5/04, chẳng hạn như 1747-L524, mã 0020 có nghĩa là một lệnh đã tạo ra kết quả nằm ngoài phạm vi số nguyên hợp lệ. Phép tính số nguyên có dấu 16 bit nằm trong khoảng từ −32768 đến +32767. Nếu vượt quá giới hạn này với ADD hoặc MUL, chia cho 0, truy cập FIFO/LIFO vượt quá bộ đệm, hoặc thực hiện NEG với −32768, bộ xử lý sẽ đặt S:5/0, sau đó chuyển sang trạng thái lỗi cho đến khi có thao tác bỏ chốt bit đó. Các sổ tay thuộc nhóm tài liệu 1747-UM011 / 1747-UM001 mô tả cơ chế bẫy này; trên sàn nhà máy, người dùng chỉ thấy một CPU ngừng hoạt động.

Các bộ xử lý SLC đời cũ vẫn điều khiển rất nhiều máy rời rạc. Lỗi bẫy tràn hầu như luôn bắt nguồn từ phép tính trong ứng dụng—không phải do backplane sắp hỏng.

Lệnh OTU giúp ngăn lỗi lan rộng

Phần lớn các cách khôi phục nhanh đều đặt một lệnh OTU trên S:5/0 để chu kỳ quét có thể tiếp tục sau khi xảy ra bẫy. Vị trí đặt lệnh là điểm mấu chốt. Hãy đặt nó ở bậc cuối cùng trong LAD 2—tệp quản lý các lệnh gọi JSR—để mọi chương trình con đã hoàn tất trước khi bạn xóa chốt lỗi. Nhờ vậy, lỗi tràn được phát hiện trong chu kỳ quét, sau đó được xóa một lần trước khi bộ xử lý chuyển sang trạng thái rảnh.

LAD 2 — bậc cuối cùng
  S:5/0
----] [----(OTU)----

Nếu đặt cùng lệnh OTU bên trong chương trình con gây tràn, bạn sẽ tạo ra một chế độ lỗi mới: xóa quá sớm, lại bị tràn ở phần sau của cùng chu kỳ quét, rồi lập tức lỗi trở lại. Hoặc OTU được kích hoạt trên một nhánh không gặp phép tính sai trong chu kỳ quét đó, khiến bạn tưởng đã “sửa” được lỗi trong khi bậc lệnh thực sự vẫn phát nổ hai lần mỗi tuần.

Tải chương trình xuống, chuyển khóa sang RUN, rồi theo dõi để đảm bảo S:5/0 vẫn ở trạng thái tắt qua vài ca làm việc. Nếu nó tiếp tục im lặng, bạn chỉ mua thêm thời gian—chưa xử lý xong nguyên nhân gốc.

Tìm phép tính thực sự gây tràn

Hãy xem OTU như một dây an toàn. Sau đó bắt đầu truy tìm:

• Mọi thay đổi gần đây có tác động đến số nguyên—số lượng theo mẻ, tín hiệu analog đã scale được đẩy vào các tệp N, hoặc phép MUL “tạm thời” để chuyển đổi đơn vị
• ADD / SUB / MUL / DIV / DDV không có giới hạn phạm vi
• Những vị trí đáng lẽ phải dùng LADD / LMUL (32 bit) khi giá trị đã vượt khỏi phạm vi 16 bit
• NEG trên một giá trị có thể đạt −32768
• Độ dài FIFO/LIFO so với kích thước bộ đệm thực sự đã dự trữ

Một số bit trạng thái liên quan cũng đáng biết khi gỡ lỗi: S:5/1 cho phép bẫy tràn, S:1/0 cho biết chu kỳ quét đầu tiên, S:2/0 cho biết lỗi bộ xử lý. Đừng xóa bẫy một cách mù quáng trong khi chỉnh sửa trực tuyến nếu chưa biết bậc lệnh nào đang gây lỗi.

Kiểm tra thực tế phần cứng

Các CPU 5/04 dòng 1747-L524 đã bước sâu vào giai đoạn lỗi thời. Nếu vẫn giữ khung máy hiện tại, hãy dự trữ một bộ 5/04 đã kiểm tra và hoạt động tốt—các nhà máy còn mua thiết bị trong dòng này thường chọn những mô-đun như 1747-L542. Các máy nhỏ hơn đôi khi chuyển ngang sang 5/03, chẳng hạn như 1747-L532, nhưng đó là quyết định của một dự án, không phải cách sửa lỗi tràn. Về lâu dài, phần lớn các nhà máy chuyển quy trình sang CompactLogix hoặc ControlLogix và loại bỏ các bẫy tính toán 16 bit cùng nền tảng cũ. Chiến lược dự phòng cho các hệ thống Logix hỗn hợp vẫn phụ thuộc vào cách bạn dự trữ các hệ thống PLC và PAC.

Cho đến khi hoàn tất việc chuyển đổi, nguyên tắc rất đơn giản: đặt OTU ở cuối LAD 2, sau đó xác minh lệnh ADD/MUL nào đang sử dụng sai phạm vi giá trị.