modbus

[erhanmete]

aster

"Modbus Emulator" mailine gönderdim.
programın modbus denemelerinde faydalı olacağını düşünüyorum(bizde oldu)

[aster]

Hocam sağolasın, arkadaşlar dosya aşağıdaki linkte
http://groups.yahoo.com/group/PicProjeUP14/files/ Modbus Emulator.zip

[Erol YILMAZ]

Merhaba;
Bu gunku yazimizda MODBUS iletisim protokulunun geri kalan konularindan secmece yapacagiz.
Daha once RTU mod agirlikli olarak calisacagimizi soylemistik. Modbus da default iletisim modunun RTU oldugunu soyluyor. ASCII daha az kullaniliyor. Iletisimde kullanilan butun cihazlar (Master/Slave's) ayni modu kullanmak zorundadir. Butun cihazlar RTU modu desteklemek zorundadir. ASCII opsiyoneldir.

RTU Haberlesme Modu
Bu mod ASCII ya gore daha iyi veri yogunlugu saglar. Yani ayni sayida gonderilen bit sayisi icin RTU daha cok veri icerir.

Bu modda herbir veri bayti icin 11 bit gereklidir.
1 start bit
8 data bit
1 bit parity (Kullanilmiyor ise bu da stop bit olacak)
1 stop bit
 
RTU modda Cift parite gereklidir. Fakat digerleri de kullanilabilir. Diger cihazlarla max. uyumluluk icin Parite kullanilmayabilir. Varsayilan parite cift paritedir. Eger parite kullanilmiyor ise 2 stop biti kullanilmalidir.

Herbir gonderi paketi frame olarak isimlendirilir. Max. MODBUS RTU frame boyutu 256 byte dir.
Herbir frame birbirinden en az 3.5 karakter zamani kadar ayri olmalidir.


CRC Tarama

Gonderilen mesajin hatasiz oldugunu incelmeye yonelik bir yontemdir.
Modbus RTU da CRC taramasi, gonderilen tum mesaj icin yapilir.
Bu mesajdan herbir baytin karakter icerigi olan 8 biti CRC islemine katilir. Start-stop-parite bitlerine CRC uygulanmaz.
CRC Tarama islemi bir dizi lojik islemdir. Nasil uygulandigini bir sonraki yazimizda bulabilma ihtimaliniz vardir.

[SpeedyX]

hocam açıklamalar için çok teşekkürler.
gerçekten birşeyler öğrendim modbus hakkında.
bunu tamamına erdirirsek ileride CAN de öğrenmek isterim.

dediğin şeyler güzel.
bizim bunu uygulamaya sokabilmemiz için kendi yazılımlarımızı geliştirmeliyiz.
hardware ile iletişim kuran prosedürler ayrı, modbusın kendi prosedürleri ayrı olmalı.
bu şekilde aynı fonksiyonları her tarz sistemde kullanmamız mümkün.
sadece hardware prosedürleri değişecek ama diğer herşey aynı kalacak.

mesela burada öyle yapmış:

unsigned char readRS(vid)
{
	while(!RCIF) continue;
	return RCREG;
}
	
void writeRS(unsigned char c)
{
TXREG = c;
TXEN = 1;
while (!TRMT);
}

bunlar hardware ile iletişim kuran fonksiyonlar.

ama bu modbus ile ilgili bir fonksiyon ve hardware fonksiyonlarını çağırıyor.

void readRegResponse(void){
unsigned char i;
T.bytes.lowByte = buffer[3]; 
T.bytes.highByte = buffer[2]; 
T.integer*=2;
buffer[2] = buffer[5]*2;
for (i=0; i<buffer[2]; i++)
     {
	startI2C();
	writeI2C(0xA0);
	writeI2C(T.bytes.highByte);
	writeI2C(T.bytes.lowByte);
	stopI2C();
	startI2C();
	writeI2C(0xA1);
	RCEN = 1;
	buffer[i+3] = readI2C();
	RCEN = 0;
        T.integer++;
      }
CRC16(buffer[2]+3,0);
for (i=0; i<buffer[2] + 5; i++)
writeRS(buffer[i]);
}

ben CCS kullanıyorum. pbp kullanan arkadaşlar var. bunları o dillere çevirerek birşeyler yapabiliriz. bunları yapabilmek için biraz daha teoriye ihtiyacımız olacaktır.

[Pyrodigy]

Modbus konusunda tecrübeli arkadaşlar!!Bu tarz bir projem var.Modbus rtu protokolü broadcast modu bu projeye cevap verebilir gözüküyor.Sizce projeme uyarlanabilirmi?Modbus protokolü türkiyede elektronikçilerin bildiği bir protokolmüdür?Ben Vb dilinde bilgileri gönderebileceğim bir program yaptım ama elektronik ve mikrochip programlanma kısmı bana yabancı...Daha önce buna benzer bir çalışması olan arkadaşlar varsa birlikte çalışmak isterim!Yada beni yönlendiriseniz sevinirim
Konu:
PC'den gönderilen ON/OFF bilgileri ile uzak noktalardaki slaveler üzerindeki 16 adet rölelere bağlı ampulleri açıp kapatma uygulaması yapmak. Bunun için bir master ve birden çok slave devreleri kullanılacak. Sanıyorum mesafe uzak olunca(max.1200 m) RS485 arabirim formatında haberleşme yapmamız gerekiyor. Slave kartlar üzerindeki DIP Switcher ile kontrol edilecek herbir rölenin ID numarasını tanımlamış oluyoruz.
Slave Modül üzerindeki dip switchler 'in değeri  1,2..,256 dan birisi olabilir
1.Master Ünitesi:
PC'den gelen RS232  formatında 8 Bit'lık bilgiyi RS485 formatına çevirip RS485 network'üne  gönderir. RS 485 hattını dinleyerek gönderdiği verilerin gereğinin yapılıp yapılmadığını kontrol etmesi gerek ve bunu tekrar PC ye iletmesi..
2. Slave Ünitesi:
RS485 networkünden gelen verileri kontrol ederek üzerindeki dip switch ile uyuşan verileri alıp  işlem yapar.Üzerindeki 16 adet farklı Çıkış rölelerini PC den gelen bilgiye göre on yada off yapar. İşlemi gerçekleştirdikten sonra Master ünitesine İşlemin tamam olduğu bilgisini gönderir.

Saygılar selamlar!

[psikokabus]

erol hocam hangi entegreyi tavsiye edersin (sleep modu olanlardan)
ayrıca bu entegreler sleep moduna nasil gecer nasil uyanir. daha önce kullandıgınız bir entegre varsa zaman kaybetmeyelim . ayrıca crc hesaplama da degisik algoritmalar var. nette crc calculator diye aratırsasınız ne demek istedigimi anlarsınız. buldugum bir application note a gore crc hesapladım. (RTU mode 16 bit) modbus her standarda uyar diyoruz. CRC hesapları farklı farklı kafam karıstı 8O  8O

[psikokabus]

:arrow:  tamam diyelim ki yazilimsal olarak her seyi hallettik...

kablolamayı nasıl yapacagız... :?:

[SpeedyX]

Burada modbus tartışılıyor kablolama ile de bir alakası yok.

[salim ALTIN]

merhaba.
Kablolama şöyle.:
Sen modbus tan haberleşeceğin cihaza bir SN75176 entegresi ilave ediyorsun mesela.(benzeri başka bir entegrede olabilir.) Sonra bu entegrenin çalışması için işlemciden 1 tane recive birtane transmit bir tanede cipseçme donamım uçlarına bağlantı yapıyorsun. Cipseçme SN75176 i recive  mi yoksa transmit te mi çalıştıracağını seçiyor , dierlerini söylemeye gerek yok sanırım.
Aynı zamanda haberleşemek istediğin dier tüm cihazlarda da aynı donanım entegren var.Bunları 2 adet kablo ile birbirine bağlıyorsun. Yani ikili  kabloya hepsi paralel bağlı . Tabiki bilgisayarın içinde bir tane RS-232 - RS-485 çevirici alıyorsun. O iki adet kablo uçlarını getirip bilgisayar için kullanacağın 485-232 çeviricisinde rs-485 girişine bağlıyorsun.(ki muhtemelen onun içindede sn75176 var) Tüm donanım kablolaması bu. Yanlız bilgisayardan en uzaktaki cihaza yani hattın sonuna 120 Ohm luk bir direnci (1/4 W yeterli) iki kablonun arasına bağlıyorsun hat sonlandırma direnci olarak.

(SN75176 http://www.parallax.com/dl/docs/prod/appkit/rs485Communication.pdf)
http://www.google.com.tr/url?sa=l&q=http://www.ti.com/rs485esd-aw&ai=BLHL_qtuIQoPoLIP6wQGW8P25D8qGkAf8w5WUAYT7spYD0IYDEAEYATgAQOgVSMk5yAEB&num=1

Burada modbus bir lisan. Türkçe , ingilizce gibi. RS-485 ise bu lisanı söyleyen ağız,dil oluyor.

[aster]

Gerçi Erol verdi ama konu hem yarım kaldı hemde sapmalar oluşuyor sanki, müsadenizle protokol tarihçesini baştan verelim neyin ne olduğunu daha iyi anlayalım

Açık Protokoller
Sıklıkla telaffuz edilmeye başlanan BACNET, LONWORKS, OPC gibi bazı terimler, muhakkak sizlerin de karşınıza çıkıyordur. Ancak her yeni teknolojide olduğu gibi "açık protokoller" olarak tanımlanabilecek bu konuda da belli bir kavram kargaşası, bulanıklık, hatta dezenformasyon dahi kaçınılmaz olarak yaşanıyor. Bu nedenle burada konuyu oldukça basite indirgeyerek sunmak istiyorum, umarım sıkıcı olmaz.

a) Protokol
Öncelikle "protokol" nedir bundan sözedelim. İki cihazın birbirlerine bilgi aktarmakta kullandıklarına lisana protokol ismi verilmektedir. Lisan benzetmesi aslında oldukça yerinde bir benzetme. Nasıl iki insanın anlaşabilmek için aynı lisanı konuşmaları gerekiyorsa cihaz ve sistemlerin de birbirleriyle anlaşmaları gerektiğinde ortak bir lisanı konuşmaları yani ortak bir iletişim protokolunu kullanmaları gerekir.

Etrafımız anlaşabilen ve anlaşamayan insanlarla dolu olduğu gibi, aynı şekilde anlaşabilen ve anlaşamayan cihazlarla da dolu. Bina otomasyon sistemleri dışındaki konulardan birkaç örnek vereyim.

Anlaşmazlıkların az, uyumluluğun had safhada yüksek olduğu bir alan bilgisayar ağları. Bugün hepimizin ofisinde enazından birkaç (çoğu durumda yüzlerce) bilgisayar, yazıcı, tarayıcı vs. birbirine bağlıdır. Yeni bir bilgisayar alınacağı zaman "acaba mevcut ağım ile uyumlu mu?" gibi bir soru kimsenin aklına gelmiyor. Bunun nedeni, bilgisayarların birbirleriyle haberleşmesinde kullanılan protokol yani lisanların çoktan standardize edilmiş olması ve tüm üreticilerin bu standartlara uygun üretim yapıyor olmalarıdır.

Farklı bir örnek olarak da hepimizin kullandığı televizyon uzaktan kumandalarını alalım. Bu konuda üreticilerin kabullendiği tek bir standart olmadığı için uyumsuzluklar her zaman karşımıza çıkıyor. Örneğin digiturk kumandamda televizyonumu da idare edebileceğim tüm tuşlar mevcut ama farklı bir marka olan televizyonumla çalışmıyor.

b) Taşıma Ortamı
Ortak bir protokolun yani lisanın kullanılması, iki farklı cihazın haberleşmesi için gerekli ama yeterli değil. Diğer önemli bir konu da bu lisanın cihazdan cihaza taşınacağı ortam. Taşıma Ortamı kavramını da lisan benzetmesini devam ettirerek açıklayabiliriz. İki insanın anlaşabilmesi için aynı lisanı kullanmaları gerekli. Ama bir de konuşmanın kişiden kişiye iletileceği ortam sözkonusu. Sadece yüzyüze konuşan iki insanı düşünmeyin, örneğin iki kişi telefon hatları üzerinden görüşüyor ya da mektuplaşıyor olabilir. Bu durumlarda kullanılan lisan aynı, ama mesajların taşınma ortamı farklı. İletişimin gerçekleşebilmesi için iki insanın hem lisan hem de bu lisanın taşınacağı ortam konusunda anlaşmış olmaları gerekli. (Örneğin Türkçeyi bugün yaptığımız gibi latin alfabesiyle ya da geçmişte olduğu gibi arap alfabesiyle yazabilirsiniz.)

Bina teknolojilerinde geçmişte en yaygın kullanılmış taşıma ortamı RS485 kısaltmasıyla bilinen ve iki-damarlı kablo üzerinden bir dizi cihazın çift-yönlü haberleşmesini sağlayan standart idi. Bu noktada şunu tekrar vurgulamakta yarar var, RS485 bir iletişim protokolu değil, yalnızca bir taşıma ortamı. Yani A ve B üreticilerinin cihazlarında RS485 çıkışlar olması, bu iki cihazın haberleşebileceği anlamına gelmiyor. Tekrar lisan benzetmesine dönersek telefon kullanarak seslerini birbirine ileten bir Çinli ile İngiliz'in anlaşamayacağı gibi...

Mikroişlemci tabanlı doğrudan sayısal kontrollü (DDC-Direct Digital Control) sistemlerin pazarda ilk belirmeye başladığı dönem 1980'lerin başlarına denk gelir. Bu teknolojinin bina endüstrisinde öncü ve başarılı olduğu uygulama alanlarının başında Isıtma-Havalandırma ve Klima (HVAC) sistemleri gelmiştir. Elektronik ve pnömatik kontrol sistemleriyle kıyaslandığında daha hassas kontrol ve uygulamada sağladığı geniş esneklik potansiyeliyle, bir yandan konfor seviyesini yükseltirken diğer yandan enerji maliyetlerini düşürmesi, DDC sistemlerin kabul görmesini ve yaygınlaşmasını kolaylaştırmış, kendi başına iş gören HVAC, aydınlatma, güvenlik, yangın algılama, söndürme ve asansör gibi sistemlerin birbirleriyle iletişim ve etkileşim içerisine girmesini sağlayan bu kontrol ağı, "akıllı bina" kavramını hayatımıza sokmuştur.

Özellikle son on beş yılda, bu teknolojinin sağladığı avantajlar ve maliyetlerindeki azalmalar daha belirgin ve etkili hale gelmiş, ancak buna rağmen "akıllı bina" kapsamının tam anlamıyla gerçekleşmesi daha çok niyet aşamasında kalmıştır. Bunda da en belirgin eksik parça, "iletişim protokolü standardı" olmuştur.

İlk kıpırdanmaların ardından, rekabet baskıları ve ihtiyacı giderecek standartların yokluğu, bina otomasyon sistem üreticilerini kendi özel iletişim protokollerini yaratmaya zorlamıştır. Ancak bu olumlu gelişmeler bir dezavantaj olarak bina sahipleri / işletmecileri için, binalarında tercih ettikleri konforu sağlayacak farklı firmaların ürünlerinin seçiminde kısıtlama ve zorlamaları da beraberinde getirmiştir.

Enerji yönetimi, aydınlatma kontrol sistemleri ve yangın algılama sistemleri binalarda yaygın ve alışıldık uygulamalar haline gelmiş olmasıyla birlikte bunların entegrasyonunun gerçekleştiği projeler bu tip sınırlamalar nedeniyle yeterli ivme kazanamamıştır.

İletişimdeki kısıtlamalar, bina otomasyonu kapsamında olan tek bir sistemin kendi iç fonksiyonunda dahi kendini göstermektedir. Kurulu bir sistemin genişlemesi veya yenilenmesinin gerektiği durumlarda, mal sahibinin, sistemi kuran firmaya / markaya bağımlı kalması veya ihtiyacını karşılamak için farklı marka seçmesi halinde, mevcut sistemin iletişim standardıyla uyumlu olamayacağından, ya kurulu sistemi, seçeceği markaya göre tamamen değiştirmesi ya da eklenen cihazların ayrı bir sistem olarak çalışması kaçınılmaz olmuştur. Hatta kimi zaman bir firmanın geliştirdiği yeni ürünlerinin eski ürünleriyle haberleşememesi de karşılaşılan bir durumdur.

Mikroişlemcilerin kapasitelerinin artması ve fiyatlarının düşmesiyle birlikte, kontrol zekasının yakalayıp içine aldığı konular da çoğalmıştır. HVAC üreticileri, kendi cihazlarına özel geliştirdikleri kontrol panelini artık cihazlarıyla birlikte temin etmekte ve hatta kendi özel iletişim protokollerini yaratmaktadırlar. Bu gelişmeler, bu cihazların bina otomasyon sistemleri ile entegrasyonunu artık bir zorunluluk haline getirmiş, otomasyon firmalarını kendi iletişim dillerini en azından belli ölçekte paylaşmaya doğru itmiş ve aradaki iletişimi kurma görevini üstlenen farklı tiplerde sistem entegratörleri türemeye başlamıştır.

Ara birimler, entegrasyon problemine bir miktar nefes aldırdıysa da uzun vadeli ve tatmin edici bir çözüm olamamıştır. Dikkate değer tek uzun vadeli çözüm standart iletişim protokolleri olarak gözükmektedir.

BACnet (Building Automation and Control Networking protocol)
Markalara özel iletişim protokolleri arasındaki uyumsuzluk Amerikan Isıtma-Soğutma ve İklimlendirme Mühendisleri Derneği'ni (ASHRAE) harekete geçmeye zorlamış ve dernek 1987 yılında bina otomasyonu ve kontrol sistemlerinde kullanılmak üzere standart bir iletişim protokolü geliştirme çalışmalarına başlamıştır. Bu amaçla kurulan Standart Oluşturma Komitesi (Standard Project Committee-SPC 135P), 1991 yılında hazırladığı ilk BACnet standardı taslağını yayınlayarak ilgili sektörlerin yorumuna açmıştır. Bu ilk baskıya altı farklı ülkeden 507 ayrı yorum gelmesi, bu tip bir standardın geliştirilmesi konusuna bina endüstrisinin ne kadar yoğun ilgisi olduğunun bir yansıması olarak kabul edilebilir. Artan ilgi ve görüşler de değerlendirilerek ilk çalışmanın revize edilmiş hali 1994'de yayınlanmıştır. 12 farklı ülkeden gelen yine yüksek sayıda yorum, standardın 1995'de üçüncü ve son revizyonunun oluşturulmasını gerektirmiştir. Standart bu haliyle ilk çalışmalarına başlandığı tarihten sekiz buçuk yıl sonra onaylanmış ve bir ASHRAE standardı olarak basılmıştır. Aynı yıl BACnet standardı Amerikan Ulusal Standartları Enstitüsü (ANSI) tarafından ulusal bir standart olarak kabul edilmiştir.

LONWORKS
Apple şirketinin kurucularından Mike Markula, 80'li yılların ortalarında, PC'ye geçişin ileriye dönük araştırma-geliştirme planlarını oluştururken, o ana kadar gelinen noktada, alanda bir açık olduğunu fark eder. Tasarım ve üretimin her seviyesinde, entegrasyon ve maliyetler azaldıkça kapasite ve uygulama çeşitliliği dramatik bir şekilde artmaktaydı ve "bilgisayar ağı teknolojisi" o dönemde, günlük kullanımdaki cihazlara henüz inmemişti.

Markula, bu konuya yatırım yapmanın ne kadar gerekli ve işe yarar olacağını görebilmek için, ilk etapta ön çalışma yapmak üzere bir ekip kurar. Ekip, yaklaşık iki yıllık bir araştırmanın sonunda, sistemin işlemesi için gerekli olan bazı donanımlar henüz eksik görünse de ilerleyen zamanda bunların temin edebilir olacağını belirtirler.

İlk tohumları bu şekilde atılan Echelon firması, günlük kullanımdaki cihazları bir ağ üzerine bağlayacak sistemleri yaratmak üzere resmi olarak 1988 yılında kurulur. Şirketin yönetimine bugün halen dümenin başında olan, PBX teknolojisinin yaratıcısı Dr. Kenneth Oshman gelmiştir.

İlk yıllar oldukça enteresan geçer. Echelon'un yaratmaya çalıştığı sistemi uygulayabilmesi için elinde ne silikonu, ne veri alış verişini sağlayan arabirimleri ne de iletişim ağını oluşturabilecek altyapıları vardır. Bu bileşenleri farklı firmalardan temin etmeye çalışırlar. Anlaşma yaptıkları silikon üreticilerinin Nöron çipleri teslimlerindeki gecikmeleri, bir miktar hızlarını kesmelerine rağmen "Lonworks" adını verdikleri iletişim ağı platformu artık bir zemin kazanmaya başlar.

Ancak, Lonworks'ün yaygınlaşması, Echelon ekibinin atlamış olduğu başka bir detay nedeniyle bir gecikmeye daha maruz kalır. O da, yabancısı oldukları kontrol endüstrisinin ilerleme ve adaptasyon hızının, elektronik teknolojisinin gelişim hızının yanında çok yavaş kalmasıdır.

İlk yıllardaki bu ağır başlangıcın ardından, sistemin benimsenmesiyle birlikte ivme kazanması kayda değer bir hızda olmuştur.

Echelon bugün, günlük kullanımdaki elektronik cihazların birbirleriyle iletişimini sağlayan teknolojiler üreten bir firma konumundadır. Lonworks'ün teknolojik altyapısını oluşturan Nöron çipin lisansını elinde tutmakla birlikte, Echelon, kontrol sektöründeki firmaların bu iletişim standardına kolay ve hızlı adaptasyonunu sağlayacak ürünler/sistemler geliştirmektedir. Bu yaklaşımla, silikon üreticisi ya da satıcısı konumuna girmeyi tercih etmemiş, bu konuda farklı firmalar ile (Toshiba, Motorola, Cypress Semiconductor) lisans anlaşması yaparak fiyat ve teknoloji rekabetini de dengede tutacak bir politika izlemiştir.

Echelon'un geliştirdiği Lonworks iletişim protokolü, bina otomasyon sektöründe bugün en yaygın kullanılan iletişim standardı halini almıştır. Bina Otomasyon sistemlerinin yanı sıra Lonworks, taşımacılık, tıbbi cihazlar, sanayi otomasyonu, ev otomasyonu ve kamu hizmetleri alanlarında da yaygın bir şekilde kullanılmaya başlanmıştır.

MODBUS
Diğer iki iletişim protokolü ile tarihsel sıralama açısından kıyaslandığında MODBUS'ın ortaya çıkması biraz daha geçmişe dayanıyor. Sektörel olarak kıyaslandığında ise endüstriyel alandaki iletişim ihtiyacını karşılayan en eski seri iletişim protokollerinden biri. PLC (Programmable Logic Controller) sektörünün ilk ve en güçlü imalatçılarından olan Modicon firması tarafından kendi ürünleri arasındaki iletişimi sağlamak üzere 1978 yılında geliştirilmiş. Zamanla PLC sistemler arasında veri transferi ve bilgi alışverişini sağlayan standart bir iletişim protokolü olarak bilfiil sektörde yerini almıştır. Modicon'a rakip pek çok endüstriyel kontrol cihazı imalatçısı kendi iletişim protokollerinin yanı sıra Modbus iletişim desteğini de vermektedirler.

Bir süre sonra Gould-Modicon, sonra AEG-Modicon adını alan Modicon firması, 1979 yılında Schneider Grup tarafından satın alınmıştır. Bir sonraki önemli gelişme olarak Schneider Electrics'in protokol üzerindeki isim hakkını, 2002 yılında endüstriyel iletişim teknolojisini geliştirmek üzere kurulan ve kar amacı taşımayan MODBUS-IDA adlı bir organizasyona aktarması, MODBUS iletişim protokolünün gelişimini ve yaygınlığını olumlu yönde etkilemiştir.

Teknolojik olarak bir kaç adım öndeki diğer standart iletişim protokollerinin yanında MODBUS bugün hala herhangi bir PC veya küçük bir microişlemci ile birlikte kullanılabilmekte ve sağlam geçmişi ve basit altyapısıyla artan sayıda imalatçı tarafından desteklenmekte ve mevcut pek çok endüstriyel sistemle iletişim kurabilmektedir.

EIB (European Installation Bus) ve KNX
1990 yılında, elektronik sektöründen on beş Avrupalı üretici firmanın, sistemlerinin/cihazlarının birbirleriyle haberleşmesinde kullanacakları ortak bir iletişim dili oluşturmak üzere bir araya gelmesiyle EIBA (European Installation Bus Association) kurulmuştur.

EIBA'nın, Kasım 1991'de, EIB adını verdiği iletişim protokolünün ilk taslağını, değerlendirilmesi ve bir sonraki adım olarak EN (Avrupa Standardı) veya ENV (ön standart) halini alabilmesi için CENELEC'e (Avrupa Elektrik Standartları Komitesi) sunmasıyla EIB'nin standart haline getirilme çaba ve çalışmalarında somut bir adım atılır.

Haziran 1992'de DKE -Alman Elektroteknik Mühendisleri Komisyonu EIB sistemini, bir standart (DIN V VDE 0829) olarak bünyelerine kabul ederler.

Fransa'da ise EIB protokolü "deneysel standart" olarak yayımlanır.

Bu aşamaya gelindikten bir süre sonra, Haziran 1996'da, EIBA ve benzer çalışmalar sürdüren BatiBUS Club International (BCI) ve European Home Systems Association (EHSA), iletişim ağını hem bina hem de konutlardaki elektronik sistemleri kapsayacak şekilde genişletmek ve daha yaygın bir standart halini alabilmek maksadıyla birleşme kararı alırlar.

Nisan 1999'da, elektro-mekanik ve bina otomasyon alanlarında aralarında Bosch, Schneider, Siemens, Electrolux, Merten gibi isimlerin bulunduğu dokuz büyük Avrupa firması, bu yeni grup ile işbirliğine gider ve Konnex Association adı altında bir dernek oluştururlar.

Derneğin amacı, mevcut üç Avrupa iletişim standardının (EIB, BCI ve EHSA) sahip olduğu teknik altyapı ve kaynakları birleştirerek bina ve konut otomasyonunda standart olarak kullanılacak tek bir açık iletişim protokolü (KNX) yaratmaktır.

Kurulduktan bir yıl sonra, Haziran 2000'de, Konnex Assoc., Avrupa Elektrik Standartları Komitesi (CENELEC) ile, standartlarının EN 50090 serisi içinde yer alabilmesi için gerekli donanımı temin etmek üzere bir işbirliği anlaşması yapar.

Bundan sonraki çalışmalar ve faaliyetler, standardın tanıtılması ve yaygınlaşmasına yönelik gelişir.

Bugün Konnex Assoc. sektörde "en" olmasa da Bina ve Konut Elektronik Sistemleri Standardizasyonunda on yıllık bir geçmişe sahip üç oluşumun mirasını taşıyan, yüzü aşkın elektrik sistemleri/cihazları üreticisini bünyesinde bulunduran önemli ve etkili bir kuruluş halini almıştır

şimdi konuya devam edelim, bu konuları bilmemizde çok yarar var ,
buyurun

Not: EIB çalışmasını izledim 2 kablo üzerinden hem besleme hem data gidiyor, bunlar uzun mesafe tek kablo ve yüzlece cihazla çalışabiliyor, ilginç bir çalışma mantığı var, hat uzadıkça kesit artıyor

[mhk]

Sevgili aster bu EIB de hız , kablo özelliği hakkında yada çalışma prensibi hakkında bilgi yazabilirmisin?. Aklıma haberleşme ve gnd bağlantısından oluşan iki hat. ( Burda haberleşme hattı aktif veya VDD Vcc gibi bilgiye göre değişebilen ) slave kısımları ise değişen bu bilgi hattını kendi beslemesi gibi kullanıp ( Tam dalga doğrultmaç gibi , diyot kondansatör vs gibi) aynı zamanda slave rx girişinede doğrudan vererek  haberleşme sağlanıyor olması lazım diye düşünüyorum. Mantıklı bir yol bence. Doğru anlayabilmişmiyim?

[aster]

Selam Hocam,
EIB konusunu isterseniz bu konunun uzmanı mmengi anlatsın
ama bu protokol üstüne özel malzemeler geliştirilmiş ve gömülmüş
başta hazreti siemens tabi
besleme hattı bildiğimiz 24 VDC, data bunun üstüne bindiriliyor ve bir bus la her cihaza dolaştırılıyor hem besleme gidiyor hem data sonra data özel bir yöntemle ayıklanıyor ve kullanılıyor tabi her cihazın bir ID bilgisi var önceden sisteme her cihaz için bir kimlik veriyorsunuz yazılımdan her işi takip edebiliyorsunuz
http://www.konnex.org/
http://esta.kiwi.co.uk/groups/BCG/library/ocp.asp
http://www.eib-home.de/instabus_eib_studium.htm
aslında EIB genel anlamda instabus diye geçiyor, malzemelere bir göz atın
http://www.auktion9.de/highlight_suche.pl?suche=instabus-jung-busankoppler&ws=jung%202070u

[psikokabus]

@salim altın hocam teşekkür ederim

kablolama onemli cunku modbusın yazılımsal olarak bir numarası yok
her fonksiyonu acıkca yazılıp kalıpları verilmiş

@mhk hocam lab. ortamında calıstırıp sahada calıstıramadıgı bir sistemden bahsetmişti. kodlarını da birguzel vermiş. kodlarda bir bozukluk yok sorun bence kablolamada

salih altin hocam hepsini anlatmıs sagolsun . benim merak ettigim kablolama topolojisi icin onerilen bir sey var mı ve ne tur kablo kullanılacagı .

anlasılan topoloji falan yok masterdan cıkan hatta butun slaveler baglanıyor kablo olarakta twisted pair kullansak olur heralde...

ayrıca crc konusu cozulmustur olay tamamen tanımlanan degişken tiplerinden kaynaklanıyor.. int tanımlarsan farklı sonuc char yazarsan farklı sonuc  önüne gelen kod yazmıs ama algoritma sabit en iyisi kendi kodunu kendin yazacaksın bende oyle yaptım..

[salim ALTIN]

anlasılan topoloji falan yok masterdan cıkan hatta butun slaveler baglanıyor kablo olarakta twisted pair kullansak olur heralde...

..

Merhaba.
Twisted pair kullanılmalı zaten. Kısa mesafede sargılı kablo olmayınca pek problem olmuyor fakat endüstriyel ortamda her iki kablo sargılı olmak durumunda. Birde recive - transmite gider. yoksa boşuna biz milletin kulağına bağırmıyoruz.
Salim ALTIN

[passwordc]

http://www.modbus.pl/index.html

http://www.protocessor.com/products/ProtoCessor.asp