Troubleshooting Modbus RTU: 8 Pemeriksaan Jaringan Sensor

Troubleshooting Modbus RTU paling efektif dilakukan berurutan: pastikan perangkat mendapat power, periksa jalur RS-485, samakan parameter serial, lalu validasi alamat dan permintaan register. Urutan ini mencegah tim mengganti sensor, menambah terminator, atau membalik kabel tanpa bukti yang cukup.

Gejala komunikasi juga perlu dibedakan. Timeout berarti client tidak menerima jawaban yang dapat digunakan. CRC atau parity error menunjukkan frame diterima tetapi rusak atau tidak sesuai. Sementara itu, exception response berarti perangkat sempat memahami frame Modbus, tetapi menolak atau gagal memproses permintaan tertentu.

Konteks sistem tetap penting. Halaman Datalogger GEOVOS 1000 mencantumkan dukungan RS485, sedangkan halaman Sensor Turbidity mencantumkan komunikasi RS485 Modbus. Informasi tersebut menunjukkan titik integrasi yang relevan, tetapi tidak menggantikan manual serial dan register map model yang benar-benar dipasang.

Troubleshooting Modbus RTU dimulai dari gejala

MODBUS over Serial Line Specification and Implementation Guide V1.02 menjelaskan bahwa frame RTU membawa address, function code, data, dan CRC. Client mengirim permintaan, lalu menunggu jawaban dari perangkat dengan alamat yang dituju. Karena itu, jenis respons dapat membantu mempersempit lapisan yang harus diperiksa.

Gejala	Arti awal	Pemeriksaan pertama
Tidak ada respons atau timeout	Tidak ada frame jawaban yang valid sebelum batas waktu	Power, port, mode RTU, baud rate, parity, alamat, dan jalur kabel
CRC atau parity error	Ada data masuk, tetapi pemeriksaan frame gagal	Parameter serial, noise, sambungan, topology, grounding, dan timing
Exception 01, 02, 03, atau 04	Perangkat merespons, tetapi permintaan tidak dapat dijalankan	Function code, register, jumlah data, nilai permintaan, dan kondisi perangkat
Nilai terbaca tetapi tidak masuk akal	Komunikasi mungkin berjalan, tetapi data diterjemahkan salah	Offset, tipe data, signedness, skala, byte order, dan word order
Satu perangkat berjalan, jaringan gagal	Masalah muncul setelah beberapa node terhubung	Alamat ganda, trunk dan stub, termination, polarization, beban bus, dan timeout

Tabel tersebut adalah titik awal, bukan diagnosis akhir. Satu gejala dapat memiliki beberapa penyebab. Yang penting adalah mengubah satu variabel pada satu waktu dan mencatat hasilnya.

Delapan pemeriksaan sebelum mengganti perangkat

1. Pastikan power dan port fisik benar

Mulai dari hal yang dapat dibuktikan. Periksa tegangan di terminal perangkat sesuai manual, status indikator, fuse atau proteksi, serta port yang dipakai oleh client. Pastikan software atau datalogger benar-benar membuka port RS-485 yang terhubung ke jaringan, bukan port lain dengan konfigurasi lama.

Jangan menyimpulkan sensor rusak hanya karena tidak merespons. Perangkat yang restart berulang, catu daya turun saat beban aktif, atau converter yang tidak mendapat power dapat terlihat seperti masalah protokol.

2. Cocokkan konduktor dengan dokumentasi perangkat

Periksa D0/D1, A/B, common, shield, dan konektor berdasarkan manual kedua sisi. Label A dan B tidak selalu digunakan dengan konvensi yang sama oleh setiap vendor, sehingga membalik pasangan hanya boleh dilakukan sebagai uji terkontrol setelah dokumentasi dan kondisi awal dicatat.

Periksa juga terminal longgar, sambungan bercabang yang tidak direncanakan, pasangan kabel yang tidak lagi terpilin, serta shield atau common yang dipasang berbeda dari desain. Jangan mengubah grounding pada sistem aktif tanpa penilaian teknisi yang kompeten.

3. Samakan mode dan parameter serial

Client dan seluruh perangkat pada satu segmen harus menggunakan konfigurasi yang kompatibel: RTU atau ASCII, baud rate, jumlah data bit, parity, dan stop bit. Pada RTU, spesifikasi serial juga menggunakan interval waktu untuk mengenali batas frame. Parameter yang berbeda dapat menghasilkan timeout, parity error, atau frame yang tidak pernah dianggap lengkap.

Salin nilai dari manual dan konfigurasi aktual, bukan dari ingatan. Jika converter USB-RS485 digunakan untuk pengujian, pastikan software test tidak mengambil alih port yang sedang dipakai aplikasi lain.

4. Pastikan setiap unit address unik

Panduan serial Modbus menetapkan alamat individual 1 sampai 247 dan alamat 0 untuk broadcast. Dua perangkat dengan unit address yang sama dapat merespons pada saat bersamaan atau membuat perilaku bus tidak dapat diprediksi.

Uji satu perangkat terlebih dahulu, catat alamatnya, lalu tambahkan node berikutnya secara bertahap. Jangan menganggap jumlah alamat logis tersebut sebagai jumlah perangkat fisik yang aman untuk satu segmen; kemampuan bus juga dipengaruhi transceiver, cable load, topology, dan repeater.

5. Periksa trunk, derivation, termination, dan polarization

Panduan resmi menggambarkan satu trunk dengan perangkat yang tersambung secara daisy-chain atau melalui derivation pendek. Line termination ditempatkan pada kedua ujung trunk untuk penyesuaian impedansi. Menambahkan terminator di setiap node justru dapat membebani jaringan.

Beberapa perangkat atau client menyediakan line polarization atau bias. Jika dibutuhkan, panduan menempatkannya pada satu lokasi untuk seluruh bus. Periksa dokumentasi sebelum menambah resistor karena gateway atau datalogger mungkin sudah menyediakannya.

6. Verifikasi function code dan register address

MODBUS Application Protocol Specification V1.1b3 membedakan coils, discrete inputs, input registers, dan holding registers melalui function code. Register yang benar tetapi dibaca dengan function code yang salah dapat menghasilkan exception 01 atau 02.

Perhatikan juga offset. Alamat pada Protocol Data Unit dimulai dari nol, sedangkan manual atau software dapat menampilkan referensi seperti 40001 atau menggunakan basis satu. Jika perangkat menjawab Illegal Data Address, cocokkan function code, starting address, dan jumlah register dengan contoh permintaan pada manual perangkat.

7. Terjemahkan data sesuai register map

Respons yang valid belum tentu menjadi nilai engineering yang benar. Konfirmasikan apakah register berisi integer bertanda, integer tanpa tanda, floating point, status bit, atau bagian dari nilai 32-bit. Terapkan skala dan satuan yang dinyatakan produsen.

Untuk nilai yang menggunakan lebih dari satu register, periksa byte order dan word order pada manual. Modbus mendefinisikan register 16-bit, tetapi cara vendor menyusun nilai yang lebih panjang harus diverifikasi pada perangkat tersebut.

8. Simpan bukti request dan response

Catat timestamp, unit address, baud dan parity, function code, starting address, quantity, data mentah, exception code, timeout, serta penghitung CRC bila tersedia. Bukti ini lebih berguna daripada laporan singkat seperti “sensor offline”.

Saat isolasi diperlukan, uji satu client dan satu perangkat dengan kabel pendek yang diketahui baik, lalu bangun kembali jaringan secara bertahap. Jangan sekaligus mengubah alamat, wiring, timeout, dan register map karena hasilnya tidak akan menunjukkan perubahan mana yang menyelesaikan masalah.

Hubungkan diagnosis dengan keseluruhan sistem monitoring

Komunikasi serial hanyalah satu lapisan. Setelah register terbaca, datalogger atau PLC masih harus menerapkan skala, timestamp, quality flag, interval polling, penyimpanan, alarm, dan pengiriman ke dashboard. Nilai yang benar di software test belum membuktikan seluruh rantai monitoring sudah dikonfigurasi dengan benar.

Jika tim masih menentukan jenis output sensor, panduan 4-20 mA atau RS485 membantu menilai antarmuka sebelum integrasi. Untuk pemahaman dasar protokol, lihat juga alasan banyak sensor menggunakan RS485 Modbus.

Fortuna Argatech dapat membantu meninjau pembagian perangkat, port client, serial settings, register map, datalogger, dan alur data sampai dashboard sebagai satu konfigurasi. Saat menghubungi tim Fortuna Argatech, sertakan model perangkat, diagram wiring, parameter serial, unit address, request register, serta log respons atau timeout agar pemeriksaan dapat dimulai dari bukti yang sama.

Sumber teknis

• MODBUS over Serial Line Specification and Implementation Guide V1.02, Modbus.org, 20 Desember 2006.
• MODBUS Application Protocol Specification V1.1b3, Modbus Organization, 26 April 2012.