Akhirnya kami berurusan dengan baud rate Modbus

Kecepatan refresh data modbus tergantung pada beberapa parameter yang tidak jelas. Pada tahap desain, muncul masalah bagaimana mengevaluasi kecepatan garis antarmuka masa depan. Pada artikel ini, kami mempertimbangkan faktor-faktor yang mempengaruhi kecepatan memperbarui data pada Modbus RTU, membuat beberapa perhitungan standar, dan pada akhir artikel akan ada tautan ke kalkulator web dari kecepatan garis Modbus RTU.

Modbus masih merupakan protokol komunikasi yang paling banyak digunakan untuk peralatan industri. Deskripsi protokol dan alasan prevalensinya dapat ditemukan di banyak artikel, misalnya di sini . Lebih lanjut dipahami bahwa Anda terbiasa dengan dasar-dasar cara kerja protokol.

Kami akan mempertimbangkan Modbus RTU, tetapi sebagian temuan akan berlaku untuk Modbus TCP.

Untuk menghitung kecepatan, kita mulai dengan mempertimbangkan protokol fisik (level 1 dari model OSI). Modbus RTU menggunakan antarmuka fisik RS-485, RS-422 atau RS-232 (yang terakhir praktis tidak digunakan untuk Modbus). Untuk transmisi sinyal, antarmuka ini menggunakan UART (Universal Asynchronous Receiver-Transmitter). Anda dapat membaca lebih lanjut tentang UART di sini .

Paket UART standar terdiri dari:

1. mulai bit ($$$start\_bit$) 1 bit
2. data yang berguna ($$$data$) 7-8 bit
3. bit paritas ($$$parity\_bit$) 0-1 bit
4. stop bit ($$$stop\_bit$) 1-2 bit

Yaitu, untuk setiap 7-8 bit data berguna, 2-4 bit tambahan ditransmisikan. Tingkat Muatan ($$$V_{data}$) akan lebih rendah dari kecepatan antarmuka ($$$V_{uart}$) Menghitung$$$V_{data}$ bisa sesuai dengan rumus:

$$

$$V_{data} = \frac{V_{uart} * data}{start\_bit + data + parity\_bit + stop\_bit}$$

Selanjutnya, Anda perlu memahami bagaimana master Modbus berkomunikasi dengan budak di lapisan data link (model OSI level 2). Karena kekhasan antarmuka fisik perangkat, terhubung ke jalur mentransmisikan data secara berurutan, yaitu, hanya satu perangkat pada waktu tertentu yang dapat mengirim data. Karena itu, penyihir berkomunikasi dengan budak secara siklis, secara berurutan membaca dan menulis register ke budak. Daftar lengkap register baca dari budak akan terlihat seperti ini:

1. keterlambatan (minimal 3,5 karakter = 28 bit, hitung di bawah dalam detik)
2. baca permintaan transmisi (8 byte)
3. keterlambatan dalam respons perangkat budak (setidaknya 28 bit, seringkali puluhan milidetik untuk membentuk pesan respons)
4. transmisi slave dari pesan respons (maksimum 256 byte untuk Modbus RTU).

Beberapa insinyur memilih versi empat-kawat dari antarmuka, berharap untuk transmisi yang lebih cepat (menyiratkan transfer data paralel untuk menerima dan mengirimkan). Jelas solusi ini tidak berfungsi. Urutan pengiriman data akan sama untuk jalur kabel 2x dan 4x.

Kami menghitung waktu yang dihabiskan pada siklus pembacaan penuh dari 125 register penampung (jumlah maksimum untuk Modbus RTU) dengan parameter garis berikut:

Format bingkai: 8N1 ​​(8 bit data, tanpa bit paritas, bit 1 stop)
Kecepatan uart:$$$V_{uart}$= 19200 bit / s
Payload rate transfer:$$$V_{data}$= 15360 bit / s
Master Delay:$$$master\_silence$ = 28 bit / $$$V_{uart}$(ini adalah keterlambatan minimum yang diijinkan, biasanya lebih)
Penundaan respons budak:$$$slave\_silence$= 0,04 s (nilainya tergantung pada perangkat slave)
Mengirim permintaan dengan 125 register holding: 8 byte atau 64 bit
Jawaban dengan 125 register register: 256 byte atau 2048 bit

Formula untuk menghitung waktu siklus baca:

$$

$$T_{cycle} = silence\_master + 64 bit / V_{data} + slave\_silence + 2048 bit / V_{data} = 0.179 s$$

Urutan untuk register penulisan hampir identik. Ukuran paket master akan lebih besar, Termasuk informasi tentang register yang dapat ditulis. Konfirmasi rekaman yang sukses dari slave akan menjadi 8 byte.

Menurut spesifikasi Modbus, 32 budak dapat dihubungkan ke saluran RS-485/422. Interogasi budak juga dilakukan secara berurutan, biasanya dalam lingkaran. Untuk memahami seberapa cepat data akan diperbarui$$$N$ budak perlu berkembang biak $$$T_{cycle}$di $$$N$Sebut saja waktu pembaruan penuh. $$$T_{full}$.
Beberapa perhitungan$$$T_{full}$(baca dan tulis jumlah maksimum holding register) untuk berbagai parameter komunikasi:
Format bingkai: 8N1,$$$V_{uart}$ = 19200 bit / s, Jumlah budak, $$$N$= 16
$$$T_{full}$= 5.727 s
Format bingkai: 8N1,$$$V_{uart}$ = 9600 bit / s, Jumlah budak, $$$N$= 16
$$$T_{full}$= 10,173 s
Format bingkai: 7E1,$$$V_{uart}$ = 19200 bit / s, Jumlah budak, $$$N$= 16
$$$T_{full}$= 6.355 s
Format bingkai: 8N1,$$$V_{uart}$ = 19200 bit / s, Jumlah budak, $$$N$= 2
$$$T_{full}$= 0,716 s

Seperti yang Anda lihat, format frame memengaruhi waktu pembaruan data, tetapi tidak banyak. Kecepatan transfer data secara signifikan mempengaruhi, tetapi dalam contoh kami kami mentransfer jumlah maksimum register, dalam proyek nyata faktor ini mungkin tidak begitu signifikan. Yang terpenting, jumlah budak mempengaruhi kecepatan refresh data.

Untuk menyederhanakan perhitungan, kami membuat aplikasi web untuk memperkirakan waktu untuk memperbarui data melalui Modbus