Seperti yang aku tulis di artikel portofolio project Automated Finish Good Weighing & Multi-QR Serialization Pipeline, project ini dikerjain dengan banyak kendala di awal. Mulai dari waktu yang mepet, sampai PLC yang bahkan belum tersedia, padahal fitur utama dari project ini justru timbang otomatis, yang alurnya dari load cell, lanjut ke indikator, masuk ke PLC, diteruskan ke node server, baru akhirnya sampai ke Laravel.
Bikin Simulator PLC Duluan
Berbekal source code node yang sebelumnya sudah pernah konek ke PLC di project lain, aku bikin simulator sendiri untuk sedikit meniru perilaku PLC. Setelah aku pelajari lagi bagaimana cara node berkomunikasi dengan PLC, aku sadar kalau node.js itu selalu membaca DM1010 sebanyak 10 word. Dari situlah aku mulai merancang simulator PLC ini, buat menunjang pengerjaan project selanjutnya.
Batasan Inti Simulator
Inti dari simulator ini harus bisa menerima input berat atau status, lalu dirakit jadi format ASCII khas timbangan, dikonversi ke hex, dan ditaruh ke address DM1010, sekaligus berkomunikasi pakai protokol FINS. Cuma itu aja sebenarnya inti dari simulator ini, nggak lebih. Setelah batasanya jelas, baru waktunya mecutin AI buat bantuin bikin simulatornya wkwkwkw.
Persiapan Sebelum Trial
Singkat cerita, project ini selesai dari sisi program timbang otomatisnya, dan siap untuk trial. Tapi tetap aja, aku nggak PD, karena bagaimanapun dugaanku soal perilaku PLC bisa saja salah. Dan kalau salah, artinya aku harus rombak cara komunikasi node server-ku dari awal lagi.
Trial dijadwalkan hari Rabu, tanggal 2 September 2026, jam 3 sore di pabrik. Tapi box panel beserta PLC-nya baru sampai kantor hari Selasa sore, yaa meskipun kata vendor barangnya sudah ready to use. Padahal rencana awalnya barang itu datang hari Senin, biar sempat ku tes komunikasi antara program dan PLC asli dulu di kantor sebelum dibawa ke lapangan.
Akhirnya, aku tidak sempat cek komunikasinya sama sekali di kantor. Tidak ada pilihan lain selain langsung kirim panel itu ke pabrik, dan nyoba komunikasinya untuk pertama kali justru langsung di lokasi, tentu dengan kondisi yang sangat tidak ideal.
Sebelum bisa dibilang siap buat real trial, ada beberapa rangkaian yang perlu dituntaskan dulu di lapangan:
- Ubah alamat IP PLC sesuai permintaan PIC pabrik.
- Pastikan PLC bisa di-ping dari server.
- Pastikan PLC bisa merekam berat dari load cell dan data itu berhasil diterima sama program yang udah aku bikin.
Arsitektur Sistem
Biar lebih jelas, arsitektur lengkap dari project ini sebenarnya begini. Di lapangan ada timbangan yang pakai load cell, dan load cell itu terkoneksi lewat kabel DB9 male ke weighing indicator AD-4406A, komunikasinya pakai standar RS-232C. Dari weighing indicator AD-4406A ini, koneksinya lanjut ke PLC lewat comport. Dari PLC ke server, koneksinya pakai LAN biasa.
Data dari PLC ini dikonsumsi sama node server, caranya Node.js terus-menerus polling ke address DM0101. Begitu ada perubahan nilai, node server langsung broadcast data itu lewat SSE (Server-Sent Events). Laravel di sisi lain berperan sebagai display buat orang di lapangan sekaligus program pencatatan data timbang, dia nerima broadcast SSE itu, sehingga tampilan nilai timbang di Laravel bisa realtime, ngikutin beban yang lagi ada di atas timbangan saat itu juga.
Alasan kenapa arsitekturnya dibikin kayak gini bukan tanpa sebab. Ada regulasi dari pabrik yang mewajibkan semua software atau program itu harus tersentralisasi ke server. Tujuannya biar kalau suatu saat ada PC di lapangan yang rusak, tinggal ganti device-nya aja, tanpa perlu ribet konfigurasi ulang program dari nol.
Mengubah Alamat IP PLC
Oke, balik lagi ke persiapan trial. Aku mencoba untuk merubah alamat IP bawaan PLC. Info dari vendor, IP-nya adalah 192.168.250.1.
Untuk merubah alamat ini diperlukan IDE CX-Programmer. Setelah ku-download, aku coba konek ke PLC tersebut dan gagal terus. Awalnya aku pikir memang aku yang lupa caranya buat konek ke PLC — ya wajar aja, udah 7 tahun lebih nggak bersentuhan sama dunia PLC. Akhirnya aku coba buka manual book di situs resmi Omron.
Pada halaman 144, tertera cara komunikasi dengan PLC via IP bisa menggunakan menu Auto Online – EtherNet/IP Node Online. Aku coba, dan masih nggak bisa.
Aku penasaran, apakah memang ada masalah dengan PLC-nya, atau bukan. Akhirnya aku merubah IP laptopku menjadi 192.168.250.10, terus ku coba ping ke 192.168.250.1. Hasilnya RTO (Request Time Out). Ini aneh banget, karena harusnya kalau memang IP dari PLC benar 192.168.250.1, seharusnya aku bisa ping, karena alamatku udah kusamain jadi satu blok yang sama.
Dari sini aku mulai menduga, sepertinya IP dari PLC bukan 192.168.250.1. Aku baca-baca lagi manual book-nya sampai ketemu halaman 145, di sub-bab Auto Online – CP1/CP2 built-in Ethernet Online. Dari situ aku baru bisa konek dengan PLC secara online, dan langsung ku cek IP PLC tersebut ternyata 192.168.1.100. Sebenarnya aku udah geram karena aku ngulik hal ini 2 jam lebih, tapi ya namanya manusia, mungkin vendornya salah ingat soal IP PLC ini.
💡TipsAku melakukan perubahan alamat IP, Aku masuk ke project tree di sebelah kiri, terus klik menu Settings yang letaknya persis di bawah nama PLC,NewPLC1[CP1L-E]. lalu cari tab paling kanan Built-in Ethernet
Momen Trial
Setelah masalah koneksi selesai, aku download program dari PLC ke laptop, buat trial dulu di laptop sebelum menggunakan server.
Load cell dan PLC siap, node server dan Laravel juga udah siap. Proses trial ku jalankan, satu temanku ku suruh naik ke timbangan. Aku lihat di indikator sudah menunjukan nilai berat, tapi di programku belum — masih 0. Aku cek log node server, hasilnya:
Original bytes: [83, 84, 44, 71, 83, 44, 43, 48, 48, 48, 48, 48, 46, 48, 107, 103, 0, 0, 0, 0]
Yang kalau di-decode hasilnya ST,GS,+00000.0kg.
Sampai titik ini sebenarnya aku udah panik, karena merasa ketakutanku sepertinya beneran terjadi. Tapi aku coba buat tetap tenang, dan coba cek nilai dari CX-Programmer pada DM0101, udah ada nilainya atau belum. Setelah ku cek, ternyata dari program PLC-nya belum mengirimkan data yang ku minta. Okee, aku cukup tenang saat tau hal ini 😀
Aku kontak ke vendor terkait hal ini. Laptopku di-remote untuk mereka troubleshoot program mereka. Ternyata, kabel koneksi indikatornya mereka salah melabeli antara TX dan RX, sehingga tim-ku salah mengkoneksikannya. Setelah dibalik…
BOOM. Berat dikirim dan ditampilkan dengan baik dan akurat oleh programku. Seluruh tim — aku, teknisi jaringan, teknisi lapangan — akhirnya lega, karena fitur utama dari project ini berfungsi dengan baik.
Migrasi ke Server
Setelah kupastikan project siap dipindah ke server, aku ganti IP sesuai yang diminta PIC, yaitu 192.168.141.2. Aku rubah IP PLC-nya ke alamat tersebut, beserta subnet mask 255.255.255.0. Lalu seluruh programku juga sudah ku pindah ke server, semua settingan CORS juga sudah ku atur agar hanya IP tertentu yang bisa request ke programku.
Tapi setelah IP PLC ku rubah, ternyata server nggak bisa ping ke PLC, sementara PC di lapangan bisa ping ke PLC. Ternyata ini karena alamat IP server adalah 192.168.50.1 — ini beda blok, PLC di 141, sementara server di 50. Aku konsultasi sama tim jaringan, katanya bisa diatasi dengan input gateway atau apalah, tapi dia bingung mau input ke mana, karena UI CX-Programmer beda sama yang biasa dia pegang.
Kenapa Server Nggak Bisa Ping PLC
Alat jaringan — PC, server, PLC — itu cuma “kenal langsung” sama alat lain yang satu subnet dengannya, ditentukan dari kombinasi IP Address + Subnet Mask.
- PLC:
192.168.141.2/255.255.255.0→ artinya PLC ini anggota jaringan192.168.141.x - PC: di-set jadi
192.168.141.10→ otomatis PC ini juga anggota jaringan192.168.141.xyang sama
Karena PC dan PLC ada di “kompleks” yang sama, mereka bisa langsung saling teriak (ping) tanpa perlu lewat siapa-siapa.
Tapi server IP-nya bukan 192.168.141.x — beda subnet, beda “kompleks”. Supaya bisa nyampe ke PLC, paket data dari server harus lewat sebuah router/gateway dulu. Masalahnya, PLC-nya sendiri nggak tahu harus lewat mana kalau ada yang minta balasan ke luar dari kompleks 192.168.141.x. Jadi walau paket permintaan dari server sampai ke PLC, balasannya dari PLC nyasar, nggak tahu jalan pulang — ping gagal.
Fungsi IP Router Table
Nah, di situlah gunanya IP Router Table. Ini semacam “peta jalan” buat si PLC: “Kalau ada paket yang tujuannya bukan ke jaringan lokal saya, kirim/lempar aja ke alamat gateway ini.”
Baris yang aku isi:
- IP Address:
000.000.000.000 - Router’s IP Address:
192.168.141.230
Ini artinya:
000.000.000.000= kolom Network Address (tujuan) →0.0.0.0berarti default route, alias semua tujuan yang tidak dikenal192.168.141.230= kolom Gateway/Relay IP → alamat router yang jadi “pintu keluar” dari jaringan192.168.141.xmenuju jaringan lain, termasuk jaringan tempat server berada
Jadi setelah aku isi ini, PLC jadi tahu: “Oh, kalau ada balasan/paket yang tujuannya bukan ke 192.168.141.x, kirim lewat gateway 192.168.141.230 itu” — gateway itu yang lanjut meneruskan ke jaringan server. Makanya server jadi bisa ping PLC.
Analoginya, PLC itu ibarat rumah di komplek 192.168.141.x. Tamu dari komplek yang sama bisa langsung masuk lewat gang komplek. Tapi tamu dari kota lain (server) harus lewat gerbang tol atau pos satpam komplek dulu, si gateway 192.168.141.230 itu. Sebelum aku isi router table, rumah itu belum tahu ada pos satpam itu, jadi surat balasannya nggak pernah nyampe ke tamu dari luar kota.
Final Trial
Setelah itu, aku coba real dengan server, dan ku suruh temanku buat mengoperasikannya, sembari testing apakah ada masalah. Soalnya kalau aku sendiri yang ngetes, aku cenderung hati-hati, jadi cenderung nggak ketemu kondisi abnormal yang biasanya justru muncul pas dipakai orang lain dengan gayanya sendiri.
Hasilnya cukup memuaskan. Walaupun begitu, konek dengan device asli baru kelihatan beberapa bug yang nggak muncul pas testing pakai simulator. Salah satunya, waktu timbang udah dinyatakan stabil dan hasilnya udah di-print, tapi display di layar masih gerak-gerak, dan ini bikin bingung operator di lapangan — padahal sebenarnya ini normal, karena beban cuma disimpan ketika timbangan lagi stabil, bukan berarti display-nya ikutan berhenti nampilin angka realtime.
Buat akalin hal ini, caranya cukup simpel: selama beban belum diangkat, alias sistem masih mendeteksi berat 0 kg, tampilan angka di display di-freeze. Dengan begitu, angka yang keliatan di layar sama laporan dan print out jadi konsisten, dan operator nggak bingung lagi ngeliat angka yang keliatan “hidup sendiri” padahal hasil timbangnya udah final.
Dari sini, project Finish Good Weighing ini akhirnya bisa dibilang selesai dari sisi teknis lapangan — mulai dari simulator yang dibikin karena PLC belum ada, salah kabel TX/RX yang bikin panik pas trial pertama, sampai urusan subnet yang ternyata jadi penentu apakah server bisa “ngobrol” sama PLC atau nggak. Semua kendala itu kelihatan sepele kalau ditulis ulang begini, tapi pas dihadapin langsung di lapangan, satu per satu bikin deg-degan tersendiri.
📌 NoteAlasan kenapa aku mau ngulik bagian PLC ini sampai sedetail itu, padahal PLC-nya sendiri dikerjain sama vendor, Ya karena aku nggak mau berburuk sangka ke vendor, tapi aku punya prinsip sendiri soal ini.— Komunikasi adalah KOENCI 🗝️
Kalau sesuatu itu dikerjakan orang lain, maka aku harus memastikan data yang aku minta itu benar-benar diberikan, dan aku bisa lihat sendiri dari programnya. Biar nggak terjadi saling menyalahkan yang nggak jelas ujungnya, yang akhirnya cuma berimbas ke project yang nggak kelar-kelar.
Sebaliknya, kalau aku yang bertindak sebagai vendor, maka aku juga harus memberikan setidaknya akses buat mereka bisa lihat nilai yang mereka minta, demi kelancaran berjalannya project itu sendiri.
Sampai jumpa di cerita project berikutnya!
