Setiap beberapa hari, SLC mengalami fault. Kesalahan utama 0020. Operator hanya mengangkat bahu, teknisi pemeliharaan menghapusnya, produksi kembali berjalan—hingga kesalahan perhitungan yang sama muncul lagi pada shift malam. Pola itu adalah bit jebakan overflow S:5/0 yang bekerja persis seperti rancangan Rockwell: mengunci kondisi agar Anda tidak dapat berpura-pura bahwa perhitungan yang salah tidak pernah terjadi.

Pada 5/04 seperti 1747-L524, 0020 berarti sebuah instruksi menghasilkan nilai di luar rentang integer yang valid. Operasi signed 16-bit berada di antara −32768 dan +32767. Jika batas atas itu terlampaui dengan ADD atau MUL, melakukan pembagian dengan nol, mengakses FIFO/LIFO melewati buffer-nya, atau melakukan NEG pada −32768, prosesor akan mengatur S:5/0, lalu tetap dalam kondisi fault sampai ada sesuatu yang melepas penguncian bit tersebut. Manual keluarga publikasi 1747-UM011 / 1747-UM001 menjelaskan jebakan ini; di lantai produksi, yang terlihat hanyalah CPU yang mati.

Prosesor SLC lama masih mengendalikan banyak mesin diskret. Jebakan overflow hampir selalu disebabkan oleh matematika aplikasi—bukan backplane yang mulai rusak.

OTU yang menghentikan masalah

Sebagian besar pemulihan cepat memasang OTU pada S:5/0 agar pemindaian dapat berlanjut setelah jebakan terjadi. Penempatannya adalah bagian yang paling penting. Pasang sebagai rung terakhir di LAD 2—file yang memiliki panggilan JSR—agar semua subrutin telah selesai sebelum Anda menghapus penguncian. Dengan begitu, overflow terdeteksi selama pemindaian, lalu dihapus satu kali sebelum kondisi idle.

LAD 2 — rung terakhir
  S:5/0
----] [----(OTU)----

Jika OTU yang sama ditempatkan di dalam subrutin yang mengalami overflow, Anda menciptakan mode kegagalan baru: kondisi dihapus terlalu cepat, overflow terjadi lagi pada bagian lain dalam pemindaian yang sama, lalu fault muncul kembali seketika. Atau OTU aktif pada jalur yang tidak mengalami perhitungan bermasalah pada pemindaian tersebut, sehingga Anda mengira masalah telah “diperbaiki”, padahal rung yang sebenarnya masih memicu fault dua kali seminggu.

Lakukan download, ubah ke RUN, lalu amati S:5/0 tetap tidak aktif selama beberapa shift. Jika tetap tenang, Anda hanya mendapatkan waktu tambahan—bukan penyelesaian akar masalah.

Temukan perhitungan yang benar-benar mengalami overflow

Anggap OTU sebagai sabuk pengaman. Kemudian lakukan pemeriksaan:

• Setiap perubahan terbaru yang menyentuh integer—jumlah batch, analog berskala yang dimasukkan ke file N, atau MUL “sementara” untuk konversi satuan
• ADD / SUB / MUL / DIV / DDV tanpa pembatas rentang
• Bagian yang seharusnya menggunakan LADD / LMUL (32-bit) setelah nilai keluar dari batas nyaman 16-bit
• NEG pada nilai yang dapat berada di −32768
• Panjang FIFO/LIFO dibandingkan dengan ukuran buffer yang benar-benar Anda sediakan

Bit status terkait yang perlu diketahui saat melakukan debugging: S:5/1 pengaktifan jebakan overflow, S:1/0 pemindaian pertama, S:2/0 fault prosesor. Jangan menghapus jebakan secara membabi buta melalui pengeditan online tanpa mengetahui rung mana yang bermasalah.

Pemeriksaan realitas perangkat keras

CPU 5/04 kelas 1747-L524 sudah sangat usang. Jika chassis tetap dipertahankan, simpan satu unit 5/04 cadangan yang telah diuji di rak—pabrik yang masih membeli dalam keluarga ini sering menggunakan modul seperti 1747-L542. Mesin yang lebih kecil terkadang bermigrasi secara lateral ke 5/03 seperti 1747-L532, tetapi itu adalah keputusan proyek, bukan perbaikan overflow. Dalam jangka panjang, sebagian besar lokasi memindahkan proses ke CompactLogix atau ControlLogix dan mengakhiri jebakan matematika 16-bit bersama platform tersebut. Strategi penyediaan suku cadang untuk armada Logix campuran tetap bergantung pada cara Anda menyediakan sistem PLC dan PAC.

Sampai migrasi tersebut selesai, langkahnya sederhana: OTU terakhir di LAD 2, lalu buktikan ADD/MUL mana yang salah memperkirakan rentangnya.