Cara Mengoptimalkan Waktu Sweep dan Memperbaiki Fault Watchdog Exceeded pada IC695CPU310

Memahami Penyebab Utama Fault Watchdog Timer Exceeded pada RX3i

Fault "Watchdog Timer Exceeded" pada GE Fanuc PACSystems RX3i IC695CPU310 tidak otomatis berarti CPU Anda kekurangan daya pemrosesan. Anda tidak boleh menangani error ini hanya dengan meningkatkan pengaturan software watchdog timer. Penyebab utamanya adalah lonjakan tak terduga pada waktu eksekusi satu sweep program PLC. Kondisi loop yang tidak normal, pemanggilan fungsi rekursif yang berlebihan, atau operasi memori yang berat biasanya menyebabkan penundaan eksekusi ini.

Menurut panduan referensi CPU GE Fanuc, software watchdog mendeteksi penundaan abnormal dalam penyelesaian sweep. Rentang software watchdog yang dapat dikonfigurasi adalah 10 ms hingga 2550 ms, yang dapat disesuaikan dalam inkremen 10 ms. Teknisi lapangan harus selalu menemukan bottleneck program yang meningkatkan waktu sweep terburuk, bukan menutupi kelemahan logika yang mendasarinya dengan timeout yang diperpanjang.

Membedakan Kegagalan Software Watchdog dan Hardware Watchdog

Teknisi harus mengidentifikasi mekanisme hardware atau software yang tepat di balik fault sebelum mengubah kode apa pun.

• Kegagalan Software Watchdog: Hal ini terjadi ketika satu sweep eksekusi melampaui ambang watchdog yang diprogram. Pemicu umumnya mencakup loop FOR atau WHILE yang sangat besar, function block rekursif, operasi array tanpa pembatasan, pemrosesan string yang berat, komunikasi Ethernet yang terkonsentrasi, atau penulisan langsung ke memori nonvolatil.
• Kegagalan Hardware Watchdog: Hal ini merupakan mekanisme internal CPU yang memicu sistem keselamatan. Berbeda dari error software, fault hardware watchdog sering kali memerlukan siklus daya fisik penuh untuk dihapus pada platform CPU lama seperti IC695CPU310.

Ketika terjadi shutdown tak terduga, akses Fault Table di PAC Machine Edition (PME). Periksa Fault Description, Fault Code, Time Stamp, dan Occurrence Count. Lanjutkan dengan pengoptimalan logika hanya jika log diagnostik secara eksplisit menunjukkan berakhirnya waktu software watchdog.

Menganalisis Dinamika Sweep: Sweep Rata-Rata vs. Sweep Terburuk Maksimum

Banyak teknisi otomasi hanya berfokus pada waktu pemindaian program rata-rata, sehingga menciptakan titik buta yang berbahaya. Sistem dengan waktu sweep rata-rata 18 ms dapat dengan mudah melonjak hingga 240 ms selama pemicu kondisi tertentu. Jika batas watchdog Anda berada pada 200 ms, PLC akan segera masuk ke kondisi stop fault.

Logika berat bersyarat biasanya menyebabkan shutdown acak ini. Operasi seperti perhitungan batch laporan harian, pengarsipan data historis, atau penyalinan memori massal yang berjalan selama satu siklus scan dapat meningkatkan waktu eksekusi puncak.

Metode Praktis untuk Mengurangi Waktu Scan pada Controller IC695CPU310

Mengoptimalkan siklus scan membuat loop kontrol tetap responsif di fasilitas pengemasan berkecepatan tinggi, pengolahan air, dan manufaktur kontinu. Terapkan teknik rekayasa berikut untuk menurunkan waktu sweep puncak:

• ⚙️ Terapkan Time-Slicing untuk Loop Besar: Jangan pernah menjalankan loop FOR atau WHILE besar dalam satu siklus sweep. Pecah pemrosesan array menjadi bagian-bagian kecil selama beberapa sweep berturut-turut menggunakan indeks state machine.
• ⚙️ Audit Pemanggilan Rekursif dan Function Block: Periksa pohon pemanggilan block di PAC Machine Edition. Hilangkan pemanggilan rekursif tidak langsung ketika Function A memicu Function B, yang secara tidak sengaja memanggil Function A lagi pada cabang logika tertentu.
• ⚙️ Beralih dari Penanganan Data Kontinu ke Berbasis Peristiwa: Hindari menyalin atau melakukan penskalaan ribuan register analog pada setiap scan. Jalankan rumus matematika yang berat dan pengurutan array hanya ketika flag perubahan data terpicu.
• ⚙️ Distribusikan Tugas Komunikasi Ethernet dan Serial: Atur komunikasi aktif seperti Modbus, SRTP, atau EGD secara bergantian di beberapa siklus menggunakan strategi polling round-robin, bukan melakukan polling terhadap semua node eksternal sekaligus.
• ⚙️ Batasi Penulisan Flash Nonvolatil: Pemanggilan logika langsung yang menulis data operasional ke memori nonvolatil membutuhkan waktu CPU yang signifikan. Picu penulisan flash secara berkala atau setelah batch selesai, bukan pada setiap sweep logika.

Alur Kerja Troubleshooting Lapangan Langkah demi Langkah

Ikuti urutan rekayasa yang sistematis ini untuk menghilangkan lonjakan waktu scan dengan aman:

1. Identifikasi Asal Fault: Periksa Fault Table PME untuk memastikan adanya trip software watchdog.
2. Catat Metrik Dasar: Catat sweep rata-rata CPU, sweep terburuk maksimum, dan pengaturan timeout watchdog saat ini.
3. Lacak Bottleneck Kode: Cari loop tanpa pembatasan, transfer array kontinu, komunikasi yang terkonsentrasi, dan penulisan memori flash.
4. Refaktor Logika: Terapkan state machine, algoritme time-slicing, dan block logika berbasis peristiwa untuk mendistribusikan beban pemrosesan.
5. Evaluasi Ulang Performa: Pantau waktu scan puncak selama beberapa shift operasional dalam kondisi beban produksi maksimum.
6. Sesuaikan Batas Watchdog: Atur batas software watchdog sedikit di atas waktu sweep terburuk yang baru ditetapkan untuk mempertahankan margin keselamatan yang andal.

Skenario Aplikasi: Optimalisasi Sistem Konveyor Lini Pembotolan

Di fasilitas pembotolan minuman berkecepatan tinggi yang menggunakan controller IC695CPU310, lini produksi mengalami stop fault PLC secara berkala setiap beberapa hari saat pergantian shift.

Penyebab Utama: Selama pergantian shift, subrutin ladder logic aktif menjalankan loop tanpa pembatasan yang mengurutkan, memperbarui, dan menyalin 4.000 register pelacakan produk ke dalam array pengarsipan dalam satu scan. Hal ini meningkatkan waktu sweep puncak dari normalnya 22 ms menjadi 265 ms, melampaui ambang software watchdog sebesar 200 ms.

Solusi: Tim rekayasa kami menyusun ulang algoritme pengurutan menjadi state machine berbasis time-slicing yang memproses 200 register per siklus scan selama 20 sweep berturut-turut. Modifikasi ini menurunkan waktu sweep puncak maksimum dari 265 ms menjadi 38 ms, sehingga sepenuhnya menghilangkan masalah trip watchdog tanpa mengubah komponen hardware.

Pertanyaan yang Sering Diajukan (FAQ)

T1: CPU310 kami sering memicu fault Watchdog Timer Exceeded. Apakah ini berarti kecepatan prosesor CPU terlalu lambat dan perlu diganti?
Jawaban: Tidak selalu. Penggantian CPU harus menjadi pilihan terakhir. Sebagian besar error watchdog berasal dari struktur logika program yang buruk, operasi loop tanpa pembatasan, atau lonjakan komunikasi yang tiba-tiba. Anda dapat menghilangkan lonjakan sweep dengan menyusun ulang perhitungan berat menjadi state machine berbasis time-slicing di beberapa siklus logika. Pertimbangkan peningkatan hardware hanya jika waktu sweep dasar rata-rata tetap mendekati kapasitas CPU setelah kode disusun ulang.

T2: Dapatkah kami mengatur Software Watchdog Timer dengan aman ke nilai maksimum 2550 ms untuk menghindari trip?
Jawaban: Meskipun menu konfigurasi CPU secara fisik memungkinkan nilai hingga 2550 ms, hal tersebut merupakan praktik rekayasa yang buruk. Memperpanjang batas sejauh itu akan menutupi error logika kritis, seperti loop tak terbatas atau pemanggilan rekursif yang macet. Dalam otomasi proses kritis, CPU yang berhenti selama 2,5 detik sebelum melakukan trip dapat menyebabkan bahaya operasional dan keselamatan yang serius. Pertahankan batas watchdog sedikit di atas waktu sweep terburuk aktual dengan margin keselamatan yang wajar.

T3: Berdasarkan pengalaman lapangan, apa cara terbaik untuk melacak block tertentu yang menyebabkan lonjakan waktu scan?
Jawaban: Gunakan alat diagnostik di dalam PAC Machine Edition bersama timer eksekusi khusus. Sisipkan pembacaan stempel waktu sistem sebelum dan sesudah function block yang dicurigai untuk mencatat durasi eksekusi puncak ke dalam register pelacakan. Bandingkan pembacaan ini dengan log status mesin untuk menemukan peristiwa produksi—seperti pergantian batch, pembuatan laporan, atau polling HMI—yang memicu beban scan puncak.

Wawasan Penulis & Pendapat Ahli

"Selama bertahun-tahun mendukung peralatan otomasi industri di Ubest Automation Limited, kami sering melihat tim lapangan mencoba mengatasi fault watchdog PLC dengan menaikkan pengaturan timer secara sembarangan atau membeli hardware baru. Pada platform seperti PACSystems RX3i, lonjakan waktu scan hampir selalu disebabkan oleh manajemen data yang tidak efisien atau komunikasi tanpa pembatasan. Pendekatan disiplin yang mengutamakan software menghemat waktu henti secara signifikan dan memperpanjang masa pakai hardware kontrol yang ada."
— Tim Rekayasa Ubest Automation Limited

Mencari Hardware GE Fanuc yang Andal dan Dukungan Ahli?

Baik untuk melakukan troubleshooting sistem lama maupun mencari suku cadang pengganti untuk otomasi pabrik, Ubest Automation Limited menyediakan komponen PLC asli yang telah diuji, modul DCS, dan solusi kontrol industri.

Jelajahi komponen GE Fanuc dan PACSystems asli di Ubest Automation Limited.