Perencanaan Kapasitas EtherNet/IP CompactLogix L35E

CompactLogix 1769-L35E tetap umum digunakan pada mesin yang telah melampaui rencana jaringan awalnya. Masalah ekspansi biasanya dimulai ketika daftar perangkat dianggap sebagai jumlah koneksi. Kapasitas EtherNet/IP bergantung pada jenis lalu lintas yang dihasilkan setiap perangkat, seberapa sering perangkat tersebut bertukar data, dan sumber daya pengontrol yang sudah digunakan aplikasi. Karena itu, peninjauan yang aman harus dimulai dari proyek dan diagnostik aktual, bukan dari aturan umum jumlah perangkat per port.

Perencanaan koneksi harus memperhitungkan lalu lintas yang dikonfigurasi, laju pembaruan, dan risiko siklus hidup, bukan jumlah konektor Ethernet.

Mulai dari batas pengontrol yang terdokumentasi

Manual Pengguna Pengontrol CompactLogix 1769 dari Rockwell Automation mendokumentasikan bahwa L35E mendukung 100 koneksi CIP. Ini adalah batas sumber daya, bukan izin untuk menghubungkan 100 perangkat. Satu perangkat dapat memerlukan lebih dari satu koneksi, sementara beberapa komunikasi dapat berbagi satu koneksi yang dioptimalkan. Revisi firmware, konfigurasi modul, tag produced dan consumed, pesan yang di-cache, serta klien HMI atau supervisori semuanya memengaruhi jumlah akhir.

Pengontrol ini juga merupakan produk yang sudah dihentikan produksinya. Rockwell mencantumkan 1769-L35E sebagai produk yang dihentikan sejak 20 Desember 2020. Hal itu tidak membuat sistem yang masih berfungsi menjadi tidak dapat digunakan, tetapi mengubah keputusan rekayasa: masalah kapasitas harus dinilai bersama ketersediaan unit cadangan, dukungan firmware, paparan keamanan siber, dan biaya kegagalan yang tidak direncanakan.

Buat inventaris koneksi dari proyek

Buka proyek offline yang sesuai dengan pengontrol yang sedang berjalan, lalu catat setiap adapter I/O yang dikonfigurasi, drive, tag produced atau consumed, jalur pesan, server data HMI, historian, gateway, dan koneksi pemrograman. Catat apakah setiap pertukaran data berupa I/O siklik, data produced, pesan eksplisit, atau polling klien. Jangan menetapkan jejak koneksi tetap hanya berdasarkan nama vendor. Konfigurasi aktual adalah acuan utama.

Untuk I/O terdistribusi, periksa apakah format komunikasi yang dipilih membuat koneksi modul langsung atau koneksi yang dioptimalkan untuk rak. Untuk instruksi MSG, identifikasi koneksi mana yang di-cache dan apakah beberapa pesan dapat aktif secara bersamaan. Untuk sistem supervisori, hitung jalur komunikasi independen dan tinjau strategi polling-nya. Lembar kerja harus mengaitkan setiap koneksi yang diasumsikan dengan objek proyek atau konfigurasi klien yang telah diuji.

Pisahkan jumlah koneksi dari beban paket

Pengontrol dapat tetap berada di bawah batas koneksinya, tetapi tetap memberikan kinerja jaringan yang buruk. Interval paket yang diminta, frekuensi pesan, ukuran paket, perilaku multicast, konfigurasi switch, dan lonjakan dari beberapa klien memengaruhi beban paket. RPI yang sangat cepat harus dibenarkan oleh proses mekanis dan respons kontrol yang diperlukan; membuat setiap perangkat lebih cepat tidak otomatis membuat mesin menjadi lebih baik.

Tetapkan kondisi dasar saat mesin berproduksi secara normal. Catat penggunaan koneksi, penghitung kesalahan Ethernet, pesan yang terlewat atau mengalami timeout, status I/O, respons HMI, dan perilaku pemindaian pengontrol. Ulangi pengambilan data saat startup, pengunduhan resep, lonjakan alarm, akses pemeliharaan, dan kondisi puncak lain yang masuk akal. Nilai rata-rata dapat menyembunyikan interval singkat yang menyebabkan gangguan sesekali.

Switch terkelola, topologi yang terdokumentasi, dan pengukuran yang dapat diulang membuat gangguan kapasitas yang terjadi sesekali dapat didiagnosis.

Jangan gunakan 1769-AENTR sebagai port L35E kedua

1769-AENTR adalah adapter EtherNet/IP untuk bank Compact I/O jarak jauh yang dikendalikan melalui jaringan. Perangkat ini bukan antarmuka Ethernet tambahan yang meningkatkan kumpulan komunikasi pengontrol L35E, dan tidak dapat dipasang sebagai port pengontrol kedua untuk memindahkan lalu lintas HMI atau pesan dari antarmuka tertanam. Perancangan berdasarkan asumsi tersebut akan menghasilkan topologi yang tidak mampu menjalankan fungsi yang diklaim.

Jika I/O jarak jauh sesuai untuk aplikasi, adapter dapat mengonsolidasikan I/O fisik di lokasi lain, tetapi koneksi I/O yang dihasilkan tetap berakhir di pengontrol. Jika aplikasi memerlukan kapasitas komunikasi yang lebih besar, jaringan independen kedua, fungsi keamanan modern, atau dukungan siklus hidup yang lebih panjang, solusinya mungkin berupa migrasi ke keluarga pengontrol yang lebih baru, bukan penambahan adapter lain.

Kurangi beban yang dapat dihindari tanpa menyembunyikan masalah

Optimisasi harus tetap mempertahankan persyaratan proses. Hapus jalur dan klien yang sudah tidak digunakan. Konsolidasikan koneksi I/O jika platform dan jenis modul mendukungnya. Cache hanya koneksi MSG yang memerlukan eksekusi berulang dengan cepat, dan atur urutan pesan nonkritis agar tidak semuanya terbuka secara bersamaan. Tingkatkan RPI atau interval polling hanya setelah memastikan bahwa waktu deteksi, interlock, alarm, dan kualitas kontrol tetap dapat diterima.

Gunakan switch industri terkelola dan dokumentasikan pengaturan VLAN, multicast, serta IGMP jika berlaku. Switch dapat mengendalikan flooding yang tidak diperlukan dan meningkatkan visibilitas, tetapi tidak dapat menciptakan sumber daya koneksi pengontrol. Demikian pula, penambahan switch tidak terkelola hanya mengubah jumlah port, bukan kapasitas pengontrol.

Diagnosis gangguan kapasitas yang dicurigai secara sistematis

Pertama, pastikan proyek yang sedang berjalan, nomor katalog pengontrol, revisi firmware, dan topologi jaringan. Kemudian bandingkan koneksi yang dikonfigurasi dengan diagnostik aktual. Cari modul I/O yang bergantian antara kondisi berjalan dan fault, instruksi MSG yang mengalami timeout saat beban puncak, atau nilai HMI yang menjadi usang sementara logika pengontrol terus berjalan.

Ubah satu variabel pada satu waktu. Putuskan klien nonesensial yang telah disetujui, hentikan sementara layanan polling nonkritis, atau atur pesan secara berurutan selama jendela pemeliharaan yang terkendali. Jika gejalanya berubah, ukur beban sebelum dan sesudah, bukan menyatakan masalah selesai hanya berdasarkan satu jam yang tenang. Jangan pernah memperpanjang timeout atau menonaktifkan alarm komunikasi hanya untuk menyembunyikan kemacetan.

Uji ekspansi saat commissioning, termasuk pengujian kegagalan

Sebelum menambahkan perangkat, tentukan jenis koneksi, kebutuhan pembaruan, penanggung jawab, dan respons terhadap kegagalan. Uji produksi normal serta permintaan simultan terburuk yang masih masuk akal. Putuskan perangkat baru, sambungkan kembali, matikan dan hidupkan daya jaringannya, lalu pastikan pengontrol, HMI, dan alarm dapat membedakan data buruk atau usang dari kondisi proses yang valid. Pastikan pemulihan tidak memulai ulang peralatan secara tidak terduga.

Simpan inventaris, cuplikan diagnostik, konfigurasi switch, dan hasil penerimaan bersama cadangan sistem kontrol. Untuk pilihan perangkat keras saat ini, lihat sistem PLC dan PAC; untuk switch terkelola dan komponen jaringan, gunakan koleksi komunikasi dan jaringan. Pandangan editorialnya sederhana: ekspansi L35E hanya dapat dipertanggungjawabkan jika beban puncak yang terukur, perilaku saat terjadi kegagalan, dan rencana siklus hidupnya semuanya terdokumentasi.