MODBUS'a Hızlı Bir Giriş

Bir enerji analizörünün kılavuzunu açıyorsunuz, karşınıza "Fonksiyon kodu: 03" yazan bir tablo çıkıyor. Yandaki inverterin kılavuzunda ise "Sadece 04 destekler" yazıyor. Peki bu numaralar da ne? 🤔 Bu yazıda MODBUS'un tüm fonksiyon kodlarını tek tek, örnek çerçeveleriyle ve sahada başınıza gelebilecek tuzaklarıyla birlikte ele alıyoruz.

Bu yazıda neler var

• MODBUS'a hızlı bir giriş
• Fonksiyon kodu tam olarak nedir?
• Dört tip veri: coil, discrete input, register
• 📋 Tam MODBUS fonksiyon listesi
• Bit tabanlı fonksiyonlar (01, 02, 05, 0F)
• Register fonksiyonları (03, 04, 06, 10, 16, 17, 18)
• Tanılama ve cihaz bilgisi (07, 08, 0B, 0C, 11, 2B)
• Dosya kaydı fonksiyonları (14, 15)
• Hata (exception) kodları
• Kod aralıkları: public, user-defined, reserved
• Limitler ve seri hat / TCP farkı
• Sahadan pratik ipuçları
• Sık sorulan sorular

MODBUS'a hızlı bir giriş 🔌

MODBUS, 1979 yılında Modicon tarafından PLC'ler için tasarlanmış bir haberleşme protokolü. Yani sizden, benden, muhtemelen bu yazıyı okuyan çoğu mühendisten daha yaşlı. Buna rağmen hâlâ her yerde: enerji analizörlerinde, ısı kontrolörlerinde, inverterlerde, debimetrelerde, güneş invertörlerinde, jeneratör kontrol kartlarında...

Bu kadar uzun yaşamasının sebebi çok basit: protokol gerçekten sade ve açık. Telif ücreti yok, lisans yok, karmaşık bir yığın yok. Bir tarafta soru soran (client / master), diğer tarafta cevap veren (server / slave) var. Master sorar, slave cevaplar. Slave asla kendiliğinden konuşmaz — bu detay ilerideki birçok tasarım kararını açıklıyor.

Üç yaygın taşıma katmanı var:

• MODBUS RTU — Seri hat üzerinden (genelde RS-485), veriler ikili (binary) formatta. En yaygın kullanım.
• MODBUS ASCII — Yine seri hat, ama veriler okunabilir ASCII karakterler olarak. Bugün nadir.
• MODBUS TCP — Ethernet üzerinden, 502 numaralı port. (TLS'li güvenli sürümü ise 802 portunu kullanır.)

Taşıma katmanı değişse de fonksiyon kodları aynı kalır. Yani bu yazıda öğrendikleriniz hem RS-485 hattındaki bir sayaçta hem de Ethernet'teki bir gateway'de geçerli olacak. 👌

Fonksiyon kodu tam olarak nedir?

Fonksiyon kodu, mesajın içindeki tek bir bayttır ve "ne yapmak istiyorum?" sorusunun cevabıdır. Okumak mı istiyorum, yazmak mı? Bit mi okuyacağım, register mı? Cihazın kimliğini mi soracağım?

Bir MODBUS RTU çerçevesinin anatomisi şöyle görünür:

┌──────────┬──────────┬─────────────────────┬──────────┐
│ Adres    │ Fonksiyon│ Veri                │ CRC      │
│ 1 bayt   │ 1 bayt   │ 0 – 252 bayt        │ 2 bayt   │
└──────────┴──────────┴─────────────────────┴──────────┘
     ▲          ▲               ▲                 ▲
     │          │               │                 └─ Hata kontrolü
     │          │               └─ Adres, adet, değerler...
     │          └─ NE yapılacak  (bizim konumuz!)
     └─ KİM yapacak (1–247, 0 = broadcast)

Gerçek örnek:   11 03 00 6B 00 03 76 87
                ▲  ▲  └───┘ └───┘ └───┘
                │  │    │     │     └─ CRC
                │  │    │     └─ 3 adet register oku
                │  │    └─ Başlangıç adresi 0x006B (107)
                │  └─ Fonksiyon 0x03 = Read Holding Registers
                └─ 17 numaralı cihaza soruyorum

MODBUS TCP'de ise adres ve CRC yerine 7 baytlık bir MBAP başlığı gelir; ortadaki "fonksiyon + veri" kısmı (buna PDU deniyor) bire bir aynı kalır:

MODBUS TCP:  00 01 00 00 00 06 11 03 00 6B 00 03
             └─────── MBAP (7 bayt) ──────┘└─ PDU ─┘
             │     │     │     │
             │     │     │     └─ Unit ID (11)
             │     │     └─ Uzunluk
             │     └─ Protokol ID (her zaman 0000)
             └─ İşlem (transaction) ID — cevabı eşleştirmek için

💡 Aklınızda kalsın: RTU'da 0x11 ilk bayttaysa "17 numaralı cihaz", ikinci bayttaysa "Report Server ID fonksiyonu" demektir. Aynı hex değeri, konuma göre bambaşka anlam taşır. Çerçeve okurken en sık yapılan karışıklıklardan biri budur.

Fonksiyonlardan önce: dört tip veri

Fonksiyon kodlarının neden bu kadar çok olduğunu anlamak için önce MODBUS'un veri modelini bilmek gerekiyor. Protokol her şeyi dört kutuya ayırır:

Veri tipi	Boyut	Erişim	Klasik adres	Tipik örnek
Coil (Bobin)	1 bit	Oku / Yaz	0xxxx	Röle çıkışı, start/stop komutu
Discrete Input (Ayrık giriş)	1 bit	Salt okunur	1xxxx	Limit switch, kapı sensörü
Input Register (Giriş register'ı)	16 bit	Salt okunur	3xxxx	Ölçülen sıcaklık, akım değeri
Holding Register (Tutma register'ı)	16 bit	Oku / Yaz	4xxxx	Set değeri, PID parametresi, frekans referansı

Mantık şu: bir şey bit mi yoksa sayı mı, ve onu yazabiliyor musunuz yoksa sadece okuyabiliyor musunuz? Bu iki soru 2 × 2 = 4 kutu yapıyor ve fonksiyon kodlarının büyük kısmı bu kutulara okuma/yazma yapmaktan ibaret. 😊

📋 Tam MODBUS Fonksiyon Listesi

İşte MODBUS Application Protocol Specification V1.1b3'te tanımlı tüm public (standart) fonksiyon kodları. Toplamda 19 tane; standartta bunların dışında tanımlı bir fonksiyon yok.

Hex	Dec	İsim	Ne yapar?	Not
0x01	1	Read Coils	Yazılabilir bitleri okur	Yaygın
0x02	2	Read Discrete Inputs	Salt okunur bitleri okur	Yaygın
0x03	3	Read Holding Registers	Yazılabilir register'ları okur	Yaygın
0x04	4	Read Input Registers	Salt okunur register'ları okur	Yaygın
0x05	5	Write Single Coil	Tek bir biti 1 veya 0 yapar	Yaygın
0x06	6	Write Single Register	Tek bir register'a değer yazar	Yaygın
0x07	7	Read Exception Status	8 bitlik özel durum baytını okur	Seri hat
0x08	8	Diagnostics	Alt fonksiyonlarla hat tanılaması yapar	Seri hat
0x0B	11	Get Comm Event Counter	Haberleşme olay sayacını okur	Seri hat
0x0C	12	Get Comm Event Log	Olay günlüğünü okur	Seri hat
0x0F	15	Write Multiple Coils	Birden çok biti tek seferde yazar	Yaygın
0x10	16	Write Multiple Registers	Birden çok register'ı tek seferde yazar	Yaygın
0x11	17	Report Server ID	Cihazın kimliğini ve çalışma durumunu sorar	Seri hat
0x14	20	Read File Record	Dosya kaydı okur	Nadir
0x15	21	Write File Record	Dosya kaydı yazar	Nadir
0x16	22	Mask Write Register	Maske ile tek bit düzeyinde yazar	Nadir
0x17	23	Read/Write Multiple Registers	Tek işlemde hem okur hem yazar	Nadir
0x18	24	Read FIFO Queue	FIFO kuyruğundaki verileri okur	Nadir
0x2B	43	Encapsulated Interface Transport	MEI kapsülleme (cihaz kimliği, CANopen)	Nadir

Gerçek hayat notu 🔧 Bu 19 fonksiyondan sahada karşılaşacağınızın %95'i şu sekiz tanedir: 01, 02, 03, 04, 05, 06, 0F, 10. Geri kalanı çoğu ticari cihazda desteklenmez; sorduğunuzda size nazikçe "Illegal Function" hatası döner.

Bit tabanlı fonksiyonlar: 01, 02, 05, 0F

0x01 — Read Coils (Bobinleri Oku)

Yazılabilir bitleri okur. Cevapta bitler paketlenmiş gelir: her bayt 8 bit taşır ve en düşük anlamlı bit (LSB) ilk coil'e denk gelir. Bu ters sıralama ilk defa gören herkesi şaşırtır. 😅

İstek:  11 01 00 13 00 25 0E 84
        └ 17 nolu cihaz, 19. adresten başla, 37 coil oku

Cevap:  11 01 05 CD 6B B2 0E 1B 45 E6
              └ 5 bayt veri geliyor

İlk bayt CD = 1100 1101 (binary)
                       ▲
                       └ Bu bit ilk coil (adres 19)

Sıra:  coil19=1, 20=0, 21=1, 22=1, 23=0, 24=0, 25=1, 26=1

0x02 — Read Discrete Inputs (Ayrık Girişleri Oku)

0x01 ile bire bir aynı mantık, tek farkı salt okunur bitlere erişmesi. Bir sensörün durumunu okuyorsanız muhtemelen bu fonksiyonu kullanıyorsunuzdur.

İstek:  11 02 00 C4 00 16 BA A9
        └ 196. adresten başla, 22 giriş oku

Cevap:  11 02 03 AC DB 35 20 18

0x05 — Write Single Coil (Tek Bobin Yaz)

Burada sevimli bir tuhaflık var: değer alanı 1 bit değil, 2 bayt. Ve sadece iki geçerli değer kabul eder — 0xFF00 = AÇ, 0x0000 = KAPAT. Neden 0x0001 değil? 1979'dan kalma bir tasarım tercihi diyelim. 🙂

İstek:  11 05 00 AC FF 00 4E 8B
        └ 172. coil'i AÇ

Cevap:  isteğin aynısı geri döner (echo)

0x0F — Write Multiple Coils (Çoklu Bobin Yaz)

Tek seferde 1968 coil'e kadar yazabilirsiniz. Veri yine paketlenmiş bit halinde gider. Cevap ise sadece "şu adresten şu kadarını yazdım" özetidir — verinin tamamını geri döndürmez.

İstek:  11 0F 00 13 00 0A 02 CD 01 BF 0B
        └ 19. adresten başla, 10 coil yaz, 2 bayt veri: CD 01

Cevap:  11 0F 00 13 00 0A 26 99

Register fonksiyonları: 03, 04, 06, 10, 16, 17, 18

0x03 — Read Holding Registers (Tutma Register'larını Oku)

Bu, MODBUS dünyasının en çok kullanılan fonksiyonu. 🏆 Bir enerji analizöründen gerilim okumak, bir inverterden çalışma frekansını almak, bir kontrolörden set değerini öğrenmek — hepsi bu fonksiyonla.

İstek:  11 03 00 6B 00 03 76 87
        └ 107. adresten başla, 3 register oku

Cevap:  11 03 06 02 2B 00 00 00 64 C8 BA
              │  └─┬─┘ └─┬─┘ └─┬─┘
              │    │     │     └─ Register 109 = 0x0064 = 100
              │    │     └─ Register 108 = 0x0000 = 0
              │    └─ Register 107 = 0x022B = 555
              └─ 6 bayt (3 register × 2 bayt)

0x04 — Read Input Registers (Giriş Register'larını Oku)

0x03 ile teknik olarak neredeyse aynı; fark, salt okunur register'lara erişmesi. Bazı üreticiler ölçüm değerlerini 0x04'e, ayarları 0x03'e koyar. Bazıları ise her şeyi 0x03'e yığar ve 0x04'ü hiç desteklemez. Kılavuz okumaktan kaçış yok. 📖

0x06 — Write Single Register (Tek Register Yaz)

Tek bir 16 bit değeri yazar. Basit, hızlı, cevabı isteğin kopyasıdır.

İstek:  11 06 00 01 00 03 9A 9B
        └ 1. register'a 3 değerini yaz

Cevap:  11 06 00 01 00 03 9A 9B  (echo)

0x10 — Write Multiple Registers (Çoklu Register Yaz)

Tek seferde 123 register'a kadar yazar. 32 bitlik bir değeri (float, uzun tamsayı) yazacaksanız bu fonksiyonu kullanmanız zorunlu sayılır — çünkü iki register'ı 0x06 ile ayrı ayrı yazarsanız cihaz arada yarım değeri işleme alabilir.

İstek:  11 10 00 01 00 02 04 00 0A 01 02 C6 F0
        │        │     │     │  └───┬───┘
        │        │     │     │      └─ Veri: 0x000A ve 0x0102
        │        │     │     └─ 4 bayt veri
        │        │     └─ 2 register yazılacak
        │        └─ 1. adresten başla
        └ Fonksiyon 0x10

Cevap:  11 10 00 01 00 02 12 98

0x16 — Mask Write Register (Maskeli Register Yazma)

Bir register'ın tamamını değil, sadece belirli bitlerini değiştirmek istediğinizde işe yarar. Klasik "oku–değiştir–yaz" döngüsünü tek işleme indirger, böylece arada başka biri araya girip register'ı bozamaz.

Formül:  Sonuç = (Mevcut AND And_Mask) OR (Or_Mask AND (NOT And_Mask))

İstek:  11 16 00 04 00 F2 00 25 66 E2
        │        │     │     └─ Or_Mask  = 0x0025
        │        │     └─ And_Mask = 0x00F2
        │        └─ Register adresi 4
        └ Fonksiyon 0x16

0x17 — Read/Write Multiple Registers (Oku ve Yaz)

Tek mesajda önce yazma, sonra okuma yapar. Hat trafiğini yarıya indirdiği için hızlı döngü gerektiren uygulamalarda değerlidir. Ancak destekleyen cihaz sayısı sınırlıdır.

İstek:  11 17 00 03 00 06 00 0E 00 03 06 00 FF 00 FF 00 FF 4B 54
        │     └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ │  └──────┬──────┘
        │     Oku adres  Oku adet Yaz adres Yaz adet Bayt  Yazılacak veri
        └ Fonksiyon 0x17

0x18 — Read FIFO Queue (FIFO Kuyruğunu Oku)

Cihazın içindeki sıra tipi bir tampondan (kuyruk) veri çeker. En fazla 31 register döndürebilir. Alarm geçmişi ya da olay kuyruğu tutan özel cihazlarda karşınıza çıkabilir; genel amaçlı cihazlarda neredeyse hiç yok.

Tanılama ve cihaz bilgisi: 07, 08, 0B, 0C, 11, 2B

Bu grup "veri okuma" değil, "cihazla ilgili bilgi alma" işi görür. Büyük kısmı yalnızca seri hat (RTU/ASCII) için tanımlıdır ve MODBUS TCP'de standart değildir.

0x07 — Read Exception Status

Cihazın 8 bitlik özel durum baytını okur. Bu 8 bitin ne anlama geldiği tamamen üreticiye bağlıdır — biri "aşırı sıcaklık" der, diğeri "kalibrasyon gerekli" der. Çok kısa bir mesaj olduğu için hızlı durum sorgulamada tercih edilirdi.

0x08 — Diagnostics

Aslında tek bir fonksiyon değil, bir avuç alt fonksiyonun şemsiyesi. Fonksiyon kodundan hemen sonra 2 baytlık bir alt fonksiyon numarası gelir:

Alt fonk.	Dec	İşlev
0x00	0	Return Query Data — gönderdiğinizi aynen geri yollar (echo testi)
0x01	1	Restart Communications Option — haberleşme portunu yeniden başlatır
0x02	2	Return Diagnostic Register — tanılama register'ını döndürür
0x03	3	Change ASCII Input Delimiter — ASCII ayırıcı karakteri değiştirir
0x04	4	Force Listen Only Mode — cihazı sadece dinleme moduna alır
0x0A	10	Clear Counters and Diagnostic Register — sayaçları sıfırlar
0x0B	11	Return Bus Message Count — hattaki toplam mesaj sayısı
0x0C	12	Return Bus Communication Error Count — CRC hatası sayısı
0x0D	13	Return Bus Exception Error Count — exception cevap sayısı
0x0E	14	Return Server Message Count — cihaza gelen mesaj sayısı
0x0F	15	Return Server No Response Count — cevapsız kalan mesaj sayısı
0x10	16	Return Server NAK Count
0x11	17	Return Server Busy Count
0x12	18	Return Bus Character Overrun Count — taşma hatası sayısı
0x14	20	Clear Overrun Counter and Flag

Özellikle 0x0C (CRC hata sayacı) çok değerlidir: RS-485 hattınızda gürültü olup olmadığını anlamanın en dolaysız yoludur. Sayaç sürekli artıyorsa kablolamaya, sonlandırma direncine ve topraklamaya bakma vaktidir. ⚡

0x0B ve 0x0C — Comm Event Counter / Event Log

Cihazın kaç başarılı işlem yaptığını ve son olayların günlüğünü verir. Event log en fazla 64 olay taşır. Bugün pek kullanılmıyor, ama eski Modicon sistemlerinde hat sağlığını izlemenin standart yoluydu.

0x11 — Report Server ID

"Sen kimsin?" sorusunun MODBUS'çası. Cevap şu alanları içerir:

Alan	Açıklama
Byte Count	Takip eden veri uzunluğu
Server ID	Üreticiye özel cihaz kimliği (standart değil!)
Run Indicator	0x00 = durmuş, 0xFF = çalışıyor
Ek veri	Firmware sürümü, model adı vb. — tamamen üreticinin keyfine kalmış

İstek:  11 11 CD EC     ← veri alanı boş, sadece soruyoruz

0x2B — Encapsulated Interface Transport (MEI)

Bu fonksiyon bir "zarf" gibi çalışır: içine başka bir protokolün mesajını koyar. İki alt tipi var:

• 0x0D — CANopen General Reference
• 0x0E — Read Device Identification (asıl işe yarayan)

0x2B/0x0E, cihazdan yapılandırılmış metin bilgileri çeker. 0x11'in aksine bu alanlar standarttır:

Nesne ID	İsim	Seviye
0x00	VendorName — üretici adı	Basic (zorunlu)
0x01	ProductCode — ürün kodu	Basic (zorunlu)
0x02	MajorMinorRevision — sürüm	Basic (zorunlu)
0x03	VendorUrl — üretici web adresi	Regular
0x04	ProductName — ürün adı	Regular
0x05	ModelName — model adı	Regular
0x06	UserApplicationName — uygulama adı	Regular
0x80–0xFF	Üreticiye özel alanlar	Extended

Dosya kaydı fonksiyonları: 14 ve 15

MODBUS'un en az bilinen köşesi. 0x14 (Read File Record) ve 0x15 (Write File Record), cihazın içindeki "dosya" benzeri yapılara erişir. Burada dosya, 16 bitlik kayıtlardan oluşan bir bloktur; klasik adreslemede 6xxxxx aralığına denk gelir.

• Dosya numarası: 0x0001 – 0xFFFF
• Kayıt numarası: 0 – 9999
• Tek mesajda birden fazla alt-istek gönderilebilir

Pratikte veri kaydediciler (data logger), trend kaydı tutan cihazlar ve bazı akış bilgisayarları kullanır. Standart bir sensörde göremezsiniz.

İşler ters gittiğinde: Exception kodları ⚠️

Cihaz isteğinizi yerine getiremezse sessiz kalmaz — size bir hata cevabı döner. Bunu anlamanın yolu çok zarif: cevaptaki fonksiyon koduna 0x80 eklenir.

İstek:   11 03 00 6B 00 03 76 87    ← 0x03 ile okuma denemesi
Hata:    11 83 02 C1 34             ← 0x03 + 0x80 = 0x83
            │  └─ Exception kodu 02 = Illegal Data Address
            └─ "Bu bir hata cevabı" işareti

Kod	İsim	Türkçesi ve tipik sebebi
0x01	Illegal Function	Cihaz bu fonksiyonu desteklemiyor. 0x04 sorup 0x03 kullanmanız gerekiyor olabilir.
0x02	Illegal Data Address	Adres cihazda yok. En sık sebep: 40001 / 0 kaymasını yanlış hesaplamak.
0x03	Illegal Data Value	Değer veya adet geçersiz. Örneğin 200 register birden okumaya çalışmak.
0x04	Server Device Failure	Cihazın içinde bir arıza oluştu.
0x05	Acknowledge	"İsteğini aldım ama uzun sürecek, bekle." Sonucu 0x0B ile sorabilirsiniz.
0x06	Server Device Busy	Cihaz meşgul, biraz sonra tekrar deneyin.
0x08	Memory Parity Error	Dosya kaydı okurken hafıza parite hatası (sadece 0x14 / 0x15).
0x0A	Gateway Path Unavailable	Gateway hedefe giden yolu bulamadı — genelde gateway ayarı yanlış.
0x0B	Gateway Target Device Failed to Respond	Gateway'in arkasındaki cihaz cevap vermiyor — kablo, adres veya baud hatası.

🚨 En çok zaman kaybettiren ikili: 0x02 ve 0x0B. İlkinde adres haritasını, ikincisinde fiziksel bağlantıyı kontrol edin. Exception alıyor olmanız aslında iyi haberdir — demek ki hat çalışıyor, cihaz sizi duyuyor ve cevap veriyor. Hiç cevap alamamak çok daha kötüdür.

Kod aralıkları: public, user-defined ve reserved

Fonksiyon kodu bir bayt olduğuna göre teorik olarak 255 farklı değer alabilir. Standart bu alanı şöyle paylaştırmış:

Aralık (Dec)	Sınıf	Anlamı
1 – 64	Public	Standartta tanımlı; boş kalanlar Modbus Organization rezervinde
65 – 72	User-defined	Üretici istediği fonksiyonu koyabilir
73 – 99	Public	Standart alan
100 – 110	User-defined	Üretici serbest alanı
111 – 127	Public	Standart alan
128 – 255	Exception	Hata cevaplarına ayrılmış; burada asla yeni fonksiyon tanımlanmaz

Bir de reserved kodlar var: 9, 10, 13, 14, 41, 42, 90, 91, 125, 126, 127. Bunlar eski Modicon ürünlerinde kullanılmış, public sayılmıyor ve yeni tasarımlarda kullanılmaması isteniyor. Yani "boş görünüyor, ben buraya kendi fonksiyonumu koyayım" demeyin — geriye dönük uyumluluk sorunları çıkarır. 🙃

Limitler ve seri hat / TCP farkı

Her fonksiyonun tek mesajda taşıyabileceği veri miktarı sınırlı, çünkü bir MODBUS PDU'su en fazla 253 bayt olabiliyor. Bu limitler ezberlenmeye değer:

Fonksiyon	Maksimum adet
0x01 Read Coils	2000 bit
0x02 Read Discrete Inputs	2000 bit
0x03 Read Holding Registers	125 register
0x04 Read Input Registers	125 register
0x0F Write Multiple Coils	1968 bit
0x10 Write Multiple Registers	123 register
0x17 Read/Write Multiple	125 okuma / 121 yazma
0x18 Read FIFO Queue	31 register

Çerçeve boyutları da şöyle: RTU'da toplam 256 bayt (adres + PDU + CRC), TCP'de 260 bayt (7 baytlık MBAP + PDU).

Taşıma katmanı farkına gelirsek — 0x07, 0x08, 0x0B, 0x0C ve 0x11 fonksiyonları seri hat için tanımlanmıştır. MODBUS TCP'de bunları sormak genelde boşuna; bazı gateway'ler kabul eder, çoğu "Illegal Function" der.

Sahadan pratik ipuçları 🛠️

1. 40001 tuzağı

Kılavuzda "40001: Gerilim" yazıyorsa, protokol seviyesinde okumanız gereken adres 0'dır. Klasik gösterimde numaralandırma 1'den, protokolde 0'dan başlar. 40108 → adres 107. Bu tek satırlık bilgi, MODBUS'ta yaşanan hataların herhalde üçte birini önler. 😄

Kılavuzdaki gösterim  →  Protokol adresi
40001                 →  0x0000  (fonksiyon 0x03)
40108                 →  0x006B  (fonksiyon 0x03)
30001                 →  0x0000  (fonksiyon 0x04)
10001                 →  0x0000  (fonksiyon 0x02)
00001                 →  0x0000  (fonksiyon 0x01)

2. Bayt ve kelime sırası (endianness)

MODBUS register içindeki 2 baytı big-endian gönderir; bu standarttır. Ama 32 bitlik bir değer iki register'a yayıldığında hangi register önce gelir sorusunun cevabı standartta yoktur. Üretici A "yüksek kelime önce" der, üretici B tersini yapar. Bu yüzden float okurken saçma sayılar görüyorsanız, önce kelime sırasını (word swap) deneyin.

3. RS-485 sessizlik kuralı

RTU'da çerçevelerin nerede başlayıp bittiği, aradaki sessizlik süresiyle belirlenir: en az 3,5 karakterlik boşluk. 19200 baud üstünde ise sabit değerler kullanılır (t3.5 ≈ 1,75 ms). Yazılımınız çerçeveleri karıştırıyorsa, çoğu zaman suçlu bu zamanlamadır.

4. Broadcast'e cevap beklemeyin

Adres 0'a gönderilen mesaj tüm cihazlara gider ve hiçbiri cevap vermez. Sadece yazma fonksiyonlarıyla anlamlıdır; broadcast ile okuma yapamazsınız.

5. Az sorgu, çok veri

Ardışık 20 register'ı 20 ayrı istekle okumak yerine tek istekle okuyun. Her istek, hat üzerinde gidiş-dönüş gecikmesi demektir; RS-485'te bu gecikme veriden çok daha pahalıdır. Haritanızı ardışık okunabilecek şekilde planlamak performansı katbekat artırır. 🚀

6. Timeout'u baud hızına göre ayarlayın

9600 baud'da 125 register okumak, sadece veri iletimi için ~270 ms sürer. Varsayılan 100 ms'lik timeout ile çalışıyorsanız cihaz suçsuzdur, ayarınız yanlıştır.

Sık sorulan sorular ❓

0x03 mü kullanmalıyım, 0x04 mü?

Cihazın kılavuzu ne diyorsa o. Adres 40xxx ile gösterilmişse 0x03, 30xxx ile gösterilmişse 0x04. Emin değilseniz ikisini de deneyin — yanlış olan size "Illegal Function" ya da "Illegal Data Address" döner, zararı olmaz.

MODBUS TCP'de slave adresi (Unit ID) ne olmalı?

Doğrudan bir Ethernet cihazına bağlanıyorsanız genelde 1 veya 255 (bazı cihazlar 0 da kabul eder). Ama bir gateway'in arkasındaki seri cihaza ulaşıyorsanız, Unit ID o cihazın gerçek RS-485 adresidir ve kritiktir.

Neden hiç cevap alamıyorum?

Sırasıyla kontrol edin: baud hızı, parite, stop bit, slave adresi, A/B hatlarının ters bağlanmış olması, hat sonu 120 Ω sonlandırma direnci, ortak toprak. Exception almak bile bunlardan iyidir — demek ki hat sağlam.

Fonksiyon listesinde olmayan bir kod gördüm, ne yapmalıyım?

Önce 65–72 veya 100–110 aralığında mı bakın; öyleyse üreticiye özel bir fonksiyondur, cevabı sadece kılavuzda bulunur. 128'in üstündeyse bu bir fonksiyon değil, hata cevabıdır: 0x80 çıkarın, hangi isteğe cevap geldiğini görürsünüz.

Modbus güvenli mi?

Tek kelimeyle: hayır. Protokolde kimlik doğrulama, şifreleme, yetkilendirme yok. Hatta bağlanabilen herkes yazma yapabilir. Bu yüzden MODBUS ağlarını mutlaka izole edin. TLS tabanlı Modbus Security sürümü (port 802) bu boşluğu kapatmak için tanımlandı, ama saha yaygınlığı hâlâ düşük.

---

🔖 Terimler Sözlüğü

Terim	Açıklama
ADU	Application Data Unit — adres, PDU ve hata kontrolünü içeren tam çerçeve.
PDU	Protocol Data Unit — fonksiyon kodu ve verisinden oluşan, taşıma katmanından bağımsız çekirdek kısım.
MBAP	MODBUS Application Protocol Header — MODBUS TCP'de mesajın başına eklenen 7 baytlık başlık.
Master / Client	Soruyu soran taraf. Haberleşmeyi her zaman o başlatır.
Slave / Server	Cevap veren taraf. Kendiliğinden asla konuşmaz.
Coil	Okunup yazılabilen 1 bitlik veri. Genelde bir röle veya komut bitidir.
Discrete Input	Sadece okunabilen 1 bitlik veri. Genelde bir sensör durumudur.
Holding Register	Okunup yazılabilen 16 bitlik değer. Ayarlar ve set değerleri burada durur.
Input Register	Sadece okunabilen 16 bitlik değer. Ölçüm sonuçları burada durur.
CRC	Cyclic Redundancy Check — RTU'da mesajın bozulup bozulmadığını kontrol eden 2 baytlık kod.
Exception	Cihazın "yapamıyorum" cevabı. Fonksiyon koduna 0x80 eklenerek gönderilir.
Broadcast	0 adresine gönderilen, tüm cihazların dinlediği ve hiçbirinin cevaplamadığı mesaj.
MEI	Modbus Encapsulated Interface — 0x2B fonksiyonuyla başka protokol mesajlarını taşıma yöntemi.
Big-endian	Çok baytlı sayılarda en anlamlı baytın önce gönderilmesi. MODBUS register'ları böyle çalışır.
RS-485	MODBUS RTU'nun en yaygın kullanıldığı, iki telli ve çok noktalı seri haberleşme standardı.

📌 Ekstra Kaynaklar

• Modbus Organization — Resmî Spesifikasyonlar · Tüm standart dokümanların (uygulama protokolü, seri hat, TCP/IP, Modbus Security) tek adresten indirilebildiği kaynak. Herhangi bir tartışmada son sözü bu sayfa söyler.
• MODBUS Application Protocol Specification V1.1b3 (PDF) · Bu yazının temel aldığı 50 sayfalık ana doküman. Her fonksiyon kodunun tam gövde yapısı, durum diyagramları ve örnek çerçeveleri burada.
• Simply Modbus · Fonksiyon kodlarını bayt bayt, örnekli anlatan klasik referans site. Bir çerçeveyi elle çözümlerken açık tutulacak sekme.
• Wikipedia — Modbus · Protokolün tarihçesi, varyantları ve güvenlik konularına dair derli toplu bir genel bakış.
• libmodbus · Açık kaynak C kütüphanesi. Fonksiyonların gerçekte nasıl kodlandığını merak ediyorsanız, kaynak koda bakmak spesifikasyonu okumaktan daha öğretici olabilir.

---

Son söz: MODBUS'un 19 public fonksiyonu var, ama günlük hayatınızda sekiz tanesi işinizi görecek. Geri kalanları bilmenin faydası şu: bir gün karşınıza 0x2B ya da 0x16 çıktığında panik yapmak yerine "aa, bu cihaz kimliği soruyor" diyebileceksiniz. 😊

Siz sahada en çok hangi fonksiyonu kullanıyorsunuz? Ya da hangi cihaz size en tuhaf exception'ı döndürdü? Yorumlarda paylaşın. 👇

RS-485/MODBUS ve CAN Bus Karşılaştırması: Hangisi Ne Zaman Tercih Edilmeli?

RS-485/MODBUS ve CAN Bus Karşılaştırması: Hangisi Ne Zaman Tercih Edilmeli?

Endüstriyel bir cihaz, otomasyon kartı, araç elektroniği veya gömülü sistem tasarlarken karşımıza sık sık şu soru çıkar:

“RS-485 ve Modbus mu kullanmalıyım, yoksa CAN Bus mı?”

İlk bakışta bu iki seçenek birbirine oldukça benzer görünür. İkisinde de genellikle iki telli diferansiyel bir haberleşme hattı vardır. İkisi de gürültülü ortamlarda kullanılabilir. İkisiyle de aynı hat üzerinde birden fazla cihaz haberleştirilebilir. Üstelik her ikisi de yıllardır sanayide güvenilir şekilde kullanılmaktadır.

Fakat biraz derine indiğimizde önemli bir fark ortaya çıkar:

RS-485 bir haberleşme protokolü değildir. Kablodaki elektriksel sinyalin nasıl taşınacağını tanımlayan fiziksel bir standarttır. Modbus RTU ise çoğunlukla RS-485 hattı üzerinde çalışan bir haberleşme protokolüdür.

CAN Bus ise yalnızca elektriksel sinyal seviyelerini değil; mesajların nasıl gönderileceğini, aynı anda konuşmak isteyen cihazların nasıl sıralanacağını, hataların nasıl algılanacağını ve hatalı cihazların ağdan nasıl uzaklaştırılacağını da tanımlar.

Dolayısıyla aslında yaptığımız karşılaştırma tam olarak “RS-485 ile CAN” karşılaştırması değildir. Daha doğru ifadeyle şunu karşılaştırıyoruz:

• RS-485 fiziksel katmanı üzerinde çalışan Modbus RTU sistemi
• CAN fiziksel katmanı ve CAN veri bağlantı protokolü

Bu yazıda RS-485, Modbus RTU ve CAN Bus yapılarını temel seviyeden başlayarak inceleyecek; hız, mesafe, güvenilirlik, gerçek zamanlılık, maliyet ve yazılım karmaşıklığı açısından karşılaştıracağız. Yazının sonunda hangi uygulamada hangi teknolojinin daha mantıklı olduğunu daha net görebileceksiniz. 😊

Önce Katmanları Doğru Yerleştirelim

Haberleşme sistemlerini bir kargo hizmetine benzetebiliriz.

• Kullanılan yol ve araçlar, fiziksel haberleşme ortamını temsil eder.
• Paketin üzerine adresin nasıl yazılacağı, veri formatını temsil eder.
• Kimin ne zaman paket göndereceği, erişim yöntemini temsil eder.
• Paket kaybolursa ne yapılacağı ise hata yönetimini temsil eder.

Bu benzetmede RS-485 yalnızca yolun ve taşıma aracının elektriksel özelliklerini tanımlar. Modbus, paketin içine ne yazılacağını ve paketin nasıl yorumlanacağını belirler. CAN ise yol kullanım sırasından paket kontrolüne kadar daha fazla konuyu kendi içerisinde çözer.

Teknoloji	Temel görevi	Tanımladığı katman
RS-485	Elektriksel sinyalin kablo üzerinde nasıl taşınacağını belirler.	Fiziksel katman
Modbus RTU	Cihaz adreslerini, komutları, register yapılarını ve veri çerçevesini tanımlar.	Uygulama protokolü ve seri hat çerçeveleme kuralları
CAN Bus	Mesaj iletimi, hat erişimi, önceliklendirme ve hata yönetimini sağlar.	Fiziksel katman ve veri bağlantı katmanı
CANopen / J1939	CAN mesajlarının uygulama seviyesinde nasıl kullanılacağını tanımlar.	Üst seviye protokol

Bu ayrım oldukça önemlidir. Çünkü “CAN kullanırsam bütün cihazlar otomatik olarak anlaşır” düşüncesi doğru değildir. CAN, mesajların güvenilir biçimde taşınmasını sağlar; ancak mesajların içerisindeki baytların ne anlama geldiğini sizin tanımlamanız veya CANopen, SAE J1939 gibi bir üst seviye protokol kullanmanız gerekir.

RS-485 Nedir?

RS-485, uzun mesafeli ve gürültüye dayanıklı seri haberleşme için geliştirilmiş diferansiyel bir elektriksel iletişim standardıdır. RS-485 hattında veri genellikle A ve B olarak adlandırılan iki kablo üzerinden taşınır.

Alıcı cihaz yalnızca bir kablonun gerilimine bakmaz. A ve B hatları arasındaki gerilim farkını ölçer. Dış ortamdan gelen elektromanyetik gürültü iki kabloyu benzer şekilde etkilediği için alıcı, ortak gürültünün önemli bir bölümünü bastırabilir.

Tek uçlu haberleşme:

Sinyal ---------------------------->
GND   ----------------------------->

Diferansiyel RS-485 haberleşmesi:

A     ----\____/----\____/--------->
B     ____/----\____/----\________->

Alıcı, A ile B arasındaki farkı değerlendirir.

Bu yapı RS-485’i fabrika ortamları, motor sürücüleri, enerji sayaçları, bina otomasyonu, HVAC sistemleri, güneş enerjisi inverterleri ve saha cihazları için oldukça kullanışlı hâle getirir.

RS-485’in temel özellikleri

• Diferansiyel sinyal kullandığı için elektriksel gürültüye dayanıklıdır.
• Düşük haberleşme hızlarında yaklaşık bir kilometre sınıfındaki mesafelere ulaşılabilir.
• Aynı hat üzerinde birden fazla cihaz bulunabilir.
• İki telli yarı çift yönlü veya dört telli tam çift yönlü kullanılabilir.
• UART bulunan hemen her mikrodenetleyiciye bir RS-485 transceiver eklenerek uygulanabilir.
• Haberleşme protokolünü kendisi belirlemez.

RS-485 neden tek başına yeterli değildir?

RS-485 yalnızca sürücü ve alıcıların elektriksel davranışını tanımlar. Aşağıdaki soruların cevabını vermez:

• Mesaj hangi baytla başlayacak?
• Cihazların adresi nasıl belirlenecek?
• Verinin doğru ulaştığı nasıl kontrol edilecek?
• İki cihaz aynı anda konuşursa ne olacak?
• Bir sensör değeri hangi veri formatında gönderilecek?
• Mesajın sonunda hangi hata kontrol yöntemi kullanılacak?

Bu kuralları sizin tanımlamanız gerekir. Alternatif olarak Modbus RTU gibi hazır ve yaygın bir protokol kullanabilirsiniz.

Modbus RTU Nedir?

Modbus, endüstriyel cihazlar arasında veri alışverişi yapmak için geliştirilmiş açık ve yaygın bir haberleşme protokolüdür. Seri hatta kullanılan sürümü genellikle Modbus RTU olarak adlandırılır.

Modbus RTU çoğunlukla RS-485 üzerinde çalışır. Ancak teorik olarak RS-232 veya başka uygun seri haberleşme ortamlarında da kullanılabilir.

Modbus RTU sisteminde genellikle bir istemci ve birden fazla sunucu cihaz bulunur. Eski dokümanlarda bunlar “master” ve “slave” olarak da adlandırılabilir.

İstemci cihaz soruyu sorar, adreslenen sunucu cevap verir.

İstemci:
"1 numaralı cihaz, 100. register'dan itibaren iki register gönder."

Cihaz 1:
"İstediğin iki register'ın değeri 1250 ve 846."

İstemci:
"2 numaralı cihaz, 20. çıkışı aktif et."

Cihaz 2:
"Komut uygulandı."

Modbus veri modeli

Modbus içerisinde veriler yaygın olarak dört temel grupta ele alınır:

Veri türü	Erişim	Örnek kullanım
Coil	Okuma ve yazma	Röle veya dijital çıkış komutu
Discrete Input	Yalnızca okuma	Buton veya dijital giriş durumu
Input Register	Yalnızca okuma	Sıcaklık, basınç veya analog ölçüm
Holding Register	Okuma ve yazma	Ayar, eşik, çalışma modu veya kalibrasyon değeri

Register tabanlı bu yaklaşım özellikle PLC, HMI ve SCADA sistemleri açısından oldukça pratiktir. Bir cihazın dokümanında register tablosu bulunuyorsa, cihazı farklı üreticilerin PLC veya yazılımlarıyla entegre etmek görece kolaydır.

Basit bir Modbus RTU mesajı

Örneğin istemci, 1 adresli cihazdan iki holding register okumak istesin:

01 03 00 64 00 02 CRC_L CRC_H

• 01: Cihaz adresi
• 03: Holding register okuma fonksiyon kodu
• 00 64: Başlangıç register adresi
• 00 02: Okunacak register sayısı
• CRC_L CRC_H: Hata kontrol değeri

Buradaki CRC, mesajın hat üzerinde bozulup bozulmadığının anlaşılmasına yardımcı olur. Fakat mesajın yeniden gönderilmesi, zaman aşımı yönetimi ve cihazın cevap vermemesi gibi durumların yönetimi büyük ölçüde uygulama yazılımına bırakılmıştır.

CAN Bus Nedir?

CAN, yani Controller Area Network, başlangıçta araç içerisindeki elektronik kontrol ünitelerinin güvenilir biçimde haberleşebilmesi için geliştirilmiştir. Günümüzde otomotiv dışında iş makineleri, tarım makineleri, medikal cihazlar, robotlar, asansörler, denizcilik sistemleri ve endüstriyel kontrol uygulamalarında da kullanılmaktadır.

CAN hattında da çoğunlukla iki diferansiyel kablo bulunur:

• CAN_H
• CAN_L

CAN’in en önemli farkı, hattaki cihazların merkezi bir yöneticiden izin beklemeden mesaj gönderebilmesidir. Bu nedenle CAN, çok yöneticili veya yaygın kullanılan ifadeyle multi-master bir yapıya sahiptir.

CAN cihaz adresi yerine mesaj kimliği kullanır

Modbus sisteminde soru genellikle belirli bir cihaza yöneltilir:

"7 adresli cihaz, sıcaklık değerini gönder."

CAN sisteminde ise cihazlar çoğunlukla belirli bir mesaj kimliğini yayınlar:

CAN ID: 0x181
Data:   23 05 00 00 00 00 00 00

Hattaki bütün CAN düğümleri mesajı fiziksel olarak görür. Ancak yalnızca ilgili CAN ID’sine göre filtre ayarı yapılmış cihazlar mesajı işleme alır.

Bu nedenle CAN haberleşmesi cihaz odaklı değil, mesaj odaklıdır.

CAN Bus arbitrajı nasıl çalışır?

Aynı anda iki CAN düğümünün mesaj göndermeye başladığını düşünelim. Normal bir seri haberleşme sisteminde bu durum çakışmaya ve mesajların bozulmasına yol açabilir.

CAN, bu sorunu bit seviyesinde ve veri kaybı oluşturmadan çözer.

CAN hattında iki temel bit durumu vardır:

• Dominant bit: Mantıksal 0
• Recessive bit: Mantıksal 1

Dominant bit, recessive bite üstün gelir. Her düğüm kendi gönderdiği biti aynı anda hattan okur. Bir düğüm recessive bit gönderdiği hâlde hatta dominant bit görürse kendisinden daha yüksek öncelikli bir mesaj bulunduğunu anlar ve iletimi bırakır.

Düğüm A mesaj kimliği: 0x120
Düğüm B mesaj kimliği: 0x080

İki düğüm aynı anda başlar.

Bitler karşılaştırılır.
İlk farklılıkta 0 gönderen mesaj üstün gelir.

Sonuç:
0x080 mesajı hattı kazanır.
0x120 mesajı bozulmaz; yalnızca daha sonra tekrar gönderilir.

CAN’de sayısal olarak daha düşük mesaj kimliği daha yüksek önceliğe sahiptir. Örneğin 0x050 kimlikli bir acil durdurma mesajı, 0x500 kimlikli periyodik sıcaklık mesajından daha yüksek öncelikli olabilir.

Önemli: CAN arbitrajı öncelik tabanlıdır. Yanlış ID planlaması yapılırsa düşük öncelikli mesajlar yüksek hat yükünde uzun süre bekleyebilir.

CAN hata yönetimi neden güçlüdür?

CAN protokolünde hata algılama yalnızca mesaj sonundaki CRC kontrolünden ibaret değildir. Protokol içerisinde birden fazla kontrol mekanizması bulunur:

• CRC kontrolü
• Gönderilen bitin hat üzerinden geri okunması
• Bit stuffing kontrolü
• Mesaj çerçevesi format kontrolü
• Alıcı onay biti, yani ACK
• Hata çerçevesi gönderimi
• Gönderme ve alma hata sayaçları
• Error Active, Error Passive ve Bus-Off durumları

Sürekli hatalı mesaj gönderen bir CAN düğümü hata sayacını artırır. Hatalar devam ederse cihaz önce pasif hâle gelebilir, ardından Bus-Off durumuna geçerek haberleşme hattından mantıksal olarak ayrılabilir.

Bu mekanizma, arızalı tek bir cihazın bütün haberleşme hattını sürekli bozmasını önlemeye yardımcı olur.

RS-485/MODBUS ve CAN Bus Kısa Karşılaştırma Tablosu

Kriter	RS-485 + Modbus RTU	CAN Bus
Temel yapı	İstemci-sunucu, sorgu-cevap	Çok yöneticili, mesaj tabanlı yayın
Hat erişimi	Genellikle istemci kontrol eder.	Bütün düğümler mesaj gönderebilir.
Çakışma yönetimi	Protokol ve uygulama yazılımıyla önlenir.	Donanımsal, bit seviyesinde arbitraj bulunur.
Önceliklendirme	İstemcinin sorgu sırasıyla yapılır.	Mesaj kimliği arbitraj önceliğini belirler.
Veri modeli	Coil ve register tabanlı hazır model	Ham mesaj verisi; uygulama modeli ayrıca tanımlanır.
Klasik veri alanı	Tek sorguda çok sayıda register taşınabilir.	Klasik CAN’de en fazla 8 bayt
Yeni nesil veri alanı	Modbus çerçevesi değişmez.	CAN FD’de en fazla 64 bayt
Hata yönetimi	CRC, zaman aşımı ve yazılımsal tekrar deneme	CRC, ACK, bit kontrolü, hata çerçevesi ve hata sınırlama
Gerçek zamanlılık	Planlı sorgulamayla öngörülebilir olabilir.	Öncelik tabanlı, olay odaklı iletişim için güçlüdür.
Mesafe	Düşük hızlarda çok uzun mesafeler için uygundur.	Hız arttıkça ağın fiziksel uzunluğu belirgin biçimde azalır.
Yazılım geliştirme	Temel uygulamalarda daha kolaydır.	ID planlama, bit timing ve ağ yükü analizi gerektirir.
Yaygın kullanım	PLC, sayaç, inverter, HMI ve bina otomasyonu	Araç, robot, iş makinesi ve dağıtık kontrol sistemi

1. Haberleşme Modeli: Sorgu-Cevap mı, Olay Odaklı mı?

Modbus RTU’da iletişimi istemci yönetir

Modbus RTU sisteminde sunucu cihazlar genellikle kendi kendine veri göndermez. İstemcinin soru sormasını bekler.

Örneğin bir PLC, sırasıyla şu işlemleri yapabilir:

1. Birinci cihazın sıcaklığını oku.
2. İkinci cihazın basıncını oku.
3. Üçüncü cihazın hata durumunu oku.
4. Dördüncü cihaza çıkış komutu gönder.
5. Tekrar başa dön.

Bu yaklaşımın önemli bir avantajı vardır: Hattın kontrolü tek bir merkezde olduğu için iletişim sırası kolayca öngörülebilir.

Ancak bir sensörde aniden kritik bir hata oluşursa sensör çoğu standart Modbus RTU sisteminde kendiliğinden bağırarak haber veremez. İstemcinin sensörü sıradaki sorgusunda yoklamasını bekler.

CAN Bus’ta olay gerçekleştiğinde mesaj yayınlanabilir

CAN ağındaki bir cihaz, hat boş olduğunda mesaj göndermeyi deneyebilir. Kritik bir olay oluştuğunda yüksek öncelikli bir CAN mesajı hemen yayınlanabilir.

Örneğin:

• Motor sıcaklığı normalde saniyede bir gönderilebilir.
• Motor aşırı akım hatası oluştuğunda mesaj anında yayınlanabilir.
• Acil durdurma mesajına çok yüksek öncelik verilebilir.
• Düşük öncelikli servis bilgileri daha sonra gönderilebilir.

Olay tabanlı, hızlı tepki gerektiren ve birden fazla kontrolcünün aktif olduğu sistemlerde CAN bu nedenle daha doğal bir çözüm olabilir.

2. Gerçek Zamanlılık ve Gecikme

“Gerçek zamanlı” ifadesi yalnızca hızlı olmak anlamına gelmez. Bir mesajın en geç ne zaman ulaşacağının öngörülebilmesi de önemlidir.

Modbus RTU gecikmesi nasıl oluşur?

Modbus RTU’da istemci cihazları sırayla sorgular. Bir cihazın cevap süresi uzarsa veya cihaz hiç cevap vermezse istemci zaman aşımını beklemek zorunda kalabilir.

Örneğin 20 cihazlı bir ağda her sorgu ve cevap toplam 10 milisaniye sürüyorsa, bütün cihazları bir kez taramak yaklaşık 200 milisaniye sürer. Fakat bir cihaz için 100 milisaniyelik zaman aşımı beklenirse toplam tarama süresi belirgin biçimde uzayabilir.

Bu nedenle Modbus performansında şu değerler önemlidir:

• Baud rate
• Sorgu uzunluğu
• Cevap uzunluğu
• Cihaz sayısı
• Cihazların cevap hazırlama süresi
• Zaman aşımı değeri
• Tekrar deneme sayısı
• Register’ların blok hâlinde okunup okunmadığı

Doğru tasarlanmış bir sorgulama tablosuyla Modbus RTU oldukça öngörülebilir çalışabilir. Ancak cihaz sayısı büyüdükçe ve zaman aşımı senaryoları arttıkça gecikme de artar.

CAN Bus gecikmesi nasıl oluşur?

CAN’de mesajın gecikmesi, büyük ölçüde mesaj önceliğine ve hat yüküne bağlıdır.

Yüksek öncelikli mesajlar hattı daha kolay kazanırken düşük öncelikli mesajlar bekleyebilir. Ağ yükü aşırı yükselirse düşük öncelikli mesajların gecikmesi önemli hâle gelebilir.

Dolayısıyla CAN sisteminde yalnızca baud rate seçmek yeterli değildir. Aşağıdakiler de planlanmalıdır:

• Mesaj ID’leri ve öncelikler
• Mesajların periyodik gönderim süreleri
• Olay tabanlı mesajların maksimum sıklığı
• En kötü durumdaki hat yükü
• Maksimum kabul edilebilir mesaj gecikmesi
• Düşük öncelikli mesajların aç kalma ihtimali

Doğru tasarlanmış bir CAN ağı, kritik mesajlar için oldukça düşük ve hesaplanabilir gecikmeler sağlayabilir.

3. Hız ve Veri Taşıma Verimliliği

Haberleşme hızını değerlendirirken yalnızca “kaç bit/saniye?” sorusuna bakmak yanıltıcı olabilir. Bir protokolün mesaj başlıkları, hata kontrol alanları ve cevap mekanizması da gerçek veri taşıma kapasitesini etkiler.

RS-485’in hızı protokolden bağımsızdır

RS-485 standardı oldukça yüksek hızlarda çalışabilen fiziksel katman çözümlerine izin verir. Ancak hız arttıkça erişilebilecek kablo mesafesi azalır.

Modbus RTU uygulamalarında sık karşılaşılan hızlar şunlardır:

• 9.600 bit/s
• 19.200 bit/s
• 38.400 bit/s
• 57.600 bit/s
• 115.200 bit/s

Bunlar zorunlu değerler değildir. Cihazlar ve hat tasarımı destekliyorsa daha yüksek hızlar da kullanılabilir.

Modbus’un avantajlarından biri, tek sorguda art arda çok sayıda register okuyabilmesidir. Örneğin 30 farklı ölçüm değeri ardışık register’larda tutuluyorsa hepsini tek işlemle okumak mümkündür.

Klasik CAN ve CAN FD

Klasik CAN mesajında veri alanı en fazla 8 bayttır. Bu miktar kontrol komutları, sensör değerleri ve durum bilgileri için çoğu zaman yeterlidir. Ancak uzun veri blokları gönderilecekse mesajın birkaç parçaya bölünmesi gerekir.

CAN FD ile birlikte veri alanı 64 bayta kadar çıkarılmıştır. CAN FD ayrıca arbitraj bölümü tamamlandıktan sonra veri bölümünde daha yüksek bir bit hızına geçilmesine imkân tanır.

Buna rağmen CAN, büyük dosyaların veya sürekli yüksek hacimli verilerin taşınması için geliştirilmiş bir teknoloji değildir. Kamera görüntüsü, ses akışı veya büyük firmware dosyaları için Ethernet gibi daha yüksek bant genişlikli çözümler daha uygun olabilir.

4. Mesafe ve Kablo Yapısı

RS-485 uzun mesafede neden avantajlıdır?

RS-485 düşük hızlarda yaklaşık 1.000 metre sınıfındaki hatlarda kullanılabilir. Gerçek ulaşılabilir mesafe aşağıdaki etkenlere bağlıdır:

• Haberleşme hızı
• Kablonun karakteristik empedansı
• Kablo kesiti ve kalitesi
• Topoloji
• Dal bağlantılarının uzunluğu
• Sonlandırma direnci
• Toprak potansiyeli farkı
• Elektromanyetik gürültü
• Transceiver özellikleri
• Galvanik izolasyon ve koruma devreleri

Uzun bir üretim hattındaki enerji sayaçlarını veya bina içerisindeki farklı katlara dağılmış cihazları okumak için RS-485 oldukça uygun olabilir.

CAN’de hız-mesafe ilişkisi daha kritiktir

CAN arbitrajı sırasında bütün cihazların gönderilen biti yeterli süre içerisinde görmesi gerekir. Sinyalin hattın bir ucundan diğer ucuna gitme süresi ve geri dönüş gecikmesi, bit timing hesabını doğrudan etkiler.

Bu nedenle CAN hızı yükseldikçe izin verilen toplam hat uzunluğu azalır. Uygulamada 1 Mbit/s gibi yüksek hızlar daha kısa ağlarda; 125 kbit/s gibi daha düşük hızlar ise daha geniş fiziksel ağlarda tercih edilir.

Kesin mesafe yalnızca baud rate tablosundan seçilmemelidir. Kablo gecikmesi, transceiver gecikmesi, düğüm sayısı, konnektörler, stub uzunlukları ve örnekleme noktası birlikte değerlendirilmelidir.

5. Topoloji, Sonlandırma ve Dal Bağlantıları

Hem RS-485 hem de yüksek hızlı CAN için ideal yapı doğrusal bir bus topolojisidir.

Doğruya yakın bus topolojisi:

120 Ω                                            120 Ω
[SON]----+---------+---------+---------+---------[SON]
         |         |         |         |
       Cihaz 1   Cihaz 2   Cihaz 3   Cihaz 4

Sonlandırma dirençleri hattın iki fiziksel ucuna yerleştirilir. Her cihaza sonlandırma direnci takılması doğru değildir.

Yıldız bağlantı neden problem olabilir?

Önerilmeyen uzun kollu yıldız topoloji:

                 +---- Cihaz 1
                 |
Merkez ----------+---- Cihaz 2
                 |
                 +---- Cihaz 3
                 |
                 +---- Cihaz 4

Sinyal bir bağlantı noktasına ulaştığında farklı kollara ayrılır. Kolların empedansları ve uzunlukları nedeniyle yansımalar oluşabilir. Düşük hızlarda sistem çalışıyor gibi görünse bile hız yükseldiğinde veya kablo uzadığında rastgele haberleşme hataları başlayabilir.

CAN sistemi genellikle stub uzunluğu konusunda daha hassastır. RS-485’te de uzun dallar problem yaratır; ancak düşük hızdaki bazı sistemler daha toleranslı davranabilir.

RS-485 bias dirençleri

İki telli RS-485 hattında hiçbir sürücü aktif değilken hat boşta kalabilir. Alıcının belirsiz değer okumasını önlemek için bazı sistemlerde fail-safe bias dirençleri kullanılır.

Ancak her cihaza ayrı bias direnci koymak hattı gereksiz yere yükleyebilir. Bias ağı çoğunlukla tek bir uygun noktada tasarlanmalıdır. Modern transceiver’ların bir kısmında dahili fail-safe özellikler de bulunur.

CAN’de boşta kalma durumu

CAN transceiver yapısı, hat boşta olduğunda recessive seviyenin oluşmasını sağlayacak şekilde tasarlanır. RS-485’teki klasik harici bias ağı yaklaşımı CAN hattında aynı biçimde uygulanmaz.

6. Cihaz Sayısı ve Adresleme

RS-485 node sayısı

Klasik RS-485 tanımlarında sıkça “en fazla 32 cihaz” ifadesi görülür. Bu sayı, bir sürücünün taşıması gereken klasik unit load yükü üzerinden ortaya çıkmıştır.

Modern 1/2, 1/4 veya 1/8 unit load transceiver’larla fiziksel olarak daha fazla cihaz bağlamak mümkün olabilir. Fakat gerçek sınır yalnızca transceiver yükünden oluşmaz. Kablo uzunluğu, kapasitans, koruma devreleri, konnektörler, topoloji ve protokol adres alanı da dikkate alınmalıdır.

Modbus seri hatta sunucu adresleri genellikle 1 ile 247 arasında kullanılır. Adres 0 ise yayın mesajları için ayrılmıştır. Yayın mesajına cihazların cevap vermemesi gerekir.

CAN’de cihaz adresi kavramı farklıdır

CAN’in temel seviyesinde cihaz adresinden çok mesaj kimliği vardır. Bir düğüm birden fazla CAN ID yayınlayabilir. Aynı mesajı birden fazla cihaz dinleyebilir.

Cihazlara mantıksal node adresi vermek isteniyorsa CANopen veya SAE J1939 gibi bir üst seviye protokol kullanılabilir ya da projeye özel bir adresleme yöntemi tasarlanabilir.

7. Hata Algılama ve Arızaya Tepki

Modbus RTU hata yönetimi

Modbus RTU çerçevelerinde CRC-16 kontrolü bulunur. CRC uyuşmazsa alıcı mesajı geçersiz kabul eder.

Ancak aşağıdaki işlemler genellikle istemci yazılımı tarafından yapılır:

• Cevap zaman aşımını takip etmek
• Mesajı yeniden göndermek
• Tekrar deneme sayısını sınırlamak
• Cihazı çevrim dışı işaretlemek
• Haberleşme hatasını operatöre bildirmek
• Yeniden bağlanma stratejisini yönetmek

Modbus sunucusu geçerli bir sorguyu uygulayamıyorsa bir exception cevabı da gönderebilir. Örneğin desteklenmeyen fonksiyon kodu, geçersiz register adresi veya cihazın işlemi tamamlayamaması bildirilebilir.

CAN hata yönetimi

CAN’de düğümler mesajı gönderirken hattı da izler. Bir düğüm hata algıladığında hata çerçevesi oluşturabilir ve mesajın diğer düğümler tarafından geçerli kabul edilmesini engelleyebilir.

Hatalı mesaj daha sonra otomatik olarak tekrar gönderilebilir. Bunun yanında her CAN kontrolcüsünde iletim ve alım hata sayaçları bulunur.

Bu mekanizma özellikle aşağıdaki sistemlerde önemli bir avantaj sağlar:

• Bir cihaz arızasının tüm ağı bozmasının kabul edilemediği sistemler
• Birden fazla kontrol ünitesinin bulunduğu dağıtık mimariler
• Elektromanyetik gürültünün yüksek olduğu araç ve makine uygulamaları
• Hata teşhisi ve ağ sağlığının izlenmesi gereken projeler

8. Donanım Maliyeti ve Mikrodenetleyici Seçimi

RS-485 donanımı

RS-485 için temel donanım oldukça basittir:

• UART çevre birimi bulunan bir mikrodenetleyici
• RS-485 transceiver
• Sonlandırma ve gerekirse bias dirençleri
• ESD, EFT ve surge koruma elemanları
• Gerekliyse dijital izolasyon ve izole DC/DC dönüştürücü

Yarı çift yönlü RS-485 transceiver’larda sürücü etkinleştirme pini bulunur. Mikrodenetleyici mesaj göndermeden önce sürücüyü aktif eder, son bayt gerçekten hattan çıktıktan sonra tekrar alıcı moduna döner.

Burada sık yapılan bir hata, UART veri register’ı boşalır boşalmaz sürücüyü kapatmaktır. UART register’ı boşalmış olsa bile son bit henüz fiziksel olarak hattan çıkmamış olabilir. Bu nedenle “transmit register empty” yerine çoğunlukla “transmission complete” durumu takip edilmelidir.

CAN donanımı

CAN için genellikle aşağıdaki bileşenler gerekir:

• CAN kontrolcüsüne sahip bir mikrodenetleyici
• Harici CAN transceiver
• İki uçta 120 Ω sonlandırma
• ESD ve transient koruma devreleri
• Gerekliyse common-mode choke
• Gerekliyse galvanik izolasyon

Mikrodenetleyicide dahili CAN kontrolcüsü yoksa MCP2515 gibi SPI üzerinden çalışan harici bir CAN kontrolcüsü kullanılabilir. Ancak yüksek mesaj trafiği, kesin zamanlama veya CAN FD gereken uygulamalarda dahili CAN çevre birimine sahip bir mikrodenetleyici daha uygun olabilir.

Donanım maliyeti açısından iki çözüm arasında her zaman büyük fark bulunmaz. Fark çoğunlukla yazılım geliştirme, test, analiz cihazları ve sistem mühendisliği tarafında ortaya çıkar.

9. Yazılım Karmaşıklığı

Modbus RTU yazılımı neden daha kolay görünebilir?

Basit bir Modbus RTU sunucusunda aşağıdaki yapı yeterli olabilir:

1. UART’tan çerçeveyi al.
2. Adresin cihaza ait olup olmadığını kontrol et.
3. CRC’yi doğrula.
4. Fonksiyon kodunu işle.
5. İstenen register’ları oku veya yaz.
6. Cevabı oluştur ve gönder.

Açık kaynak Modbus kütüphaneleri ve hazır PLC fonksiyon blokları oldukça yaygındır. Register tablosu düzgün hazırlanmışsa üçüncü taraf entegrasyonu da kolaylaşır.

CAN yazılımında neler planlanmalıdır?

CAN sürücüsünün çalıştırılması başlangıçta kolay görünebilir. Fakat iyi bir CAN ağı tasarlamak için aşağıdaki konuların düşünülmesi gerekir:

• 11 bit veya 29 bit kimlik kullanımı
• Mesaj ID dağılımı
• Mesaj öncelikleri
• Mesaj periyotları
• Timeout ve alive counter mekanizmaları
• Sinyal ölçekleri ve offset değerleri
• Byte order
• Mesaj bütünlük kontrolleri
• Bus load hesabı
• Bus-Off durumundan geri dönüş stratejisi
• Yazılım güncelleme ve teşhis mesajları
• Sürüm uyumluluğu

CAN’in donanım seviyesinde güçlü olması, uygulama protokolünün otomatik olarak hazır olduğu anlamına gelmez.

10. Veri Formatı ve Birlikte Çalışabilirlik

Modbus register haritası

Modbus cihazı geliştiren üretici genellikle bir register tablosu yayınlar:

Register	Açıklama	Veri tipi	Ölçek
100	Besleme gerilimi	Unsigned 16 bit	0,01 V/bit
101	Kart sıcaklığı	Signed 16 bit	0,1 °C/bit
102	Dijital girişler	Bit alanı	Her bit bir giriş

Ancak bazı ayrıntılar Modbus standardı tarafından kesin biçimde çözülmez. Örneğin 32 bit veri iki register’a yerleştirildiğinde word sıralaması üreticiye göre değişebilir. Bu nedenle register dokümantasyonunda byte ve word sırası açıkça belirtilmelidir.

CAN sinyal tanımı

CAN tarafında benzer bir mesaj tanımı şu şekilde yapılabilir:

Mesaj adı : Device_Status
CAN ID    : 0x181
Periyot   : 100 ms
DLC       : 8

Byte 0-1  : Besleme gerilimi
            Unsigned 16 bit
            Little-endian
            Ölçek: 0,01 V/bit

Byte 2-3  : Kart sıcaklığı
            Signed 16 bit
            Ölçek: 0,1 °C/bit

Byte 4    : Dijital giriş bitleri
Byte 5    : Hata kodu
Byte 6    : Alive counter
Byte 7    : Uygulama CRC değeri

Otomotiv projelerinde bu tanımlar çoğunlukla DBC dosyalarında tutulur. Böylece analiz araçları ham CAN verisini gerilim, sıcaklık veya hız gibi fiziksel değerlere çevirebilir.

11. Galvanik İzolasyon Gerekli mi?

Hem RS-485 hem de CAN hatlarında galvanik izolasyon bazı uygulamalarda son derece önemlidir.

İzolasyon özellikle aşağıdaki durumlarda değerlendirilmelidir:

• Cihazlar farklı güç kaynaklarından besleniyorsa
• Toprak potansiyelleri arasında fark oluşabiliyorsa
• Kablo bina veya makine sınırlarının dışına çıkıyorsa
• Motor, kontaktör ve inverter bulunan gürültülü ortamdaysa
• Yüksek gerilimli güç katı ile kontrol katı arasında güvenlik ayrımı gerekiyorsa
• Uzun kablo nedeniyle yıldırım veya surge riski oluşuyorsa
• İnsan erişimine açık konnektör bulunuyorsa

İzole bir arayüz genellikle iki parçadan oluşur:

• Sinyal izolasyonu
• İzole tarafta transceiver’ı besleyecek izole güç kaynağı

Yalnızca dijital izolatör eklemek yeterli olmayabilir. Bus tarafının enerji beslemesi de izolasyon bariyerinin uygun tarafında oluşturulmalıdır.

12. Siber Güvenlik Açısından Karşılaştırma

Ne standart Modbus RTU ne de klasik CAN temel hâliyle şifreleme ve güçlü kimlik doğrulama sağlar.

Modbus RTU güvenliği

Modbus RTU mesajında cihaz adresi, fonksiyon kodu, veri ve CRC bulunur. Ancak CRC bir güvenlik mekanizması değildir. Yalnızca iletim hatalarının algılanmasına yardımcı olur.

Hatta fiziksel erişimi olan bir saldırgan teorik olarak geçerli CRC’ye sahip sahte bir Modbus komutu oluşturabilir.

CAN güvenliği

CAN mesajlarında da temel seviyede gönderen cihazı kriptografik olarak doğrulayan bir mekanizma yoktur. Hatta erişebilen bir düğüm geçerli biçimde CAN mesajı yayınlayabilir.

CAN CRC’si ve hata kontrol mekanizmaları rastgele iletim hatalarına karşı güçlüdür; ancak kötü niyetli mesaj üretimine karşı kimlik doğrulama sağlamaz.

Güvenlik kritik sistemlerde aşağıdaki önlemler değerlendirilebilir:

• Fiziksel erişimin sınırlandırılması
• Ağ segmentasyonu
• Gateway ve firewall kullanımı
• Mesaj frekansı ve davranış anomali kontrolü
• Uygulama katmanında mesaj kimlik doğrulama
• Rolling counter veya freshness value
• Güvenli bootloader ve imzalı firmware
• Servis ve teşhis fonksiyonlarının erişim kontrolü

13. Örnek Proje: Endüstriyel Giriş-Çıkış Modülü

12–24 V ile çalışan, dört analog girişe ve dört adet high-side MOSFET çıkışına sahip bir saha cihazı geliştirdiğimizi düşünelim.

Cihaz aşağıdaki görevleri yapacak:

• Dört analog sensörü okuyacak.
• Dört adet 24 V çıkışı kontrol edecek.
• Besleme ve kart sıcaklığını izleyecek.
• Bir PLC veya merkezi kontrolcüyle haberleşecek.
• Yaklaşık 300 metre kablo üzerinden çalışacak.

Bu proje için RS-485 ve Modbus neden mantıklı olabilir?

• PLC entegrasyonu kolaydır.
• Analog değerler input register olarak yayınlanabilir.
• Çıkışlar coil veya holding register ile kontrol edilebilir.
• 300 metre gibi bir mesafe düşük baud rate’te rahat yönetilebilir.
• Cihazın acil ve kendiliğinden mesaj göndermesi gerekmeyebilir.
• Register tablosu üçüncü taraf müşterilere kolayca verilebilir.
• UART destekli ekonomik bir mikrodenetleyici yeterli olabilir.

Örnek register haritası şöyle olabilir:

30001 : Analog giriş 1
30002 : Analog giriş 2
30003 : Analog giriş 3
30004 : Analog giriş 4

40001 : Çıkış komutları
40002 : Akım limiti
40003 : Haberleşme watchdog süresi

00001 : Çıkış 1
00002 : Çıkış 2
00003 : Çıkış 3
00004 : Çıkış 4

Aynı proje için CAN ne zaman daha mantıklı olur?

• Birden fazla kontrolcü bulunuyorsa
• Giriş değişimleri anında yayınlanacaksa
• Aşırı akım gibi hataların gecikmeden iletilmesi gerekiyorsa
• Çıkış modülleri birbirinden bağımsız mesaj üretecekse
• Sistem mobil bir araç veya iş makinesi üzerindeyse
• Mesaj önceliği ve hata sınırlama önemliyse
• İleride CANopen veya J1939 entegrasyonu planlanıyorsa

Örneğin aşırı akım mesajına 0x080, periyodik analog ölçümlere 0x300, servis bilgilerine ise 0x600 gibi daha düşük öncelikli ID’ler verilebilir.

14. Hangi Uygulamalarda RS-485/MODBUS Tercih Edilebilir?

Aşağıdaki şartlarda RS-485 üzerinde Modbus RTU genellikle güçlü bir adaydır:

• PLC, HMI veya SCADA sistemiyle entegrasyon yapılacaksa
• Cihazlar merkezi olarak sorgulanacaksa
• Uzun kablo mesafesi gerekiyorsa
• Veriler register tablosu şeklinde ifade edilebiliyorsa
• Haberleşme hızı kritik değilse
• Sistem mimarisi basit ve merkeziyse
• Düşük maliyetli mikrodenetleyici kullanılacaksa
• Üçüncü taraf entegrasyonu kolay olmalıysa
• Saha teknisyenlerinin mevcut Modbus araçlarını kullanması isteniyorsa

Tipik örnekler:

• Enerji sayaçları
• Güneş enerjisi inverterleri
• Motor sürücüleri
• Uzaktan giriş-çıkış modülleri
• HVAC kontrol cihazları
• Bina otomasyonu
• Endüstriyel sensörler
• Pompa ve kompresör kontrol panoları

15. Hangi Uygulamalarda CAN Bus Tercih Edilebilir?

Aşağıdaki şartlarda CAN Bus daha uygun olabilir:

• Birden fazla aktif kontrolcü bulunuyorsa
• Cihazların olay oluştuğunda kendiliğinden mesaj göndermesi gerekiyorsa
• Kritik mesajlara öncelik verilmesi gerekiyorsa
• Güçlü hata algılama ve hata sınırlama isteniyorsa
• Sistem dağıtık kontrol mimarisine sahipse
• Kısa ve sık durum mesajları gönderilecekse
• Araç veya hareketli makine uygulaması geliştiriliyorsa
• CANopen, J1939 veya başka bir CAN tabanlı standart kullanılacaksa
• Düğüm arızalarının ağ üzerindeki etkisi sınırlandırılmak isteniyorsa

Tipik örnekler:

• Otomotiv elektronik kontrol üniteleri
• Elektrikli araç batarya sistemleri
• Tarım makineleri
• İş makineleri
• Robotik sistemler
• Asansör kontrol sistemleri
• Denizcilik elektroniği
• Dağıtık motor kontrol sistemleri
• Medikal ve laboratuvar cihazları

16. RS-485/MODBUS ve CAN Aynı Sistemde Kullanılabilir mi?

Evet. Hatta birçok gerçek sistemde iki teknoloji birlikte kullanılır.

Örneğin:

• Araç içerisindeki düğümler CAN ile haberleşebilir.
• Merkezi kontrolcü bina otomasyon sistemine Modbus RTU ile bağlanabilir.
• Bir gateway, CAN mesajlarını Modbus register’larına dönüştürebilir.
• Yerel hızlı kontrol CAN ile, uzak saha haberleşmesi RS-485 ile yapılabilir.

[CAN Sensörleri]
       |
       | CAN Bus
       |
[CAN / Modbus Gateway]
       |
       | RS-485 Modbus RTU
       |
[PLC veya SCADA]

Gateway tasarlanırken yalnızca veri çevrimi yapılmamalıdır. İki haberleşme sisteminin farklı zamanlama modelleri de düşünülmelidir.

CAN mesajları kendiliğinden ve hızlı biçimde gelebilirken Modbus istemcisi veriyi aralıklı olarak sorgular. Bu nedenle gateway içerisinde son değerlerin tutulduğu bir veri tabanı, timeout bilgisi ve veri güncellik işareti bulunması yararlı olabilir.

17. Sık Yapılan Tasarım Hataları

RS-485 ve Modbus tarafındaki yaygın hatalar

• RS-485 ile Modbus’un aynı şey olduğunu düşünmek
• Hattın her cihazına 120 Ω sonlandırma bağlamak
• Uzun yıldız topoloji kullanmak
• A ve B isimlendirmesinin her üreticide aynı olduğunu varsaymak
• Transceiver yön kontrolünü yanlış zamanda değiştirmek
• Ortak referans hattını ve toprak potansiyeli farkını dikkate almamak
• Her düğüme ayrı bias dirençleri koymak
• CRC doğrulaması yapmadan mesajı işlemek
• Zaman aşımı ve tekrar deneme stratejisi oluşturmamak
• Register tablosunda veri tipi, ölçek ve byte sırasını belirtmemek

CAN tarafındaki yaygın hatalar

• Her düğüme sonlandırma direnci takmak
• Uzun yıldız topoloji kullanmak
• Bit timing değerlerini rastgele seçmek
• Bütün mesajlara benzer öncelik vermek
• Düşük sayısal CAN ID’nin yüksek öncelik olduğunu unutmak
• Hat yükünü hesaplamamak
• Bus-Off durumundan geri dönüş stratejisi oluşturmamak
• Çok sık periyodik mesaj göndererek ağı gereksiz yüklemek
• CAN’in uygulama protokolünü de otomatik olarak tanımladığını düşünmek
• Sinyal ölçeklerini ve mesaj sürümlerini dokümante etmemek

18. Hızlı Karar Rehberi

Aşağıdaki sorular seçim sürecini kolaylaştırabilir:

PLC veya SCADA ile kolay entegrasyon mu gerekiyor?

RS-485 ve Modbus RTU genellikle daha uygun olur.

Birden fazla cihaz kendiliğinden mesaj gönderecek mi?

CAN Bus daha doğal bir mimari sunar.

Çok uzun kablo mesafesi mi gerekiyor?

Düşük hızda çalışan RS-485 önemli avantaj sağlayabilir.

Kritik mesajlara donanımsal öncelik mi verilecek?

CAN Bus arbitraj mekanizması sayesinde öne çıkar.

Basit bir sensör veya giriş-çıkış cihazı mı geliştiriliyor?

Merkezi sorgulama yeterliyse Modbus RTU daha kolay olabilir.

Araç, robot veya dağıtık kontrol sistemi mi geliştiriliyor?

CAN Bus çoğunlukla daha uygun olur.

Tek mesajda çok sayıda ölçüm değeri mi okunacak?

Ardışık register okuması sayesinde Modbus RTU oldukça pratik olabilir.

Mesajların olay oluştuğunda hemen yayınlanması mı gerekiyor?

CAN Bus tercih edilebilir.

Sonuç: Hangisi Daha İyi?

RS-485/MODBUS ile CAN Bus arasında herkese uyan tek bir kazanan yoktur. İki teknoloji farklı sistem ihtiyaçlarına cevap verir.

RS-485 üzerinde Modbus RTU; merkezi olarak yönetilen, uzun mesafeli, PLC ve SCADA entegrasyonu gereken, register tabanlı endüstriyel uygulamalarda sade ve ekonomik bir çözümdür.

CAN Bus ise; birden fazla aktif kontrolcünün bulunduğu, mesajların olay tabanlı gönderildiği, kritik mesajlara öncelik verilmesi ve güçlü hata yönetimi gereken dağıtık sistemlerde öne çıkar.

En önemli seçim kriteri yalnızca haberleşme hızı değildir. Aşağıdaki konular birlikte değerlendirilmelidir:

• Sistem mimarisi
• Mesafe
• Düğüm sayısı
• Mesaj gecikmesi
• Gerçek zamanlılık
• Hata yönetimi
• PLC ve üçüncü taraf uyumluluğu
• Yazılım geliştirme maliyeti
• Gelecekteki genişleme ihtiyacı
• Güvenlik ve izolasyon gereksinimleri

Kısaca özetlersek:

“Bir merkez cihazları sırayla sorgulasın, mesafe uzun olsun ve PLC entegrasyonu kolay olsun” diyorsanız RS-485 + Modbus RTU güçlü bir seçimdir.

“Cihazlar gerektiğinde kendiliğinden konuşsun, kritik mesajlar öncelikli olsun ve haberleşme hataları donanımsal olarak yönetilsin” diyorsanız CAN Bus daha uygun olabilir.

🔖 Terimler Sözlüğü

Terim	Kısa açıklama
RS-485	Diferansiyel ve çok düğümlü seri haberleşmenin elektriksel özelliklerini tanımlayan standart.
Modbus RTU	Çoğunlukla RS-485 üzerinde kullanılan, sorgu-cevap tabanlı endüstriyel protokol.
CAN Bus	Mesaj tabanlı, çok yöneticili, öncelik ve güçlü hata yönetimi sunan haberleşme sistemi.
Transceiver	Mikrodenetleyicinin dijital sinyalini fiziksel haberleşme hattına dönüştüren alıcı-verici devre.
CRC	İletim sırasında oluşan veri bozulmalarını algılamaya yarayan hata kontrol değeri.
Arbitraj	Aynı anda mesaj göndermek isteyen CAN düğümleri arasında öncelik belirleme işlemi.
Dominant bit	CAN arbitrajında recessive bite üstün gelen, mantıksal 0 değeri.
CAN ID	CAN mesajının türünü ve arbitraj önceliğini belirleyen kimlik alanı.
Sonlandırma	Kablo üzerindeki sinyal yansımalarını azaltmak için hattın uçlarına yerleştirilen direnç ağı.
Bus-Off	Sürekli hata üreten bir CAN düğümünün kendisini haberleşme hattından ayırdığı durum.
CAN FD	64 bayta kadar veri alanı ve veri bölümünde daha yüksek hız sağlayabilen geliştirilmiş CAN sürümü.

📌 Ekstra Kaynaklar

• Modbus Organization – Resmî Modbus spesifikasyonları ve uygulama kılavuzları
• Texas Instruments – RS-485’e giriş ve izole RS-485 uygulamaları
• Bosch – CAN protokolü ve CAN Specification 2.0 kaynakları
• CAN in Automation – CAN FD temel çalışma prensibi
• Microchip – CAN arbitrajı, bit timing ve mesaj filtreleme mekanizmaları

CAN Bus Yükünün/Yoğunluğunun/Doluluğunun Hesaplanması

Bu yazıya başlamadan önce eğer CAN Bus hakkında bilgi almak isterseniz aşağıda yer alan blog yazılarını inceleyebilirsiniz.

Otomobillerin Dili: CAN Bus Protokolü Nedir?

CAN Bus Fiziksel Katmanı Nedir?

Otomotiv Ethernet vs CAN FD: Hangisi Otomotivin Geleceği?

CAN Bus'ın Avantajları ve Dezavantajları: Modern Araçların Gizli Kahramanı

https://autoditex.com/page/can-bus--controller-area-network-34-1.html

Bu blog yazısına giriş yapmak gerekirse, CAN Bus hattı üzerinden iletilebilecek maksimum paket sayısı, tanımlanan CAN hızı ve mesaj paket yapısı ile doğrudan ilişkilidir. Ancak CAN Bus mimarisinde yer alan bit stuffing mekanizması nedeniyle bu değer tek ve kesin bir sayı olarak ifade edilemez.

Başka bir deyişle; aynı CAN hızında çalışan iki sistemde, gerçekleşen paket sayısı, hatta efektif veri throughput’u birbirinden farklı olabilir.

Bit stuffing hakkında okuma yapmak isterseniz bu linkten inceleyebilirsiniz.

CAN Mesaj Çerçevesi ve Bit Seviyesinde Yapı

Standart bir CAN 2.0A (11-bit ID) veri çerçevesi aşağıdaki temel alanlardan oluşur:

• Start of Frame (SOF)
• Arbitration Field (ID + RTR)
• Control Field (DLC vb.)
• Data Field (0–8 byte)
• CRC Field
• ACK Field
• End of Frame (EOF)

Bu alanların nominal bit uzunlukları sabit gibi görünse de, bit stuffing devreye girdiğinde gerçek iletilen bit sayısı artar.

Bit Stuffing Nedir?

CAN protokolünde, arka arkaya 5 adet aynı seviyede bit (0 veya 1) iletildiğinde, alıcı ve verici senkronizasyonunu korumak amacıyla zıt seviyede bir bit otomatik olarak eklenir.

Bu eklenen bit:

• Veri değildir
• Çerçeveye ait değildir
• Ancak hattı meşgul eder

Dolayısıyla bit stuffing yoğunluğu arttıkça, aynı mesaj daha uzun sürede iletilir.

Teorik Maksimum Paket Sayısı Nasıl Yaklaşık Hesaplanır?

Teorik bir üst sınır hesaplamak için genellikle şu yaklaşım kullanılır:

1. CAN hızı (bitrate) belirlenir. Örnek: 500 kbps.
2. Bir CAN mesajının minimum ve maksimum bit uzunluğu hesaplanır. Bit stuffing yok varsayımı, iyimser senaryo. Bit stuffing maksimum varsayımı, kötümser senaryo.
   
3. 1 saniyede iletilebilecek maksimum mesaj sayısı yaklaşık olarak bulunur.

Standard ve Extend Mesaj Tipleri için Teorik Maximum, Minimum Bit Sayısı

Bu kısımda verilen yüksek seviyedeki bit değerleri teoride ulaşılması güç değerlerdir. Genellikle düşük bit sayısına yakın bir değerde genellikle bir paket oluşturulur. Bu sayılarda mesaj paketlerinin tamamı 8-byte olarak kabul edilir.

Frame Type	Standard Frame	Extended Frame
Minimum Bit Count	111	128
Maximum Bit Count	130	140

Farklı frame tiplerinde maximum minimum bit sayısını bulduktan sonra iş kolay. CAN Bus için tanımlanan hız üzerinden bir bit için gereken süreyi hesaplayıp bulduğumuz bit sayıları ile çarpıyoruz.

Bunu 500 kbps hız üzerinden örnekleyecek olursak bir bit için gereken süre 1/500.000 olacaktır. Bu da 2 us değerine denk gelir.

2 us tablodaki değerler ile çarpıldığında 500 kbps hızında tanımlanmış bir CAN Bus hattında bir CAN paketi için gereken süre aşağıdaki gibi hesaplanır.

Frame Type	Standard Frame	Extended Frame
Minimum Time	222 µs	256 µs
Maximum Time	260 µs	280 µs

Bir sonraki adımda tabloda tanımlanan değerler üzerinden 1/mesaj süresi formülü üzerinden 1 saniye içerisinde gönderilebilecek maksimum mesaj paketi hesaplanmış olur.

Frame Type	Standard Frame	Extended Frame
Minimum Time Package Count	4504	3906
Maximum Time Package Count	3846	3571

Bu yazı kapsamında vereceğim son bilgi olarak, son tabloda verilen maksimum değerler üzerinden CAN Bus doluluğu yüzdesel olarak ifade edilebilir. Bu ifadenin basit formülü de CAN Bus Load=100*Gerçek mesaj sayısı/Maksimum mesaj sayısı.