Menghubungkan GX Simulator ke Factory I/O melalui OPC

Commissioning virtual menjadi berharga ketika adegan yang disimulasikan berperilaku seperti mesin yang dikendalikan, bukan sekadar animasi yang tidak terhubung. Untuk proyek PLC Mitsubishi, diperlukan jalur data yang dapat ditelusuri dari simulator rekayasa GX, melalui server OPC yang kompatibel, hingga tag Factory I/O.

Tujuannya bukan sekadar membuat konveyor bergerak. Penyiapan yang baik membuktikan kepemilikan alamat, arah sinyal, perilaku urutan, interlock, pewaktuan, respons terhadap hilangnya komunikasi, dan logika mulai ulang sebelum I/O fisik tersedia.

Konveyor virtual kecil dapat mengungkap cacat pemetaan, pewaktuan, dan pemulihan sebelum masalah tersebut muncul pada panel kontrol nyata.

Pastikan kompatibilitas perangkat lunak sebelum memetakan tag

“GX Simulator” dapat merujuk pada fungsi simulasi yang terkait dengan berbagai generasi GX Works dan keluarga CPU MELSEC. Produk OPC juga berbeda berdasarkan versi dan dukungannya terhadap OPC DA atau OPC UA. Pilihan driver Factory I/O mungkin tidak mendukung setiap kombinasi dengan cara yang sama.

Catat keluarga PLC, versi GX Works, komponen simulator, produk dan versi server OPC, jenis antarmuka, serta versi Factory I/O secara tepat. Kemudian pastikan server OPC dapat terhubung ke CPU yang disimulasikan tersebut. Jangan menganggap metode koneksi yang berfungsi dengan modul Ethernet fisik akan otomatis berfungsi dengan simulator perangkat lunak.

Mitsubishi menjelaskan MX OPC sebagai perangkat lunak yang mengekspos data pengontrol terprogram MELSEC melalui OPC. Perangkat keras MELSEC iQ-R yang lebih baru juga dapat menggunakan modul server OPC UA tertanam, tetapi arsitektur tersebut berbeda dari server yang di-host pada PC dan terhubung ke pengontrol yang disimulasikan. Pisahkan jalur-jalur tersebut dalam catatan desain dan pemecahan masalah.

Tulis kontrak data sebelum mengonfigurasi perangkat lunak

Buat daftar I/O dengan satu baris untuk setiap sinyal. Sertakan tag Factory I/O, alamat perangkat Mitsubishi, tipe data, arah, makna teknis, keadaan bawaan, keadaan aman, kebutuhan pembaruan, dan pemiliknya. Simulasi biasanya harus memiliki kendali atas keadaan input lapangan, sedangkan logika PLC memiliki kendali atas perintah aktuator.

Aturan kepemilikan tersebut mencegah dua aplikasi menulis titik yang sama. Photoeye yang disimulasikan dapat menulis perangkat input PLC, sementara PLC menulis perintah motor yang dibaca Factory I/O. Jika kedua sisi menulis satu tag, tampilan dapat berkedip atau terlihat acak meskipun setiap koneksi individual secara teknis aktif.

Perangkat bit, word, bilangan bulat bertanda, nilai titik mengambang, dan array memerlukan penanganan tipe yang eksplisit. Klien OPC mungkin berhasil menampilkan suatu nilai, sementara Factory I/O menafsirkan tipe atau urutan bit yang salah. Mulailah dengan satu titik Boolean dan satu word yang nilai perubahannya mudah dikenali. Perluas hanya setelah arah dan penskalaan terbukti benar.

Bangun dan uji koneksi secara berlapis

Pertama, buat program PLC minimal dan jalankan dalam simulator GX yang didukung. Paksa atau ubah keadaan perangkat internal yang diketahui, lalu pastikan monitor ladder menampilkan keadaan yang diharapkan. Ini membuktikan bahwa program, CPU yang dipilih, dan simulator beroperasi.

Kedua, konfigurasikan server OPC untuk pengontrol yang disimulasikan tersebut. Buat hanya beberapa tag pengujian. Gunakan klien atau tampilan diagnostik milik server untuk mengonfirmasi kualitas, stempel waktu, nilai, dan kemampuan menulis. Nilai yang ditandai “bad” atau “uncertain” harus diperbaiki pada lapisan ini sebelum Factory I/O dibuka.

Ketiga, konfigurasikan klien OPC Factory I/O dan telusuri atau masukkan tag yang telah terbukti. Petakan satu sensor yang disimulasikan dan satu perintah aktuator. Konfirmasikan kedua arah secara terpisah: ubah input adegan dan amati memori PLC, lalu ubah output PLC dan amati adegan.

Metode berlapis ini memisahkan sumber gangguan. Jika memori GX tidak berubah, masalahnya berada pada simulasi PLC. Jika GX berubah tetapi klien OPC tidak berubah, periksa konfigurasi server dan pengalamatan perangkat. Jika server OPC sehat tetapi Factory I/O tidak berubah, periksa koneksi klien, nama item, hak akses, dan pemetaan tag.

Verifikasi lapis demi lapis mengisolasi gangguan konfigurasi PLC, server OPC, dan Factory I/O.

Perhitungkan pewaktuan di tiga sistem yang independen

Pemindaian PLC, polling server OPC, langganan klien, dan pembaruan fisika Factory I/O tidak terjadi pada saat yang sama. Pulsa sensor yang lebih singkat daripada interval pengambilan sampel gabungan dapat menghilang sebelum diamati PLC. Beban jaringan atau PC juga dapat menambah jitter, bahkan pada workstation lokal.

Peristiwa penting harus dirancang agar bertahan melewati pengambilan sampel. Perangkat yang disimulasikan dapat mempertahankan keadaan hingga dikonfirmasi, atau logika PLC dapat mengunci transisi yang terdeteksi hingga urutan menggunakannya. Memperpanjang setiap pulsa memang praktis untuk demonstrasi, tetapi dapat menyembunyikan cacat penanganan edge. Sesuaikan perilaku pengujian dengan sensor fisik dan kecepatan produksi yang diharapkan.

Ukur jeda efektif dari ujung ke ujung, bukan menganggap laju pembaruan OPC yang dikonfigurasi sebagai keseluruhan latensi. Catat transisi adegan, stempel waktu OPC, pengamatan PLC, keputusan output, dan tindakan adegan yang dihasilkan ketika pewaktuan penting bagi urutan.

Rencanakan keterbatasan OPC DA dan workstation

OPC DA klasik menggunakan teknologi COM Microsoft. Jika semua aplikasi berjalan di bawah satu akun Windows pada satu komputer, penyiapan biasanya lebih sederhana. Konfigurasi terdistribusi menimbulkan masalah identitas DCOM, izin, firewall, dan akun layanan. Koneksi yang berfungsi secara interaktif dapat gagal setelah reboot jika server OPC dimulai menggunakan akun yang berbeda.

OPC UA menggunakan model keamanan yang berbeda dengan endpoint, sertifikat, dan kebijakan. OPC UA menghindari DCOM, tetapi tetap memerlukan kepercayaan sertifikat, izin pengguna, dan model data yang kompatibel. Gunakan antarmuka yang benar-benar didukung oleh perangkat lunak yang dipilih, bukan menganggap DA dan UA sebagai label yang dapat dipertukarkan.

Uji keadaan kegagalan dan mulai ulang secara sengaja

Putuskan koneksi klien OPC saat konveyor aktif. Hentikan simulator PLC. Mulai ulang server OPC. Buka kembali Factory I/O dengan output yang sebelumnya aktif. Mesin tidak boleh melanjutkan gerakan berbahaya hanya karena nilai lama muncul kembali atau klien tersambung ulang.

Tentukan respons terhadap kualitas buruk, komunikasi yang terputus, dan nilai awal. Perintah dapat dipaksa mati, dipertahankan, atau ditangani dengan penghentian terkendali, bergantung pada prosesnya. Input mungkin memerlukan bit kesehatan komunikasi yang eksplisit agar PLC dapat membedakan keadaan salah yang sebenarnya dari data yang tidak tersedia.

Uji juga mulai dingin, mulai ulang hangat, retensi penghitung, ketidaksesuaian resep, sensor terhalang, kedatangan bersamaan, dan reset operator. Dokumentasikan keadaan awal setiap tag yang dapat ditulis serta urutan yang diperlukan untuk masuk ke mode otomatis.

Jadikan sel virtual sebagai perangkat uji

Gunakan kasus penerimaan yang dapat diulang: tidak ada aktuator sebelum izin mulai terpenuhi; satu hitungan untuk setiap produk; penghentian terkendali pada target; waktu habis saat sensor terhalang; gangguan ketika komunikasi terputus; dan pemulihan yang dapat diprediksi setelah tersambung kembali. Tren tag dan catatan lulus/gagal memberikan bukti yang lebih kuat daripada tangkapan layar adegan yang bergerak.

Pilihan pengontrol Mitsubishi dapat ditinjau dalam koleksi Mitsubishi Electric, dengan perangkat keras pengontrol yang lebih luas di Sistem PLC & PAC.

OPC hanyalah lapisan transportasi. Nilai rekayasanya terlihat ketika sel virtual menjadi lingkungan pengujian yang dapat diulang untuk perilaku PLC, kepemilikan sinyal, asumsi pewaktuan, respons terhadap gangguan, dan logika mulai ulang yang akan diterapkan pada mesin fisik.