Komunikacija mreža kontrolera-računar

Dakle ovako

Potrebno je ostvariti komunikaciju u mreži od n kontrolera (npr n=10) od kojih je jedan master.Jedina uloga mastera je da komunicira sa Slave kontrolerima i da rezultat komunikacije prosledi PC-u preko RS232 porta.
Interesuje me koju vrstu interfejsa da odaberem od mastera ka slave kontrolerima i kako da sve to organizujem.

Ako master i slave kontrolere vežem rs232 linijom postavlja se pitanje kada master šalje komande slave kontrolerima, kako izbeći da te komande prima i PC-ja mislim nemoguće. Ima tu još pitanja, ali da ne dužim.

Pregledao sam dosta tema ali nikako (bar za sada) da složim mozaik. Ako je neko radio nešto slično, bio bih zahvalan da izloži ideje vezane za organizaciju ovakve mreže

Udaljenost master od slave kontrolera je oko 10-tak metara.

Koristi RS485 komunikaciju s time da ti je PC master. Vjerojatno ti treba nešto kao ovo moje na www.micromatic.hr/rht.htm

Potpis

www.micromatic.hr

Hvala na ideji,

mislim da ću ići u tom smeru.
Imam neka pitanja da bih sebi skratio lutanje

1.Koji USB/RS485 konvertor koristiš?
2.Koji RS485 konvertor koristiš?

Hvala.

Izvinjavam se zbog nepažnje kod drugog pitanja. Treba da glasi

2. Koji RS485 transiver koristiš.

1. I-7561 doduše imam i neki vlastite izrade (FTDI232+ADM485) ali se I-7561 pokazao boljim kod dugih 485 linija jer ima galvansko odvajanje PC-a od 485 linije. Za tvoju udaljenost zadovoljio bi i FTDI+ADM485.

2. već spomenuti ADM485

Potpis

www.micromatic.hr

Najbolje resenje za taj problem je CAN komunikacija i eventualno USB za vezu sa PC-jem.
CAN je kom. standard na visem nivou od RS485 i boljih je karakteristika. Po definiciji je masterless ali se moze implementirati tako da jedan cvor ima ulogu mastera(njegove poruke bi imale najveci prioritet u mrezi a ostali cvorovi bi vrsili slanje samo posle prozivke). Ono sto je takodje bitno je da nije potrebna manuelna arbitraza na magistrali kao kod rs485 vec CAN poseduje ugradjeni MAC mehanizam. Zbog toga je upravljanje takvom mrezom mnogo lakse,prenos podataka pouzdaniji a sama mreza mnogo fleksibilnija.
CAN transiveri (mcp 2551) su cak jeftiniji od nekih RS485 transivera, jedino ostaje problem CAN kontrolera(ili standalone ili ugradjenog u MCU) koji obezbedjuje funkcionalnost na mreznom i nivou podataka. Ja za to koristim Freescale 9S08DZ60 MCU ali ima i PIC-ova, AVR-ova ST-ova i ostalih sa ugradjenim CAN modulom. Jedino nepostoji 8-bitni mcu koji ima i CAN i USB.

Ali zato postoje 32-bitni sa CAN i USB: http://www.microchip.com/productselector/MCUProductSelector.html

Hvala na odgovorima,

mislim da razmotrim realizaciju sledeće konfiguracije:

1.Interfejs bi bio RS485.
2.Kao što kaže micromatic odbacio bi moju početnu ideju sa master mikrokontrolerom. Sve kontrolerske pločice bile bi slave a računar bi bio master. Računar bi po potrebi prozivao svaki od slave-ova.
3.Dvoumim se šta da upotrebim kao RS485 trancievere SN75176 (koji su već pomalo kritikovani u nekoj od tema na ovom forumu), ali su dosta jeftiniji u odnosu na MAX485.
4.Kao u micromaticovom rešenju www.micromatic.hr/rht.htm napravio bih RS485/RS232 konvertor. Predlog rešenja ima na:
http://members.home.nl/bzijlst...tware/communication/Benbus.htm. Pa odatle RS 232 veza ka računaru.
5.Opciono ta RS232 veza se može konvertovati u USB.Nešto sam gledao pa vidim da Mikroelektronika ima zanimljivo i krajnje jeftino rešenje:
http://www.mikroe.com/eng/products/view/444/usb-uart-boards/.
Da rezimiram: Svih 10 pločica su međusobno povezane RS485 interfejsom.Nakon toga ide jedan RS485/RS232 konvertor pa RS232/usb konvertor i to na USB port računara.
Šta mislite o ovakvoj topologiji. Vredili ulagatiu truda u realizaciju ove ideje ili da nešto menjam.

Pošto komunikacija napreduje želim da proverim neke moje ideje.
Radi se o tome kako organizovati komunikaciju između mreže kontrolera i računara sa urađenim aplikativnim programom (treba da se radi). U toj komunikaciji računar je master. Moja ideja je sledeća:

1.Računar šalje paket u kome se nalazi između ostalog i adresa kontrolera sa kojim želi komunikaciju. Pošto koristim Atmel kontrolere oni imaju zgodan 9-to bitni mod serijske komunikacije (AVR i 51 familija). Zbog toga bi adresni bajt paketa (prvi u nizu) imao 9 bitova podataka +start i stop bit. 9-ti bit mogu da dobijem ako u komunikaciji uključim bit parnosti (odaberem odgovarajući nivo bita-MARK ili SPACE). Ako je 9-ti bit jedinica svi kontroleri znaju da je u pitanju adresa i provere je sa svojom. Svi koji nisu adresirani ne slušaju dalju komunikaciju jer računar nadalje šalje taj deveti bit nulu (sve dok ne želi da popšalje ponovo adresu).
Ovim želim da rasteretim kontrolere da neprekidno osluškuju komunikaciju i proveravaju da li su adresirani.

2.Kontrolu smera komunikacije želim da ostvarim upotrebom pina 7 (RTS) serijskog porta koji je na logičkoj 1 dok računar šalje podatke. Ovim bih kontrolisao komunikaciju sa strane RS232-RS485 konvertora. Što se tiče kontrolera oni su svi u stanju prijema dok ne prepoznaju adresu i tu je kontrola komunikacije laka (jedan pin mikrokontrolera). Normalno tada adresirani kontroler prelazi na predaju a računar na prijem.

Interesuju me vaša iskustva, može li to kako sam ja zamislio.
Unapred hvala.

par pitanja
- zasto bezis od CAN, on ima resen ceo hw protokol vec tako da ne moras ti da brines o tome ko menje a ko slusa
- RTS na RS485 koliko se ja secam ne postoji tako da ne znam kako mislis da ga iskoristis za "direkciju"
- 9N1 je ok setup za seriski port ali kako mislis da time rasteretis slave uredjaje kada oni svakako moraju da procitaju svaki paket i pogledaju da li mu je setovan deveti bit .. isto tako mogu da provere bilo sta sto sedi u paketu...

po meni, prvo treba da budes siguran da znas zasto si odabrao RS485 a ne CAN i da to nije zato sto "RS485 vise lici na seriski port a to znas kako radi", posto se mnogo vise isplati da izgubis 3 dana da provalis kako radi CAN (a i forum moze da pomogne) nego da budzis to sve preko RS485 posto na 485 ti moras da implementiras protokol dok tu ne moras da brines sa CAN-om. Kapiram da voles atmel, ali [url=www.atmel.com/dyn/resources/prod_documents/doc4069.pdf ] ima i atmel mcu sa can-om [/url] .. oces '51 T89C51CC01, T89C51CC02, AT89C51CC03 - sva tri imaju CAN, os standardni avr AT90CAN128 je prava stvar .. da ne kazem da stavis obican CAN transciever sa usart ili spi portom i bas te briga ..

Da ne spominjem ODLICAN atmelov CAN tutorijal

drugo treba da osmislis protokol koji ce da trci na toj "mrezi". setovanje "smera" nije dobra ideja.. a to ces morati ozbiljno da osmislis ako hoces da ostanes na RS485 posto ti sam interface ne pomaze koliko ni moj komsija koji evo opet u 7 ujutro lupa snicle ..

Ako ti je CAN prekomplikovan, skup ili imas neku odbojnost prema njemu, onda je resenje LIN. To je bus, vrlo lici na seriski port, transcieveri obicno idu na usart port mcu-a mada i atmel i microchip i mnogi drugi imaju lin u hardware-u ... dosta je jednostavniji od CAN-a a BUS je, nije "interface" kao rs485 tako da ima svoj transport layer odradjen kako valja i "master slave" je pa je nekima jasnije kako radi. Neki korisni dokumenti za LIN su http://www.atmel.com/dyn/resources/prod_documents/doc7548.pdf i http://www.atmel.com/dyn/resources/prod_documents/doc8123.pdf

Pogledaj i datasheet za MCP201 ... to je odlican, jeftini, mali transciever za LIN :)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

da ne zaboravim ... LIN je
- na JEDNOJ ZICI .. (ume da bude vrlo zgodno)
- nije previse brz (mnogo sporiji od CAN-a) - tj 20kbps mu je max brzina, mada ne verujem da ti je to problem, 20kbps je prilicna brzina za pricu osmobitnih kontrolera :D

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ovako

Prvo da dam objašnjenje zašto RS485-pa jednostavno počeo sam i sada mi je bez veze, nemam dovoljno vremena i želim da za to vreme najsigurnijim putem (da li sam ga i odabrao?) dođem do pouzdanog rešenja.
Takođe moram da priznam da me je privukla Micromatic-ova ideja iz posta u ovoj temi. On je realizovao baš ono što i ja hoću.
Što se tiče Bogdanove nedoumice oko 9-to bitne RS232 komunikacije-to atmeli mogu, a kao što vidim iz Korakovog posta (http://www.elitesecurity.org/t151037-0#987837), mogu i Motorole. U adresnom bajtu je 9-ti bit jedinica, a u ostalim nula. Zahvaljujući nekim flegovima, samo adresirani kontroler će primati ostale bajtove itd, itd.

Znači molim one koji su radili ono što ja želim, ako imaju dovoljno vremena da prokomentarišu moj prethodni post i izlože svoje viđenje stvari.
Hvala.

pazi ja sam to "na zalost" radio .. zato sam se uopste i ukljucio u pricu ..

za ovo sa devetim bitom, nisam nikad probao, nemam nedoumicu posto je 9n1 i 9e1 regularan setup za usart sami nisam nikad video da mozes da setujes mcu da ti picne interrupt samo ako je deveti pin setovan, ako mozes na taj nacin da oslobodis da mcu zna kad je adresni a kad nije paket to je extra ... bas cu overiti jednom kako sa tim stoje TI i MCP posto bi to bilo extra, bacis mcu u sleep da ne sisa struju i ako ga taj deveti pin probudi on cekne jel njegpova adresa, ako jeste servisira ako nije vrati se u san .... a ako ti stize interrupt na svaki receive pa ti onda proveravas dal je deevti pin, moz da overis onda i onih osam vec si izgubio vreme da otrcis u isr, da citas iz registra .. no ko sto rekoh, nisam probao, super ako moze, odlicna fora

sto se tvoje ideje tice, 485 je super "stabilan", brz, radi extra, transcieveri su pouzdani, prave se i koriste decenijama i bacaju "daleko" .. to je sve super ... ono sto ja vidim kao problem

arbitraza - sa ovim sam ja sam sebe sutao u dupe 3 meseca dok nisam napravio a imao sam samo 4 uredjaja na bus-u .. to uopste nije jednostavno ako imas iole komplikovaniji protokol. Ja sam na kraju batalio ceo inicijalni trip i napravio glupi protokol "pitam, cekam odgovor, ako ne stigne odgovor xyz ms ja se resetujem" .. sto je zahtevalo da pitanje i odgovor uvek imaju "poznat" broj bitova... dakle ako ne znas da li ce slave da vrati 1 ili 10 bajtova moras ili da ides na varijantu da ti prvo slave javi "koliko salje" pa tek onda da salje datu (sto je bedak posto najcesce treba da uzmes samo jedan bajt pa za njega saljes duplo) ili da slave uvek vraca samo jedan a da ti saljes zahtev za svaki sledeci (256 komajdi, 256 mogucih rezultata .. opet - limit) ... ako ti treba jace od 256 komandi onda opet, duplas pa saljes komandu od 2 bajta .. sve u svemu, ovo bez ozbiljnog protokol analyzera - mnogo za*bano testirati ... a ja kad sam to pravio nisam imao ni scope .. tako da .. savetujem, ozbiljno, neki logic analyzer pre svega .. nedaj boze da pravis multimaster ... ja probao pa se ... ok ja sam imao i problem sa slave-slave pricom, master failover setup-om (ako rikne master da drugi mcu moze da preuzme) ali to je vec neka druga prica ... sve u svemu, ako nemas potrebu za slave-slave pricom i ako nemas potrebu za master failoverom (a to nemas posto ti je komp master), i ako kolicina podataka koja prolazi izmedju uredjaja nije velika onda ti je to resenje ok - bas te briga sto saljes dodatni bajt za broj bajtova ili sto su ti komande dvobajtne ..

drugi potencijalni problem je "seriski port na kompu" - to je vec teeeeeeeeeeski raritet a kod usb adaptera kontrola direktna pinova u vremenu ne postoji, tako da moras da razmisljas o USB->485 a ne nikako RS232->485 ... imas za atmel onaj open usb cdc firmware koji mozes da iskorists .. ili mozes da uzmes neki od ovih novih USB enabled atmel kontrolera .. ima ih nekoliko i skroz su iskusni pa vezes RS485 direkt na njega

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Eto samo kratko jer nemam trenutno baš vremena pisati i čitati ove postove u detalje.

1:kecmanove primjedbe i sugestije su uglavnom OK ali ako čovek oče da ovo riješi poznavajući donekle RS232, RS485 komunikaciju ajde da mu pomognemo tako
2:koristi FTDI232 (ima pin za smjer 485 komunikacije) odnosno USB/RS485 ono s RTS neće ići
3:ako nemaš pretjeranu komunikaciju (količinu transfera podataka) stvar će raditi OK s druge strane ako puno toga i ćesto šalješ neće
4:koristi standardni UART 8n1 tako da poruku "tekstualnog" (hexadecimalnog) oblika uokviriš u STX i ETX karaktere a na početak poruke stavi adresu slave uređaja (1.karakter) po potrebi iza etx neki čeksum

Ako ti ovo pomaže OK i možeš pitati dalje al sad trenutno ne mogu bolje objasniti (valjda sutra stignem ako će trebati)

Potpis

www.micromatic.hr

Hvala Kecmanu i Micromaticu

nadam se da će imati strpljenja u eventualnoj daljoj komunikaciji, a i drugi su dobrodošli.

Verovatno nisam bio dovoljno precizan pa da pokušam da pojasnim

1. Što se tiče RTS pina pomoću njega želim da kontrolišem smer komunikacije samo rs232-rs485 konvertora. Znači računar šalje podatke ka slave procesorima i samo tada planiram da iskoristim RTS liniju (logička jedinica dok se šalje bajt) da aktiviram predaju kod rs232-rs485 konvertora. Neznam zašto ovo nebi išlo a sutra planiram da probam pa ću videti.

2.Nemam obilnu komunikaciju. Slave procesori broje neke impulse, a računar ih redom proziva i oni trebaju da mu pošalju ono što su izbrojali.

3.Interesuje me kako je Micromatic rešio problem sa nepotrebnim osluškivanjem komunikacije na BUS-u od strane slave procesora obzirom na njegov predlog
.

Smer komunikacije slave procesora lako kontrolišem-jedan pin procesora.

Hvala na vremenu.

Izgleda da ces morati jos malko da razmislis o nacinu funkcionisanja MAX485/SN75176 cipova. Naime, u stanju "prijema" svi tvoji slejvovi "osluskuju" sta sa desava na komunikacionoj parici, transmiteri su u stanju HiZ. Odgovorice samo "prozvani" uredjaj, odnosno onaj cija se adresa poklapa sa adresom koju si poslao u "paketu" sa racunara.

Jedan banalan primer,

PC inicira slanje:
<STX>
AdresaSlejva
KomandaSlejvu
<ETX>

Svi slejvovi "osluskuju"

Slejv cija je adresa == AdresaSlejva cita koju je komandu dobio (KomandaSlejvu)
i posle kratke pauze (kada PC predje u rezim prijema) ukljuci svoj transmiter i posalje sta je od njega trazeno, posle toga se odmah vraca u stanje prijema.

Slejvovi cije su adrese != Adresa slejva jednostavno ignorisu sav saobracaj na magistrali

Na slican nacin funkcionise i DMX-512 protokol, samo sto je tu komunikacija jednosmerna PC -> slejvovi

Evo još pojašnjenja:

1. Problematika korištenja RTS linije - imao sam par pokušaja rješavanja RS232/RS485 korištenjem RTS linije za definiranje smjera komunikacije ali su svi bili pomalo problematični. Kako sam odustao od tih rješenja probati ću se sjetiti što nije bilo dobro (isprika ako mi se potkrade nekakva greška)
→Korištenjem " Hardware flow control " imao sam problem s smjerom na zadnjem bajtu poruke jer se RTS ugasio prije odašiljanja kompletnog zadnjeg bajta.
→Programskom kontrolom RTS linije kroz MSComm kontrolu iz Visual basica promjene na RTS liniji bile su nesinkronizirane s slanjem (TX pin) pa je trebalo ubacivati relativno duge pauze (promjena RTS; PAUZA; Slanje poruke; PAUZA; promjena RTS) što je grozno usporilo komunikaciju.
•Najbolje riješenje RS232/RS485 adaptera je korištenje invertiranog TX-a na D/RE pinu (TX linija s 232 porta prije MAX-a spojena preko 10k na D/RE pin 485 konvertera i zenerica od 5V1 na D/RE pinu)

3. problem sa nepotrebnim osluškivanjem komunikacije na BUS-u od strane slave procesora nije moguće riješiti odnosno svi slejvovi stalno osluškuju komunikaciju. Kako to ne bi pretjerano opterećivalo kontroler svakako koristi hardverski UART kontrolera i u interapt rutini prijema bajta prvo zanemariš sve do prijema STX karaktera (start poruke), slijedeći primljeni bajt je adresa i njega usporediš s adresom slejva pa ako nije isti zanemariš sve ostalo do slijedećeg STX a ako je isti obradiš komandu mastera u sljedečem bajtu (ako ti je komanda potrebna ili jednostavno još sačekaš ETX i nakon njega uz kratku pauzu odgovoriš masteru) .

2. Komunikacija i zašto hexadecimalno (dva bajta umjesto jednog)
- pretpostavimo da su tvoji brojači 8 bitni pa je vrijednost koju trebaš poslati masteru bajt koji može biti 0x00 do 0xFF (0 do 255)
- šaljemo li masteru vrijednost brojača bez konverzije u hexadecimalno moglo bi se desiti da mu pošaljemo 0x02 ili 0x03 što su ustvari STX odnosno ETX karakteri koje koristimo kao limitere poruke (označavaju početak i kraj poruke) te bi to unjelo zbrku na komunikacijskom busu
- druga prednost ove konverzije je što su ovakve poruke čitljive i u običnom hyper terminalu
REZIME:
Master traži vrijednost brojača slejva s adresom "a"
1 2 3 4 ; bajt poruke mastera
<STX>aR<ETX> ;ASCII > R=komanda čitaj
02 61 52 03 ;HEXA


Slave s adresom "a" javlja masteru da je vrijednost njegovog brojača 3

1 2 3 4 5 ; bajt poruke slejva
<STX>a03<ETX> ;ASCII
02 61 30 33 03 ;HEXA


Nadam se da sam pomogao.

Potpis

www.micromatic.hr

Mala dopuna: kada slave primi STX startuj timer pa ukoliko ne dobiješ ETX posle određenog vremena očisti prijemni buffer.
A da, može i ethernet! :)

Potpis

gorankg

Može i tako mada mislim da je nepotrebno kompliciranje s timerom. Ja STX i adresu ne stavljam u buffer već to radim na slijedeći način:

;prijemni buffer "InBuff" je dug koliko je maksimalna poruka s mastera
;"InCnt" bajt govori na koju poziciju se upisuje primljeni bajt poruke

kad se primi STX InCnt se postavi na početak InBuff i setiram fleg "AdByte" koji govori da je sljedeći bajt adresa
prvi sljedeći primljeni bajt usporedim s svojom adresom, obrišem "AdByte" , i setiram fleg "ForMe" koji govori da je poruka za mene ako je moja adresa
ako je setirani fleg "ForMe" svaki sljedeći primljeni bajt upišem u InBuff na poziciju InCnt i InCnt povećam za 1. ako on nije veći od zadnje pozicije u InBuff-u a ako je veći resetiram ForMe Tako je sve predugo zanemareno jer ionako nije dobro.
Primljeni ETX uz setirani "ForMe" pokreće obradu primljene poruke (doduše ja još imam dodan čeksum koji se provjerava prije obrade poruke ali da sad ne kompliciram s njim)

Potpis

www.micromatic.hr

samo da dodam za RTS i ostale "flow control" linije na usartu na strani kompa .. ako imas neki prastari komp sa pravim usart cipom onda mozes da kontrolises sve pinove vrlo kvalitetno ali na novijim masinama cak i ako imas seriski port (a u 99% slucajeva nemas) on ne ide preko standardnog usarta koji je okacen na magistralu i adresira se direktno, vec imas neki usart kontroler na nekoj od sporednih magistrala tako da nemas direkt kontrolu nad reigstrima usart kontrolera nego ga kontrolises preko os drajvera a tu ti je garantovano samo da ce nesto otici tom brzinom i da ce ispostovati flow koji se postavio - bit banging status/kontrol pinova je nemoguc (tj moz ti da ih bangujes ali timing nema teorije da ispostujes)... ista prica je i sa usb->rs232 adapterima koji rade na vise manje isti nacin... zato svi oni programatori za ovo i ono koji su isli na seriski port ne da rade na novim masinama i ne da rade sa usb->rs232 adapterima

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/